Feed on

Before going in the details of this first example we provide a basic description of the GUIArtifact, the basic artifact used for managing an Android GUI in JaCa-Android.

The GUIArtifact

The GUIArtifact is the basic artifact used for managing an Android GUI in JaCa-Android. This artifact wraps a real Android GUI using a IJaCaActivity — which is an interface part of our middleware representing a JaCa-Android extension of an Android GUI base class — for providing developers a connection between the concrete GUI and the artifact that manages it. Thanks to the IJaCaActivity it is hence possible to manipulate the Android GUI directly from the artifact—e.g. see what we have done in the getting started example where inside the addSMSToList operation of the ViewerArtifact we added a new SMS to a list displayed in the smart-phone screen.

This artifact has only one observable property (state) representing the current state of the GUI, and provides a set of built-in mechanisms (i.e. protected methods linkOnStartEventToOp, linkOnTouchEventToOp, etc.) for linking each kind of GUI-related Android event to the artifact operation responsible of the managing of such event. In the artifact initialisation — once the linking between events and operations has been made — is executed an internal operation (execInternalOp(“fetchGUIEvents”);) that manages the notification of Android GUI events. This operation is meant to cyclically: (i) wait for new events and (ii) call the appropriate artifact operation (using the primitive execInternalOp).

The GUIArtifact cannot be directly used for realising a GUI in JaCa-Android. For concretely realise an artifact-based GUI we need to specialise the GUIArtifact (like in the case of the ViewerArtifact in the getting started): (i) explicitly defining the links between events and operations we are interested in, (ii) wrapping the specific IJaCaActivity — i.e. the GUI — we want to manage.

The sample

In this first example we will show how to work with GUI in JaCa-Android through the classic hello world example. You can find the source code of this example in the folder /jaca/android/tests/gui placed inside the main tests folder. The GUI used in this example is composed of three different tabs (wrapped in three different artifacts), each one of them contains a print button that once clicked will produce in standard output the following message: Hello World from X, where X is the identifier of the Artifact used to discriminate the tab the user was in when he pressed the print button.

In this example we will use three instance of the HelloWorldGUIArtifact, each one representing one tab of our sample, extending the base GUIArtifact class. Below is reported a source code snippet of the HelloWorldGUIArtifact.

public class HelloWorldGUIArtifact extends GUIArtifact{

  protected void init(JaCaActivity activity, Bundle savedInstanceState) {
    super.init(activity, savedInstanceState);
    Button btnInc = (Button) activity.findViewById(R.id.btnPrint);
    linkOnClickEventToOp(btnInc, "onClick");

  @OPERATION void print() {
    System.out.println("Hello World from: "+getId().getName());

  @INTERNAL_OPERATION void onClick(View view) {

  @INTERNAL_OPERATION void onStart() {

  @INTERNAL_OPERATION void onStop() {

HelloWorldGUIArtifact highlights:

  • In the artifact initialisation the protected methods linkOnXXXEventToOp are used for linking the execution of artifact’s internal operations: (i) to the occurrence of Android events, and (ii) to the corresponding actions that the user can do on the GUI (linkOnClickEventToOp(btnInc,”onClick”) for linking the execution of the onClick internal operation to clicks on the print buttons).

  • In the onClick internal operation the HelloWorldGUIArtifact emits a signal (perceivable by agents that are observing the artifact) containing the name of the artifact identifying the tab. The name of the artifact is retrieved by the getId() method inherited from the Artifact base class.

  • The other internal operations generate signals indicating the occurrence of particular Android events (onStart, onStop, etc.).

Below is reported the source code of the agent used in this first example.

  <-  lookupArtifact("workspace", Id);
		  println("init done").

+state(State) [artifact_name(_,X)]
  <-  println("state  ", X, " :", State).

+onStart [artifact_name(_,X)]
  <-  println("onStart ", X).

+onStop [artifact_name(_,X)]
  <-  println("onStop ", X).


+artifact("first_activity", _, Id)
  <-  println("first activity created");

+artifact("second_activity", _, Id)
  <-  println("second activity created");

  <-  print [artifact_name("first_activity")].

  <-  print [artifact_name("second_activity")].

  <-  print [artifact_name("third_activity")].

Agent highlights:

  • The agent has a init plan where it lookups and focuses the workspace artifact. In this way, each time a new artifact is created in the workspace the agent is able to receive the +artifact(Name, Template, Id) event.

  • The +artifact(Name, Template, Id) event is handled by a set of reactive plans that the agent uses for starting focusing each HelloWorldGUIArtifact as soon as it is created.

  • When a click on the GUI buttons is performed by the user the corresponding HelloWorldGUIArtifact generates a signal that is handled by a proper reactive plan of the agent (+first_activity in case of signal coming from the first HelloWorldGUIArtifact, +second_activity in case of signal coming from the second HelloWorldGUIArtifact, etc.) where the print operation of the HelloWorldGUIArtifact is used for printing in the console the Hello World message.

We know that at first glance the dynamic just described could seems a bit tricky. Actually it is, but we realised this example in order to show you: (i) the linking of artifacts' operations to both GUI and Android events and (ii) the possibility to notify to agents the occurrence of events performed by the user on the GUI. In a real world application, you can imagine to update the GUI directly inside the artifact internal operation (the onClick in the example) that handles a particular event without generating a signal for delegating the update task to the agent (unless you do not want to do this on purpose, e.g. for notifying to the agent the click, as in the case of this sample).

A screenshot of the running example.

Comments are closed.