Friday, 24 June 2011

Structure of an Android App

An Android application (the Android project that makes up an Android application) consists primarily of Activity and Service classes and also an xml manifest. In addition, the project contains a ‘res’ (resources) folder which consists of the images (‘res/drawable’), views (‘res/layout’) and strings/styles/colors/arrays/etc (‘res/values’) used within the application and a ‘gen’ folder that contains a static (auto-generated) R class providing design time access to the resources in the ‘res’ folder. We describe below the manifest, and then the Activity and Service components.

Application Manifest

An application’s manifest is an xml file defining the structure and metadata of the application and its components, i.e. its activities and services. The manifest contains only one ‘application’ node which acts as a container to specify the application’s components (i.e. ‘activity’ and ‘service’ nodes). A component must be registered in the manifest in order to be used in the application.


An activity represents a screen and is the base class for the application’s visual, interactive components. Every screen in an application will extend the Activity class.

When a new Activity starts during the running of an application, the current foreground screen is moved to the top of the ‘Activity stack’. If the user navigates back using the back button, or the foreground Activity is closed, the next Activity on the stack moves up and becomes active.

Android provides a series of event handlers that are fired and for the programmer to take care of an Activity’s transitioning through its different possible lifetimes (‘full’, ‘visible’, ‘active’) and states within those lifetimes (‘active’, ‘paused’, ‘stopped’, ‘inactive’), e.g. onCreate(Bundle), onRestoreInstanceState(Bundle), onStart(), onRestart(), onResume(), onSaveInstanceState(Bundle), onPause(), onStop(), onDestroy(). These methods are to be overridden by the programmer to perform the tasks desired of the activity as it passes through its different lifetimes/states.

Some of the key user interface classes that an activity will make use of are as follows:

  • View:  An Activity uses a View to form a graphical user interface that displays information and responds to user actions. It is the visual component (layout) of an activity and may itself consist of (sub-) views as well as controls/widgets. Views can be defined in code but preferably are defined in xml and stored in the project’s ‘res’ folder. In the latter case, the user interface elements within the view’s definition are given identifier attributes to get access to them in code (via the R class).
  • Menu: Each activity can specify its own Activity menu that’s displayed when the device’s menu button is pressed. A Menu as such offers a way to expose additional functions of an Activity without sacrificing screen space. To define a menu for an Activity, the Activity’s onCreateOptionsMenu(Menu) method is overridden. This method is triggered the first time an Activity’s menu is displayed.
  • Dialogs: A Dialog is a floating window that is constructed entirely within an Activity and which partially obscures from view the Activity that launched it.

Another key class that an Activity will make use of is an Intent, which is used for the transitioning between Activities. It is a message-passing mechanism that declares the intent for an action to be performed. Whilst not the only use for Intents, the most common use is indeed to start, stop and transition between the Activities within an application. The startActivity(Intent) method of the Activity class is used for this purpose and the Intent passed in either explicitly specifies the class to open or includes an action that the target should perform. An Activity started in this way is independent of its parent and will not provide any feedback when it closes. The startActivityForResult(Intent, int) method of the Activity class is an alternative method to start a sub-activity which is inherently connected to its parent.


Services are the invisible workers of an application. Service components perform tasks that run in the background and which do not require a user interface, such as updating data sources and visible Activities, and triggering notifications. They’re used to perform regular processing that needs to continue even when an application’s Activities aren’t active or visible.

(Essay written as a tw hour timed test for the boss at work. Didn’t get time to look at: Bundles, Contexts, Content Providers; Broadcast Receivers; Data Storage, Retrieval and Sharing; Maps etc)

Tuesday, 21 June 2011

App Deployment Tool

Completed the app deployment tool (built as a Windows Presentation Foundation client application) which compiles and deploys (/uploads) an app based on an xml description of the different languages and platforms the app has been built for (where source code for the app can be found, where the app is to be deployed, and so on). Additionally, tool can change version number of app (by declaring the different places in the source code where the version number is specified) as well as change general lines of code and move files around prior to (and as part of) a compile/deploy action.

Technical note: the 'deployment' process is multi-threaded (hence the existence of 'configuration wrapper' classes as well as 'deploy instruction' classes). The 'compilation' process on the other hand is single-threaded.

Description of the two main deploy actions:
GroupAction - Uploads each of the files/directories specified individually from the source locations to the target location, clearing the target of all its contents prior to the upload if this option has been specified.
BuildAction - Builds the gadget/zip from the source files/directories specified (according to the platform the gadget is being built for), naming the build as specified, and then uploads the build to the target location, clearing the target of all its contents prior to the upload if this option has been specified.

Description of the two main compile actions:
AndroidCompileAction - Compiles the Android project found at the project location specified and then moves (and renames) the 'apk' file built from the project's 'bin' folder (which is cleared with each compilation) to the compile rename path specified.
GWTCompileAction - Compiles the GWT project found at the project location specified according to the class paths and modules specified.

Additional actions which can be specified within the above four main actions: ChangeVersionNumberInCode,  ChangeLineInCode, CopyFileAction, CopyDirectoryContentsAction.

Thursday, 9 June 2011

Katana Sales System

Just finished the Katana Sales System for Katana management to keep track of contact/actions with individuals at specific agencies and also to keep track of the different work (case studies) done by the different agencies for the various clients they have worked for. System built using Microsoft Sql Server 2008 (database tables and stored procedures), Microsoft Visual Studio 2010 (data access layer and serving web requests) and Google Web Toolkit (client-side web interface). Built the client-side web app loosely based on the Model-View-Presenter architecture.