\documentclass{llncs}
\usepackage{epsfig}

\begin{document}
\small
\title{Mobile Device Application Synthesis from Domain-specific Models}

\author{Raphael Mannadiar}
\institute{McGill University \email{rmanna@.cim.mcgill.ca}}

\maketitle

\begin{abstract}
A meta-model for modelling mobile device applications (MDA) is presented along with transformations to translate domain-specific models into \texttt{Google Android (GA)} code that runs on \texttt{GA} enabled devices.
\end{abstract}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
From bits to assembly code, from assembly code to Object-Oriented programming languages, from OO languages to the UML, software development has been steadily moving away from the machine language of 0s and 1s to the human language of English for several decades. However, despite the UML being far more intuitive than bits and opcodes to a human developer, it is still very close to the underlying OO philosophy which, it can be argued, should not concern higher level domain experts who wish to develop domain-specific applications. Hence, further movement away from machine language and code and toward the domain model is still required. The following presents a meta-model at a level of abstraction appropriate to the development of mobile device applications. This meta-model alone would not solve the problem introduced above so transformations are described to translate domain-specific models into running code on \texttt{GA} enabled devices.\\

Section 2 will describe related work and provide some useful background. Section 3 will describe the pertinent meta-models while section 4 will describe the transformations that lead from one the other. Finally, section 5 will explore example models that were built using the introduced meta-model.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Related Work and Background}
The most pertinent related work is that of \texttt{Nokia} who designed a meta-model for MDA using \texttt{MetaCase's MetaEdit+} \cite{metacase}. Their meta-model, currently used to develop applications targeted to the public smartphone platform \texttt{Series 60}, is very similar to the one introduced in this work but the lack of published documentation makes it difficult to judge the span of the meta-model's features.\\

Another noteworthy effort is \texttt{DroidDraw} \cite{droiddraw}. This applet produces \texttt{GA} XML code for a graphically specified \texttt{GA} GUI.\\

Before proceeding, a brief description of a general \texttt{GA} \cite{android} application seems appropriate. A \texttt{GA} application has 3 key components:
\begin{itemize}
	\item A manifest file, \textit{AndroidManifest.xml}, which holds some information regarding the application's features and classes.
	\item XML files, \textit{res/layout/*.xml}, which each describe a visible screen on the mobile device.
	\item Java files, \textit{src/package/name/*.java}, which describe the control flow of the application.
\end{itemize}
This is of course a very crude description but provides the key notions to understand the following. Much more information can be found at \cite{android}.
	 
	 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The Meta-Models}
The are in fact 3 meta-models in play: \texttt{PhoneApps}, \texttt{TextualPhoneApps} and \texttt{GA}. A sufficient description of the latter was already given; this section will describe the 2 others which were both developed using the \texttt{AToM3} \cite{atom3} modelling environment. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PhoneApps}
This is the domain-level meta-model that is used by the mobile device application developer. It provides a sufficient set of components to express a wide variety of applications. Note however that it is not sufficient to express all of the features of \texttt{GA}. Restrictions were imposed both by the limited device emulator provided by \texttt{Google} and by the time constraints for the development of this work. Future work on both limiting factors should lead to a complete meta-model with the same expressiveness as \texttt{GA}.\\

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{3.1.1\quad Model Components and Associations\\}
Below is a detailed description of the class diagram of the \texttt{PhoneApps} meta-model:
\includegraphics[scale=0.35]{images/phoneappsmdl}
\begin{itemize}
	\item \texttt{VisualElement}: an abstract class that represents anything related to the GUI i.e. what appears on the screen of the mobile device; all subclasses inherit the following attributes: \textit{height}, \textit{width} and \textit{ID} where \textit{ID} is a unique identifier that can be used to reference the component elsewhere in the model.\\

	\begin{itemize}
		\item \texttt{Container}: contains -- containment is represented by \texttt{Contains} edges -- some number of \texttt{VisualElement}s whose positions are determined by the \textit{index} attribute of the appropriate containment edge (further positioning information is encoded in a \texttt{Container}'s \textit{layout} and \textit{orientation} attributes); \texttt{Container}s that aren't contained in any other represent full screens on the mobile device and are referred to as top-level \texttt{Container}s.\\
		
		\item \texttt{WindowGadget}: an abstract class that represents simple widgets that are used to populate \texttt{Container}s; all subclasses inherit the following attributes: \textit{code} and \textit{is\_coded} where \textit{code} is non-mandatory modeller-specified Java code that can generate the contents of the widget when this content is the result of complex computations (e.g. retrieving data on the Web, computing mathematical equations, etc.) that can not be modelled with the provided meta-model.\\
	
		\begin{itemize}
			\item \texttt{TextLabel}: represents a label; the \textit{text} attribute of this component can either be generated by Java code or be explicitly specified.\\
			\item \texttt{TextField}: represents a editable textfield; the \textit{text} attribute of this component can either be generated by Java code or be explicitly specified.\\
			\item \texttt{TextButton}: represents a clickable button; the \textit{text} attribute of this component can either be generated by Java code or be explicitly specified.\\
			\item \texttt{List}: represents a list of options; the \textit{options} attribute of this component can either be generated by Java code or be explicitly specified; the \textit{is\_clickable} attribute determines if the options in the list should be rendered as buttons or labels.\\
		\end{itemize}
	\end{itemize}
	
	\item \texttt{Action}: an abstract class that represents an action, be it a user-specified action (e.g. \texttt{ExecuteCode}) or a built-in action provided by the mobile device (e.g. \texttt{SendMessage}); all subclasses inherit the following attribute: \textit{ID}, a unique identifier.\\

	\begin{itemize}
		\item \texttt{SendMessage}: represents the sending of a textual message to some recipient (phone number, email address); the \textit{dest} and \textit{message} attributes are explicitly specified.\\
		\item \texttt{DialNumber}: represents the dialing of number; the \textit{dest\_number} attribute is explicitly specified.\\
		\item \texttt{ViewWebPage}: represents the launching of a web browser at some explicitly specified URL, \textit{url}.\\
		\item \texttt{ExecuteCode}: this component enables the modeller to specify Java code to be run; it can be especially useful to overcome some of the limitations of the introduced meta-model such as reading/writing \texttt{GA} data structures.\\
		\item \texttt{ExitApplication}: represents closing the application and returning to whatever the mobile device was doing before its launch.\\
	\end{itemize}
	
	\item \texttt{StartApplication}: represents the starting point of the application; it is connected to a \texttt{Container} that will become the initial screen of the application.\\
\end{itemize}

One type of class association has yet to be discussed: \texttt{TransitionsTo}s. In short, under certain conditions, \texttt{Container}s and \texttt{Action}s can transit to \texttt{Container}s and \texttt{Action}s. This represents transiting from screen to screen, from screen to action to screen, from action to action... Such transitions are parametrized via the modeller-specified mutually exclusive \textit{delay} and \textit{user\_event} attributes of \texttt{TransitionsTo} edges. 
\begin{itemize}
	\item The \textit{delay} attribute enables the modeller to specify that a screen should transition elsewhere after some number of milliseconds or that the application should do something/go somewhere after an action has completed.
	\item The \textit{user\_event} attribute enables the modeller to specify that a screen should transition elsewhere after the user clicks on some option of a clickable list or on some button.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{3.1.2\quad References\\}
The previous subsection mentioned that it was possible to reference model components and to specify ``user events'' based on list option and button clicks. This subsection explores the syntax to accomplish this.\\

There are 3 scenarios were one can reference other model components:
\begin{enumerate}
	\item When specifying a component's attribute:\\e.g. a modeller may want some action to trigger the sending of a text message where the message text contains text that was specified by the user in a textfield from a previous screen as well as a choice the user made in a list from a previous screen; this could be accomplished by specifying the \textit{message} attribute of the \texttt{SendMessage} instance to ``the user entered $<<<textFieldID.text>>>$ and chose $<<<listID.???>>>$ sometime ago''.\\
	
	\item When specifying a button-click user event:\\e.g. a modeller may want the click of button to trigger the exiting of the current \texttt{Container}; this could be accomplished by specifying the \textit{user\_event} attribute of the appropriate outgoing \texttt{TransitionsTo} edge to ``$onClick(<<<buttonId>>>)$''.\\
	
	\item When specifying a clickable list option-click user event:\\e.g. a modeller may want the click of one or any of a clickable list's options to trigger the exiting of the current \texttt{Container}; these 2 cases could be accomplished by specifying the \textit{user\_event} attribute of the appropriate outgoing \texttt{TransitionsTo} edge to ``$onClick(<<<listId=optionText>>>)$'' and ``$onClick(<<<listId=???>>>)$'' respectively.\\
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{3.1.3\quad Code\\}
Code can be specified either to generate content for a coded \texttt{WindowGadget} or as the \textit{code} attribute of an instance of \texttt{ExecuteCode}.
Modeller-specified Java code can reference model components as explained above (hence yielding non-compilable Java code). Furthermore, it must follow a strict syntax: all the code must be encompassed in a class named \emph{ExecuteCode} that must contain a public method named \emph{executeCode()} with return type \emph{String}, \emph{java.util.ArrayList$<String>$} or \emph{void}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{3.1.4\quad Constraints\\}
Many constraints are applied on the meta-model to ensure that only valid models are saved and to ensure that certain assumptions made in the transformations below hold. The following is a sample of these constraints:
\begin{itemize}
	\item \texttt{abstract\_noinst}: ensures that it is impossible to instantiate abstract classes (e.g. \texttt{Action}, \texttt{WindowGadget})\\
	\item \texttt{prevent\_loops}: ensures that a \texttt{Container} can not contain a \texttt{Container} that directly or transitively contains it.\\
	\item \texttt{exit\_is\_final}: ensures that no \texttt{TransitionsTo} edges exit instances of \texttt{ExitApplication}.\\
	\item \texttt{valid\_*} where * is some attribute name: ensures that the given attribute is valid (e.g. the \textit{ID} attribute matches this pattern ``$[a-zA-Z\_0-9]+$'')\\
	\item \texttt{valid\_references}: ensures that every ``$<<<elementId.[attributeName|???]>>>$'' pair references a valid $elementId$.\\
	\item \texttt{container\_large\_enough}: ensures that a \texttt{Container} is large enough to display all of its direct and transitive contents.\\
	\item \texttt{flag\_unreachable\_containers}: ensures that there are no unreachable \texttt{Container}s in the model.\\
	\item \texttt{validate\_ALL}: ensures that constraints that were never checked (e.g. because they are triggered by the editing of an element that was never edited) are checked.\\
\end{itemize}
Note that many constraints such as multiplicity constraints do not have an explicit model constraint like those above but are implicit from the meta-model definition (i.e. the class diagram).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{3.1.5\quad Notes\\}
Some of the design choices above may seem bizarre or absurd. Many of such choices were made to accommodate the modelling environment. Examples of this are:
\begin{itemize}
	\item Due to a problem with the matching of \emph{Text} type variables in the \texttt{AToM3} transformation mechanism, the \textit{code} attribute needs to be specified by a \emph{String} rather than a \emph{Text}. This poses the obvious inconvenience of coding in a 20 character long textfield. This is however no more than a minor inconvenience since it is assumed that most modellers would develop their code snippets using a Java editor rather that the bundled \texttt{AToM3} Python editor.
	\item Due to a problem with multiple levels of inheritance and associations among classes being ported to their sub-sub-classes, no \texttt{ModelElement} with attribute \textit{ID} was created; the \textit{ID} attribute was instead created once for \texttt{Action}s and once for \texttt{VisualElement}s.
	\item Due to limitations in specifying when a constraint should be checked, it was decided to create the \texttt{validate\_ALL} constraint, checked before saving, rather than to create twin constraints for many already existing constraints that would be checked after editing and before saving respectively.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{TextualPhoneApps}
This meta-model is not seen by the modeller. It is merely a simplified representation of a \texttt{PhoneApps} model where superfluous information has been removed and important information  has been aggregated to make the translation to \texttt{GA} code easier. All \texttt{TextualPhoneApps} models are generated by the transformations that will be explored in the next section.\\

\begin{center}
	\includegraphics[scale=0.6]{images/textualphoneappsmdl}\\
\end{center}
As shown in the previous class diagram, a \texttt{TextualPhoneApps} model is simply a collection of possibly connected instances of \texttt{Description}s where the \textit{node\_type} and \textit{params} attributes take on values that summarize the values of the attributes of corresponding \texttt{PhoneApps} model elements. This process will become clearer in the following section.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The Transformations}
The meta-models have been introduced. It is now time to explore the steps that lead from a \texttt{PhoneApps} model to a \texttt{GA} application.

\subsection{PhoneApps2TextualPhoneApps}
This transformation translates \texttt{PhoneApps} models to \texttt{TextualPhoneApps} models. It is made up of the following rules:\\
\begin{enumerate}
	\item \texttt{Initial Action}\\
	Every element in the \texttt{PhoneApps} model is marked as visited.\\

	\item \texttt{StartApplication2Desc} (Order = 1)\\
	The unique instance of \texttt{StartApplication} in the \texttt{PhoneApps} model is replaced by a new instance of \texttt{Description} where \textit{node\_type} is $StartApplication$ and \textit{params} is $<start:StartingContainerId/start>$ where $StartingContainerId$ is the \textit{ID} of the \texttt{Container} to which the instance of \texttt{StartApplication} was connected.\\

	\item \texttt{Container2Desc} (Order = 1)\\
	A new instance $d1$ of \texttt{Description} is connected to every \texttt{Container} in the \texttt{PhoneApps} model. $d1$ has \textit{node\_type} set to $Container$ and \textit{params} set to $<ID:ContainerId/ID><height:ContainerHeight/height><width:.../width><layout:.../layout><orientation:.../orientation><containsI:VisualElementId/containsI>$ where there is one $containsI$ for every \texttt{VisualElement} contained in the \texttt{Container} and $I$ represents the index of the corresponding \texttt{Contains} edge.\\
	A second instance of \texttt{Description} is also created and connected to $d1$; this instance has \textit{node\_type} set to $Transitions$ and \textit{params} set to $<src\_ID:ContainerId/src\_ID><transitionsto0:DestId0/transitionsto0><onevent0:Event0/onevent0>...<transitionstoN:DestIdN/transitionstoN><oneventN:EventN/oneventN>$ where there is one $transitionstoI$ for every outgoing \texttt{TransitionsTo} edge; $EventI$ is the event that triggers the transition to the \texttt{Action} or \texttt{Container}, described by $DestIdI$, that lies on the other end of the \texttt{TransitionsTo} edge. To ensure this rule is only executed once per \texttt{Container}, the \textit{visited} flag set in the initial action is checked before execution and set after execution.\\
	
	\item \texttt{TextField2Desc} (Order = 2)\\
	Every \texttt{TextField} in the \texttt{PhoneApps} model is replaced by a new instance of \texttt{Description} where \textit{node\_type} is $TextField$ and \textit{params} is $<ID:TextFieldId/ID><height:TextFieldHeight/height><width:.../width>VALUE$ where $VALUE$ is either $<text:ValueOfTextAttribute/text>$ or $<code:ValueOfCodeAttribute/code>$ depending on whether the particular \texttt{TextField} is coded or not.\\
	
	\item \texttt{TextLabel2Desc} (Order = 2)\\
	Same as \texttt{TextField2Desc} but for \texttt{TextLabel}s instead of \texttt{TextField}s.\\
	
	\item \texttt{TextButton2Desc} (Order = 2)\\
	Same as \texttt{TextField2Desc} but for \texttt{TextButton}s instead of \texttt{TextField}s.\\
	
	\item \texttt{List2Desc} (Order = 2)\\
	Every \texttt{List} in the \texttt{PhoneApps} model is replaced by a new instance of \texttt{Description} where \textit{node\_type} is $List$ and \textit{params} is $<ID:ListId/ID><height:ListHeight/height><width:.../width><is\_clickable:True|False/is\_clickable>VALUE$ where $VALUE$ is either  $<options:[ValueOfOption0]...[ValueOfOptionN]/options>$ or $<code:ValueOfCodeAttribute/code><max\_length:ValueOfMaxCodedLengthAttribute/max\_length>$ depending on whether the particular \texttt{List} is coded or not.\\
	
	\item \texttt{SendMessage2Desc} (Order = 2)\\
	A new instance $d1$ of \texttt{Description} is connected to every \texttt{SendMessage} in the \texttt{PhoneApps} model. $d1$ has \textit{node\_type} set to $Action$ and \textit{params} set to $<ID:SendmessageId/ID><dest:.../dest><message:.../message><type:SendMessage/type>$.\\
	A second instance of \texttt{Description} is also created and connected to $d1$; this instance has \textit{node\_type} set to $Transitions$ and \textit{params} set to $<src\_ID:SendMessageId/src\_ID><transitionsto0:DestId/transitionsto0><onevent0:onComplete/onevent0>$ where $DestId$ is the \textit{ID} of the \texttt{Action} or the \texttt{Container} on the other end of the \texttt{TransitionsTo} edge. Note that unlike \texttt{Container}s, the only possible trigger out of an \texttt{Action} is the completion of the associated action which can only lead to one ``place'' to preserve determinism. To ensure this rule is only executed once per \texttt{SendMessage}, the \textit{visited} flag set in the initial action is checked before execution and set after execution.\\
	
	\item \texttt{DialNumber2Desc} (Order = 2)\\
	Same as \texttt{SendMessage2Desc} but for \texttt{DialNumber}s instead of \texttt{SendMessage}s. The only difference is that $d1$'s \textit{params} attribute is now set to $<ID:DialnumberId/ID><dest\_number:.../dest\_number><type:DialNumber/type>$.\\
	
	\item \texttt{ViewWebPage2Desc} (Order = 2)\\
	Same as \texttt{SendMessage2Desc} but for \texttt{ViewWebPage}s instead of \texttt{SendMessage}s. The only difference is that $d1$'s \textit{params} attribute is now set to $<ID:ViewWebPageId/ID><url:.../url><type:ViewWebPage/type>$.\\
	
	\item \texttt{ExecuteCode} (Order = 2)\\
	Same as \texttt{SendMessage2Desc} but for \texttt{ExecuteCode}s instead of \texttt{SendMessage}s. The only difference is that $d1$'s \textit{params} attribute is now set to $<ID:ExecuteCodeId/ID><code:.../code><type:ExecuteCode/type>$.\\
	
	\item \texttt{RedirectContainedContainers} (Order = 4)\\
	Every \texttt{Contains} edge from \texttt{Container} $c1$ to \texttt{Container} $c2$ is replaced by an edge from the \texttt{Description} that represents $c2$ to the one that represents $c1$.\\
	
	\item \texttt{RedirectContentsToContainerDesc} (Order = 5)\\
	Every edge from \texttt{Container} $c1$ to \texttt{Description} $d1$ -- such edges were created in rules 4 to 7 -- is replaced by an edge from $d1$ to the \texttt{Description} that represents $c1$.\\
	
	\item \texttt{ExitApplications2Desc} (Order = 6)\\
	Every \texttt{ExitApplication} in the \texttt{PhoneApps} model is replaced by a new instance of \texttt{Description} where \textit{node\_type} is $ExitApplication$ and \textit{params} is $<ID:ExitApplicationId/ID>$.\\
	
	\item \texttt{CleanContainers}, \texttt{CleanSendMessages}, \texttt{CleanDialNumbers}, \texttt{CleanViewWebPages}, \texttt{CleanExecuteCodes} (Order = 6)\\
	Every remaining \texttt{PhoneApps} model element is removed.
\end{enumerate}

The initial \texttt{PhoneApps} model has now been reduced to a much simpler version of itself on which the \texttt{TextualPhoneApps2Android} transformation will now be applied.\\

You may have noticed that some of the above rules seem redundant; this is due to the fact that \texttt{AToM3} does not seem able to apply rules declared on parents to their sub-classes.

\subsection{TextualPhoneApps2Android}
This transformation translates generated \texttt{TextualPhoneApps} models to \texttt{GA} applications. It is made up of the following rules:\\
\begin{enumerate}
	\item \texttt{Initial Action}
	\begin{itemize}
		\item Initializes and populates several global dictionaries and lists that are read and written by the rules below.
		\item Removes old output directory if any and creates new one. 
		\item Replaces any occurrence of $<<<ElementId.AttributeName>>>$ by $pastEntries.get("<<<ElementId.AttributeName>>>")$ in all the values of the \textit{params} attributes of all the model elements. $pastEntries$ is a global \emph{HashMap} in the final generated \texttt{GA} Java code.\\
	\end{itemize}
	
	\item \texttt{TextField\_Label\_Button2Android} (Order = 1)\\
	Deletes every instance of \texttt{Description} with \textit{node\_type} $TextField$, $TextLabel$ or $TextButton$ and...
	\begin{itemize}
		\item Produces appropriate \texttt{GA} XML code and stores it in global dictionary \textit{XML\_code} under $ElementId$.
		\item Produces Java code to set the text of the button/label/textfield and stores it in global dictionary \textit{settext\_code} under $ElementContainerId$ where $ElementContainerId$ is the \textit{ID} of the top-level \texttt{Container} in the \texttt{PhoneApps} model that contained this element. If the element is not coded, this code explicitly sets the text to that specified by the modeller. If it is, this code is a call to $setText\_ElementId()$, a generated function that calls modeller-specified Java code and sets the text of the element to the result of the \emph{public String executeCode()} function. The code for the $setText\_ElementId()$ function, also generated within this rule, is stored in global dictionary \textit{android\_code} under $ElementId$.
		\item If \textit{node\_type} is $TextField$ and its \textit{ID} -- encoded in the \texttt{Description}'s \textit{params} attribute --  is referenced elsewhere -- references are resolved as part of the initial action --, produces Java event listener code that will update $pastEntries("<<<TextFieldId.text>>>")$ as the user types in the textfield and stores this code in global dictionary \textit{event\_listeners} under $ElementContainerId$.\\
	\end{itemize}
	
	\item \texttt{List2Android} (Order = 1)\\
	Deletes every instance of \texttt{Description} with \textit{node\_type} $List$ and...
	\begin{itemize}
		\item Produces appropriate \texttt{GA} XML code and stores it in global dictionary \textit{XML\_code} under $ListId$. This code is essentially a \emph{LinearLayout} of buttons or labels depending on if the list is clickable or not.
		\item Produces Java code to set the text of the buttons/labels that make up the list and stores it in global dictionary \textit{settext\_code}  under $ElementContainerId$. If the list is not coded, this code explicitly sets the text to that specified by the modeller. If it is, this code is a call to $setList\_ListId()$, a generated function that calls modeller-specified Java code and sets the text of the buttons/labels to the results of the \emph{public java.util.ArrayList$<String>$ executeCode()} function. The code for the $setList\_ListId()$ function, also generated within this rule, is stored in global dictionary \textit{android\_code} under $ListId$.
		\item If this list is clickable, produces Java event listener code with cases for each option in the list and stores this code in global dictionary \textit{android\_code} under  under $ListId$. This code is encapsulated in a function called $onListItemClick\_ListId(String\ selection)$. Some portions of the $onListItemClick\_ListId(String\ selection)$ function are not available when its code is generated. To overcome this, special comments are generated in the method body (e.g. ``//ACTION\_FOR\_ListOption'' and ``//DEFAULT\_ACTION'') and are replaced by the appropriate code in the \texttt{Transitions2Android} rule.		
		\item If this list is clickable, produces Java event listener code to ensure each ``list-button'' calls $onListItemClick\_ListId(ButtonText)$ upon being clicked and stores it in global dictionary \textit{event\_listeners} under $ElementContainerId$.
		\item If the list is clickable and is referenced elsewhere, produces Java code that will update $pastEntries("<<<listId.???>>>")$ when the user clicks on a ``list-button''. This code becomes the first line of the $onListItemClick\_ListId(String\ selection)$ function.\\
	\end{itemize}
	
	\item \texttt{SendMsg\_DialNum\_ViewUrl2Android} (Order = 1)\\
	Deletes every instance of \texttt{Description} with \textit{node\_type} $Action$ and \textit{params} containing $<type:SendMessage/type>$,  $<type:DialNumber/type>$ or $<type:ViewWebPage/type>$ and...
	\begin{itemize}
		\item Produces Java code that carries out the action (e.g. makes the required \texttt{GA} function calls to send a text message) and stores it in global dictionary \textit{android\_code} under $ActionId$. This code is encapsulated in a function called $action\_ActionId()$.
		\item If $type$ is $DialNumber$, a special line of \texttt{GA} XML indicating that the application requires the permission to dial the phone is produced and stored in global list \textit{permissions}.\\	
	\end{itemize}
	
	\item \texttt{ExecuteCode2Android} (Order = 1)\\
	Deletes every instance of \texttt{Description} with \textit{node\_type} $Action$ and \textit{params} containing $<type:ExecuteCode/type>$ and...
	\begin{itemize}
		\item Produces Java code that carries out the action (i.e. instantiates the \emph{ExecuteCode} class provided by the modeller and calls its member function \emph{public void executeCode()}) and stores it in global dictionary \textit{android\_code} under $ExecuteCodeId$. This code is encapsulated in a function called $action\_ExecuteCodeId()$.\\
	\end{itemize}
	
	\item \texttt{Container2Android} (Order = 2)\\
	Deletes every \texttt{Description} with \textit{node\_type} $Container$ that has no incoming connections from \texttt{Description}s with \textit{node\_type} $Container$ (i.e. either there were never any such connections or the ones that existed were removed by previous applications of this rule; this condition actually implies that all of the original \texttt{Container}'s contents have already been translated by this rule or previous ones) and...
	\begin{itemize}
		\item Produces appropriate \texttt{GA} XML code and stores it in global dictionary \textit{XML\_code} under $ContainerId$.
		\item If the concerned \texttt{Description} describes a \texttt{Container} that was contained in no other, outputs the produced XML to a file name $screen\_ContainerId.xml$ and, produces Java method $transitionTo\_screenContainerId()$ and stores it in global dictionary \textit{android\_code} under $ContainerId$. This method is structured as follows:
		\begin{enumerate}
			\item Sets the mobile device's current screen to the one defined in $screen\_ContainerId.xml$.
			\item Invokes every statement in global dictionary value \textit{settext\_code[$ContainerId$]}.
			\item Invokes every statement in global dictionary value \textit{event\_listeners[$ContainerId$]}.
			\item If there is a delay before the exiting of this screen, invokes statements that will implement the timeout.
		\end{enumerate}
		Some portions of the $transitionTo\_screenContainerId()$ function are not available when its code is generated. To overcome this, special comments are generated in the method body (e.g. ``//DELAY\_ON\_EXIT'' and ``//EVENT\_LISTENERS'') and are replaced by the appropriate code in the final action.\\
	\end{itemize}
	
	\item \texttt{Transitions2Android} (Order = 3)\\
	Deletes every \texttt{Description} with \textit{node\_type} $Transitions$ and generates code corresponding to the events stored in the \textit{params} attribute (recall its structure is $<src\_ID:SrcId/src\_ID><transitionsto0:DestId0/transitionsto0><onevent0:Event0/onevent0>...<transitionstoN:DestIdN/transitionstoN><oneventN:EventN/oneventN>$) according to the logic below:\\
	For each $<transitionstoI:DestIdI/transitionstoI><oneventI:EventI/oneventI>$ where I takes on values 0 to some N
	\begin{itemize}
		\item If $EventI$ is $onComplete$, produce Java code that will invoke $transition\_code$ (defined below) upon completion of the action described by $SrcId$ and store this code in global list \textit{oncomplete\_events}.
		\item If $EventI$ is $after(millis\_delay)$, produce Java code that will invoke $transition\_code$ after $millis\_delay$ have gone by since entering the screen described by $SrcId$ and replace the single occurrence of ``//DELAY\_ON\_EXIT'' in global dictionary value \textit{android\_code[$SrcId$]} by the produced code. Reminder, the value of \textit{android\_code[$SrcId$]} is the definition of the $transitionTo\_screenSrcId()$ function.
		\item If $EventI$ is $onClick(<<<ButtonId>>>)$, produce Java event listener code that will invoke $transition\_code$ whenever the user clicks on the button described by $ButtonId$ and store this code in global dictionary \textit{event\_listeners} under $ElementContainerId$ where $ElementContainerId$ is the \textit{ID} of the top-level \texttt{Container} in the \texttt{PhoneApps} model that contained the concerned button.
		\item If $EventI$ is $onClick(<<<ListId=???>>>)$, produce Java code that invokes $transition\_code$ and replace the single occurrence of ``//DEFAULT\_ACTION'' in global dictionary value \textit{android\_code[$ListId$]} by the produced code. Reminder, the value of \textit{android\_code[$ListId$]} is the definition of the $onListItemClick\_ListId(String\ selection)$ function.
		\item If $EventI$ is $onClick(<<<ListId=ListOption>>>)$, produce Java code that invokes $transition\_code$ and replace the single occurrence of ``//ACTION\_FOR\_ListOption'' in global dictionary value \textit{android\_code[$ListId$]} by the produced code.
	\end{itemize}
	
	The $transition\_code$ mentioned above is set according to the logic below:
	\begin{itemize}
		\item If $DestIdI$ was the \textit{ID} of an \texttt{Action} in the original \texttt{PhoneApps} model, $transition\_code\ =\ action\_DestIdI();\ return;$
		\item Else If $DestIdI$ was the \textit{ID} of a \texttt{Container} in the original \texttt{PhoneApps} model, $transition\_code\ =\ transitionTo\_screenDestIdI();\ return;$
		\item Else If $DestIdI$ was the \textit{ID} of an \texttt{ExitApplication} in the original \texttt{PhoneApps} model, $transition\_code\ =\ finish();\ return;$ where \emph{finish()} is a \texttt{GA} function that terminates the current \emph{Activity} and returns the mobile device to its state prior to launching the current \emph{Activity}.\\
	\end{itemize}

	\item \texttt{StartApplication2Android} (Order = 4)\\
	Deletes the unique \texttt{Description} with \textit{node\_type} $StartApplication$ and sets global variable \textit{starting\_container\_ID} to the container \textit{ID} specified in the \texttt{Description}'s \textit{params} attribute.\\

	\item \texttt{CleanExitApplication} (Order = 6)\\
	Deletes every \texttt{Description} with \textit{node\_type} $ExitApplication$.\\

	\item \texttt{Final Action}\\
	This is where all the pieces of the puzzle come together: the global variables that were populated throughout the \texttt{TextualPhoneApps2Android} transformation are cleverly pieced together to produce a \texttt{GA} application equivalent to the original \texttt{PhoneApps} model. Below are the steps that make up this final rule:
	\begin{itemize}
		\item For each \textit{ID} $ContainerId$ that describes a top-level \texttt{Container} in the original \texttt{PhoneApps} model, replace the single occurrence of ``//EVENT\_LISTENERS'' in global dictionary value \textit{android\_code[$ContainerId$]} by global dictionary value \textit{event\_listeners[$ContainerId$]}
		\item Produce and output \texttt{AndroidManifest.xml}. This is very straightforward: all of the contents the manifest file are static at the exception of the permissions section which is populated with the contents of the global list \textit{permissions}.
		\item The contents of the global list \textit{on\_complete\_events} are placed in the definition of \texttt{GA} method \emph{public void onWindowFocusChanged(boolean hasFocus)}, which is called any time an action (i.e. SendMessage, ExecuteCode, ...) terminates, and the resulting code is stored in local variable \textit{on\_complete\_events\_code}
		\item The final step consists in producing and outputting \texttt{PhoneApp.java}, the Java file that contains all of the application logic. 
		\begin{enumerate}
			\item Static package and import statements are produced followed by
			\item Global variable declarations (e.g. $pastEntries$) followed by
			\item The \texttt{GA} equivalent for a main, \emph{public void onCreate(Bundle icicle)},  which contains a unique function call: $transitionTo\_screenStartingContainerId();$ where $StartingContainerId$ is retrieved from global variable \textit{starting\_container\_ID} followed by
			\item The contents of local variable \textit{on\_complete\_events\_code} followed by
			\item All the contents of the global dictionary \textit{android\_code}.\\
		\end{enumerate}	 
	\end{itemize}	
\end{enumerate}

The 3 key components of a \texttt{Google Android} application have now been produced:
\begin{itemize}
	\item A collection of screen\_*.xml files
	\item The \texttt{AndroidManifest.xml} file
	\item A Java file that contains application logic
\end{itemize}
All of the output files are generated in \emph{CURRDIR/\_dest\_dir/} where \emph{CURRDIR} is the directory from where \texttt{AToM3} was launched. The only remaining steps are to move these files to their appropriate locations as detailed in Section 2 and to run the generated application on the \texttt{GA} mobile device emulator.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Example Models}
Three example models were created to demonstrate the various features of the introduced DSMM.

\subsection{\texttt{Menu} Application}
This application demonstrates the meta-model's ability to express the very common \texttt{Main Menu} application that ships with modern phones. In short, a list of options is displayed each representing available applications such as dialing a number, sending a text message or browsing the web. The \texttt{PhoneApps} model for this example is located in \emph{User Formalisms/PhoneApps/test\_MENU\_MDL.py}.
	
\subsection{\texttt{Currency Converter} Application}
This application demonstrates the meta-model's ability to express another very common application on hand-held devices: a currency converter. In short, a screen is displayed where the user can enter an amount and choose to convert it from Dollars to Euros and vice versa. This application demonstrates coded \texttt{TextField}s (the conversion is computed in modeller-specified code that could potentially get live exchange rates of the Web and returned by \emph{public String executeCode()}), clickable \texttt{List}s and \texttt{TransitionsTo} self-loops. Below are screenshots of the \texttt{PhoneApps} model (located in \emph{User Formalisms/PhoneApps/test\_CURRENCY\_CONVERTER\_MDL.py}) and the application running on the \texttt{GA} mobile device emulator.
\begin{center}
\includegraphics[scale=0.4]{images/testcurrconvmdl}
\includegraphics[scale=0.4]{images/testcurrconvga}
\end{center}

\subsection{Conference Registration}
This application is much more complex than the other two. It demonstrates the meta-model's ability to express applications that span several screens, that make use of mobile device features such as sending text messages and viewing web pages, that use timeouts to transit from one screen to the next, and more. Below are screenshots of the \texttt{PhoneApps} model (located in \emph{User Formalisms/PhoneApps/test\_CONFERENCE\_REGISTRATION\_MDL.py}) and the application running on the \texttt{GA} mobile device emulator.
\begin{center}
\includegraphics[scale=0.25]{images/testconfregmdl}
\includegraphics[scale=0.4]{images/testconfregga1}
\includegraphics[scale=0.4]{images/testconfregga2}
\includegraphics[scale=0.4]{images/testconfregga3}
\includegraphics[scale=0.4]{images/testconfregga4}
\end{center}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusion and Future Work}
A domain-specific meta-model for developing mobile device applications has been introduced as well as the means to synthesize \texttt{Google Android} applications from domain-specific models. No research efforts have attempted to compare the `exact'' speed up of developing applications using the introduced DSMM rather than implementing them directly on the \texttt{GA} platform. Nevertheless, the obvious similarities between the example models shown in the previous section and the synthesized applications is a testament to the fact that the \texttt{PhoneApps} meta-model is indeed the proper level of abstraction for the development of MDA.\\

As for future work, full support for \texttt{GA} widgets along with more complete integration with all \texttt{GA} features and data structures would definitely make MDA modelling with \texttt{PhoneApps} a strong alternative to coding in \texttt{GA}. Finally, interesting and useful extensions to \texttt{PhoneApps} would be to add an elegant way to do user input checking before transiting out of \texttt{Container}s and providing an efficient mechanism to self-loop on \texttt{Container}s without having to reload widget contents.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliographystyle{splncs}
\begin{thebibliography}{}
\bibitem{metacase}
MetaCase:
Domain-specific modelling with MetaEdit+: 10 times faster than UML
2007
\bibitem{droiddraw}
DroidDraw: http://www.droiddraw.org/
\bibitem{android}
Google Android: http://code.google.com/android/
\bibitem{atom3}
AToM3: http://atom3.cs.mcgill.ca/
\bibitem{Android Demo}
Android Demo : http://www.youtube.com/watch?v=1FJHYqE0RDg
\bibitem{Skypop on Android}
Skypop on Android : http://www.youtube.com/watch?v=PyxWnIalDcY
\bibitem{Androidology - Architecture Overview}
Androidology - Part 1 of 3 - Architecture Overview : http://www.youtube.com/watch?v=Mm6Ju0xhUW8
\bibitem{Androidology - Application Lifecycle}
Androidology - Part 2 of 3 - Application Lifecycle : http://www.youtube.com/watch?v=ITfRuRkf2TM
\bibitem{Androidology - APIs}
Androidology - Part 3 of 3 - APIs : http://www.youtube.com/watch?v=iiD4fGjjXcc
\bibitem{Android application building example}
A first hand look at building an Android application : http://www.youtube.com/watch?v=ENRcZcnoptM

\end{thebibliography}
\end{document}
