A Domain-Specific Language for Cross- Platform Smartphone Application Development

Transcription

1 Master s Thesis A Domain-Specific Language for Cross- Platform Smartphone Application Development Kristoffer Rosén Department of Computer Science Faculty of Engineering LTH Lund University, 2013 ISSN LU-CS-EX:

2

3 A Domain-Specific Language for Cross-Platform Smartphone Application Development Kristoffer Rosén August 30, 2013 Supervisor: Shingo Takada Examiner: Görel Hedin

4

5 Abstract In recent years, smartphone devices have become more and more common, with the two major competitors on the market being Android and iphone. This has also led to a significant increase in the number of applications being developed specifically for these platforms. However, developing the same application for multiple platforms can be both challenging and time consuming, since it requires knowledge of different tools and programming languages. This thesis investigates the possibility of using a domain-specific language (DSL) to develop native cross-platform smartphone applications. The DSL is implemented using the Spoofax Language Workbench, which provides functionality for specifying the language grammar and to create rules that transform code written in the DSL to native code for the target platforms. The implementation is evaluated by a use case study, in which the participants are asked to implement a smartphone application using the DSL according to a requirements specification. It is shown that the DSL works as a proof of concept, and it is argued that it would be possible to add support for new language features and other platforms in the future. i

6 Acknowledgements I would like to express my deepest gratitude to my supervisor Associate Professor Shingo Takada of Keio University for his valuable input and guidance during the early parts of researching and working on this thesis. I would also like to thank all the students of Takada laboratory; the weekly meetings, discussions and comments were immensely helpful. My sincere thanks also go to Professor Görel Hedin of Lund University, for the feedback and suggestions during the later part of this project. Last but not least, I would like to thank Kurara for her never-ending support through all challenges. Without you, this would have been vastly more difficult. ii

7 Contents 1 Introduction Problem Statement Thesis Outline Related Work 3 3 Theory Domain-Specific Languages Stratego/XT Annotated Term Format Syntax Definition Formalism The Stratego Language Spoofax Language Workbench Grammar and Parser Presentation Editing Semantic Smartphone Platforms iphone Android Method Architecture Overview Alternative Framework Implementation Approach Implementation Grammar Definition Grammar Basis User Interface Low-level Logic Custom Data Types Web Services DSL Overview Code Generation User Interface Low-level Logic Custom Data Types iii

8 5.2.4 Web Services Supporting Files Code Analysis Collecting Entity Information Checking Constraints Checking Type Consistency Evaluation User Experience Evaluation Questionnaire Results Tool Evaluation Limitations Discussion 43 8 Conclusion Future Work Bibliography 47 Appendix A Lexical Syntax Definition 49 Appendix B User Experience Evaluation Handouts 50 B.1 TODO Application Requirements Specification B.2 Questionnaire Appendix C Example Application 53 iv

9 List of Figures 3.1 Stratego/XT architecture AST with constructor names highlighted Parse tree for a mathematical expression AST for a mathematical expression File structure of a Spoofax project Grammar definition in a Spoofax project Spoofax DSL editor and abstract representation view Overview of architecture used for DSL implementation Iterative process of DSL implementation High-level DSL overview B.1 Example TODO application for Android B.2 Example TODO application for iphone List of Tables 5.1 Code generation UI widget mappings Code generation type mappings Code generation value mappings User experience evaluation data C.1 Files generated from DSL entities v

10 Program Listings 3.1 Simple grammar in BNF Simple grammar in SDF Reduction sequence of a mathematical expression Simple grammar in SDF with constructor annotations Example of modular grammar in SDF A simple Stratego program Syntax highlighting specification in Spoofax Builder specification in Spoofax Code generation in Spoofax Grammar basis of DSL Screen type grammar View and UI widget grammar Primitive data type and expression grammar Operator grammar Statement grammar Function definition grammar Custom data type grammar Web service grammar Screen transition and passing data on Android Screen transition and passing data on iphone A.1 Lexical syntax definition C.1 Example application code vi

11 List of Abbreviations ADT API AST ATerm BNF DSL EMF GUI IDE JSON MOFM2T PIM PSM REST SDF SDK SLOC UI XML Android Development Tools Application Programming Interface Abstract Syntax Tree Annotated Term Format Backus Naur Form Domain Specific Language Eclipse Modeling Framework Graphical User Interface Integrated Development Environment JavaScript Object Notation MOF Model to Text Transformation Language Platform Independent Model Platform Specific Model Representational State Transfer Syntax Definition Formalism Software Development Kit Source Lines of Code User Interface Extensible Markup Language vii

12 Chapter 1 Introduction The term smartphone is by no means a new concept. It first appeared in the early to mid-1990s, when mobile devices such as IBM s Simon and Ericsson s GS88 were released. Until recently, smartphones were still a somewhat niche market, and so called feature phones have been more common. However, in recent years, many new smartphone operating systems and devices have seen the light of day, and with the release of Apple s iphone and Google s Android operating system, smartphones started to reach a wider audience. They are now projected to soon overtake feature phones in global market share [13]. Along with these new smartphone devices, new ways to digitally distribute thirdparty mobile applications were also launched. Platforms such as Apple s App Store and Google Play make it possibly for anyone to upload an application for the entire world to see. It is now easier than ever to reach out to a large audience; you no longer have to be a big company with proper distribution channels. This makes smartphone application development a very lucrative business, and has grown to become a billion dollar industry [17]. Today, most people probably have an intuitive understanding of what makes a mobile phone a smartphone, however no clear-cut definition exists. For the purpose of this thesis, we will define a smartphone as a mobile device that apart from having the normal functionality of a feature phone (such as voice calling and text messaging), also have features such as web browsing, , camera, GPS, and video and audio playback. Furthermore, a smartphone can run third-party applications written via an application programming interface (API) that usually provides better access to the underlying operating system and hardware, compared to a feature phone. 1.1 Problem Statement Today, there are two major competitors in the smartphone market; Apple s iphone and Google s Android operating system. Furthermore, there are many other platforms that hold smaller market shares as well. When developing a smartphone application, a natural goal is to try to reach out to as many potential customers as possible. However, due to the fragmentation of the smartphone user base, this isn t always a trivial task; one needs to have knowledge in several different programming 1

13 languages, frameworks and APIs, not to mention the extra time commitment (and subsequently extra economical investment) it would take to rewrite the application for a different platform. In this thesis, we explore one way to support cross-platform smartphone application development. We chose to create a small domain-specific language (DSL) that can be used to develop smartphone applications targeting multiple platforms. This would potentially remove the need for the developer to have knowledge of the programming languages used and implementation details of the various smartphone platforms. We define the following research questions, which we will reflect upon in Chapter 6: RQ 1 How much flexibility does the proposed solution offer the developer? What type of applications can be created using it? RQ 2 Does the proposed solution speed up the work of the developer? RQ 3 How scalable is the proposed solution? Can we easily add support for other platforms, or make changes to already existing ones? 1.2 Thesis Outline The rest of this thesis report consists of the following chapters: Related Work: Summary of previous approaches related to solving the same general problem. Theory: Introduction to important concepts that are referred to throughout this report. Method: The method that was taken in solving the problem presented in the introduction, and overview of the architecture that was used. Implementation: Description of the implementation of our proposal. Evaluation: Evaluation of our proposal and the tools that were used, and discussion of the results and limitations. Discussion: A more in-depth comparison to previous approaches, and related discussion. Conclusion: Concluding comments and suggestions for future work. 2

14 Chapter 2 Related Work In the past, there have been numerous attempts trying to unify the development of cross-platform smartphone applications. In this chapter, some of the most relevant ones will be presented. In general, past attempts can be divided into two categories; solutions based on a DSL, or so called hybrid frameworks. Kramer et al. [19] proposes MobDSL, a domain-specific language for developing mobile applications. The authors proposal includes a virtual machine that is meant to run on the mobile device and interpret the language directly. Such a virtual machine would have to be implemented for each platform, and would also be highy reliant on the underlying architecture, making the scalability questionable. Another attempt using a DSL is found in [16] from Hemel and Visser. Mobl is a DSL that is translated into web technologies such as HTML and JavaScript code, which then creates an application that can be run in a web browser on the mobile device. However, since the application is browser based, no native device features or native user interface components are available for the developer to use. Also, depending on what browser the mobile device uses, differences in rendering as well as features might occur. Finally, since the code is interpreted and not compiled, it might not perform as well as a native application would [11]. Behrens [9] proposes a DSL that can be translated into native code for iphone. However, it is limited to data-centric applications, and does not offer a lot of flexibility for the developer. Le Goaer and Waltham [20] proposes Xmob, a DSL that is based on model-driven architecture, where the idea is to produce fully native code for the target platforms. There exist quite a lot of so called hybrid frameworks for mobile application development. The name refers to the fact that applications created using one of these frameworks are essentially a mixture of native and web based concepts. Usually, the user interface is created using HTML and JavaScript, and is then styled using CSS to emulate a native user experience. The framework provides an API (usually in JavaScript) which enables the developer to access some commonly used native device features, such as the camera or GPS. PhoneGap [5] is a framework that supports development for the most common mobile operating systems. It provides a foreign function interface that gives the developer access to hardware features. The user interface is created using HTML and CSS, which is then wrapped inside a native WebView (a user interface widget 3

15 that is used to display web content and is available on all modern smartphone platforms). Rhodes [4] from Motorola is another framework similar to PhoneGap, which lets the developer write hybrid applications using non-native code. What makes Rhodes different is that it uses Ruby instead of JavaScript for the controller code. Another hybrid framework that uses JavaScript is Appcelerator Titanium [2]. Others, such as Sensa Touch [6], provides a JavaScript library for purely mobile web applications, and thus do not have support for any native features. 4

