Android Jetpack Compose Is Welcome, But What About The Churn?
Written by Nikos Vaggalis   
Wednesday, 09 September 2020

The ever-changing landscape of development on the Android platform gets an update with the new Jetpack Compose UI toolkit.

I think it's important to know where to draw the line between evolution and stability. On one hand innovation and bringing new ideas and features to a framework are necessary and welcome. On the other hand if you constantly and totally substitute
the ways you do things rather than improve them, you force everyone to work just in order to just keep up.

The Android platform is one such case - breaking backwards compatibility every step of the way. First there was Java, now there's Kotlin. Saying that, it's not just the introduction of Kotlin that has changed the face of development, but the whole revamping of the platform, the libraries and the way of building apps.

Admittedly, developing for the platform has never been an easy task to undertake. Memory leaks, notorious fragment handling and asynchronous programming, transactional exceptions, orientation changes,Listeners everywhere, fragmentation of version releases, confusion regarding the correct versions of libraries etc have rendered the effective building of apps a difficult proposition.

The answer to these problems was Android Architecture Components. For instance before Components were introduced there was overuse of specific patterns and practices. Take the most popular one, the Loaders. Most code was literally "littered" with calling Loaders and LoaderManagers in order to access the database on a separate thread, to cache the data fetched, to survive configuration changes and to refresh the UI when the Activity's events took place. A large percentage of coding effort was in those kind of tasks which Components came about to replace.

But the introduction of the Architecture Components also altered considerably the ways you do things. You had to forget what you'd learned and start from scratch. It's like a new technology has totally superseded its predecessor with a degree of churn and rate of change we have repeatedly commented on with new releases of Android studio,another part of the ecosystem in constant evolution.

Mike James, set the matter under perspective in "Android Development - Constant Churn" :

Developing on Android feels increasingly like taking aim at a target that moves every time you think you have it in your sights.

This is all part of the constant revolution that the Android Dev platform seems to be. Just as you think you know what best practices are, they change and you have an app whose code is outmoded, if not actually deprecated, and so you have to work on it. Even things that are generally good, like Kotlin, are causing us to have to rework large parts of our code to take advantage of them.

The Android team seems to be unaware of all of the tutorials and programming help they are invalidating by their constant changes.

Churn is not good.

Then we had Jetpack which encompassed all of the Architecture Components, and today we have the new Jetpack Compose UI toolkit under which you write dramatically less UI code in declarative fashion.

The Alpha version of Jetpack Compose just released, includes:

  • Animations
  • Constraint Layout
  • Initial A11Y support
  • Input and Gestures
  • Interoperability with Views (start mixing Composable functions in your existing app)
  • Lazy Lists
  • Material UI components
  • Performance optimizations
  • Testing
  • Text and editable Text
  • Theming and Graphics
  • Window management

It also promises backward compatibility with the "old" view-based UI code bases:

compose elements into your existing UI, either by creating an entirely new Compose-based screen, or by adding Compose elements into an existing fragment or view layout.

or

add view-based UI element into your composable functions. Doing so lets you add non-Compose widgets, such as MapView or WebView, into a Compose-based design.

the real deal is the "Migrating to Compose depends on you and your team", emphasis on "Migrating" which implies a really big paradigm shift - a starting over. When can we simply "keep up" with improvements and not  "migrate" is the question.

The other question is, is it Kotlin only? Browsing through the official documentation confirms the case :

If you want to start a new project that includes support for Jetpack Compose by default, Android Studio includes new project templates to help you get started. To create a new project that include Jetpack Compose, proceed as follows:

Note that, in the Language drop-down menu, Kotlin is the only available option because Jetpack Compose works only with classes written in Kotlin.

So it's like saying:

 "Dear Java developers, your time is up.You have to go Kotlin from now on to take advantage of all the new goodies".

Thanks for the supposed Java-Kotlin interoperability. On top of that you've got to, sooner or later, learn a new programming language too.

With that said, I believe that it's too difficult to keep with the radical changes, and I think that I do not just speak for myself. I'm not a professional Android developer, although I've had my fair share of coding on the platform as part of taking and graduating from the Udacity Android Developer Nanodegree Program. Not being a professional Android developer, I simply lack the motivation to re-learn the platform once again.

As Mike James puts it "I can sum up today's Android environment very simply - too much churn and too much uncertainty".

 

 

More Information

Related Articles

Android Development - Constant Churn

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook or Linkedin.

Banner


Cockroach Creates Pebble
28/09/2020

Cockroach Labs has introduced Pebble, which is described as a RocksDB inspired and RocksDB compatible key-value store. Until now, CockroachDB has used RocksDB as its key-value store, but Pebble provid [ ... ]



GitPod Adds Native GitLab Integration
15/10/2020

Users of GitLab can now make use of the Gitpod UI. GitLab is a popular DevOps tool that is used by more than 100,000 organizations. A partnership between GitLab and Gitpod means developers can make us [ ... ]


More News

square

 



 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Wednesday, 09 September 2020 )