Droidcon London 2017
For the second time, I was able to attend Droidcon London this year. My goal this year was to learn more and get ideas on software architecture and how to put these in context of our app. Currently, my mind is blowing caused by all the information.
Reactive Apps
With a growing usage of RxJava for Android and especially the usage of Rx in one single app memory management is becoming a hot issue. Let’s rephrase it as ‘with great power comes great responsibility’.
As speaker Paco Estevez says in his talk “Most leaks in Android are caused by inappropriately retaining a callback called Activity.” In other words, if you have any reference to an activity in your app, the GC of Android is not able to release the memory if needed. If you load data via Rx in your activity without observing the state of your activity you’ll retain a reference as long as your apps lives.
As powerful as Rx is, use it wisely in association with Activities. Or of course fragments, services, etc. Such a ‘mistake’ is easily made.
Now having the app in mind and knowing the increasing use of Rx, I have something to look into.
Check Paco’s slides at https://speakerdeck.com/pakoito/short-about-memory-management-in-fully-reactive-apps
Deep linking, Universal Links or App Linking?
Since a couple of months we’re struggling with universal links. So the talk of Ty Smith came at the right moment. Ty is currently Mobile Tech Lead at Uber and before did a bunch of other stuff at other great companies.
When it comes to anyway of linking to your app there’s one thing you should always keep in mind. Whatever happens -always- preserve the user’s context. He explained it with a very common example. Someone is on a webpage with a certain context (for an Uber user for example his current LatLong coordinates). The user gets a proposal to install the app via the store. Opening that app may show him some onboarding screens. After that you want the user to show the proposed view and not the default. So always retain the user’s context and restore it. Try with everything within your power to retain it.
Not so very old is the app linking technique (> Android 6.0). A server side json file with some information about how the app should react on a website. To me, it look a bit similar like the the way Apple does it. This is definitely something to investigate. Also this integration is more seamless.
Check his almost similar talk on youtube.
Vector Images
I did play with the possibility to use vector drawables instead of images. It has a lot of advantages. The biggest one (and ironically the smallest one) is the number of total bytes used. And XML drawable would be for example 8kB while the image variant can be more than 200kB. And even on the largest display the vector assets would still look ‘Razor sharp’.
Nick Butcher developer @ Google did a lot of talks about this topic and on #DroidconUk 2017 he did it again. And again he managed to enthuse me to apply it. Why I stopped investigating it? I think it was because of the backwards compatibility, but with using the right components (AppCompat) and some settings it should be possible.
His slides can be found here: https://j.mp/vector-workflows
Which reminds me: shouldn’t we (we as ‘my team’) upgrade from a minSdkVersion 16 to 19 (or higher)? Let’s investigate the market share when I get home…
Modularizing Android Applications
As our apps are growing in time it can become very difficult to maintain them. Morley when your development team is also growing. With the introduction of instant apps Marvin Ramin (developer @ soundcloud) felt the need of splitting up the app not only in functionality but also create modules of the functionality.
In his talk he did not really gave code examples but explained his vision on this topic and gave some handles how to start with it. And again the slogan ‘Think big, act small’ or the PacMan strategy is applicable.
Creating modules will have some advantages in the future; shorter build times, less merge conflicts, more maintainable code, etc. etc. But keep in mind that managing library version between modules is very important. To prevent strange behavior be sure to use the same version numbers over modules.
To be honest, I couldn’t resist myself to apply it for the new functionality I’m currently writing for the app.
Why do we need Clean Architecture
As a follow-up from the modularizing talk, Igor Wojda (Developer @ Babylon) takes the software architecture to a next level. He talks passionate about his way of implementing the MVP design pattern.
With neath slides and animations he explains the principles and how they implemented it at Babylon. He admits the boilerplate code is a bit more, but if you always apply functionality this way it will get rid of large merge conflicts, make your components easy swappable or addible and makes your code easier to understand.
He made a list of his talks and android example projects. When my head have had some rest I will dive into that.
Testing with Rx and Dagger
For large apps with multiple developers unit and integration test become more important. As Fabio Collini says, Unit-, integration- and UI tests together are maybe more important than end-to-end tests. As a developer you don’t want to wait for such long tests. Quick results are a must.
One important architecture principal is separation of concerns. Before being able to do any integration test you’ll have to apply this. Fabio explains (in for me hard to follow Italian English) how to create tests using Dagger for applications using Dagger and RxJava.
Kotlin
For now our app has been written in 99% java code. With Google officially supporting kotlin maybe it’s time to dive more into that. On the 2nd day there were several talks about Kotlin. Not only how to write it, but also how to migrate. Because Kotlin is back and forwards compatible with Java it’s also possible to apply it step by step.
Josh Skeen did a nice talk about the nice do’s and don’ts when using Android Studio’s built in Kotlin Conversion Tool. And what to check when a conversion has been applied. By presenting this step by step with simple examples het made the syntax more understandable and most of all readable for non-kotlin developers.
Josh dared to speak of Java as ‘legacy’. Kotlin has some neath features and provides a way to create clean code. One of the powerful things are ‘extensions’ as you might know from C#. Personally I don’t see it as a competition. Whatever suits your needs. Every language has its pro’s and con’s.
Conclusion
Unfortunately it was not possible to attend all talks. But a short summary: everything stands or falls with clean architecture. When you’ve got that solved in your app and team it’s easy to apply other languages, tests, etc. You will get benefits in several ways. Build times, release times, small learning curves and so on. I gathered enough information to have a good look at our app and improve it where possible.
