The Android Cookbook

From small and affordable to powerful and large, nearly 80% of all newly shipped smartphones in the world use some version of the Android operating system. Primarily designed to be flexible, Android adapts to all types of mobile devices. Regardless of whether the device is a tablet or a smartphone, regardless of the screen size and built-in hardware features, the operating system must always provide the best possible user experience.

I talked about this specific topic at this years Mobility Day conference held in September in Zagreb. This article is just an addition to my talk on the basics for developing adaptable applications and describes the key features of the Android platform.

[slideshare id=26609076&doc=mobilityday-razvojaplikacijazaandroidfinal-130927032225-phpapp02]

Beneath the hub

Android`s underlying kernel is based on Linux, but has been customized to suit Google`s directions. It uses Dalvik VM, a special open-source virtual machine designed to optimally run on hardware typically found on mobile devices. In other words, it has the potential to be used in different areas where memory, disc space and CPU is limited. Linux kernel takes care of the file-system and process management. It also takes care of security and manages hardware components through the drivers.

Dalvik VM runs applications and code written in Java. A standard Java compiler turns source code into Bytecode, which is then compiled into .dex files that are executed on Dalvik VM. In essence, .class files are converted into the .dex files, a format which is optimised for minimal memory footprint, and then read and executed by the Dalvik Virtual Machine.

Understanding Android apps

Android uses its own run time and virtual machine to manage application memory. Every Android application runs in a separate process within its own Dalvik instance inside one Linux process. The use of Dalvik enables a device to run multiple VMs efficiently.

Applications run independently so if an app crashes it shouldn’t affect other applications running on the device. In case the device needs more memory the Android OS turns off background applications using the FIFO principle (First In, First Out). The first applications to be sent to run in the background is the first application to be turned off. The same goes for the background process hosting Activities that can be shut down at any moment in case the OS needs additional memory for applications that are in the foreground.

The last components to be turned off by the OS are foreground services. These services expose their state or controls by notification bar. A typical example for a foreground service is the music player service. They can be shut down if resources are needed to support active and visible processes.

Development Environment

Android apps can be build using the Java programming language or Scala. For that matter, they can be developed in any other language that can be compiled into Java bytecode. To get started just download the Android software development kit (SDK) which provides the tools and APIs necessary to begin developing applications on the Android platform. Developers can choose between different IDE`s: Eclipse, Intelij IDEA or Android Studio (based on Intelij IDEA).

I prefer developing Android projects in Intelij IDEA (Android Studio) because of its powerful intelliSense and refactoring features that increase productivity and significantly decrease the number of bugs introduced by refactoring.

The life cycle of an application

The Android operating system completely controls the memory, and all applications are treated equal until there`s memory shortage. Apps are packaged in APK files that contain the program code, the app resources and Android Manifest – an XML document containing all app details. The OS uses the Manifest to manage applications both on their installation and on run-time. The Manifest contains the name of the Java package, the list of application components, list of permissions required to access the system APIs, the minimal Android API level and the targeted Android API.

The main components of Android applications:

  • Activity
  • Service
  • Content Provider
  • Broadcast Receiver

The Activity has a user interface and represents one “Window” in our application, while the Service component executes in the background for a longer period of time, usually in a separate thread. For accessing databases we use Content Providers. These components can be used internally inside the app or can be exposed to the OS for external use by other applications. Broadcast Receivers are components that listen to system or local events (eg. an incoming phone call) thus allowing apps to take some action in response to received events.

Intents are data-objects used for broadcasting events and connecting different app components on run-time. Containing the information about the action that needs to be done or a message about an event, Intents are mostly used for navigation among Activities, for launching services and sending Broadcast messages.

For instance, and Intent can define the name of the component, an action (View, Dial, Edit), Data (URI, MIME type), component category (BROWSABLE; HOME; LAUNCHER) and additional data (Bundle object).

Single-entry point

Android applications don`t have a single-entry-point. This means that the application can be started by opening any activity within it. That mechanism enables a seamless interconnection of different applications because the user isn`t aware that the next activity belongs to a different application (process).

Typical use case could be: User reviews a content in the browser and clicks on a an email address. The browser generates an intent that navigates to a specific Activity inside an e-mail application. When the user completes the email and sends it, the OS closes the mail Activity and automatically returns to the browser.

Flexible user interface

Android runs on a incredible variety of devices with different screen sizes and pixel densities so it is absolutely essential that the OS provides mechanisms for easy creation and management of flexible and adaptable user interfaces.

The key practices for making adaptable user interfaces are:

  • using only density-independent pixels for all UI dimensions
  • defining multiple variants of resources (layouts, images, strings, dimensions…) for different types of device configurations (based on screen size, screen-density, orientation, api-level…)

One of the easiest way to work with different versions of resources is achieved by using Resource Qualifiers.

Powerful components aimed to provide best user experience on both phones and tablets are Fragments. Instead of being just UI components, they are completely independent and reusable screen components that, except their user interface, also define their own logic. A single Activity can contain one or more Fragments depending on the screen size, or its current orientation.

The freedom to innovate

For me, Android provides a flexible and open platform that gives developers great freedom to innovate using the full potential of numerous devices ranging from smartphones and tablets to TV-box sets and In-car entertainment systems.

This article is primarly for those new to Android app development to help them get a better grip on the basics for developing adaptable mobile applications.