16 Chapter 3 Theory In this chapter, some of the more important theory and concepts that will be referred to later on in this thesis are briefly described. 3.1 Domain-Specific Languages A domain-specific language (DSL) is a programming language that is meant to be used in solving a particular type of problem, or to be used in a particular problem domain. Two examples of commonly used DSLs are SQL for relational databases and HTML for web pages. In contrast to DSLs are general-purpose programming languages (such as C and Java), which can be used in solving a wide variety of problems. In fact, a DSL can usually not be used outside of its intended domain, since it should only have a limited set of features. Van Deursen et al. [23] proposes the following definition: A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. Fowler [14] categorizes DSLs into two groups; internal and external. An internal DSL uses a subset of a general-purpose programming language for the implementation, while an external DSL uses a custom syntax. Fowler furthermore states that DSLs can be implemented either by interpretation or code generation. Designing a DSL is not a trivial task, since it requires knowledge in both programming language design as well as the particular domain itself. Furthermore, a DSL should preferably be rather small in scope but still provide enough freedom for the programmer to do whatever he or she needs to do. This might be difficult to achieve. For this thesis, we develop a small DSL in the domain of smartphone applications. The goal is to be able to write applications targeting multiple mobile platforms using our language, without having to rewrite code for any specific platform. The DSL will work as a proof of concept, and thus we focus on today s two major smartphone platforms, iphone and Android. Using Fowler s definitions, the DSL will be external and will be implemented using code generation to the platform s respective native languages. 5

17 3.2 Stratego/XT Figure 3.1: Stratego/XT architecture Stratego/XT [10] is a framework for creating program transformation systems, i.e. systems that take a program as input and automatically generate another program as output. As the name implies, it consists of Stratego, a transformation language, and XT, a collection of components for implementing transformation systems such as parsing and pretty-printing. When a programmer writes a program, it is usually done as text in a text editor. However, the text of the program needs to conform to certain syntactical rules, called a grammar. The grammar is a very important concept in Stratego/XT, since the transformation tools use the information contained in the grammar for performing operations such as parsing the text, generating syntax trees, and pretty-printing. Figure 3.1 shows the general architecure of a Stratego/XT transformation system. First, the program text is parsed using a parse table, produced from the grammar of the language. This produces a parse tree which in the next step is turned into an abstract syntax tree (AST) by removing any unnecessary information (such as whitespace and brackets) from the original tree. When the AST has been produced, different transformation tools (written by the transformation system developer using the Stratego language) can manipulate it. Checking for type correctness or optimizing the code are two examples of operations that could be performed, before the program is pretty-printed Annotated Term Format Looking at Figure 3.1, it seems like trees are being passed between the tools in the transformation system. However internally, these trees are represented using the annotated term format (ATerm) [22]. To show how an ATerm corresponds to an AST, lets consider the following example program code: foo(x+5) + 10 In this example, a function foo is being called with an argument, and the value 10 is added to the value returned from the function call. Figure 3.2 shows a visual 6

18 Figure 3.2: AST with constructor names highlighted representation of this program using an AST, while the corresponding ATerm is shown below: Add(Call( foo, [Add(Var( x ), Int( 5 ))]), Int( 10 )) The identifiers are called constructors, and are derived from the language grammar. This is explained in more detail in the next section. It can be seen that the outermost constructor, Add, corresponds to the root node in the AST, while the string literals correspond to the leaves. In general, each constructor corresponds to a node in the AST Syntax Definition Formalism Syntax Definition Formalism (SDF) [15] is a language for defining formal grammars, e.g. for textual programming languages. In the Stratego/XT framework, SDF is used to specify the grammars which the transformation tools work on. The grammars defined using this language are context-free grammars, which were first described by Chomsky [12]. A context-free grammar consists of production rules, which in most notation techniques take the form A B 1... B n where A is a non-terminal symbol and B 1... B n are either non-terminal or terminal symbols. A non-terminal symbol is a symbol which can be replaced by a sequence of zero or more symbols, while a terminal symbol is a symbol that cannot be replaced (e.g. a string literal). While most notation techniques for describing context-free grammars such as the commonly used Backus-Naur Form (BNF) take the above form, SDF uses the different, albeit similar form B 1... B n A 7

19 Again, B 1... B n are either non-terminal or terminal symbols, while A is a nonterminal symbol. To illustrate this concept, lets consider a simple grammar for mathematical expressions written using both the BNF and SDF notation techniques: 1 Var ::= ID 2 Exp ::= Int Var Exp "+" Exp Exp "-" Exp Exp "*" Exp Exp "/" Exp Exp "=" Exp "(" Exp ")" Listing 3.1: Simple grammar in BNF 1 ID -> Var 2 Int -> Exp 3 Var -> Exp 4 Exp "+" Exp -> Exp 5 Exp "-" Exp -> Exp 6 Exp "*" Exp -> Exp 7 Exp "/" Exp -> Exp 8 Exp "=" Exp -> Exp 9 "(" Exp ")" -> Exp Listing 3.2: Simple grammar in SDF In this grammar, a variable is an identifier (usually defined as a sequence of characters and digits), and integers and variables are considered to be expressions. Furthermore, an expression can also consist of other expressions separated by arithmetic operators, or one that is enclosed in parentheses. ID and Int are terminal symbols, while Var and Exp are non-terminal. One obvious difference between the BNF and SDF notations is that the former allows a production rule to have multiple choices, separated by a vertical bar. On the other hand, SDF requires each choice to be written as a separate production rule. The grammar allows us to write simple mathematical expressions, such as: (x+10) * y When this expression is parsed, a parse tree is first created which contains all the information of the original expression. The parse tree can be seen as being made up of a sequence of reductions, as shown below: 1 (x + 10 ) * y 2 -> (ID + 10 ) * y 3 -> (Var + 10 ) * y 4 -> (Exp + 10 ) * y 5 -> (Exp + Int) * y 6 -> (Exp + Exp) * y 7 -> (Exp ) * y 8 -> Exp * y 9 -> Exp * Id 10 -> Exp * Var 11 -> Exp * Exp 12 -> Exp Listing 3.3: Reduction sequence of a mathematical expression 8

20 Figure 3.3: Parse tree for a mathematical expression Figure 3.3 shows the parse tree that corresponds to this reduction sequence. It is clear that the parse tree, when traversed from the root to the leaves, is the same as the reduction sequence in listing 3.3, traversed upwards from the bottom. Furthermore, the leaves of the tree make up the original mathematical expression when concatenated. Production rules in SDF can be annotated with constructors, which are used when a parse tree is reduced to an AST. Revisiting our grammar for mathematical expressions, it can now be written as: 1 ID -> Var {cons("var")} 2 Int -> Exp {cons("int")} 3 Var -> Exp 4 Exp "+" Exp -> Exp {cons("add")} 5 Exp "-" Exp -> Exp {cons("sub")} 6 Exp "*" Exp -> Exp {cons("mul")} 7 Exp "/" Exp -> Exp {cons("div")} 8 Exp "=" Exp -> Exp {cons("eq")} 9 "(" Exp ")" -> Exp {cons("br")} Listing 3.4: Simple grammar in SDF with constructor annotations The cons annotation declares a constructor for a production rule. The constructor names are used to label the nodes in the AST, as is shown in Figure 3.4. It is 9

21 Figure 3.4: AST for a mathematical expression not always necessary for every production rule to have an associated constructor, e.g. when the production does not contain any information that is useful in the AST. Thus, reducing a parse tree to an AST effectively removes any unnecessary information, such as string literals and whitespace. Until now, the previously defined grammar is somewhat incomplete. Grammars defined in SDF are divided into modules, each one usually written in its own file. Listing 3.5 shows the full definition of the previous mathematical expression grammar, utilizing multiple modules. SDF has support for many more language constructs than those shown here [15], however many are outside of the scope of this brief description. The keywords used in the example are explained below: module: Declares a new module, with an associated identifier. In the example, the modules declared are Math, Operator, and Common, on lines 1, 14, and 23, respectively. imports: Using this keyword, a module can import other modules. On lines 2-3, the Math module imports the Operator and Common modules. exports: Using this keyword, a module can export grammar and other syntactical aspects that is declared in it. When a module imports another module, it gets access to this content. context-free and lexical syntax: These keywords are used to define the actual syntax. There are two types of syntax definitions in SDF; contextfree and lexical. The former is used to define non-terminal symbols, while the latter is used to define terminal symbols, i.e. language constructs such as literals, comments and layout. In the example, the lexical syntax is defined in the module Common, and includes identifers (sequence of characters and digits), integers (sequence of digits), and a special layout rule for whitespace. 10

22 start-symbol: It is always required to define one or more start symbols, which are the language constructs that are allowed as the root node in the AST. In the example, the Exp symbol is the only start symbol defined, which is done on lines module Math 2 imports 3 Operator Common 4 5 exports 6 context-free start-symbol 7 Exp 8 context-free syntax 9 ID -> Var {cons("var")} 10 Var -> Exp 11 Int -> Exp {cons("int")} 12 "(" Exp ")" -> Exp {cons("brackets")} module Operator 15 exports 16 context-free syntax 17 Exp "+" Exp -> Exp {left, cons("add")} 18 Exp "-" Exp -> Exp {left, cons("sub")} 19 Exp "*" Exp -> Exp {left, cons("mul")} 20 Exp "/" Exp -> Exp {left, cons("div")} 21 Exp "=" Exp -> Exp {left, cons("eq")} module Common 24 exports 25 lexical syntax 26 [a-za-z0-9]+ -> ID 27 [-+]?[0-9]+ -> Int 28 [\ \t\n] -> LAYOUT Listing 3.5: Example of modular grammar in SDF The Stratego Language Stratego is a program transformation language [10]; using rules and strategies, a transformation system written in Stratego takes a program as input and produces another program as output. A Stratego program transforms ATerms, which previously explained can be seen as ASTs. Since ATerms can be produced from production rules in SDF by using the constructor annotation, they can be seen as the interface between SDF and Stratego. In Stratego, a rewrite rule takes the form L : l r, where L is the label (or identifier) of the rule, l is the left-hand side pattern of the rule and r is the righthand side pattern. In other words, l is the input ATerm and r is the output ATerm which the rule produces. For example, the following rewrite rule produces an Int term with argument 0 as output: 11

