The Android platform
Since the beginning, I liked switching to the new platform and learning new things about activities, asynchronous programming, push notifications and concurrency. Then, Honeycomb arrived with fragments; and then, Ice Cream Sandwich with Holo. People where having a lot of fun writing code for small apps.
As applications grew, devs started to think about cleaner code, better architectures, better tools and testing. They realized that those huge activity classes would backfire one day and they reused classic programming patterns and came up with new ones. Everybody started talking about MVP, MVVM, hexagonal architecture and open source libraries where thriving. I was excited reading all those posts by fellow programmers, and watching those great talks.
The Android platform was designed to be very versatile. Actually, I think that’s its greatest quality and that’s why it works on so many phones, tablets, TVs, watches, cars and things. It was thought to be scalable, always being aware of hardware constraints like CPU speed, memory and battery. Android’s layered architecture allows separating concerns for different technologies and teams working on them. Thanks to this, for example, Google was able to seamlessly switch to OpenJDK in Android Nougat:
Something feels wrong
I think Android is a great platform, but I also think that some APIs available to developers in the framework layer (the green one in the previous image) really should be redesigned.
Activities are arguably the most important component in Android, and along with fragments, they are hard to grasp and to be used correctly — and Google knows it. Their lifecycle is intricate, and this only adds complexity and confusion to the developer: