The Ingredients of Android Applications

A simple application in a process In a classical programming environment, the OS would load the program code into a process and then start executing it. Major high-level concepts involved in programming for the Android platform

A Java application, running in a Java virtual machine, in a process To use a rich GUI system like Swing, start a UI system and then write callbacks to code that process events.

Android introduces a richer and more complex approach by supporting multiple application entry points. Starts them in different places, depending on where the user is coming from and what she wants to do next. Instead of relying on the user to directly start each application, the components themselves invoke one another to perform interactions on behalf of the user. Activities, Intents, and Tasks

Android classes

Activities, Intents, and Tasks An Android activity is both a unit of user interaction filling the screen of an Android mobile device—and a unit of execution. An Android program starts by subclassing the Activity class. Activities provide the reusable, interchangeable parts of the flow of UI components across Android applications.

How, does one activity invoke another, and pass information about what the user wants to do? The unit of communication is the Intent class. An Intent represents a function that one activity requires another activity to perform Activities, Intents, and Tasks

Intents form the basis of a system of loose coupling that allows activities to launch one another. When an application dispatches an intent, it’s possible that several different activities might be registered to provide the desired operation. Activities, Intents, and Tasks

Android programs look like we page applications A well-designed activity is resposible for managing a single UI page and each has its own unique name. Android applications find their interactions invoked by an intent. Activities provide UIs and the services.

When the system starts this activity it calls the constructor for TestActivity, a subclass of Activity, and then calls its onCreate method. This causes the view hierarchy described in the main.xml file to load and display. The onCreate method starts the life cycle of the Activity,

one of the most important classes in the Android system, promoting apps' modularity and allowing functionality to be shared. interacts with the Android runtime to implement key aspects of the application life cycle. Each activity is separate from other activities. one activity does not directly call methods in the code that implements another activity. The Activity class

Other elements in the Android framework—such the Intent —are used to manage communication instead. Instead of a user interface flow control based on method calls, applications describe an Intent that they want to execute and ask the system to find one that matches. The Activity class

Other Android Components: services, content providers, and broadcast receivers The Service class supports background functions. The ContentProvider class provides access to a data store for multiple applications, The Broadcast Receiver allows multiple parties to listen for intents broadcast by applications.

Content providers and intents are secondary APIs to use in order to take advantage of Android's strongest features and integrate seamlessly with the Android platform.

Service Class Background tasks that may be active but not visible on the screen. A music-playing application (service) continue to play music while a user might be viewing web pages. allow applications to share functions through long- term connections

Content Provider class A special Uniform Resource Identifier (URI) starting with the content://, which is recognized across the local device, gives you access to the content provider data To use a ContentProvider, you specify a URI and how to act on referenced data create (insert), read (query), update, and delete are basic data handling activities

Content Provider class by providing a ContentProvider, application can share data with other applications and manage the data model of an application. ContentResolver class, enables other components in an Android system to find content providers. Unique among the Inter Process Communication (IPC) systems found on other platforms, such as CORBA, RMI, and DCOM, which focus on remote procedure calls. shares entire SQL databases across processes

Provides the central content provider API, which you can subtype to manipulate specific types of data. Activities access specific content provider instances using the ContentResolver class and associated URLs as follows: Content Provider class

When a developer calls the query method on a content provider, the call returns a Cursor object that implements the android.database.Cursor interface. Content Provider class

BroadcastReceiver implements another variant of Android’s high-level interprocess communication (IPC) mechanism using Intent objects. receives the action of Intent objects, similarly to an Activity, but does not have its own user interface. might receive an alarm that causes an app to become active at a particular time

Component Life Cycles onCreate method starts an application. efficient use of each application’s memory, or heap space, enable the state of entire processes to be preserved and restored so that the Android system can run more applications than can fit in memory.

Activity Life Cycle most complex component life cycle The key elements of handling life cycle state transitions are: selecting which life cycle callbacks you need to implement, and knowing when they are called.

Activity Life Cycle Activity life cycle states

The runtime calls onSaveInstanceState method when it determines that it might have to destroy the activity, but wants to be able to restore it later.

The onRestoreInstanceState method is called when an activity that was destroyed is being recreated.

Static Application Resources and Context The app name, the intents it registers, the permissions it needs and so on are stored in a file called the manifest. These data are called resources. Together, all this information forms the context of the application, and Android provides access to it through the Context class.

Application Manifests Android requires applications to explicitly describe their contents in an XML file called AndroidManifest.xml includes content providers, services, required permissions, and other elements The file organizes an Android application into a well-defined structure that is shared by all applications and enables the Android operating system to load and execute them in a managed environment.

AndroidManifest.xml we declare an intent filter that tells Android when this Activity should be run.

Android applications place images, icons, and user interface layout files into a directory named res.

Applications access resources in these directories using the method Context.getResources() and the R class. directory gen, which contains a class always named R, which resides in the Java application package named in the Android manifest.

The Android Application Runtime Environment Android executes multiple instances of the Dalvik VM, one for each task. Android must divide memory into multiple small heaps. garbage-collected when heap space is tight, and then restored when needed.

Android’s approach to multiprocessing requires that each instance of the VM be space-efficient. This is achieved partly through the component life cycle, which enables objects to be garbage-collected and recreated, and partly by the VM itself. Android uses the Dalvik VM to run a bytecode system developed specifically for Android, called dex. The Android Application Runtime Environment

Zygote: Forking a New Process inefficient for each new process to load all the necessary base classes each time. Android puts each application in a separate process, it can take advantage of the fork operation in the underlying Linux OS to spawn new processes from a template process that is in the optimal state for launching a new VM instance. This template process is called Zygote. It is an instance of the Dalvik VM.

Sandboxing: Processes and Users Android makes an interesting use Linux’s inherent multi-user support: Android creates a new user for each application vendor. This means each application runs with different user privileges (except for those signed by the same vendor). Files owned by one application are, by default, inaccessible by other applications