When a Java developer switches to Android
After over six years of work experience as a Java Software Developer, I decided to try my hand as an Android Developer. I read that Java could be a very good basis for starting to learn programming for the Android platform. Personally, I worked in technologies such as Spring, Struts, Hibernate, etc., and I began my work in Java version J2SE 5.0. That is why I thought it would be a good idea.
So, how do you become an Android Developer? Here is my story. You will find here my conclusions, read about my attempts, and learn about the problems I’ve encountered and how to cope with them.
How to begin?
Begin with a project. My first Android project was an application allowing you to plan your journey on US highways. Thanks to this app, the users are able to plan the drive in such a way that they can have dinner in their favourite restaurant or visit places which are interesting for them. It took us a little more than a month to create the app.
The best initial step to prepare for the construction of the first app is to read the “Getting Started” chapter of the documentation for developers. In my opinion, it is very clearly written, which makes the learning considerably easier. The guide introduces a beginning programmer into the world of Android step by step, from the installation of the development environment to more complicated things like taking and downloading photos from the phone.
Android Studio — is it worth using the IDE?
In my work, I have used IntelliJ for two years and before that I had worked with Eclipse. As an Android Developer, I had to face Android Studio, that is the official IDE for Android app development, based on IntelliJ IDEA.
Android Studio looks practically just like IntelliJ and that is no surprise, as both environments are based on the same source code. However, whereas IntelliJ offers quite a wide scope of functionalities (it supports the creation of JEE, Scala, Groovy, etc.), Android Studio is a simplified environment oriented at Android. It enables you to create a new project and configure it in an easier way. Still, I think that the Android Studio functions will be added to IntelliJ sooner or later.
Personally, I’m not a fan of using the IDE in which you have a lot of already installed components serving to operate many tools, libraries, languages, etc., which you don’t use anyway. The Android-oriented development environment where you have access to a collection of libraries and plugins for Android only is a much better solution in my opinion.
Android Studio preview mode — a functionality worth recommending
A functionality which is worth recommending is the preview mode. I discovered it while working with Android Studio. It lets you preview the designed application on many different phone and tablet screens.
Application lifecycle
The application lifecycle in the Android system has been designed in a completely different way than in applications controlled by JVM. In Android, there is no classical static method public static main(String[] args) {…}. Instead, you find a series of new methods in Activities classes, such as onCreate, onResume, onPause, onDestroy, etc. Covering the above mentioned methods, you define specific “behaviours” of a given Activity class.
Each of the abovementioned methods participates in the lifecycle of a given Activity class, which you can see in the diagram below.
JVM vs. Dalvik
The difference in the lifecycle of JVM processes and processes run on the Dalvik virtual machine are significant. Java application processes run on JVM can be closed at any time, so you have a total control over the lifecycle of a given application process in JVM.
In Android, it’s a bit different — even after you’ve closed the application using the user interface, it usually remains active in the background. It’s the operating system that decides when to “kill” the application process. Imagine you’ve closed your favourite game or app in your phone. In fact, it can be still active in the background, it only freed up storage space, such as the Internet connection, etc. Why does that happen?
The creators of Android came to the conclusion that in such weak devices as mobile phones it’s easier and quicker to switch the app into the standby mode than to close it and upload all the information to the memory all over again. The overhead and the CPU usage are much higher when you reopen the app from scratch than when you restart it from the sleep mode. On stackoverflow.com, you can find non-standard solutions to how to completely kill the application process, but there are many who disapprove of them. To my mind, everything depends on the application and needs. If you have no strong need to do otherwise, you should leave the control to Android.
Objects vs. primitives
In Android, a lot of pressure is put on the optimization of CPU and memory usage. That is why many programmers recommend using primitives instead of objects. To explain why, they normally provide the following argument: “Using Integer for arithmetic involves more CPU cycles and consumes more memory. Primitive types are not objects, so they do not cause any garbage collection.”
If you create an app for older phone models, you have to think about the optimization from the start. One could say: “Premature optimization is the root of all evil”. Well, you will need to find the golden mean.
MVC
In Android, you won’t find the classical MVC design pattern. The view is built in many different XML files and in the Activity classes themselves. There is a thin border between logic and the view defined in Activity classes or fragments. You can create many classes whose function is to operate the logic for one or more views (Fragments). Activity classes are often responsible for both the view and the business logic operation. Some people claim that in Android you deal with “View-Controller”. For me, it’s still quite difficult to make Activity classes and not to break the Single Responsibility Principle.
Enums
It was a great surprise to me that it is not recommended to use enums in Android, which is specifically mentioned in the guide: “Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”.
Instead of using enumerated types, they recommend employing static constants and variables. It might change in the future, when phones have stronger processors and the memory limitations are not so problematic.
Java 8
Unfortunately, Android does not support Java 8. When building an app for Android, only apps for min. Android 4.0, API level 14 are supported.
When you make an app which must be compatible with older Android systems and you want to use lambdas offered in Java 8, you need to use external libraries, such as RetroLambda. However, RetroLambda does not offer other functionalities available in Java 8, which is remarked in Android documentation: “Unfortunately, Java 8 features other than lambda expressions are not supported by RetroLambda for now.
Only Android N introduces support for Java 8 language features.” As far as I know, Android N is not going to fully support Java 8.
camelCase vs. _underscore
When viewing different examples of Android applications, their authors use various conventions of ID writing in XML files. I have found no information in the guide on the ID attributing convention, what is worse, the document itself is not consistent when it comes to that issue. In some examples, ID objects are called main_layout, and in other — mainLayout. Fortunately, the very programming environment defines the rules clearly: when giving ID in XML files, you use underscore. To give names to XML files, you also use underscore. The argument in favour of such nomenclature is the fact that files created in the /res folder cannot contain uppercase characters.
.class vs .dex
In classical Java, each class is compiled to a separate .class file. If you have one public class, one nested class, and one static class in a given class, you get three .class files. In Android, all the classes are compiled to one .dex file. The .dex files are created by means of a tool called dexer. In contrast to the .class files, the .dex files have been strongly optimized regarding the use of memory.
.jar vs. .apk
The .apk file is an executable file serving to open or install an application in Android. Unlike the .jar file, which consists of many compiled .class files, the .apk file contains one .dex file, where all the application classes have been packed.
As you can see in the image above, a .jar file consists of many classes compiled into a .class file.
What happens to the .jar library files added to an Android application? All the .class files placed in the .jar files are compiled to the bytecode of the Dalvik machine and then attached to one .dex file with the remaining classes.
Java bytecode vs. Dalvik bytecode
Android applications are compiled to the bytecode run on DVM (Dalvik Virtual Machine), which is a bit different from the Java bytecode. JVM is based on a stack, while DVM is based on registers. JVM has about 200 opcode instructions, whereas DVM has 218 and they are longer since they include the source and target register address.
In JVM, many instructions are responsible for the data transfer between a stack and list of local variables. In DVM there are no such instructions, because there is no stack.
To sum up
This is how the first few weeks of my work on creating an Android app passed. The Android system creators place a lot of emphasis on code optimization and memory or CPU usage. DVM as such differs significantly from JVM. What surprised me most was the fact that a special bytecode was developed for DVM and that the .dex files structure is so distinct from the .jar files. Personally, I did not expect so far-reaching changes.
Originally published at xsolve.software on September 23, 2016.
