ICE Android Development

NiCE Android Development

As of March 1, 2011, ICEAndroid has been re-implemented to incorporate recent ICE architecture changes.

Primary among these architectural changes is the addition of ICECore and subtraction of StateManager. To do this, NiCEAndroid creates its own subclassed version of ICECore, called AndroidICECore. This is done for one simple reason: Android does not have a file system / directory structure similar to a regular Linux workstation. Currently, ICECore queries the user for the location of their .app and .mip files. This is difficult on Android because there is no user home directory to reference and it is a hassle for an Android user to manually copy files onto their mobile device. So AndroidICECore does not ask the user for the location of their files, but instead hard-codes an emulator's directory for testing/debug purposes. This will change in the future, as we develop and implement a REST architecture. Other than that, AndroidICECore does everything else the same as ICECore.

Also, ICEAndroid has its own Launcher called AndroidLauncher. It is not a subclass of Launcher because it still needs a reference to a Viewer and a ICECore, both attributes that Launcher has but are private and not protected. This class is needed because the true launcher is the actual main Activity class. User interface views in Android are subclasses of the android.app.Activity class. There is no main method, just an Activity, with an onCreate() method, that is declared as the MAIN activity in the Android Manifest XML file. The current main activity starts a Viewer and ICECore, through the AndroidLauncher's launch() method, and waits until the user selects a new Item through the menu. After clicking a new item, AndroidLauncher tells the viewer to create the item through the method launchNewItem(String item) (the only method added that Launcher did not have).

Each Activity is its own stand-alone view. There are methods to return user input data, but they are cumbersome and difficult. In addition, the top-level parent Activity that launches the application is needed to launch new Activities. Moreover, Android uses its own user interface thread to launch Activities, which is not optimal for ICEAndroid because as the main ICE part runs, it must be able to access activity data and launch new activities. To overcome this, NiCEAndroid uses a class called SystemStack which implements the Singleton design pattern. This design pattern allows the instantiation of only one SystemStack object whose state is accessible and changeable by any object. ICEAndroid stores references to the main top-level Activity in this SystemStack object, as well as a reference to the main thread.

Lastly, ICEAndroid implements a subclass of ICEWindow called AndroidWindow. This class overrides methods that present the user a list of items to select, a confirmation dialog, a generic user input field, and an editable options table. Each one of these actions requires its own Android Activity class to present the user with the interface. To launch these Activities AndroidWindow uses the SystemStack reference to the main Activity. Also, each Activity is run in its own, newly created, thread, while the main thread is told to wait for user input completion. In this way ICEAndroid involves any Android/DalvikVM threading headaches. Once user data is received, the main thread continues and properly interacts with the Viewer.

Participants

Alex McCaskey