jetc.dev Newsletter Issue #108
This week, we look at
movableContentOf() and dependency inversion options.
We peek at migrating from legacy
Views to Compose UI and testing our composables.
We explore more free-form drawing composables, more calendar composables, and more
Tinder-like swiping composables. Plus, I prattle on about whether newcomers
to Android should jump straight to Compose and avoid the legacy
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
When do we call functions on our Hilt
ViewModel to tell it what data to work
with, such as some identifier of a model object. We explore a few possibilities
in this week’s highlighted Kotlinlang
#compose Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
sinasamaki examines what
moveableContentOf() does for us, in terms of helping to
avoid unnecessary recompositions. In a nutshell, we
can define a set of composables once and apply them in different scenarios within
another composable — one example is toggling a list of composables between
row and column representations, without recomposing that list.
Everybody loves a good DI framework fight, so Patryk Kosieradzki compares Dagger with Hilt against Koin in terms of how well you can use them in a Compose UI app. In the end, Hilt and Koin hug it out, but reviewing Patryk’s pros and cons is worth the read!
Joe Birch continues his Compose UI authentication example.
Joe built the form — here, Joe tests that form to confirm that it all
works as expected, using
createComposeRule() as the foundation.
Ahmed Tikiwa delivered a presentation for Conf42 covering how to migrate from
View system to Compose UI, including dealing with interoperability concerns
and a deep dive into the actual migration of a search screen. See also
Ahmed’s Medium post
focusing on one specific aspect of that
migration: bottom sheets.
Other Interesting Links
- Medium: Jetpack Compose: Concepts, principles and construction of an architecture in a multi module project. Part 2: Best Practices and Anti-Pattern
- Medium: Animated Splash Screen with JetpackCompose
- Medium: Handling back press for modals on Android Compose
- Convert RecycleView to LazyColumn
- Medium: 10 Jetpack Compose Projects To Inspire You
- Jetpack Compose — Expandable Card
100% pure code!
Other Interesting Links
- GitHub: mohsenoid / SvgToCompose (convert SVG paths to Compose canvas calls)
- GitHub: saket / swipe (swipe, not to dismiss!)
- GitHub: slaviboy / JetpackComposePercentageUnits (express sizes as percentages of “device size”)
…And One More Thing
In a Twitter thread on whether you should learn Compose UI or the classic
View system first, Google’s Jim Sproch wrote:
For beginners, I’d suggest learning Compose first, for a couple reasons: (1) easier to learn (2) skate to where the puck is going, not where it has been (3) you’ll never compete with devs with decade+ of XML/View experience, but can easily become your company’s top Compose expert
You can pick up XML along the way as needed. You’ll encounter XML eventually and can always learn it at that time, but I don’t see a compelling reason to start with the old/hard thing.
Twitter sucks for nuance, and perhaps Jim would answer differently in a long format. And I agree with the super-high-level perspective: Compose UI is likely to become dominant in the coming years.
However, I feel that Jim’s recommendation has its limitations, particularly for
people looking to get a job as a professional Android app developer in the next
few years. By 2025, it may be reasonable to get a job with a pure-Compose, no-legacy
education. However, right now, it is 2022, and IMHO it will be very difficult to get a
job now without broader experience, including with the existing
View-based UI system.
Simply put, right now, the vast majority of commercial app development projects:
View-based UI system for most, if not all, of the app functionality
Have small teams, such that even if there is a chunk of functionality that has been migrated to Compose UI, the team cannot support a developer who can only work on that code and cannot contribute on the rest
If your mindset is “I’ll learn the new stuff and be happy waiting for the right
Android opportunity”, great! Do what Jim suggests and start with Compose UI and incrementally add on experience
View-based UIs in time. And perhaps Jim’s argument is that by the time you
gain enough experience to get an Android development role, pure-Compose experience will be
more amenable to potential employers.
I am not arguing about the future of Compose UI. At the same time, I want to manage expectations: Compose UI is still a niche technology. It is a rapidly growing niche, one that may “eat the world” in short order. Just take that into account when you start making decisions about what to learn and when you might be able to get a job based upon it.
- 2022-09-13: Compose updates! Tracking down and fixing recompositions! Maestro! Redwood! Molecule! And Twitter's rules for composables!
- 2022-09-06: Snapshots! A Glance support library! Measuring and drawing! Swipe-to-dismiss! Speed dials! And... a redwood sighting?!?
- 2022-08-30: Android 13 per-app language support! Performance optimizations! Expandable lists! MVI! Zooming! Steppers! And... another Compose beta? Already?!?