Activity Screens

We programmatically populate the activity screens and provide call-backs for the intents. Instead of programmatically populating the activity screens we could also inflate them from an .xml file. Inflation has the advantage that the GUI can be easily changed without recompiling the code. On the other hand programmatically populating the activity screens offers more flexibility in dynamically defining layouts. In the following we use the habit of programmatically populating the activity screens, although this is not fully necessary.

The details of the code for the screens can be found in the appendix. We exemplarily show a snippet from the population of the criterias screen. Population can be done in the onCreate() call-back method of an activity. When using programmatically populated screens the views of a screen can be directly referenced via the fields of the screen. We do not need to lookup fields via identification numbers. The onCreate() call-back method will initialize those fields such as text input fields and button fields:

     * Called when the activity is first created.
    public void onCreate(Bundle bundle) {

        TextView labelname = new TextView(this);
        TableRow.LayoutParams layoutparams = new TableRow.LayoutParams(
ViewGroup.LayoutParams.WRAP_CONTENT); layoutparams.setMargins(0, 0, 12, 0); TableRow row = new TableRow(this); row.addView(labelname, layoutparams); name = new EditText(this); name.setWidth((int) (name.getPaint().measureText("#") * 10)); name.setInputType(InputType.TYPE_CLASS_TEXT |
name.setImeOptions(0x1000000 | /* flagNoPersonalizedLearning */
EditorInfo.IME_ACTION_NEXT); name.setFocusable(true); layoutparams = new TableRow.LayoutParams( ViewGroup.LayoutParams.WRAP_CONTENT,
ViewGroup.LayoutParams.WRAP_CONTENT); row.addView(name, layoutparams);

The search criterias screen will be invoked from the search results screen. It will allow the end-user to specify search criterias and then return to the search results screen. The entered search criterias have to be passed back to the search results screen. We use the intent with results mechanism in the first place to invoke the results screen. We can then pass back the search criterias by a new intent. The code for passing back the search criterias is found in the handler for the buttons of the search criterias screen:

     * Button has been clicked.
     * @param view The button.
    public void onClick(View view) {
        if (view == ok) {
            Intent intent = new Intent();
            intent.putExtra("name", name.getText().toString());
            intent.putExtra("fromage", fromage.getText().toString());
            intent.putExtra("toage", toage.getText().toString());
            setResult(RESULT_OK, intent);

The search criterias will be picked up by the onActivityResult() call-back method of the search results screen. As a first step we have to check whether the criteria screen was finished to re-turn some results. If this is the case, the method will then request a knowledge base from the data holder. As a next step the method will unpack the search criterias from the intent and supply it to the query. Finally it will dynamically build a query and which can be used to request the list of the result rows.

     * Handle return from an intent.
     * @param request The request code.
     * @param result  The result code.
     * @param data    The data.
    protected void onActivityResult(int request, int result, Intent data) {
        if (result != RESULT_OK)

 Interpreter inter = know.iterable();
final Query query = new Query(inter);
final String[] cols = query.listColumnIdentifiers();
final TermVar[] vars = query.makeVars();
final AbstractTerm goal = query.makeQuery(vars);

The results are later wrapped into an adapter. The adapter will define how each row is displayed in the list view of the search results screen. Our present implementation of the adapter is quite flexible. It can react on changes in the number of columns returned by the query, since it builds the row views based on the meta-information defined by the list of column identifiers. The detailed code of the adapter can be found in the appendix. Instead of retrieving all rows, we could also opt for a non-exhaustive solution. This would require a different implementation of the query object as a cursor.