We give an overview of the components and the execution flow that we will use in the solu-tion. As an implementation technology we will use Android technology. For Android we can implement everything in Java. We do not directly reuse some components from the non-Android version. Instead we have copied these components and re-implemented them with fewer columns. This is to make the Android less voluminous.
Since screen space is rare on mobile devices, we envision a solution with two screens. The first and last screen will be the results screen. In between a criterias screen will be shown that allows the end-user to specify the search criterias. The flow between these two screens is choreographed by the exchange of messages. These messages are realized as Android intents. We use the predefined activity method signatures to implement call-backs that will receive the messages inside the screens.
The above diagram shows the main flow of the mobile application. The main application entry point is the results screen. The creation of this screen is left to the Android environment. Typ-ically the main application entry point screen will be created when the end-user clicks the application icon from the applications screen of the device. The main scenario only covers the sunshine case when the end-user really desires a results screen. In the full implementation we also find alternative flows for when the end-user cancels one of the screens.Main Scenario:
The mobile deployment is a hybrid between the standalone deployment and then web de-ployment. From the standalone deployment the mobile deployment shares the use of a GUI and the execution of a single image. From the web development the mobile deployment shares the use of a static data holder. The data holder caches the knowledge base across multiple main activity invocations. As long as there are enough memory resources the An-droid environment will not remove the image from memory.