The Fundamentals Of Android Applications

admin    8615     Android, Applications, Fundamentals

The Fundamentals Of Android Applications

The Fundamentals of Android Applications

While written in Java programming language, Android applications represent a compiled Java code that is packaged into an Android package known as an .apk file.  Bundling application data in this way allows applications to be easily distributed for installation on mobile devices.  Indeed, the .apk file is the file that users are required to download and all the code in an .apk is essentially one application.  In some ways, it can be said that Android applications are isolated applications.  For example, Android applications run in their own Linux process which is started when the applications’ codes are executed and stops when the applications are no longer needed and system resources are utilized by different applications.  Similarly, each process has a dedicated Java virtual machine (VM) such that one application’s codes run independently from the codes of other applications.  And finally, each Android application is associated with a separate Linux user ID.  This means that application files are seen only by the user in that particular application while there are still methods by which these files can be exported to other applications.  This article will go on to discuss some of the components of Android applications and how different codes for various applications can work together.

Android Components

One of the main features of Android is that the basic elements of applications can be shared.  If permissions are granted for these elements, it is possible to use already developed features of other applications.  For example, on application might make use of a great scrolling list of images that you want to use for your application.  If that scroller is made available to others you can utilize that scroller rather than developing your own.  Interestingly, your application doesn’t use the code from the other application or even link to it.  Instead, that piece of code is started in the other application whenever the need should arise.

This means that Android has been designed to allow application processes to be started when any part of it is needed as well as allowing Java objects for that part to be instantiated.  In other words, while most systems and applications have a single entry point, or main function, Android applications rely on central components that are instantiated and run when they are needed.  There are 4 major types of Android components: Activities, Services, Broadcast receivers, and Content providers.  Let’s consider them more closely.

Activities

An activity is a representation of a visual user interface that allows users to choose a particular task to undertake.  This might be a list of menu items or a display of photographs and while activities may work together to create a consistent user interface, they each act independently of the others.  In other words, each activity is applied as a subclass of the Activity base class.  Within applications there is a great range of diversity when it comes to activities.  For example, an application may be made up of only one activity or it may be a collection of activities.  We can move from one activity to the next by having the current activity act as the starting point for the next.  Moreover, each activity in an application is assigned a default window in which to draw.  These windows may fill the screen, float atop other windows, or can interact with other windows.  

The visual content of activity windows is determined by hierarchical views which are derived from the base View.  There are different types of views that determine the rectangular space within the window.  For example, Parent windows organize the layout of subsequent windows and leaf views, which are at the bottom of the hierarchy, draw in their controlled rectangles and can respond to the user’s actions.  As such, views give us the point at which activities can interact.

Services

Because services don’t have a visual user interface, they run in the background indefinitely.  This might be background music that plays while users deal with other problems or it could be background calculations that are provided to the user/activity as needed.  A media player is the perfect example of a service.  As songs are played from a list, the application is designed around multiple activities that allow the user to choose songs and start playing them.  On the other hand, the playback itself is not an activity but a service.  Activities, as you may remember, start and stop as the application is being used, but we want the music to continue playing even when we move onto something different.  As such, services allow the music to continue playing even after the activity that launched it has left the screen.  Similar to activities and other components, the main thread of the application process is where services are run.  

Broadcast Receivers

This kind of component is fairly simple as broadcast receivers merely receive and react to broadcast announcements.  While broadcasts begin in the system code, announcements about a low battery or language change, many applications can also start broadcasts.  This allows applications to communicate to other applications that some information has been downloaded and is available for use.

Content providers

Content providers are how we share application data across applications.  Data is stored in an SQLite database, or other appropriate manner, and then the content provider enables other applications to store similar data.  A content resolver is utilized by applications in order to call these methods and content resolvers can communicate to any content provider.  

If you enjoyed this article please consider sharing it!