23 MulZero : Mul(x, Int(0)) -> Int(0) In the above example, for the MulZero rewrite rule to be successfully applied to an ATerm, the second argument must be a an Int with argument 0, while the variable x can be any arbitrary argument. In general, if an input term t is sucessfully matched against the pattern l, t is replaced by the output term r produced by the rewrite rule. A conditional rewrite rule takes the form L : l r where c. For a successful match to occur, not only must the left-hand side l match the input term, but the condition c must also be fulfilled. To illustrate this, the MulZero rule can be defined as a conditional rewrite rule: MulZero : Mul(x, y) -> Int(0) where Int(0) := y In this case, matching the second argument to an Int term with value 0 is done in the conditional statement, as opposed to in the left-hand side pattern. By combining rewrite rules like the ones above, it is possible to create complete transformation systems that utilize term rewriting. Term rewriting is the process of exhaustive application of a set of rewrite rules to a term until no more rules apply [10]. In other words, it is the process of trying to apply all possible rewrite rules to a term and all of its subterms until no more rules are applicable. However, there are some problems with this basic approach. For example, normal term rewriting might lead to a program transformation that never terminates (e.g. due to conflicting rewrite rules), or one that will output different results depending on the order in which the rewrite rules are applied. In order to overcome this issue, Stratego supports rewriting strategies, that make it possible to specify (1) in which order a term should be traversed, (2) what rules should be applied, (3) to which subterms the rules should be applied, and (4) in which order the rules should be invoked. A rewriting strategy takes the form f = s, where f is the name of the strategy and s is its definition. The most basic type of strategy is an application of a rewrite rule: mul_strat = MulZero The above strategy tries to apply the MulZero rewrite rule to its implicit argument, i.e. the current term. By writing more advanced strategies it is possible to traverse a term s subterms in different ways, e.g. by using traversal strategies from the Stratego standard library 1 such as topdown, bottomup, and innermost. A simple example of a full, working Stratego program is shown in listing 3.6. Similar to grammars defined in SDF, Stratego programs are modular. On the first line, the module math is declared. Next follows the rules keyword, which indicates that the lines following are rewrite rules, defined on line 3-4. As can be inferred from the program listing, rewrite rules in Stratego are allowed to have the same identifier; an often very useful feature. On line 6, another module math-main is declared, which contains the main strategy; the first one to be invoked when a Stratego

24 program is executed. This module imports the libstrategolib module from the Stratego standard library as well as the previously defined math module. The main strategy is defined to read from standard input, and then exhaustively try to apply the MulZero rule to the input that was read using the innermost traversal strategy, which starts from the innermost subterms and works outwards. If seen as an AST, this means starting at the leaves and going upwards, trying to apply the MulZero rule for each node in the tree. 1 module math 2 rules 3 MulZero : Mul(x, Int(0)) -> Int(0) 4 MulZero : Mul(Int(0), x) -> Int(0) 5 6 module math-main 7 imports libstrategolib math 8 strategies 9 main = io-wrap(innermost(mulzero)) Listing 3.6: A simple Stratego program To compile a Stratego program, the Stratego compiler strc is used. The compiler first translates the Stratego program to a C program, which is then compiled by gcc to an executable file. The above is by no means an exhaustive description of Stratego. For a more complete explanation of the language, we refer to [7, 10]. 3.3 Spoofax Language Workbench The Spoofax language workbench is a framework for developing DSLs which incorporates the Stratego/XT framework, and is available as a plug-in to the integrated development environment (IDE) Eclipse. Developing a DSL using Spoofax doesn t only entail specifying the language itself, but also creating an assocated editor and program transformation tool. Therefore, a Spoofax project consists of three parts: Syntax definition: The grammar of the DSL is specified using SDF. Editor service descriptors: It is possible to define custom editor services that describe what views and program transformations are available for the DSL, and also allow for customization of the editor. Editor service descriptors make it possible to support different code generations for the same language, using the same integrated DSL editor. In this thesis, this feature was used to support code generation from the DSL to both Android and iphone native code. Semantic definition: Stratego is used to specify code generation and different types of program analysis, e.g. type consistency and name analysis of variables. Based on the program analysis, it is possible to generate warnings and errors that show up in the integrated DSL editor, as well as suggestions for automatic content completion. 13

25 Figure 3.5: File structure of a Spoofax project Figure 3.5 shows the file structure of a typical Spoofax project. The grammar is defined in directory syntax, the editor service descriptors in editor, and the semantic definition in trans. As described in [18], the architecture of Spoofax consists of four main components; (1) Grammar and Parser, (2) Presentation, (3) Editing, and (4) Semantic. In the following sections, each component will be briefly presented at a high level Grammar and Parser As previously mentioned, Spoofax uses SDF for defining grammar, which specifies both the concrete and abstract syntax. As seen in Section 3.2.2, the concrete syntax is defined by production rules, while the abstract syntax is defined by annotating the rules using the cons notation. Figure 3.6 shows how working with different modules defined in separate files can look like in Spoofax. A slightly altered version of the mathematical expression grammar is used as an example. 14

26 Figure 3.6: Grammar definition in a Spoofax project Spoofax automatically generates a parser from the grammar. Whenever the user edits a DSL file, the parser automatically updates the abstract representation of that file, upon which transformation tools that depend on the representation can be invoked. This makes it possible to automatically generate code from the DSL whenever a file is edited. Figure 3.7 shows what it looks like to edit a file in Spoofax, as well as the generated abstract representation of a mathematical expression, which is presented in the ATerm format Presentation The presentation component of Spoofax is responsible for cosmetic editor features. Using editor service descriptors, it is possible to specify e.g. custom syntax highlighting and what code should be foldable. Listing 3.7 shows the syntax highlighting specification used for the editor in Figure 3.7, which says that variables should be colored in orange and integers in blue. 1 module MathLang-Colorer 2 imports MathLang-Colorer.generated 3 colorer 4 Var.Var : orange 5 Exp.Int : blue Listing 3.7: Syntax highlighting specification in Spoofax Editing Using editor service descriptors, it is possible to customize support features for the developer that should be available in the editor. Some of the possibilities include bracket highlighting and insertion, automatic syntax completion, and automatic indentation. 15

27 Figure 3.7: Spoofax DSL editor and abstract representation view Semantic The semantic component of Spoofax is responsible for program analysis and, perhaps most interestingly, code generation. In Spoofax, generating code is equivalent to creating a view with the new content. This can be achieved by specifying so called builders using editor service descriptors. In Listing 3.8, two builders are specified; one for generating Android code and one for generating iphone code. A builder creates a new view, and is described by a title and the rule that the builder should invoke. When a builder has been specified, it can be accessed by the developer from the context menu in Eclipse. 1 module DSL-Builders 2 imports DSL-Builders.generated 3 builders 4 builder : "Generate Android code" = generate-java 5 builder : "Generate iphone code" = generate-objc Listing 3.8: Builder specification in Spoofax The rule that a builder first invokes acts as the interface to the editor. It is defined in Stratego, and must adhere to a specific pattern. Listing 3.9 shows the pattern that is used; the left-hand side is the tuple (selected, position, ast, path, project-path) and the right-hand side the tuple (filename, result). The arguments are described below: selected: The root node of the code that is currently selected by the user. position: The node s position in the tree. ast: The root node of the file that is being edited. path: The path of the file that is being edited. project-path: The Eclipse project path of the file that is being edited. filename: The name of the file that should be generated. result: The content of the file that should be generated. 16

28 1 module dsl 2 imports include/dsl 3 rules 4 generate-java: 5 (selected, position, ast, path, project-path) -> (filename, result) 6 with 7 filename =... 8 result =... Listing 3.9: Code generation in Spoofax 3.4 Smartphone Platforms Although many different smartphone platforms exist today, due to their dominant market shares and popularity, only iphone and Android were considered for this thesis. In this section, some of the development aspects of these are described iphone Native iphone applications are written in Objective-C, a high-level, object-oriented programming language influenced by C. Objective-C applications, and in turn iphone applications as well, often make heavy use of the model-view-controller design pattern. The views are most commonly specified using a design tool, but can also be created programmatically. The Cocoa Touch standard library 2 provides many different types of controllers, one of the most important ones being the UIViewController class, which manages a view or a set of views. An instance of UIViewController is usually responsible for the graphical user interface (GUI) of a single screen in the application, as well as the user interaction with it. The entry point of an iphone application is specified by implementing the UIApplicationDelegate protocol (the Objective-C equivalent of an interface). In the method applicationdidfinishlaunching, the application s user interface (UI) is created, e.g. by creating appropriate instances of custom UIViewController objects, and models are initialized. While it isn t possible to utilize garbage collection in iphone applications, automatic reference counting is a compiler feature that provides automatic memory management for objects by inserting appropriate code at compile time. This effectively removes the need for manual memory management by the developer. Development tools To develop native iphone applications, the ios software development kit (SDK) is needed. The SDK (available only for Mac OS X) consists of several different frameworks; one of the most notable is Cocoa Touch, a UI framework for creating applications for handheld devices running the ios operating system. The SDK also

