I love being a developer, I love writing apps and I love writing good quality code. I call myself a software crafter as I believe in our manifesto that reminds me to write well-crafted code and behave professionally.
A few days ago Google published the source code for the Google I/O app. Since the early days of Android, this has been the showcase for what is state of the art developing an Android app. With what we’ve seen in the last two years, Google giving hints and tools for how to architecture an app, many of us were curious about the code.
But soon, developers posted about huge methods and classes in there. To be honest it’s not as bad as it used to be but it’s not the reference source base it should be. The problem, developer from all over the world will look at this code, they will copy it. It was always like that. This code should be a role model, an ideal example. It is not. Especially sad for a rewrite as stated in the Android blog.
There is more to it
Not only are samples sloppy, the tools and documentation start to favor unprofessional habits. A while ago I posted this tweet:
Reading https://developer.android.com/guide/app-bundle/build … sounds like building releases or even deploying should be done from @androidstudio It is the other way around! If more than a pet project NEVER build releases locally! Be professional! Gradle first! Ci first! AS last! @AndroidDev be professional!
My intention with this was not to accuse Googlers of being unprofessional. What I wanted to ask for was to discourage cowboy development and make real world professional development a first-class citizen.
In the beginning
In the past Android sample code was focused on the usage of Android APIs. The snippets didn’t bother about architectural questions nor if it’s clean code. And that’s fine. But developers had no other code to learn from an started copying sample code. The thought behind: This is how “Google” says you have to use this.
Things changed
Fortunately, things got better. Googlers became more aware of the unintended mess they created. We got testing support, architectural guidelines, architecture blueprints, architecture components.
When I discovered that “app bundles” can now be created via Android Studio and the documentation favours this method over releasing via gradle by placing it first which resulted in my often misinterpreted tweet.
It reminded me of Google I/O where it was announced that you can now publish from Android Studio right into the PlayStore. That feature, I remember, made me really angry. In my opinion it’s a very useless feature, even more, I consider it dangerous. It is encouraging cowboy development.
Whats wrong?
Publishing from your IDE does not guarantee reproducibility. Is this project checked in into version control? Is everything that is being sent committed? What branch are we on?
How do you know what you are sending actually works? Maybe you tested it on your device but did you check there is no serious lint warning telling you this will crash on older android version? Did you run your unit test suite to make sure all the old features still work?
“Works on my machine” issues are something that should never be the case for a release.
Mobile is serious business nowadays, apps are serious software projects. For most companies, it’s their core business! Often developers still don’t treat them like this. Testing, architecture, clean code took a long time till they made it to Android. The knowledge from Java backend developers didn’t make it over although both spoke the same language by then.
It can even be seen in Android itself:
The Android source
If you ever peaked in into the Android open source code (AOSP), you know: It’s a huge mess. It’s such a large and hard to maintainable mess that maybe the only way out is a new platform with a new API called Flutter.
As I said in the beginning, I don’t think that the developers at Google are unprofessional but they sometimes encourage (unintended) unprofessional development.
Android Studio
Does Android Studio or the development documentation help us here? Not much to be honest.
Most developers I know, spend the first minutes removing all the boilerplate that the “new project wizard” created.
Or think about the UI tools like the SVG import of Android Studio. How do you import dozens of SVGs? Manual, one by one! Why is there no batch tool? In most companies, there is a process for designers to deliver specs and assets. Designers don’t work inside Android Studio. So is our IDE aiming for the hobbyist only?
Let’s talk about tests! It feels like the developers working on Android Studio hardly run tests from there. How often do we see: “no tests found” issue after clicking the icon next to some test. Lately, thanks to caching code, tests won’t run at all or wrong code runs. Running tests in Android Studio became like gambling: the outcome is unpredictable. Something like test-driven development becomes very hard with such a setup.
Speaking about caching: “Invalidate caches and restart” is the most used option developers seem to use nowadays. That there is a menu entry for that says a lot!
I’ve never hated an IDE and I’ve used most of them, from JBuilder, Eclipse and even the horrible Java IDE for Blackberry development. But I do hate Android Studio! Especially as using IntelliJ for Java projects is like wellness and Android Studio is just a fork. It’s unbelievable how big the difference is especially when it comes to performance.
The broken chain
Android Studio became the biggest pain point in daily Android development for many of us. After a broken platform, we now have broken tools.
Stabilising our tools should be more important than adding some nice to have options. Or as one developer said to me: “at least finish them for once!”. InstantRun anyone? It feels like Android Studio is facing some serious feature creep.
While writing this article Android Studio 3.1 is still the stable version to go with. It has been for a long time. That sounds wrong. We need smaller, quicker releases. Like the ones, we aim for in our mobile apps. Release once or twice a year that proved wrong in the past decades and is the opposite of agile development.
You might say, there are canary builds. But we don’t develop for fun, this is our work. We want less pain, not more. For the canary builds, version jumps in AS often means version jumps in your tools and project so it’s not easy to go back.
As another developer once said in a discussion about tooling: “give me a sharp knife”!
What do we need?
Focus on the small and mid-size teams and apps!
Don’t focus on the hobbyist. Flutter made the entry level for starters so low that it this battle is already lost.
Don’t focus on large organizations: At some point Android Studio doesn’t scale, very large teams like Uber or Facebook can’t use it. That is fine. You can’t cover all possible cases.
To the developers of the Android teams:
- Be aware of the role model you are as a developer and the responsibility you got with that.
-
Focus on clean code! Just look at the I/O app: There might be some basic architecture now but the code itself is far from clean. Same goes for AOSP including architecture components.
- Give us tools we can work with! Give us sharp knives! Something that can do few things but those really well.
https://shop.deadzebra.com/feature-creep-kills-print/
- (not another Dagger rant)