Execution Flow

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.

Picture 21: Mobile Application Search Flow

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.

Main Scenario:

1.    The mobile application sets up the Prolog runtime.

2.    The mobile application consults the Prolog code.

3.    The end-user presses the search button on the results screen.

4.    The end-user enters search criterias in the criterias screen.

5.    The end-user presses the Ok button on the criterias screen.

6.    The mobile application lets the query interpreter build the query.

7.    The mobile application lets the query interpreter execute the query.

8.    The results screen shows the result to the end-user.

The mobile deployment is very similar to the standalone deployment. With the standalone de-ployment the mobile deployment shares the use of a GUI and the execution of a single binary image. As long as there are enough memory resources the Android environment will not re-move the binary image from memory. A more advanced solution might detect that a closed and reopened activity screen can reuse an already loaded knowledge base.