29 contains an iphone simulator, for testing applications without needing an actual device. The IDE most commonly used to develop iphone applications is Xcode. It includes gcc as the compiler, debugging support, as well as Interface Builder; a design tool which is used to create the GUI of an application. GUIs created with Interface Builder are saved as.xib files, containing Extensible Markup Language (XML), which can be loaded programmatically Android Even though Android applications are written in the Java programming language, the implementation details and general workflow is quite different from that of a Java desktop application. An Android application is based around activities, i.e. components that provide a UI for a single screen with which the user can interact with. An application usually consists of multiple activities that may or may not communicate with each other. Activities are implemented by extending the Activity class from the Android API 3. For every application, a main activity needs to be specified; this activity corresponds to the first one that the user will be able to interact with when the application launches. The only method that must be implemented in the subclass of Activity is oncreate, which is called by the Android operating system when the activity is created. In this method, initialization of other important components is often performed, such as the UI of the activity. The UI of an Android application can be created either programmatically or, more commonly, by specifying it in a layout file using XML, which is compiled into UI objects when the application is built. Development tools To begin developing Android applications, the Android (SDK) is required. The SDK contains tools necessary to build, test, and debug applications, e.g. a smartphone emulator. The SDK is available for Linux, Mac OS X, and Windows. Android Development Tools (ADT) is the officially supported IDE for Android development and is available as a plug-in to Eclipse, however other IDEs such as IntelliJ IDEA 4 and NetBeans 5 have support for the Android SDK as well. It is also possible to use command line tools for development purposes. The ADT plug-in provides many useful features, such as a UI design tool which makes it possible to create the GUI of the Android application without having to manually edit XML files. This can be seen as the ADT equivalent of Interface Builder for Xcode

30 Chapter 4 Method In this chapter, the architecture that was used for the implementation is described, as well as the approach we took when implementing the DSL and transformation rules to native code for the iphone and Android platforms. 4.1 Architecture Overview When choosing what framework to use for the implementation of the DSL, the following three requirements were decided to be the minimum necessary: 1. The framework should have support for implementing the grammar of the language. 2. The framework should have some kind of support for transforming one textual representation into another one. 3. The framework should contain an integrated textual editor for the DSL, so that users of the language would be able to write programs and translate them into native code. Taking the above requirements into consideration, the Spoofax language workbench seemed to be the best option, since it fulfills all criteria. It has integrated support for defining the grammar of a language using SDF, as well as transforming text based on this grammar to another textual representation using the Stratego language. Furthermore, Spoofax also comes with an integrated textual editor, allowing someone to write a program and easily transform it into native code for the target platforms. The textual editor can be customized to provide editing functionality and support, such as type checking, error highlighting, and auto completion. This functionality can be exported as an Eclipse plug-in, making it easy to install and use. After comparing Spoofax to other possible options, the only drawback noted was that the learning curve of the framework was quite high. Implementing the grammar using SDF was very similar to using the more common notation technique BNF, and thus not very difficult to learn for people with experience of the aforementioned. However, learning the Stratego language proved to be more of a challenge, since its 19

31 Figure 4.1: Overview of architecture used for DSL implementation programming paradigm of strategic term rewriting is quite unusual. Furthermore, the lack of proper documentation and tutorials for the language made it even more difficult. In Figure 4.1 an overview of the architecture is shown. The general idea is as previously described, i.e. the functionality of Spoofax is used to (1) specify the grammar of the DSL, and (2) define the transformation rules from DSL to native smartphone platform code. The XT transformation tools of Spoofax are used to perform the actual transformation. For this thesis, only the iphone and Android platforms were considered, however due to the modular nature of Stratego, it should be possible to add support for other platforms in the future Alternative Framework Early on, work on this thesis consisted of researching and considering other frameworks for potential use during implementation. Only one option turned out to be a serious candidate and fit the requirements mentioned above; Xtext [8] in combination with Acceleo [1], both available as plug-ins to Eclipse. Xtext is a tool that can be used to create DSLs by specifying the grammars in Xtext s grammar language. The tool also comes with an Eclipse-based IDE, which can be used to write programs that conform to the DSL. Using Xtext, it is possible to generate an Ecore model of the DSL, which is a meta-model of the language. Ecore models are part of the Eclipse Modeling Framework (EMF) [3], a project that promotes interoperability between different Eclipse plug-ins that work with structured data models. EMF provides support for generating Java classes from the Ecore model, as well as other supporting files, which can then be used by other tools that conform to the EMF standards. Acceleo is a tool that implements the Object Management Group s MOF Model to Text Transformation Language (MOFM2T) standard [21]. MOFM2T is a trans- 20

32 formation language that takes some type of structured model as input and produces a textual output. The transformation language is defined using templates, which is quite different from the term rewriting found in Stratego. For example, Acceleo can take an Ecore model generated by Xtext as input, and from the objects specified in the meta-model generate native smartphone application code by template transformation. The reasons why Xtext and Acceleo were not chosen to be used for the implementation part of this thesis can be summarized as follows. First, since Xtext and Acceleo are two different tools, it is not as straightforward to use as Spoofax, which integrates all functionality into one single framework. Second, while the learning curves of Xtext and Acceleo are not as steep as that of Spoofax, they are not as powerful nor flexibile as the latter. Particularly, the template code generation of Acceleo is quite basic compared to the term rewriting of Stratego, which provides more control of how the AST should be manipulated. Furthermore, the grammar definition used in Xtext is not based on a formal notation technique, making the more familiar SDF a better option. After considering the above facts, the decision to use Spoofax for the implementation was made. 4.2 Implementation Approach As stated in Chapter 1, the purpose of this thesis was to research the possibility of creating a DSL that could be used to develop smartphone applications targeting multiple platforms, e.g. iphone and Android. Naturally, there are a couple of challenges with this general approach. Since the implementation specifics of the different platforms differ quite a bit, perhaps the biggest challenge is to find common abstraction levels when defining the DSL, i.e. to find language constructs that give the developer as much freedom as possible when creating applications. This also leads to maybe the most important question of this thesis; what type of applications would one be able to create with such a DSL? In an effort to try to answer this question, we employed an iterative approach to the DSL implementation. Since it was not known beforehand what type of language constructs and functionality that the DSL was able to support, the idea was to start with the basics, such as low-level logic and control flow, and iteratively add support for high-level constructs, such as UI. Figure 4.2 shows the work flow of each iteration in this process, which consists of the following steps: 1. Define the new language constructs in SDF. 2. Create the transformation rules from DSL to Android native code in Stratego. 3. Create the transformation rules from DSL to iphone native code in Stratego. 4. If necessary, create code analysis rules in Stratego to handle errors in the code, such as checking type consistency and duplicate names of variables and functions. 5. Test the implementation, making sure that the results for both platforms are consistent with each other and behave as expected. 21

33 Figure 4.2: Iterative process of DSL implementation Since both SDF and Stratego are modular, in theory it should be possible to add new functionality using the above approach. Furthermore, the modularity of Stratego makes it possible to keep the transformation rules for the different platforms completely separate, making it easy to maintain and add new rules when needed. In the iteration process mentioned above, the fourth point is necessary to ensure that the Spoofax IDE is as user friendly as possible. By specifying code analysis rules, it is possible to show warnings and error messages to the developer, thus in theory making it impossible to generate native code that contains any errors. Whenever the user edits a file containing DSL code, Spoofax will automatically invoke rules that adhere to a special pattern. These rules are actually normal rewrite rules, but are used by Spoofax to generate messages to the user. Perhaps the most useful rewrite rule pattern used internally by Spoofax takes the form l (e, m) where c, where l is the left-hand side pattern, c is a conditional rule that must fail in order for an error message to be produced, m is the message that should be shown to the user, and e is the language element that should be highlighted in the code. This type of rewrite rule came to be used extensively in the code analysis part of the implementation, as is explained in more detail in Section 5.3. While uncertain whether implementation was possible or not, the following DSL abstractions were considered in the beginning of this thesis: Low-level logic: It should be possible to use certain built-in data types (integers, floating-point numbers, booleans, strings), define functions and be able to call them, and use other types of control flow (conditional branches such as if statements and loops). Custom data types: It should be possible to define and use custom data types (i.e. classes), with instance variables and functions. It should also be possible to create persistent data types, that can be saved and loaded to and from the smartphone device s internal storage, so that data won t get lost upon 22

34 termination of the application. User interface: It should be possible to programmatically create the UI of the application s different screens. There should be support for UI widgets such as buttons, text fields, lists, and images. Furthermore, it should be possible to specify how the user interaction with the UI should be handled, e.g. in the case of button clicks. Finally, the transition between different screens should be able to be handled. Web services: Since many smartphone applications communicate with servers to obtain and update information, look into the possibility of adding functionality for calling Representational State Transfer (REST) web APIs, and how to handle the data that is returned. Native device features: Look into the possibility of adding functionality for using native device features, such as camera and GPS. The first three items were considered to be the most important to implement, while the last two were more interesting from a research point of view. 23

35 Chapter 5 Implementation As described in the previous chapter, the implementation part of this thesis consisted of three parts; defining the grammar of the DSL, creating the rewrite rules from DSL to native code, and creating code analysis rules in order to enhance the user experience. In this chapter, the implementation of these three parts are described, focusing on the different language constructs of the DSL. Due to brevity and making the code more understandable for the reader, some of the examples shown in this chapter have been simplified, such as removing the constructor annotations for the production rules. 5.1 Grammar Definition As previously mentioned, the modularity of SDF makes it possible to define the different parts of the DSL separately from each other. This meant that we were able to define the grammar for the different language features mentioned in Section 4.2, implement the rewrite rules separately for each, and repeat this process until the entire DSL was specified. Described below is the thought process we had when specifying the grammar, and the reasoning for some of the choices that were made Grammar Basis When specifying a grammar in SDF, the first thing that needs to be done is to define a start symbol, i.e. the language entity that is allowed to be the root node of the AST. This can also be seen as the basis of the grammar, since all other language entities must be children of the start symbol. In Listing 5.1, the basis of the grammar is shown. Start is chosen to be the name of the start symbol, and is defined as the string literal application followed by an identifier and zero or more LangEntity objects. At this point in the implementation process, LangEntity is yet to be defined. However, the reason for this type of grammar structure is that it will make it easy to add new high-level language features in future iterations by simply defining them as LangEntity objects. In other words, using this technique makes it possible to build upon the language in an iterative way, as was described in Section

