Google IO, Android Jetpack and Architecture components

This past week Google did their annual developers conference. I rarely watch the main keynote because I’m not that interested in their products but nonetheless I always keep an eye on what other platforms are doing, there is so much to learn from others. This year they announced Android Jetpack and more Architecture components, I think is good for the Apple community to take a look at how Google is treating their developers and learn from it.

Android Jetpack is nothing more than a marketing name for a bundle of libraries that already existed. But the impact of having a first party solution separated from the platform SDK goes beyond marketing.

Taking a quick look at the list of libraries in Jetpack we can see that the different libraries seem to have different value and reason for existing, at least from the point of view of an iOS developer.

Some of the libraries provide solutions to problems that are intrinsic to the Android SDK (Lifecycles 👋); others are a modern take on things that we already had on Apple platform for years (Room, a SQLite wrapper); but they also provide high level common functionality (Paging) and directly recommended architectural solutions (Data Biding and ViewModels, Navigation).

One interesting thought that I had looking at the reaction of the Android community is about how the Apple community would react to Apple announcing something like this. One would expect everyone to be grateful but I have my suspicions that a lot of the feedback would be like “too late we already have solutions for this”. Because of that reason I can’t really blame Apple for not even thinking in providing things like this, I hope I’m wrong.

Architecture guidance

Apple solution has always been: use MVC. And that’s great for small Apps, but we all know that MVC doesn’t have all the answers. Is not that it’s the wrong architecture, it’s just that it doesn’t specify a lot of things that are needed when software starts to grow. That’s why the a lot of projects endup with massive view controllers. MVC is not to blame for that, but it would be nice to have some recommendations from Apple and official support in the SDK to avoid it.

Google guidance is more direct, they directly champion for an MVVM solution that integrates well in the system and they even have their own FRP version with Bindings. macOS has had a version of bindings for years now but we’ve never seen official support on iOS.

Seeing Apple at least recognising that Rx is a thing that exist in the world would be great. I’m not asking for them to be involved with every new thing that pops up, but ViewModel and reactive designs have been quite common in the community for years now. And if they don’t thing that’s the right approach it would be good to at least have some opinion from them.

As a side note, seeing this set of first party libraries outside of the SDK reminds me about the conversation that keeps happening in the Swift forums, people want more first party solutions to common problems.

Navigation and visual tools

On to more exciting things, Android now has storyboards! It was a fun conversation with Android devs:

• WOOOO I CAN VISUALLY DESIGN THE FLOW!
• And the arrow that is drawn represents and object that I can call from code!
• Me: Yes, we call that Segues.

Joking aside, I’ve seen the videos and it looks really cool. It’s basically the same as Xcode Storyboards but with some better things. I persoanlly thing Storyboards are fine for small Apps but they are hard to scale, I like to have control of the flow in my code.

The difference here is that it’s not only a visual tool, but the Navigation library solved deep linking handling on Android. That’s another story!

I want so hard to have official support for a Coordinator like architecture with tooling like this around it. I already have my coordinator structure working, handling deep linking with stack creation, etc. But I wouldn’t mind having that officially supported.

I’m not willing to use Storyboard and not be able to diff or even read the code that crates my UI, and even less to lose the type safety and dependency injection. But seems like Google has solved those things. As usual the visual tool is just a representation of an XML that you can edit by hand, and with tooling they’re able to bring type safety to it. If Apple did that to Storyboards it will make me rethink my decisions.

A modern take on old ideas

Apple platforms have CoreData, and it’s a battle proof framework that has evolved over the years. But on the community the feeling that everybody has is: just don’t use it. I think that’s a little to much negativity but is true that CoreData has some rough edges that you need to be aware to avoid problems (read The Laws of Core Data by Dave DeLong), but to be honest that’s as every other ORM that I’ve seen. Threading is hard.

Google has released Room, in the surface is just an abstraction layer over SQLite as any other but it has interesting things. Thanks to Java/Kotlin annotations you can create annotated methods that have the SQL code automatically generated. But the best thing is that it’s even checked at compile time! Something that any modern framework should have. Tooling is so important.

Solving common problems

Pagination of data sets is a really nice thing to have a first party solution for. Android solution is similar to NSFetchedResultsController but, again, with a modern and improved take on it. The NSFetchedResultsController works with CoreData, but Android solution has the dataSource abstracted and integrated with other parts of the system so you can paginate trough local or remote data sets.

But it doesn’t only give you the logic, it also works together with UI components out of the box. When was last time we had a new UI component in iOS? Android solution is not far from iOS standard patterns, with the data source on CollectionView be based in a protocol it’s not hard to provide Pagination for it. In fact there are many libraries that do it, but again, a first party integrated solution would be nice.

WorkManager is another library that we could say “we kind of have it in iOS” but this is much nicer. It serves to perform deferrable asynchronous tasks, think of it as a combination of our NSOperations with background tasks but with much better control over when they should run.

The fact that you can specify constraints to tell the system when they should run (when online, when connected to power, etc) and chain them, or wait for a bunch of them to complete can make it super easy to create background jobs.

The future

Google’s view of the future with Jetpack and Android components is that eventually this will be THE WAY of creating Android apps. Some of them are already part of the compatibility libraries, which means that third party libraries can rely on them.

More libraries are gonna come to solve common problems like error handling. And Google is determined on improving the frameworks to be used from Kotlin, what they call the Kotlinification. That’s one of the things that Apple did a good job with Swift.

But they won’t stop there. They plan to have a unified vision about these components, use them in guides, tutorials and any kind of educational material.

Conclusions

All in all it looks like a really good improvement that Google has made for Android developers. And I just hope Apple looks at it and tries to follow it a little.

I have to be honest, I rarely expect much from WWDC anymore. The operative system is in a place where innovation is slower and I’m fine with it. And development wise they keep announcing amazing frameworks that don’t really help me in my day to day. Yes, ARKit, MLKit are great, but that doesn’t help my development productivity.

But I think Apple can do it. I’m not saying they haven’t been doing anything for us (that amazing memory debugger is a recent thing that comes to mind) but I feel like we’re in modern times that need a change of tactics. Swift being developed in the open has changed so many things and I just wish that they do more like that.

For me the main issue is that Apple ties everything to the OS release cycle, so even when they have great ideas and tools, we all know that if there’s a bug you will have to live with it for at least a year if not more. That provokes that at the end of the day even when Apple gives us great solutions we tend to prefer community driven ones just for the rhythm of updates and improvements.

The other issue is that I’m not sure that Apple would take the risk of taking an official opinion on this kind of frameworks. It feels like Apple is really reserved in supporting any new paradigm.

With all this Marzipan rumour people keeps making the ball bigger and bigger, but I’m not sure Apple will be so opinionated on it. At least it gives me hopes to imagine a future where I can write a declarative UI in Xcode and see immediately a visual preview in Interface Builder, and modify something in the visual editor and see the code update automatically. That’s the future I want, the best of all worlds.

To finalise, kudos to Google for ending the talk by thanking developers for filling issues and giving their time to provide feedback, opinion and beta testing pre-release components. Meanwhile we’re gonna keep throwing radars to Cupertino.