|Android Studio 4 & Jetpack Compose - More Churn|
|Written by Mike James|
|Wednesday, 20 November 2019|
We don't normally talk about Alpha releases, but this one is important because it gives the direction that Android development is being pushed in. The shock is that it deprecates much of what we've learnt already and introduces yet another approach.
There is no doubt that the future of Android development is Kotlin, but the recent announcement that Jetpack Compose will only work with Kotlin comes as something of a shock. In fact, the idea that Android UI development could be changed to something new, irrespective of the language choice, is a shock.
Consider the work and effort that has been put into Android Studio to make UI development easy and efficient. The creation of the UI designer was a big step forward in making it possible for beginners to get involved in Android development. It also made quick prototypes much easier to create. I know that many Android pros claim not to use the UI designer, but to build the UI in raw XML - well we can all choose the hard way if we want to.
The Android Studio team has overhauled the UI designer and the way the UI is implemented relentlessly, and this in itself is a cause for concern. The level of churn is unacceptable. It renders what you have worked hard to learn irrelevant. It renders so much documentation, tutorials, online courses and so on to out of date material. Where can you find a definitive "this is how you do it" if the game keeps changing so rapidly?
Yes I know - the mantra is to move fast and break things but also maintain backwards compatibility and the invested knowledge of your devoted developers. However, this isn't agile, it's a scramble.
With the introduction of the constraint layout, its incorporation as the default layout in the UI designer, and the moving of the relative layout to the "legacy" bin in recent release, I had hoped that we might be moving into an era of stability with Android Studio 4 - but no. Top of the list of new feature is Jetpack Compose, a whole new way of building the Android UI!
Can you believe it? It might be that Compose is better, it is too early to say, but the idea that an Android development team can simply replace everything that has gone before suggests a lack of leadership. We have seen this before in the mad panic to keep up with Java and the poorly thought out idea of the Jack and Jill compilers. It could be the adoption of the constraint layout and other capricious changes are also evidence that there is no strong overall direction.
Android Studio 4 overly complex and by gaining new layers it is not getting simpler, despite the propaganda. Take a look at the video "selling" us Compose. The most important thing to note is that the comparison between the almost declarative Compose code and the totally declarative XML is that the Compose team is not using the designer!! What sort of communication is going on here when one team developing a new approach to the UI doesn't seem to know the alternatives? There are lots of other examples of the playing field being un-leveled by the choice of the competing approach.
The idea of moving from a full UI designer to a preview facility that, at the moment, obscures a chunk of the code you are working with, is crazy and entirely undesirable.
OK what about Android Studio 4 ignoring the churn of Compose? First it is difficult to ignore Compose because support for it in 4 is given star billing. Apart from it there are lots of small improvements, but nothing major or important. Android Studio is still a resource hog and it runs slow. We do get more support for Java 8 - but wait I thought the future was Kotlin? We also have an updated live layout inspector and improvements in the designer and the animation editor in particular. The animation editor lets you do interactive animation design and it will create the XML for you.
There is also a new Fragment wizard, which is supposed to make fragments easier to use. Personally I think fragments were the worst idea ever to be introduced to the Android framework and anything that makes them easier to use is welcome. There is also a gallery of fragment templates, making it easier to add standard fragments to your UI. A change that I'm not sure is good is that the basic App template now come with two fragments as standard - this is enough to frighten any beginner as the way they work is far from obvious. I hope this change gets rolled back before the final version, but given my deductions about the way Android Studio development proceeds I doubt it.
My other complaints include the fact that Android Studio lacks an easy way to introduce custom widgets or even standard widgets into the designer's palette. The templating system isn't documented. The whole system of fragments and constraint layouts is overly complex and fragile.
Yes, we need some things to put Android development right, but not through a starting over that throws everything we have away. And you might say, "OK, you don't have to use it" but the way it is being sold the pressure to use it will grow and programmers don't always get to make logical choices. Compose is the new way and the new way is usually assumed to be the only, or at least the main, way to go..
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 20 November 2019 )|