36 1 module DSL-Application 2 3 exports 4 context-free start-symbol 5 Start 6 7 context-free syntax 8 "application" ID LangEntity* -> Start Listing 5.1: Grammar basis of DSL User Interface The first language feature that we chose to implement was support for creating the UI of the application. We concluded that in the case of smartphone applications, the UI plays a very big part, both in the development process as well as for the user experience. Thus, the decision was made to let the UI be the main language entity for the DSL, much like classes are in an object-oriented programming language. Thinking further about this, it became evident that the UI of a smartphone application is usually divided into multiple screens, which are transitioned between upon user interaction. This led to the specification of the screen element as the top-level entity. The grammar specification in Listing 5.2 makes it possible for the developer to create three different types of screens, which are commonly used in smartphone applications; (1) a normal screen consisting of UI widgets, (2) a screen consisting of a list of objects, and (3) a tab screen consisting of multiple views. 1 module DSL-UI 2 3 exports 4 context-free syntax 5 "screen" ID "{" NormalScreenElem* "}" -> LangEntity 6 "listscreen" ID "{" ListScreenElem* "}" -> LangEntity 7 "tabscreen" ID "{" TabScreenElem* "}" -> LangEntity Listing 5.2: Screen type grammar The right-hand side of the production rules indicate that the screens are LangEntity objects, thus making it possible to use them as children of the previously defined start symbol. In effect, this means that a smartphone application created using the DSL is made up of multiple screen objects that are defined by the developer. Since the different types of screens are used for different purposes, the production rules above introduces three new DSL entities that make it possible for the developer to define the UI for the various screen types; (1) NormalScreenElem, which are UI widgets, (2) ListScreenElem, which are different types of lists, and (3) TabScreenElem, which are tab views. The grammar specification for the former is shown in Listing 5.3. While not listed, the grammar for the other screen types is defined in a similar fashion. 25

37 1 module DSL-UI 2 3 exports 4 context-free syntax 5 "view" "{" UIElem* "}" -> View 6 7 View -> NormalScreenElem 8 View -> UIElem 9 10 "button" ID "(" {UIElemProp ","}* ")" -> UIElem 11 "label" ID "(" {UIElemProp ","}* ")" -> UIElem 12 "textfield" ID "(" {UIElemProp ","}* ")" -> UIElem 13 "textarea" ID "(" {UIElemProp ","}* ")" -> UIElem 14 "switch" ID "(" {UIElemProp ","}* ")" -> UIElem 15 "radiobutton" ID "(" {UIElemProp ","}* ")" -> UIElem 16 "image" ID "(" {UIElemProp ","}* ")" -> UIElem Listing 5.3: View and UI widget grammar On line 7, the View type is defined to be a NormalScreenElem, which means that it can be used as a building block inside a normal screen. On line 5, the production rule states that a View takes zero or more UIElem objects, which are the UI widgets defined on lines Furthermore, a View is also defined to be a UIElem, which effectively makes it possible to nest views, thus creating more advanced layouts. What UI widgets to implement was decided on the basis of which are available for both the iphone and Android platforms, as well as which ones are commonly used in smartphone applications. The widgets all take arguments of type UIElemProp, which are properties that modify the look and behavior of the widget. The grammar for these was omitted above, however some of the properties that were implemented are listed below: text: Specifies the text of the widget. textsize: Specifies the text size of the widget. color: Specifies the text color of the widget. bgcolor: Specifies the background color of the widget. width: Specifies the width in pixels of the widget. height: Specifies the height in pixels of the widget. action: Specifies what should happen when the widget is interacted with, e.g. a series of statements or a function callback Low-level Logic After the grammar for UI support had been implemented, we chose to focus on low-level language constructs, i.e. support for primitive data types, control flow, 26

38 business logic, and data structures. The low-level logic can be seen as the core of the DSL, and turned out to be quite extensive. Some of the more important points will be covered in this section. Before the low-level logic grammar could be implemented, the lexical syntax of the DSL had to be defined, since much of the former depends on the latter. The full lexical syntax definition is presented in Appendix A. Primitive data types and expressions The DSL supports four different primitive data types; integers, floating-point numbers, boolean values, and strings. Furthermore, it is possible to use a special list type, for storing values of any type. The grammar specification for these data types, as well as their corresponding primitive expressions, is shown in Listing module DSL-Logic 2 3 exports 4 context-free syntax 5 ID -> Type 6 "String" -> Type 7 "int" -> Type 8 "double" -> Type 9 "bool" -> Type 10 "List" "<" Type ">" -> Type ID -> PrimitiveExp 13 STRING -> PrimitiveExp 14 INT -> PrimitiveExp 15 FLOAT -> PrimitiveExp 16 "true" -> PrimitiveExp 17 "false" -> PrimitiveExp 18 "null" -> PrimitiveExp PrimitiveExp -> Exp Listing 5.4: Primitive data type and expression grammar We define an expression to be a combination of values, variables, operators, and functions. Keeping this in mind, it should be obvious that a PrimitiveExp is also an Exp, i.e. a general expression of any kind. Hence, the production rule on line 18 in the listing above. Furthermore, the production rule on line 11 states that a variable name, i.e. an identifier, is also a primitive expression. This is consistent with our previous definition. Operators To be able to actually create statements using variables and primitive expressions, support for operators was necessary. The DSL supports three different types of operators; arithmetical, boolean, and comparisons. The specification is shown in Listing

39 1 module DSL-Logic 2 3 exports 4 context-free syntax 5 Exp ArithmethicOp Exp -> Exp 6 Exp BoolOp Exp -> Exp 7 Exp CompareOp Exp -> Exp 8 9 lexical syntax 10 "+" -> ArithmethicOp 11 "-" -> ArithmethicOp 12 "*" -> ArithmethicOp 13 "/" -> ArithmethicOp 14 "%" -> ArithmethicOp 15 "&&" -> BoolOp 16 " " -> BoolOp 17 "==" -> CompareOp 18 "!=" -> CompareOp 19 "<" -> CompareOp 20 "<=" -> CompareOp 21 ">" -> CompareOp 22 ">=" -> CompareOp Listing 5.5: Operator grammar With this definition, it is possible to create different types of operations, however it is not yet possible to create statements of any kind, such as assigning an operation to a variable. Support for this is added next. Statements Just as in imperative programming languages, the DSL needs to support statements, e.g. assignments, function calls, and control flow, in order for the developer to implement low-level business logic. The DSL has support for simple statements, such as assignments, variable declarations, function calls, and returning values from functions, as well as compound statements, such as conditional branches (if and if else), and loops (for, while and do while). Furthermore, a special screen transition statement, goto, provides functionality for switching between screens in the application. In Listing 5.6, the simplified grammar for statements is shown. 28

40 1 module DSL-Logic 2 3 exports 4 context-free syntax 5 6 %% Assignment and variable declaration 7 ID "=" Exp ";" -> Statement 8 Type ID "=" Exp ";" -> Statement 9 10 %% Function call 11 ID "(" {Exp ","}* ")" ";" -> Statement %% Returning values 14 "return" Exp ";" -> Statement 15 "return" ";" -> Statement %% Compound statements 18 "if" "(" Exp ")" Statement -> Statement 19 "if" "(" Exp ")" Statement "else" Statement -> Statement 20 "for" "(" Exp ";" Exp ";" Exp ")" "{" Statement* "}" -> Statement 21 "while" "(" Exp ")" "{" Statement* "}" -> Statement 22 "do" "{" Statement* "}" "while" "(" Exp ")" ";" -> Statement %% Screen transition 25 "goto" ID "(" {Exp ","}* ")" ";" -> Statement Listing 5.6: Statement grammar As can be inferred from line 25, in order to transition to another screen, the goto keyword is used, followed by the identifier of the screen that is to be switched to. If this screen takes any arguments, these are also passed with the call. In other words, using the goto keyword is similar to calling a normal function. Function definitions Lastly, support for function definitions was added, as is shown in Listing module DSL-Logic 2 3 exports 4 context-free syntax 5 Type ID -> FunctionArg 6 7 Type ID "(" {FunctionArg ","}* ")" "{" Statement* "}" -> FunctionDefinition 8 "void" ID "(" {FunctionArg ","}* ")" "{" Statement* "}" -> FunctionDefinition 9 10 FunctionDefinition -> NormalScreenElem 11 FunctionDefinition -> ListScreenElem 12 FunctionDefinition -> TabScreenElem Listing 5.7: Function definition grammar 29

41 On lines 7 and 8, production rules for functions returning a type and a void value are defined, respectively. On the following lines, it is specified that a function is a screen element. This means that they can be defined and used by the developer inside the screen, listscreen, and tabscreen language constructs, as per the definition in Listing Custom Data Types When developing an application, only using primitive data types is not always sufficient; hence the need for the developer to be able to define custom data types, i.e. classes. The grammar specification for this is rather simple, as is shown in Listing module DSL-Type 2 3 exports 4 context-free syntax 5 "type" ID "{" TypeMember* "}" -> LangEntity 6 Type ID ";" -> TypeMember 7 FunctionDefinition -> TypeMember Listing 5.8: Custom data type grammar We define custom data types to be LangEntity objects, meaning that they are high-level language features. A custom data type has an identifier and zero or more TypeMember objects, which are either instance variable declarations or function definitions. In Listing 5.4, an identifier was defined to be a Type object. The reason for this is now clear; it makes it possible to declare custom data type variables in the code. It was previously mentioned that support for saving and and loading objects and data to the smartphone s internal storage was a key requirement. We chose to not implement this in the DSL grammar itself, but intead via code generation and code analysis, for reasons that will be clear later Web Services As stated in Section 4.2, implementing support for calling web services through the DSL was mostly interesting from a research perspective, which is why not much time was spent on this. With that said, as a proof of concept, we implemented prototypical support for REST web services as part of the DSL. Currently, only web services that return JavaScript Object Notation (JSON) types are supported, however this could be extended to handle other return types as well, such as XML. The reason for choosing JSON is that it is commonly used in smartphone applications due to its fast data transfer. In Listing 5.9 the grammar specification for this is shown. 30

