Develop Your Android app in a modern way — Google I/O ’18 tips
Every year, Google’s famous conference brings programmers fresh look on Android development. The idea of one of the talks seemed appealing to me — how to write code in a modern way. Modern (theoretically) means better, faster, easier. Will new components from Google change the way we look at Android Framework?
This year, the talk involved new tools for code profiling and memory tracking, short overview on Kotlin and KTX library, some advice on layouts, Jetpack components, lifecycle, best coding practises and many, many more. In this article, I’ll focus on Google’s programming advices and new approach to architecture.
Kotlin
Now, you don’t have to create multiple overloads of methods or builders all the time. Kotlin provides the ability to extend a class with a new functionality, without having to inherit from the class or use any type of design pattern such as Decorator. This is done via special declarations called extensions.
I simply loved one sentence from the speaker:
“That’s the level of laziness we’ve reached with Kotlin”
In order to “achieve the laziness” faster than ever, Google provided a set of extensions for Android app development, which seems to be really cool and makes me want to try it out (example taken from library’s readme):
Kotlin:
Kotlin with Android KTX:
Pure beauty. All you have to do is add KTX to your dependencies and import the appropriate packages in your project files.
Kotlin coding style
When it comes to coding style, a few tips were mentioned. mNames, used in Java documentation code examples, are not used anymore in Kotlin. The reason why is that property syntax makes it difficult to use the style.
Also, especially for fans of clean and consistent code, there are new official style and interop guides available. Interop guide was written with interoperability of Java and Kotlin in mind, so that APIs written in both languages could be used in a natural manner.
Layouts
First of all, AbsoluteLayout is bad (what was quite surprising is that I didn’t even know about the class existence and I got to know it from I/O…). But… who uses it anyway? It has been deprecated since API 3, so…
Some simple tips on layouts usage were mentioned:
LinearLayoutfor simple use cases,FrameLayout— the situation when there’s only one view in Activity UI and we don’t need advanced layout manager, so all we need is to set padding for the view,GridLayoutis considered to be difficult to maintain and inflexible,
It is also recommended to use ConstraintLayout instead of RelativeLayout. It provides better capabilities of relative positioning of children with respect to each other. To finally convince us, the speaker came up with another great line:
“ConstraintLayout is a RelativeLayout that works.”
Thank you! You’ve convinced me now (I was already convinced…).
Android Jetpack
Jetpack is “the next generation of components to accelerate app development”. It’s a set of libraries, tools and architectural guidances to help making building great Android apps quick and easy. It provides common infrastructure code so you can focus on what makes your app unique. Android Jetpack components are provided as “unbundled” libraries that are not part of underlying Android platform. I’ve sorted out a few of them.
Slices
How fresh idea it is? Well…
Slices component will be a way to surface app’s UI inside of the Google Assistant as a result of a search. For me, it means lots of possibilities — rich, flexible layouts, dynamic and interactive content, especially since Assistant was given a massive update this year. I’m really looking forward to checking this out.
Navigation
Navigation is a new component for structuring your in-app UI. It simplifies the process of navigation implementation in an Android app — handles the complexity of FragmentTransactions for you, while you get all the Architecture Components’ benefits such as ViewModel and Lifecycle.
Navigation Editor lets you see and manage your navigation visually. It was created to help with one-activity apps structuring. The new approach is to use one-activity structure whenever possible. It means richer experience for the user, especially with proper Fragments’ animations usage. This part of library is in alpha testing phase, so it might take some time before stable version will be released, but — still — it looks like Android Framework is going in the right direction.
Fragments
Fragments, which are considered by many to be a rather difficult part of coding, are getting an update. Core platform API is now deprecated. Use Support Library version or Android Jetpack version.
Architecture
Question: How should I design my Android application? What kind of MVC should I use?
“We don’t care. We are not you. We don’t know how your application works. We don’t know the best architecture for your application, so please make your own decision!”
…but it doesn’t mean that we cannot get tips on recommended app architecture in different scenarios.
Lifecycle
Old approach on handling lifecycle was to override each of its methods: onCreate(), onResume(), onDestroy(), etc. Lifecycle state was only known by overriding all of those methods; there was no API to query this. As a consequence, there was too much logic in those methods and too much was happening during Activity/Fragment restart. The new approach uses a Lifecycle component — object LifecycleOwner. Now you can query the state of your app, or attach observers and get callbacks from those methods. Also, you can implement your LifecycleOwner in a place where it does make sense in your app. It means much smaller Activities!
Views and Data
Similar problem of having too much stuff in Activities comes with views and data changes. We have all the information about the views, data for them and finally the methods to track their lifecycle. Thanks to ViewModel, we can decrease number of lines in our Activities (again) and only have information about views and a reference to ViewModel. So, instead of data for views, tracking lifecycle and data change, we abstract it all to LiveData — observable and lifecycle-aware data holder classes. Advantages? No memory leaks, no crashes due to stopped activities and proper configuration changes.
Room
Jetpack includes a lot of original ideas for app architecture and Room is definitely one of them. Built on top of SQLite, it offers local data persistence to allow fluent database access without affecting the full power of SQLite. Also, compile time validation allows you to catch errors at the build time and integration. Of course, the new library is fully integrated with LiveData.
This is only a short overview of an idea, so I recommend you checking this out in practice.
Data Paging
The last library mentioned was Paging Library. It’s actually RecyclerView helper — it makes easier to load data gradually. What is more, the library helps your app observe (via LiveData or RxJava2) and display a reasonable subset of your data. The solution lets you create data-conscious apps and respond quickly to users’ input, even during data updates. It’s also fully integrated with Room library.
That’s all for today! I hope you liked my post :) I will be glad to hear your opinion about the content. Don’t forget to clap 👏 !!!
Thanks to Tup for proofreading, thank you very much for your help :)
Finally, thank you for over 400 👏 on my last post and for all the people that followed my blog — that’s unbelievable!
