jetc.dev Newsletter Issue #108

Published: 2022-03-22

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 View system.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

How Do We Detect Clicks Within an Image?

Detecting clicks on an image is simple. Detecting where clicks are within an image requires pointerInput(), as we see in this week’s highlighted Stack Overflow question.

How Do We Initialize a ViewModel From a Composable?

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.

Composable Commentary

Posts, videos, and other new information related to Jetpack Compose!

Medium: Exploring MovableContentOf in 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.

Dagger/Hilt vs Koin for Jetpack Compose Apps

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!

Keyboard handling in Jetpack Compose

Thomas Künneth is back, looking at keyboard-related concerns, including panning the UI to avoid the soft keyboard, managing focus, hiding and showing the keyboard, and more!

Testing an Authentication Form with Jetpack Compose

Joe Birch continues his Compose UI authentication example. Previously, Joe built the form — here, Joe tests that form to confirm that it all works as expected, using createComposeRule() as the foundation.

Video: From XML to Compose, transforming a large app to Jetpack Compose

Ahmed Tikiwa delivered a presentation for Conf42 covering how to migrate from the legacy 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 View-to-Compose migration: bottom sheets.

The Making of Jetpack Compose Form Builder Library

Two weeks ago, I pointed out a form-builder library for helping you manage a set of field in a form. In this post, Linus Muema talks more about the creation of this library and how to use it.

Medium: Jetpack Compose: Custom Google Map Marker

Erselan Khan looks at the Marker() composable supplied by the Maps Compose library, and how you can use its icon property to customize its look.

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

Resource Roundup

100% pure code!

GitHub: akshay2211 / DrawBox

Akshay Sharma brings us another drawing composable! Using DrawBox() and rememberDrawController(), you can add a free-form drawing area to your UI, with customizable stroke colors and widths.

GitHub: hi-manshu / Kalendar

Himanshu Singh offers a calendar composable… or, more accurately, a Kalendar() composable. It comes complete with week and month views, highlighting for scheduled events, custom colors, and more!

GitHub: suzdaleva/ComposeSwipeableCards

Koval Anastasiya is back, this time with another take on the “swipe away the top card of a stack” UI popularized by Tinder.

GitHub: joaopegoraro / ComposePdfViewer

João Pegoraro created a composable wrapper around the framework’s PdfRenderer and turned it into a PdfViewer() for rendering PDF documents in your Compose UI.

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:

• Use the 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 with 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.