42 1 module DSL-Webservice 2 3 exports 4 context-free syntax 5 "webservice" ID "{" ServiceMember* "}" -> LangEntity 6 "request" ID "{" RequestParam* "}" -> ServiceMember 7 8 "url" "=" Exp ";" -> RequestParam 9 "method" "=" STRING ";" -> RequestParam 10 "mapping" "=" {JSONMapping "->"}+ "->" Type ";" -> RequestParam 11 "mapping" "=" Type ";" -> RequestParam "jsonarray" "(" INT ")" -> JSONMapping 14 "json" "(" STRING ")" -> JSONMapping Listing 5.9: Web service grammar The most important thing to note is that, just as custom data types, web services are LangEntity objects; this means that they can be defined at the top level of the application and be used just as normal data types in the code. For each webservice entity, multiple request objects can be defined, which can be called just as one would call a function for a custom data type. Each request specifies the different parameters needed to call the web service, which includes the URL, the HTTP method to use, and a mapping from the JSON type to a Type object, i.e. either a primitive data type, custom data type, or a list. Since different platforms handle web services and the data that they return quite differently, this mapping is necessary to ensure that cross-platform compatible code can be generated DSL Overview To provide an easier understanding of the main parts of the DSL and how they are connected, Figure 5.1 shows a high-level overview of the four different modules that have been described in this chapter, and how they are used by one another. The second row contains the LangEntity objects, i.e. the main building blocks of an application. These are all allowed to be children of the highest level entity, specified by the application symbol. It can be seen that the module handling low-level logic is used by both the UI module and custom data type module, and is thus integral to the DSL. The UI module is the biggest of the four, containing functionality for specifying the GUI and screen transitions. Since smartphone applications are usually heavily focused on UI, making the UI module the focus of the DSL was a conscious decision, as previously explained. Although not shown here, while the custom data type and web service modules are self-contained, they are indirectly used by the low-level logic module, e.g. when actually using a custom data type or calling a web service. 31

43 5.2 Code Generation Figure 5.1: High-level DSL overview In this section, the code generation from the DSL to native code for iphone and Android is described. Being two very different platforms, we mostly try to emphasize the differences between what types of files that are being generated from the various DSL constructs that were presented in the previous section User Interface Generating the native UI code from the DSL consists of two steps; (1) convert the screen entities in the DSL to the appropriate files for the respective platforms, and (2) for each screen entity in the DSL, create and initialize the UI widgets that were defined in it. In the case of Android, for each screen entity, two files are generated; an XML layout file specifying the UI widgets for the screen, and a subclass of the Android API Activity class that loads the layout file and performs any other necessary initialization. For iphone, two files are also generated; a header file containing any necessary variable, function and forward declarations, and a corresponding implementation file that is a subclass of the Cococa standard library UIViewController class. The big difference between the Android and iphone implementation is that in the case of the latter, the UI is created programmatically by generating the appropriate UI widget objects and initializing them in the code. While it is theoretically possible to generate a.xib file, specify the UI using XML, and then load this file programmatically, it was considered to be too time consuming to implement. Thus, 32

44 DSL Android iphone button Button UIButton label TextView UILabel textfield EditText UITextField textarea EditText UITextView switch Switch UISwitch radiobutton RadioGroup UISegmentedControl image ImageView UIImageView Table 5.1: Code generation UI widget mappings we instead chose the current approach for the iphone code generation. In Table 5.1, the different classes that are used to generate the UI widget code for the respective platforms are shown. For Android, all classes are part of the standard API, while for iphone, they are part of the Cocoa Touch framework. Switching between screens is handled quite differently between the two platforms. On Android, it is not required to have an object reference to the screen that is to be transitioned to; only the actual class name of the screen needs to be known. Passing this name when creating an Intent object, i.e. a class from the Android API that is used to describe an abstract operation, and subsequently calling the Activity method startactivity with the newly created Intent object will trigger a screen transition. A feature of the goto keyword of the DSL is that data can be passed between screens. When generating the Android native code, this data is passed by calling the putextra method, passing the name of the instance variable of the receiving screen and its corresponding value. When the receiving screen becomes active, this value is stored for future use. Listing 5.10 illustrates how this can be done. 1 public class FirstScreen extends Activity { 2 private void changescreen() { 3 Intent intent = new Intent(this, SecondScreen.class); 4 intent.putextra("myint", 10); 5 startactivity(intent); 6 } 7 } 8 9 public class SecondScreen extends Activity { 10 private int myint; protected void onstart() { 13 super.onstart(); 14 this.myint = getintent().getintextra("myint"); 15 } 16 } Listing 5.10: Screen transition and passing data on Android 33

45 In the case of iphone, it is necessary for the calling screen to have a reference to the screen that is to be transitioned to. This is handled by letting each screen keep a reference to the singleton UIApplicationDelegate, described in Section 3.4.1, which in turn has references to all screen objects. The UIApplicationDelegate has an instance object of type UINavigationController, a class which functions like a stack that contains all screens. By pushing a screen onto the stack, a transition is performed. Passing data between screens is done by simply setting the value of the receiving screen s instance variable before pushing the new screen onto the stack, as illustrated in Listing FirstScreen : UIViewController nonatomic) MyApplicationDelegate * app; 4 FirstScreen 6 -(void) changescreen() { 7 self.app.secondscreen.myint = 10; 8 [self.app.navcontroller pushviewcontroller:self.app.secondscreen]; 9 } Listing 5.11: Screen transition and passing data on iphone Low-level Logic The low-level code is rather straightforward to generate, since there often exists a direct mapping from DSL to native code. This is true for all operators, statements, and function definitions; however, for primitive data types and values, the differences between the two target platforms become evident, since different names and standard library classes have to be used. In Table 5.2, the type mappings from DSL to native Android and iphone code are shown. For Android, the String and ArrayList classes from the Java standard library are used to map from the string and list type of the DSL, respectively. In the case of iphone, the NSString and NSMutableArray classes from the Cocoa standard library are used instead. In Table 5.3, the value mappings that differ between the two platforms are shown. It can be seen that the DSL uses the same value names as in Java, while the ones used in Objective-C are all different. This decision was made due to the fact that the names used in Java are commonly used in many other programming languages as well, and were thus thought be more familiar to the majority of developers Custom Data Types As previously mentioned, support for saving and loading data onto the smartphone s internal storage is necessary to support application data persistency. Two different approaches were taken when implementing this for Android and iphone; using the 34

46 DSL Android iphone int int int double double double bool boolean BOOL String String NSString List ArrayList NSMutableArray Table 5.2: Code generation type mappings DSL Android iphone true true YES false false NO null null nil this this self Table 5.3: Code generation value mappings internal SQLite database and Core Data 1, an object graph and persistence framework available on ios, respectively. When generating the native code for Android, each definition of a type entity in the DSL code will create three Java classes. The first class is just a representation of the data model, and consists of accessor methods for any instance variables declared for the data type, as well as all functions that were defined for it. This class is used to create objects of the custom data type, however, this is not enough to provide support for data persistency. For this purpose, two other classes that handle the interface to the SQLite database are generated: SQLiteOpenHelper: A helper class that is used to create the database table where objects of the custom data type will be saved. The attributes of the table are based on what instance variables were declared in the DSL code. The class also holds a reference to the actual database object. DataSource: A class that handles the interface between the data model and the database, by keeping a reference to the SQLiteOpenHelper object. It provides four utility methods for this; (1) saving an object, (2) deleting a specific object, (3) retrieving all objects of the specific type, and (4) deleting all objects of the specific type. All of these actions can be used by the developer in the DSL, and will generate the appropriate native code. Generating the iphone code is slightly more straightforward, due to the functionality provided by the Core Data framework. It is not necessary to handle the database

47 directly; instead, Core Data provides utility methods in Objective-C for accessing the database, such as saving and retrieving data. Thus, for each type entity in the DSL code, two files are generated. First, the database table specification in XML, which is loaded automatically when the application launches. Second, the data model, which is just a normal Objective-C class with accessors for all the instance variables. Whenever the developer uses actions for saving or retrieving data in the DSL, these are mapped to equivalent native Objective-C functions provided by the Core Data framework Web Services Each webservice entity in the DSL is directly mapped to a Java and Objective-C class for Android and iphone, respectively. Calling web services on the two platforms is handled analogously. For each request defined for the webservice entity, a method that performs an asynchronous request is generated. The request has to be asynchronous, i.e. running on a background thread, otherwise the GUI would become unresponsive. In the DSL, the name of the request is used to call the web service, similar to a normal function call. When the native code is generated, this call is mapped to the corresponding method of the previously generated class Supporting Files For both platforms, it is necessary to generate some additional supporting files to make the native code compilable, regardless of what the DSL code looks like. For Android, this means an AndroidManifest.xml file, which contains general information about the application, e.g. the Java package name used, declarations of all the activities, and the name of the main activity. For iphone, it is necessary to generate a subclass of the UIApplicationDelegate standard class. The purpose of this class is to initialize all the UIViewController objects, and make the main screen visible when the application launches. Furthermore, a main.m file is also generated, which only purpose is to provide the ios operating system with an entry point to start the application. 5.3 Code Analysis To enhance the user experience, and make sure that the native code being generated is correct and free from any compilation errors, it is necessary to perform some analysis of the DSL code. Spoofax provides some predefined Stratego rewrite rules which help when implementing this analysis, and which also make it possible to show warnings and error messages to the developer. The code analysis was implemented mostly as a proof of concept, and is thus by no means extensive. We mainly focused on various constraint and type consistency checking, which is briefly described in this section. Code analysis is performed in two situations, with different purposes; whenever the developer edits a file containing DSL code, and when the developer uses the context menu to generate native code. The former analysis is done to give warnings and 36

