Android Searchlight: Discovering the Latest Tech Trends Within the Industry
The ever-changing Android scene provides constant tools and opportunities for developers. This post presents a quick overview of the latest industry trends to supercharge your product with the best tools available in the market today.
1. Breaking free of Java 7 with Kotlin
The very first thing you learn as an Android developer is that you must use Java to code your apps. While this was the case when the android platform first launched, it is no longer entirely true. Today, we encounter a plethora of different languages that stand a chance as a Java alternative within the Android market.
Kotlin, however, is the most popular alternative to Java within native Android development. Kotlin is a production ready, industry based and statically-typed programming language that runs on the JVM created by the JetBrains team. (The developers of IntelliJ, a popular IDE which Android Studio is based upon).
Kotlin offers many features that are unavailable in Java 7 as well as some sweet syntactic sugar that can make coding in Android a breeze while maintaining full interoperability with Java.
What does this mean? Simply put, you can keep using all those Java (and Android) libraries that you use and love and/or gradually migrate your existing code base since both Java and Kotlin files can be used together.
Coding your app in a modern language like Kotlin can dramatically reduce your source code, resulting in an easier to maintain app and, ultimately, increase your developer’s overall happiness. Additionally, Kotlin is fully supported by Android Studio making the learning curve from Java extremely straightforward.
Even though Kotlin can provide some really cool tools for your next project, it is important to remember that using a technology less mature than Java can have its drawbacks too. Although some are very minor , like the slight compilation time increase compared to Java based projects. Others may represent considerable issues for some developers, like the APK size, which can increase noticeably when building Kotlin apps without using ProGuard.
2. Points of View about Fragments
Since 2011, Google has been pushing developers to write modular UIs using Fragments. The main idea behind this was to modularize code between cell phones and tablets, but today the line that separates those two types of devices and the way of coding their UI elements is blurred. Using Fragments instead of plain old Activities introduces new challenges and adds some complexity to the app’s code.
This has lead many developers to ask themselves many non-trivial questions, such as:
- Do we really need Fragments?
- Should every Fragment be contained inside its own Activity?
- … or should we just use one Activity that swaps many Fragments?
- If Activities end up being wrappers of Fragments, why don’t we just use Activities?
- Is it okay to have nested Fragments or is it an overkill?
- Do we always need all of the Fragment lifecycles?
- And finally: Is there any alternative to this madness?
Because of this, some frameworks that aim to replace Fragments with simple Android Views have emerged. Flow (by Square), Conductor and Scoop (by Lyft) are all examples of this and provide a brand new approach to the architecture of your app. Using Views instead of Fragments comes with a list of both pros and cons for both cases. Definitely not a decision that should be taken lightly.
Should you decide to give any of the frameworks (listed above) a try, bear in mind that the community behind them is much smaller than the Fragment approach supported by Google.
3. Fast and Furious building with Buck
For a while now, the Gradle build system has been the official tool for building projects for Android. However, for many developers working on large projects with Gradle may be too slow.
If you are one of those developers struggling with compilation times, Buck (Facebook’s alternative build system) may come in handy. This tool can reportedly decrease building times up to 1000% and is currently being used in large apps such as Facebook, Facebook Messenger, Instagram, Uber and Vine (Check out their blog post about Buck here).
While Buck is usually a faster tool than Gradle, when it comes to building the project, it is less developer-friendly and requires an additional effort to get it up and running. The frustrating (really frustrating) feature about Buck is its outdated documentation and the little to no information available to guide the user. Additionally, as of today, using remote dependencies is not straightforward (like it is with Gradle) and its support for Kotlin is limited at the moment.
In conclusion, because of its trade off between speed and flexibility, Buck is definitely a tool oriented towards developers working on fewer large apps than those working on many small to medium sized ones.
4. The Vector to success (and pixel perfect images)
As you may know, there is another way of representing an image that does not use pixels, but instead, math coordinates. The images implementing this technique are called “vector graphics” which are inherently resolution independent. This means that while you would normally need several versions of the same asset to correctly support different screen densities (hdpi, xhdpi, xxhdpi, etc.), vector graphics allow you to use one asset that will be adapted to the device’s resolution.
Devices running Android Lollipop (5.0+) and higher will adapt the vector graphics on the fly to the device’s resolution to be pixel perfect. This is a great benefit for developers since only one lightweight asset needs to be shipped within the APK. Additionally, developers can forget about maintaining several assets within the project :).
For first time users, check out the documentation of Android Studio as it is very helpful when using vector graphics initially.
The only drawback that should be taken into consideration is that vector graphics need to be processed before being shown, meaning that an overuse of this type of asset may result in lower app performance. According to the official Android documentation, vector graphics should be used for simple (not too detailed) and preferably small images, not exceeding 200 x 200 dp.
If you plan to support Kitkat (4.4) devices or older you won’t be able to use vector graphics as assets directly. Fortunately, Android Studio has a feature that allows you to convert vector graphics to rasterized graphics (a.k.a the classic .png or .jpg assets you’ve been using all along) to use them with your app.
5. Living in a reactive world: RxJava & RxAndroid
RxJava is a library developed by Netflix to bring Reactive Extensions (Rx) to Java. Reactive Extensions is a platform independent standard that aims to provide functional style programming based on the observer pattern.
Reactive Extensions can be great when dealing with asynchronous operations (like waiting for user input, an HTTP response or performing some background job) and this is why it can be particularly helpful in a mobile app, where many situations are asynchronous by nature.
On top of RxJava sits RxAndroid, a library that can simplify the usage of RxJava in an Android application. When everything is put together, the code ends up looking like this:
The code above generates a stream that emits six strings with the name of the topics of this blog post from an array (which will act as the Observable object).
An Observable can be as complex as you need, it doesn’t necessarily need to be an array. Those strings will be emitted from a background thread and will be received by the Android main thread.
Inside the subscribe() method is an implementation of an Observer object, which will handle the objects emitted by the Observable.
Notice how easy the threading result to be. Instead of strings we could be performing some long running tasks in a background thread and still modify UI elements with the main thread quite easily.
6. Playing Da Vinci with the ConstraintLayout
Android Studio 2.2 provides developers a new way to bring to life UI designs in the form of a new ViewGroup, the ConstraintLayout. This new type of layout allows you to specify view positions in a similar way of what RelativeLayout does, but adds more flexibility and provides an intuitive editor preview that promises to boost up productivity.
According to Google, ConstraintLayout benefits are maximized when developing complex views as it helps flatten views hierarchies, thus improving the rendering time of the whole layout. However, for simpler views, more traditional layouts (like LinearLayout and RelativeLayout) should still perform better.
As part of the 2.2 Android Studio update, the ConstraintLayout is tagged as production ready and can -at least theoretically- be used in any real world scenario. Use it at your own risk, however, since this new layout has little mileage on its shoulders and you may end up discovering undocumented and unpleasant effects.
Although not bulletproof yet, its looking up and now is as good time as any to start experimenting with it. To get started, you can try with this official tutorial by Google.
There are many reviews about the current state of the ConstraintLayout on the internet, if you are interested this blogpost details the experience of using it.
Noticeable Android developers and Google are backing this project and we can expect future releases to add even more flexibility and performance improvements to the layout.
Thanks to developers that are pushing the boundaries of what can be done in the Android platform, we have witnessed a continuous stream of new technologies coming through. Every year, we see libraries and frameworks rise and fall. As developers, it is our duty to surf this huge data influx and choose the best of it to deliver great mobile experiences to our users.
I hope that some of the new technologies listed above help you on the Android journey!