Assisting for the first time to an Android conference
Introduction
I want to start by saying that this was my first time attending an Android conference in person. I had always followed them online, watching the recorded sessions. So, for this article, I would like to focus more on my personal experience and impressions, rather than diving deep into the technical details.
I would like to highlight the variety of events available over the two days. These activities made the conference feel more dynamic and fun, offering plenty of opportunities to interact with others. Some of these included stamp collecting, a nail art session, a Japanese festival (Matsuri), an after-party featuring a マグロ解体ショー (tuna carving show), and various themed chat spots for mingling.
Listing and briefly explaining every presentation I attended would make this article too long. Instead, I’ve decided to pick up the ones I found most interesting, offering my impressions and highlighting any technical aspects that could be applied to our work at Eureka.
09/11
Learning Large-Screen Support from the Ground Up — Development Insights from a “Large screen differentiated”-Certified App-
As seen in the recent behavior change for apps targeting Android 16 or higher, displays with a width of 600dp or more will ignore orientation, resizability, and aspect ratio restrictions. This clearly shows Google is pushing developers to support large screens, turning what was once a ‘nice-to-have’ into a ‘must-have’ feature.
With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today’s multidevice world.
https://developer.android.com/about/versions/16/behavior-changes-16#adaptive-layouts
It’s important to note that Google doesn’t require a premium large-screen experience from the start. Instead, they offer three tiers of support allowing us to choose the level that best fits our use cases, development schedule, and business goals:
- Tier 3 (basic) — large screen ready
Users can complete critical task flows but with a less than optimal user experience. Your app runs full screen (or full window in multi-window mode), but app layout might not be ideal. The app is not letterboxed; it does not run in compatibility mode. The app provides basic support for external input devices, including keyboard, mouse, trackpad, and stylus.
- Tier 2 (better) — large screen optimized
Your app implements layout optimizations for all screen sizes and device configurations along with enhanced support for external input devices.
- Tier 1 (best) — large screen differentiated
Your app provides a user experience designed for tablets, foldables, and ChromeOS devices. Where applicable, the app supports multitasking, foldable postures, drag and drop, and stylus input.
The presentation also mentioned that reaching Tier 2 or 1 means the app is nearly ready for Android XR, qualifying as an “Android XR compatible large screen app”.
The speaker recommended that if an app is still primarily View-based, or only partially uses Compose, migrating fully to Compose is the best path forward. This is because Compose simplifies the logic for adapting layouts based on screen and window size. Jetpack Compose Navigation 3 also facilitates the implementation of large-screen layouts.
Below is the recommended phased approach by the speaker:
Step 1: TIER 3 support — possible with View base
- run app in full screen
- handle configuration changes properly
- add scroll support and max width constraints
Step 2: optimize for large screens targeting TIER 2+
- flexible layout support
- keyboard and mouse support
At Eureka, we haven’t officially committed to first experience large-screen support, though we’ve always aimed to provide an experience close to what would be considered Tier 1. I believe now is an excellent time to discuss our current strategy with the Android team and, if necessary, rethink our direction for the near future.
Beyond Exceptions: Building Resilient Android Apps with Safety-Critical Principles
The session’s main argument is to avoid using exceptions to represent errors in domain logic. Relying on exceptions for this purpose is problematic because it requires developers to understand the internal implementation details to handle all possible cases exhaustively.
The presentation also critiqued the use of Kotlin’s built-in Result type, pointing out several drawbacks:
- It leads to the unnecessary creation of exception classes.
- It does not allow for exhaustive, compile-time checking of all possible error outcomes.
- The
Result.runCatchingfunction inadvertently catchesCancellationException, which can interfere with the intended behavior of Kotlin Coroutines.
It was noted that even the official Kotlin team advises against using the Result type for handling domain-specific errors, as stated in their KEEP proposal.
For more appropriate error representation, the speaker recommended two primary approaches:
- Using
nullfor simple, lightweight error cases. - Defining custom classes with a
sealed interfacefor more detailed and robust error modeling.
Looking to the future, the talk mentioned a potential new language feature called “Rich Errors” planned for Kotlin 2.4.
As a personal experience, I have been struggling with this topic in our application for some time. Recently, I have been digging into this and came up with a similar conclusion about avoiding exceptions and instead defining custom classes with a sealed interface for errors representing domain logic. However, as mentioned in the presentation, you need to write some extra code, so I am quite happy that the Rich Errors feature will be released.
After Party
After the day’s presentations, there was an after-party featuring a “Maguro Kaitai Show” (a live tuna carving demonstration). The room was set up with standing tables for 7–8 people, creating a dynamic and casual atmosphere for eating, drinking, and talking.
Since it was my first time at the conference and I didn’t know anyone, it was a bit challenging to join a group at first. However, I eventually introduced myself to a table of strangers and started socializing.
Overall, it was a great experience where I got to meet different people and share our experiences as Android engineers.
09/12
The Complete Guide to Android Value Passing: Control Your Architecture, Control Your “Passing”!
I will not go into detail about the content of this session, but I wanted to mention it because it was one of the best I attended during the conference. The clarity of the explanations, the use of examples, the presentation flow, and the overall dynamic were outstanding. I recommend watching this presentation not just for its technical content, but also as a great example of how to deliver an effective talk.
Cache Me If You Can
This presentation is great for anyone like me who wants to dig deeper into Gradle and understand how it works behind the scenes.
It provides a grasp of the Gradle and AGP lifecycles, explaining what happens in each phase and how to use their APIs and extensions. It also explains the typical bottlenecks in each phase and offers API usage strategies that respect the lifecycle.
Furthermore, the presentation gives us mechanisms and best practices to speed up builds with different kinds of caching systems, like the Gradle Build Cache and Configuration Cache. It also presents common anti-patterns that disable these caches and how to avoid them.
I think the timing was perfect for me to attend this presentation, since I am currently working on our application’s Gradle configuration and also trying to enable the configuration cache. Its contents will be very helpful for my current work.
Themed Meetups
During lunch on the second day, I joined a themed meetup called Parenting and Work.
It was a very enriching experience, hearing firsthand how families with children balance their careers with parenting. Most attendees worked fully remotely or relied on grandparents for help during work hours.
We also discussed topics like the pros and cons of different housing types, such as apartments (mansion) versus detached houses.
Final Impressions
Attending my first in-person Android conference was a completely different experience from watching recorded sessions online. The biggest takeaway for me wasn’t just the technical knowledge, but the strong sense of community. The themed meetups, casual conversations at the after-party, and the dynamic social events created an environment where it was easy to connect with other developers, share challenges, and learn from their experiences. This personal interaction is something you simply can’t get from a recorded video.
I’m returning to work not only with new technical insights to discuss with the team at Eureka but also with a renewed sense of motivation and a broader perspective on the global Android community.
It was a valuable experience that I would highly recommend.
元の記事を確認する