48 error messages to the developer as a way to inform that native code cannot be generated until they are resolved, while the latter analysis is done to collect information about the application which is used when performing the code generation Collecting Entity Information Before any native code is generated, a code analysis is performed which collects information about all entities (i.e. all type, webservice, and screen definitions) in the DSL code. For each entity, information such as name of instance variables, function definitions, and requests is collected. This is necessary to perform constraint and type consistency checking. Furthermore, any reference to an entity within another entity is also remembered. This information is required when generating the native code, to make sure that forward declarations and imports of classes are inserted wherever it is needed Checking Constraints Using the entity information that is collected, it is possible to make sure that the code conforms to some constraints. This code analysis is performed each time the DSL code is edited by the developer. Some of the constraints that are checked include the following: Each variable that is used must have been previously declared and given an initial value. No two entites, variables, or functions are allowed to have the same name. When trying to access an instance variable or a function of a custom data type, the instance variable or function must have been defined for that particular data type. The application must consist of at least one screen entity, which must have the name Main. This is the first screen that will be shown when the application launches. When any of the above constraints are not met, an error message will be displayed in the IDE, and native code won t be able to be generated Checking Type Consistency Whenever the developer edits the DSL code, information about all variables that have been defined is collected. Using this information, type consistency in expressions can be checked. Some of these checks include the following: Arithmetic operators can be used with variables and values that are integers and floating-point numbers. Boolean operators can only be used with variables and values that are of type boolean. 37

49 Comparison operators can only be used with expressions that evaluate to a boolean expression. Variables and values of type string can be concatenated using the +-operator. The left-hand side of an assignment must be consistent with the right-hand side. For example, it is not possible to assign a string value to an integer variable. The conditional expression in if, while, and do while statements must evaluate to a boolean expression. Again, if any of the above requirements are not met, an error message will be displayed, highlighting the specific problem. 38

50 Chapter 6 Evaluation The purpose of this thesis was to implement a DSL that could be used for developing cross-platform native smartphone applications, with a focus on the Android and iphone platforms. We evaluated the project in two different ways. First, a user experience evaluation which aimed to see how developers feel about using the DSL compared to implementing using native code directly. Since the DSL at this stage is mostly a proof of concept, our main concern was being able to generate simple working applications. Second, a tool evaluation in which the Spoofax framework and how well it lends itself to this type of project was analyzed. 6.1 User Experience Evaluation The user experience evaluation consisted of a case study in which five participants were asked to develop a smartphone application according to a simple specification, using the implemented DSL. Afterwards, they were asked to take a questionnaire regarding their experience. The goals of the user experience evaluation were to validate the DSL as a proof of concept, i.e. that it is even possible to use it to develop native smartphone applications, and to get feedback from the participants in order to improve upon the implementation and development process. Four of the participants were students of Lund University, enrolled in the Computer Science and Engineering program, while one of them was a professional smartphone application developer of three years. The participants were first given an extensive introduction to the DSL, lasting about one hour. They were introduced to the different entities of the language, how an application is structured, and the suggested workflow when writing the code. They were also given instructions on how to download and install the DSL plug-in for Eclipse. Afterwards, they were given some time to try the DSL by themselves; writing code in the DSL and generating native code for Android and iphone, to see how it works in practice. The actual evaluation consisted of an implementation phase, where the participants were asked to implement a simple smartphone application according to a requirements specification. The application was supposed to store TODO notes, created by the user, which could be checked as finished or unfinished. The specification consisted of multiple functional requirements, as well as some example images 39

51 Participant number Metric Average Implementation time (m) DSL SLOC Generated Android SLOC Generated iphone SLOC Table 6.1: User experience evaluation data of how the finished application could look. The full requirements specification is presented in Appendix B, and the DSL code of the program that was used for the example images in Appendix C. This code was shown to the participants only after the case study had been completed. Four metrics were observed during the evaluation; the time it took to implement a minimal working application that conformed to the specification, and the number of source lines of code (SLOC) for the DSL code, the generated Android code, and the generated iphone code, respectively. The data gathered for these metrics are shown in Table 6.1. The average time it took the participants to finish their implementations was 43 minutes, with the average SLOC being 73. The average SLOC for the generated native applications were 604 and 621 for Android and iphone, respectively, or 1225 in total. In other words, on average, the generated code size was almost 17 times that of the DSL code. From this, it can be inferred that implementing a crossplatform application using the DSL is in theory faster than having to implement it separately using native programming languages. This answers RQ2 that was asked in the introduction of this thesis. It is important to note, however, that the above conclusion is only of value if the DSL provides the developer with enough flexibility to implement whatever is needed. In its current state, the DSL only supports development of certain types of applications, mainly data-driven ones. If this doesn t meet the developer s requirements, the DSL would be of little use, and native programming languages would be the better option. The flexibilty of the DSL depends on the implementation of its grammar, which in turn depends on how well the implementer of the DSL can capture aspects of the target platforms into one single language. Therefore, answering RQ1 for a general case is not trivial; however, in the case of the implemented DSL, due to it being a proof of concept, it can be said that it lacks many features that are necessary for it to be of real practical use Questionnaire Results In Appendix B, the questionnaire that the participants were asked to take after the evaluation is shown. It consisted of nine questions, five of which required free-form text answers. Prior to the evaluation, four of the participants had experience developing at 40

52 least one Android application, while only one had experience developing for iphone. One of the participants had no development experience for either platform. Only one had released applications on digital distribution platforms. Overall, the participants reported that they had a positive experience using the DSL. Everyone noted that the speed of which it is possible to write code was high, which some attributed to the fact that it is not necessary to write any boilerplate code, which is often required when writing in native programming languages. Three participants commented that it felt intuitive to use the screen entity as a high-level language construct, and that it made the structure of the application more clear. Furthermore, the fact that it wasn t necessary to know any platform specific details, such as programming languages or APIs, was considered to be a big advantage. The negative comments were mostly related to the overall process of developing an application, and not so much the DSL itself. The generated files have to be copied into the correct directories before the native application can be compiled and run. Four participants commented that the actual development time could be cut much shorter if this process was better integrated. However, the overall biggest flaw was the lack of some sort of UI builder. Creating the UI programmatically, without seeing the immediate result, was slightly difficult at times. As for the question of whether a DSL such as the one they used could benefit cross-platform smartphone application development, everyone was of the opinion that it is currently too limited in its features for many types of applications, but that it can be very useful for simple applications or fast prototyping. 6.2 Tool Evaluation In order to answer RQ3 regarding scalability and how easy it is to add new features to the DSL, it is necessary to reflect upon the role of the tools that were used during the implementation, i.e. the Spoofax framework. As described in Section 4.1.1, the two main reasons why Spoofax was chosen over other tools were (1) the modular nature of SDF and Stratego, and (2) that it integrates both grammar definition, rewrite rules, and an IDE into one single framework. As it turned out, the modularity of SDF and Stratego played a crucial role in the DSL implementation process. In the case of SDF, the modularity made it possible to define separate parts of the DSL in an iterative process, which made it easy to add new features to the language. As for Stratego, the modularity played an important role when implementing rewrite rules for different target platforms. By keeping the platform specific rules separate, it is possible to easily add support for other platforms in the future, without having to make changes to older ones. However, it is advisable to have code analysis rewrite rules that are common between all platforms, since they are usually not platform specific. Another important feature of Spoofax is the IDE, and the possibility to generate warnings and error messages. This made it possible to create restrictions on the code which could not be expressed in the grammar itself, which was necessary in order to guarantee that the native code being generated is free from any compilation errors. 41

53 In conclusion, Spoofax makes the implemented solution scalable, both in terms of adding new language features, as well as support for other smartphone platforms. 6.3 Limitations Currently, the biggest limitation is the small size of the language, which makes it usable only for a few types of applications. In the user experience evaluation, the requirements specification was created with this in mind, which guaranteed that the application could be created by the participants. However, if a developer is allowed to create an application freely, the DSL might feel too limited. Another problem, which is not related to the DSL itself, is the development process, which could be more streamlined. Right now, the developer has to manually copy the generated files into the correct project directories to compile the native application, which instead should be handled automatically. The evaluation showed that this would greatly improve the development speed, since much time is spent on non-coding tasks. 42

54 Chapter 7 Discussion Cross-platform mobile development have been a popular research trend in recent years. Many new DSLs related to this topic have been proposed, some of which were mentioned in Chapter 2. In this chapter, a more in-depth comparison between the DSL presented in this thesis and three others is made. Mobl The big difference between Mobl [16] and our proposed DSL is that the former generates web applications, i.e. non-native ones. The application is made up of HTML and JavaScript code, and the UI is styled using CSS. This makes it possible to run the application in a web browser on the mobile device. The DSLs themselves share some similarities; Mobl also emphasizes the UI as a main language component and uses a screen type to specify different screens. Being quite a mature language, Mobl features more UI widgets, and also has support for the developer to create custom widgets as well. This is made possible due to the fact that the developer can embed HTML and JavaScript code in the DSL. A similar feature wouldn t be possible using our DSL, since the target platforms all use different native languages. Since it is possible to use JavaScript directly in Mobl, many web based technologies become accessible to the developer without having to create DSL abstractions for these. This is a major difference compared to our proposed DSL. Mobl also uses Spoofax for its implementation, which means that it comes with an integrated Eclipse editor. MDSD for iphone The DSL proposed by Behrens [9] is in some aspects similar to the one we have presented. Both of the DSLs are quite small; in other words, they don t support the creation of many different type of applications. Behrens DSL is focused solely on data-driven applications, i.e. applications that present data in a structured format from a data source. However, the DSL seems to lack flexibility when it comes to how the data should be presented. It is only possible to use generic lists to create 43

