I have been using Android Studio 3.0 since since the alpha versions, and it is good to see it finally released.
This is just some initial comments on using some common and new Android tools and libraries with the 3.0 version of Android Studio and the associated Android Gradle plugin.
Hopefully this will be useful for anyone thinking of upgrading from Android Studio 2.x.
Java 8 Finally, Maybe
Java 8 was released back in 2014, and with Android Studio 3.0 it is finally supported in Android. Finally I can say goodbye to RetroLambda (although many thanks to the authors for this very useful library).
Just be aware that many of the Java 8 language features will only be available if the minSkdVersion is 24.
Since devices running Nougat or Oreo are still in the minority, supporting older versions will continue to be an issue for a while if you want to use Java 8. Some ideas floated around to support older API version, are to have min API version flavors or do Build.VERSION checks for the API version in the code to provide alternative code paths.
Desugar
The Jack tool chain has been replaced with the desugar tranformation process to support Java 8. Some older libraries and code may have some problems with this build stage.
JUnit 5
JUnit 5 has also been released recently, and with the help of this plugin you can use it for unit testing in Android Studio.
However if you use JUnit 4 Rules in your tests, there is limited support in JUnit 5 as they are meant to be replaced with extensions. Some Rules may be supported with the JUnit 5 migration support, but if not you will have to wait until the Rules are rewritten as extensions or not use the Rules at all.
Of course this is only for unit testing. Instrumentation tests still depend on JUnit 4 and the AndroidJUnitRunner.
Architecture Components, RxJava
I have also been using some of Google’s Architecture Components, but only the ViewModel and LiveData. This is another alternative to design patterns such as MVP or MVVM with Databinding.
If you use RxJava, then this will of course continue to work as it is compatible with Java 6. You may consider replacing RxJava with the more light weight LiveData for activities and fragments, and they can be adapted to each other.
Dependency Injection with Dagger
I have had no problems with Google’s Dagger, but be aware of the API changes for the Android Gradle plugin 3.0 in the gradle build file (e.g. implemention instead of compile, annotationProcessor instead of apt, etc).
See the Android Gradle plugin 3.0 migration guide.
Butterknife, Timber
Some common utilities like Butterknife and Timber for logging are working fine. I’m also using the slf4j binding for Timber without any trouble.
JRebel for Android
During the Android Studio alpha and beta process, JRebel for Android was always playing catch up with the latest version. I still have issues with the current version (2.4.14) of their free edition, so I am using instant run instead at the moment.
I’m a big fan of JRebel so I’m hoping they will have a stable version of their android plugin for Android Studio 3.0 soon.
AOP with AspectJ
There are various AspectJ plugins for Android, and the one I have been using in Android Studio 2.x was this one.
Unfortunately it doesn’t support the Android plugin for Gradle 3.0 yet, but the author seem to be working on it so hopefully the support will be there soon
Update (15 Nov 2017)
Version 3.2.0 of the GradleAspectJ-Android plugin now supports the Android plugin for Gradle 3.0. I like this plugin because it supports both aj files and annotation style aspects.
Things will get better
Of course since Android Studio 3.0 has only recently got general release, we should expect tool and library support to improve going forward.
I have only scratched the surface with some common Android tools and libraries, and there are many more around. Please let me know of your experiences with others.
| Published on Java Code Geeks with permission by David Wong, partner at our JCG program. See the original article here: Android Studio 3.0 – Initial Impressions of Tool Support Opinions expressed by Java Code Geeks contributors are their own. |
