This month we have interviewed Diego Ojeda – Android Lead @Apiumhub. In this interview he shares his top 3 lessons learned as well as discusses some recommendations and Android development trends that make a difference nowadays.
1.How to start using Android SDK?
The SDK (Software Development Kit) is a set of tools developed and distributed by Google so that programmers can develop applications that run on Android, the most popular mobile operating system today.
Within this SDK we find tools that allow us to interact with our device (installing applications from the computer), decompile an .apk file to see its interior, debug our applications…
Apart from these tools, this SDK contains the necessary libraries to be able to interact with the Android operating system through code; that is, to develop our own applications.
The easiest way to use this SDK is to download the official tool for developing Android applications: Android Studio. This is an IDE that, from the moment we start it, allows us to start programming our own applications and run them both on our device and on an emulator. In addition, Google provides free courses to get you started in the world of app development from its Code Labs platform.
2.What is Google Play Instant & Instant Apps?
Does anyone remember the Demos of games back in the 2000s? Those little snippets of a game that allowed you to play a level or two before asking you to buy the full game. Well, Instant Apps are the modern equivalent. Instead of installing an application with its full functionality on your device, you have access to a small part to try it out, or do a specific operation without having to install anything on your device.
The best example of these instant apps are games. Do you want to try a game without having to install it on your device and download the hundreds of MegaBytes it takes up? With instant apps you can.
However, like everything else in the world of computing, instant apps also have their drawbacks. For example, you can’t receive push notifications, they overload your RAM and they only work on devices from Android 6.0 onwards.
Even so, instant apps are a breakthrough in the world of mobile application development, as they allow developers to expand their user base enormously by allowing users to test their applications before downloading them.
3. Reasons to choose Flutter for cross-platform apps?
Since the birth of the most popular mobile platforms (Android and iOS), attempts have been made in order to find a way to unify them; in other words, they have tried to use a single code base to obtain an application that works on Android and another that works on iOS.
This has been more than 10 years ago, and over this time, these technologies have evolved and improved. One of the most popular in recent times is Flutter, Google’s commitment to cross-platform applications. Flutter is a framework for developing mobile applications using Dart as the programming language. It is a highly innovative venture on the part of Google, as it is the first framework of its kind that allows user interfaces to be declared declaratively.
Even so, the main difference with its competitors, and what has made it so popular, is that the code of our Flutter application is compiled to native code for each platform, which allows us to use each and every one of the functionalities available in them (for example, access to the camera is not done through plugins as in other similar frameworks).
Flutter has also managed, from a single code base, to achieve a native look and feel on Android and iOS, making its components transform to those of each platform, which results in a better user experience and less effort on the part of developers to adapt their applications to each of these platforms.
4. Top 3 lessons learned in Android Development/architecture
Throughout our years of experience developing Android applications, we have learned a lot and we have come across mistakes that are recurrent in mobile application development. Here are some examples of our learnings:
- A paradigm shift with the introduction of ConstraintLayout: Until the advent of this type of layout, views were built by nesting LinearLayout inside LinearLayout, with some RelativeLayout or FrameLayout between them. This made the construction of views by the operating system really expensive, as well as the maintenance of the code by the developers, as the .xml files with these views were huge. ConstraintLayout changed this, as it allows to have a flat view hierarchy, where the positioning of the views is specified according to other views and their parent, which solves most of the problems mentioned above.
- Kotlin corroutines misuse: A few months after Kotlin was announced as the language officially recommended by Google for Android application development, corroutines were released. Corrutines are a tool that helps us to solve the problem of working with asynchronous code in a sequential and non-blocking way in our application. In our experience we have found that the implementation of these corroutines in Android applications is not done correctly, as the concept of scope or the implications of launching a corroutine without associating it to the lifecycle of an Activity is not properly understood.
- ViewModels misuse: Some time ago, Google launched its Architecture Components libraries, which included the ViewModel; a Google approach to solve the problem of recreating Activities/Fragments when switching, for example, between landscape and portrait modes in our application. These Viewmodels are components that are agnostic to the lifecycle of the application, and that is why they survive these changes of orientation. Throughout our experience we have come across many cases where there are references to views within the viewModel, or actions dependent on the lifecycle of the Activity to which they are linked, which goes against the reason for the existence of these ViewModels.
The post Android development: 3 lessons learned appeared first on Apiumhub.
Top comments (1)
I thought one of those "lessons learned" would be that Android SDK is terribly written.