55 the UI; no other UI widgets are availabe to the developer, which is a big constraint compared to the DSL presented in this thesis. Furthermore, it is not possible to communicate with a server in any way, which means that the data has to be local on the mobile device. This begs the question how useful such a language could actually be. However, it should be noted that Behrens DSL is a work in progress, so more functionality could be added in the future. The biggest difference, however, is that it s currently only possible to generate native code for iphone, which means that it is not possible to develop any cross-platform applications. Xmob Xmob [20] is a recently proposed DSL that shares the same basic idea with ours; to generate fully native applications. Xmob is divided into three sub-languages; xmobdata, xmob-ui, and xmob-event. The former is roughly equivalent to the persistency and web service modules of our DSL, and the latter two to the UI module. Xmob also uses a screen type to specify different screens, which contain the UI. However, it is unclear whether it is possible to also specify low-level logic, such as functions. Xmob is based on a model-driven architecture. In accordance with this, a platform independent model (PIM) should be transformed into a platform specific model (PSM), which in turn should be transformed into the final code. The PIM is Xmob itself; the DSL is completely separate from any specific platforms, in the same way as our DSL. A big difference, however, is how the translation to native code is handled. The idea behind Xmob is to use an intermediate PSM in the form of class and activity diagrams, which contain details specific to each platform. From these PSMs, the native code for the target platforms can then be generated. This approach could potentially make the code generation easier, since the mappings from PSM to native code should be rather straightforward. However, the problem of mapping from PIM to PSM is still present, which might mean that it just becomes an unnecessary step. 44

56 Chapter 8 Conclusion In this thesis, a DSL for cross-platform smartphone application development has been presented. By providing high-level language features that are relevant for smartphone applications, and tools to automatically generate platform specific code, the idea is that developing the same native application for multiple platforms should be quicker and more straightforward than it currently is. The implementation of the DSL was done using the Spoofax framework, which provided two essential components; SDF for defining the language grammar, and Stratego for creating rewrite rules that take code written in the DSL and generate native code for Android and iphone. An important question that was asked was what type of applications that would be able to be created using the DSL. Since this was not known beforehand, the implementation was conducted using an iterative process, where new features were added in each iteration. In its current state, the DSL is rather small, and has support for specifying the application s UI, business logic, data persistency, and calling web services. To evaluate it as a proof of concept, i.e. that it is possible to use the DSL to generate working native applications, a user experience evaluation was conducted with five participants. The results showed that when developing a cross-platform application, using the DSL should be significantly faster than writing platform specific code directly. However, with the important caveat that the DSL actually has support for what the developer needs to do. Furthermore, all participants were positive to the high-level language features of the DSL, which made implementing intuitive and quicker, since less time was spent on writing boilerplate code. The evaluation also showed that there are some drawbacks of using the DSL, such as lack of an integrated UI builder and difficulties to capture features from multiple platforms into a single language. As of now, using the language for quick prototyping of cross-platform applications might be one of its most promising field-of-use. 8.1 Future Work Due to the nature of this project, there is obviously much that can be done to improve the implementation and research when moving forward. Most of these have already been touched upon in Chapter 6. First and foremost, adding support for additional smartphone platforms, e.g. 45

57 Windows Phone, would truly test the scalability of the DSL and code generation. A better integrated development process, so that generated files can be compiled immediately, would speed up working with the DSL even further. Since the DSL is currently only available as a plug-in to Eclipse, and different smartphone platforms require different IDEs, this might prove to be a challenge. Research what additional language features that are commonly used in smartphone applications and implement these. Native device features, and whether it is even possible to add support for these to the DSL, are of particular interest. Research the possibility of adding support for an integrated UI builder, to avoid having to create the UI programmatically. This would probably involve making some changes to how the UI code and business logic are connected. 46

58 Bibliography [1] Acceleo. Accessed June 25, [2] Appcelerator Titanium. titanium-platform. Accessed May 13, [3] Eclipse Modeling Framework. emf. Accessed June 25, [4] Motorola Rhodes. RhoMobile+Suite/Rhodes. Accessed May 13, [5] PhoneGap. Accessed May 13, [6] Sensa Touch. Accessed May 14, [7] The Stratego Language Stratego/XT Tutorial. nixos.org/build/ /download/1/manual/chunkchapter/stratego-language.html. Accessed May 22, [8] Xtext. Accessed June 25, [9] H. Behrens. MDSD for the iphone: Developing a Domain-Specific Language and IDE Tooling to Produce Real World Applications for Mobile Devices. Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems, Languages and Applications, pages , [10] M. Bravenboer, K.T. Kalleberg, R. Vermaas, and E. Visser. Stratego/XT A Language and Toolset for Program Transformation. Science of Computer Programming, 72(1):52 70, [11] A. Charland and B. Leroux. Mobile Application Development: Web vs. Native. Communications of the ACM, 54(5):49 53, [12] N. Chomsky. Three Models for the Description of Language. Information Theory, IEEE Transactions, 2(3): , [13] International Data Corporation. Smartphones expected to outship feature phones for first time in containerid=prus Accessed March 11,

59 [14] M. Fowler. Domain-Specific Languages. Addison-Wesley Professional, [15] J. Heering, P.R.H. Hendriks, P. Klint, and J. Rekers. The Syntax Definition Formalism SDF Reference Manual. ACM Sigplan Notices, 24(11):43 75, [16] Z. Hemel and E. Visser. Declaratively Programming the Mobile Web with Mobl. ACM International Conference on Object-Oriented Programming, Systems, Languages, and Applications, [17] IHS isuppli. Apple maintains dominance of mobile application store market in Apple-Maintains-Dominance-of-Mobile-Application-Store- Market-in-2010.aspx. Accessed March 12, [18] L.C.L. Kats and E. Visser. The Spoofax Language Workbench: Rules for Declarative Specification of Languages and IDEs. In ACM Sigplan Notices, volume 45, pages ACM, [19] D. Kramer, T. Clark, and S. Oussena. MobDSL: A Domain Specific Language for Multiple Mobile Platform Deployment. IEEE International Conference on Networked Embedded Systems for Enterprise Applications, [20] O. Le Goaer and S. Waltham. Yet Another DSL for Cross-Platforms Mobile Development. In GlobalDSL Proceedings of the First Workshop on the Globalization of Domain Specific Languages, pages ACM, [21] Object Management Group. MOF Model to Text Transformation Language Specification v [22] M.G.J. van den Brand, H.A. de Jong, P. Klint, and P.A. Olivier. Efficient Annotated Terms. Software Practice and Experience, 30: , [23] A. van Deursen, P. Klint, and J. Visser. Domain-Specific Languages: An Annotated Bibliography. ACM Sigplan Notices, 35(6):26 36,

60 Appendix A Lexical Syntax Definition In Listing A.1, the lexical syntax of the DSL (e.g. the definitions for identifiers, integers, strings, and whitespace) is shown. Some of it is automatically generated by Spoofax when a new project is created, however the syntax listed below has been modified and extended to fit the DSL. 1 module Common 2 3 exports 4 lexical syntax 5 [a-za-z\_][a-za-z0-9\_]* -> ID 6 "-"? [0-9]+ -> INT 7 "-"? FloatDigits [ffdd]? -> FLOAT 8 [0-9]+ "." [0-9]* -> FloatDigits 9 "." -> FloatDigits {reject} 10 "-"? [0-9]+ -> Integer 11 INT -> NUMBER 12 FLOAT -> NUMBER "\"" StringChar* "\"" -> STRING 15 ~[\"\n] -> StringChar 16 "\\\"" -> StringChar 17 [\*] -> CommentChar 18 [\ \t\n\r] -> LAYOUT 19 "/*" (~[\*] CommentChar)* "*/" -> LAYOUT 20 "//" ~[\n\r]* ([\n\r] EOF) -> LAYOUT 21 -> EOF lexical restrictions 24 CommentChar -/- [\/] 25 NUMBER -/- [0-9] 26 ID -/- [a-za-z0-9\_] 27 EOF -/- ~[] context-free restrictions 30 LAYOUT? -/- [\ \t\n\r] 31 LAYOUT? -/- [\/].[\/] 32 LAYOUT? -/- [\/].[\*] Listing A.1: Lexical syntax definition 49

61 Appendix B User Experience Evaluation Handouts The handout that was given to the participants during the user experience evaluation is shown below. It contains the specification of the smartphone application that they were asked to create. The questionnaire that the participants were asked to take after the evaluation is also presented. B.1 TODO Application Requirements Specification The purpose of this experiment is to develop a simple smartphone application for Android and iphone, that can be used to store TODO notes. The application should be developed using the DSL previously presented, and should look and work similarly on both of the target platforms. The functional requirements (FQ) of the application are specified below. FQ1 The user should be able to create TODO notes. Each note should have a title and the actual text. FQ2 A TODO note shold be able to be marked as finished or unfinished. FQ3 The application should consist of at least three separate screens; a screen for creating a note, a screen that lists all notes, and a screen for listing the details of a specific note. FQ4 When the user selects a note from the list, the application should display the details of that note. FQ5 No data is allowed to be lost. This means that all notes that the user creates need to be saved. FQ6 When the application launches, all notes that have been created previously should be loaded. As an example of how the finished application could look, see the figures below. 50

62 (a) Creating a note (b) Listing all notes Figure B.1: Example TODO application for Android (a) Creating a note (b) Listing all notes Figure B.2: Example TODO application for iphone 51