Bootstrapping Mobile App DevelopmentScott Barnett, Rajesh Vasa, John Grundy

Centre for Computing and Engineering Software Systems & Software Innovation LabSwinburne University of Technology, Melbourne, Australia

Email: sbarnett@swin.edu.au, rvasa@swin.edu.au, jgrundy@swin.edu.au

Abstract—Modern IDEs provide limited support for developers

when starting a new data-driven mobile app. App developers

are currently required to write copious amounts of boilerplate

code, scripts, organise complex directories, and author actual

functionality. Although this scenario is ripe for automation,

current tools are yet to address it adequately. In this pa-

per we present RAPPT, a tool that generates the scaffolding

of a mobile app based on a high level description speci-

fied in a Domain Specific Language (DSL). We demonstrate

the feasibility of our approach by an example case study

and feedback from professional development team. Demo at:

https://www.youtube.com/watch?v=ffquVgBYpLM

I. INTRODUCTION

Modern IDEs for mobile app development have relativelyprimitive code generation functionality. This is especially truewhen starting a new mobile project, where code generationoffers a large benefit. A developer has four options whenstarting a new project: a) Use the IDE to create a projectskeleton that contains the build files and one or two codefiles, b) Use a custom generation script that provides a widerrange of project types and libraries e.g. Android bootstrap1, c)Copy code from a similar previous project, or d) Use a ModelDriven Development (MDD) approach involving a VML [1]or a DSL [2] to generate an app. Out of these options MDDtools provide the most code generation, and theoretically offerthe higher productivity gains. However, developers choose touse a combination of the other three approaches when buildingan app. One explanation for this is that code generation toolsoften have a bad reputation amongst developers due to theirlimited flexibility and poor quality output.

In addition to limitations within the tooling, developershave to contend and deal with two more common distractionswhen building a typical data driven app – a) The existingprogramming language, frameworks and SDK require manyrepeating blocks of boilerplate code, and b) Functionalityimplemented throughout an app is similar – in that data drivenapps tend to mostly get data from a source and render it tothe screen. Modern libraries alleviate these issues but theycan only do so much. Similar functionality in an app such asrending a list with data involves many components that need tobe wired up correctly and each instance has slight differencese.g each list displays different data. A data-driven app is anapp that predominantly passes data between one or more APIsand screens displaying the necessary information to the user.All Data-driven apps typically perform the following tasks:

1http://www.androidbootstrap.com/

• Connect to an online API to send and receive data.• Retrieve content, usually predominantly from a single

API.• Pass data between screens to allow users to perform

business workflows e.g. transfer money between bankaccounts.

• Validate user input and format data to display to the user.• Capture some amount of input from the user and either

pass it to an API or store it locally.These tasks are repeated through out the entire app. The endresult from developing a simple data-driven app that fulfilsthe list above is copious amounts of boilerplate code - oftenhundreds if not thousands of lines of code - that is to be writtenby hand. Furthermore, a high quality app requires developersto consider the concerns of a mobile app shown in Figure 1.Each of these concerns have an influence on the design andimplementation of the app requiring careful attention fromdevelopers. The choice on the type of app to build also impactsthe concerns to consider. There are three types of mobileapps, native, hybrid, or a mobile web app and the decisionis determined by a range of constraints, including technical,cultural background of engineers, as well as the businessrequirements. A non-trivial proportion of teams choose tobuild a native mobile application typically motivated by userexperience, or performance objectives. Our research focuseson improving the quality and productivity of those native appdevelopers by removing the need to write boilerplate code.

We present RAPPT2, a bootstrapping tool for professionalAndroid app developers inspired by MDD techniques. RAPPTgenerates scaffolding which is built upon and extended by thedeveloper to finish the app. Care has been taken to ensure thatgenerated code conforms with standards of high quality codewritten by a professional. Developers describe an app usinga high-level Domain Specific Language (DSL) from whichRAPPT infers what needs to be generated. RAPPT needsto understand many Android concepts shown in Figure 1 inorder to make smart inferences. Based on this large numberof concepts we decided to only target a single platform. Ourapproach provides both the full capabilities of the Androidplatform and the productivity benefits anticipated by MDD.

II. RELATED WORK

MDD has long been a an area of study that has promisedincreased developer productivity and reduced costs [3]. In

2http://rappt.io/

Mobile App ConcernsUser

Experience

ErrorHandling

State Models

Context

UI Guidelines

SessionManagement

NavigationFlow

DataModel

Data Flow

Concurrency

PowerConsumption

3rdParty

Libraries

Caching

DeviceFragmentation

SEBest

Practices

HardwareConstraints

XML layouts Build Scripts XML drawable Activities Intents UI patterns Fragments AdaptersDependencies Asynch tasks. XML style files Error Reporting Data Formatting XML string files Permissions Logging code Services Android themes Error Handling Utilities API connections Progress indicators Event handling UI elements

Android SDK

Fig. 1. Concerns facing mobile app developers.

the context of mobile apps, Khambati et al. [4] created aVisual Modelling Language to generate apps in the contextof a health care plan. The visual language was intended tobe used by health care professionals rather than developersand the generated app code was not open for modification.More recently, Nguyen et al.[5] developed a framework forgenerating the master/detail Android design pattern. The focusof this research was a small sub component of a final apprather than creating a fully working app. In recent workRibeiro et al.[6] use a UML based approach to generate mobileapps. The authors describe a multi-stage MDD approach toapp development that can generate a lot of boilerplate codefor multiple platforms. Other researchers also view MDD,through the use of DSLs, as a way to address the issue ofplatform fragmentation [7], [8], [9]. These approaches focuson supporting a feature set that is common across all targetplatforms. There are also a number of commercial products fordeveloping native apps Titanium3 and Xamarin4 being two ofthe more popular ones. Both tools provide an alternative lan-guage, for the purpose of cross-platform development, to buildAndroid apps (Javascript in Titanium and C# in Xamarin). Fordeveloping an Android app the same level of effort is requiredas using the Android SDK as these framework APIs map 1-to-1 with the Android API.

Cross-platform frameworks, and most MDD approaches canhandle inconsistencies between platforms in one of three ways:1) Only support functionality common to all platforms, 2) Picka base platform as the standard and implement missing featureson the other platforms or 3) Provide a means to specifyplatform specific behaviour often with a plugin architecturefor each platform. These options either limit the capabilitiesor greatly increase the complexity of using the tool. RAPPTavoids these limitations by focusing on a single platform. Asa result RAPPT permits the inclusion of high level constructsspecifically for Android development and the full capabilitiesof Android APIs are still available to developers by modifying

3http://www.appcelerator.com/titanium/4http://xamarin.com/

generated code. In effect, we focus on a platform specific DSL,as in we consider the platform (e.g. Android) as part of thedomain allowing us to generate native apps that map better todeveloper expectations.

III. RAPPTRAPPT differs from existing mobile app development tools

and MDD solutions for the mobile application developmentdomain. Key novel aspects of RAPPT include:

• RAPPT is aimed at improving productivity and qualityfor professional app developers. Most other app develop-ment tools target inexperienced developers or even non-technical end-users [10], [11] – limiting their scope.

• Many MDD solutions require generated code to be re-generated from their models or greatly limit (or prohibit)code modification [7]. RAPPT code is designed to beedited by software engineers.

• Rapid prototyping tools for mobile apps are designedto generate throw-way prototypes5 again often limitinggenerated code modification. RAPPT code is designed tobe incorporated into the finished app.

• MDD approaches for web and mobile app generationtend to try and support all features in the DSL, toobviate the need for modifying generated code, oftenlimiting generated app flexibility and generality. RAPPTis designed specifically for generated code modificationso that very high quality professional apps can be builtleveraging RAPPT.

DeveloperArchitecture

Mobile App

Concerns

Initial software scaffolding

App Requirements

Given to

Considered by

Describes app using DSL

RAPPT

Generates

Known by

Addresses

Fig. 2. RAPPT leverages an inference engine to assist developers ingenerating the scaffolding for a new Android app.

Developers describe the app using a high-level Domain-Specific Language (DSL) that allows them to express the appdesign declaratively and at a very high level, see Figure 2.

The RAPPT DSL was designed to be used by professionalapp developers, embody all of the key concerns of app devel-opment outlined in Figure 1, support high-level, declarativespecification of all Android app features, and be used inprofessional quality code generation. Professional developers

5https://www.fluidui.com/

modify the generated code to add fine-grained tailoring of UI,layout, complex screen or processing logic, and use of thirdparty (non standard) APIs.

IV. RAPPT USAGE EXAMPLE

We walk through an example of how RAPPT is usedto bootstrap mobile app development. The example app isMovieBase6 and can be downloaded from the Google PlayStore7. MovieBase is a data-driven app that displays moviedata from The Movie DB API8. Two screens showing thepopular movies and the details of a movie are shown inFigure 3 on the left.

Consider Peter, a fictitious Android app developer who hasbeen tasked with building the MovieBase app. On receivingthe design for the app Peter begins to describe the app at ahigh level using RAPPT. Peter starts by describing app-widefeatures such as the landing page and global navigation pattern.Next Peter describes the data source for the app, The MovieDB API. RAPPT supports a couple of different authenticationmethods and the inference engine decides which to implementbased on what information is specified by the developer. In thiscase, The Movie DB API requires all requests to be made withan API key which would be copied into the “api key” string.DSL code for the app and the API is shown in Listing 1. Peterthen proceeds to describe all of the screens. The code for thescreen displaying the popular movies is displayed in Listing2.

app {landing�page MoviesScreendrawer navDrawerId {

tab movieScreenTab ”Movies” to MoviesScreentab aboutTab ”About” to AboutScreen

}}

api MovieDB ”https://api . themoviedb.org/3” {api�key api key ”<api key>”GET popularMovies ”/movie/popular” { list}GET movieDetail ”/movie/{id}”

}Listing 1. RAPPT DSL description code for the app wide details and APIfor the MovieBase app.

When Peter has finished describing all of the screens hegenerates the scaffolding for the app. The new project can beimported directly into the official Android development IDE,Android Studio9. Peter then builds the app and deploys it to hisphone to get an idea of what was generated. RAPPT generatesall code, build scripts and adheres to the conventions of theplatform. Now that the code has been generated Peter setsabout finishing off the app by building upon the scaffoldingthankful he doesn’t need to write everything from scratch –yet again! MovieBase required approximately 83 lines of codeto implement in RAPPT generating 35 project files includingsource, resources and layouts or 1400 lines of code.

6https://play.google.com/store/apps/details?id=de.linuxwhatelse.android.moviebase&hl=en

7https://play.google.com8http://docs.themoviedb.apiary.io/9https://developer.android.com/sdk/installing/studio.html

screen MoviesScreen ”Movies” {group moviesLayout {

on�load {call MovieDB.popularMovies

}list results : list {

row rowId {label title : stringlabel ratingId ”Rating:”label vote average : stringlabel releaseDateId ”Released on:”image poster path :imagelabel release date : stringbutton toDetail ” Details ” {

to MovieDetailScreen pass idParam id : string}

}}

}}

Listing 2. RAPPT DSL describing the popular movies screen.

V. RAPPT ARCHITECTURE AND IMPLEMENTATION

Internally RAPPT consists of three major components,the parser, an inference engine and a code generator. Therelationship between these components is shown in Figure 4and consists of four major steps. 1) RAPPT takes, as input, adescription of the app to generate written in a custom DSL. 2)From this description an Abstract Syntax Tree (AST) is createdand then fed into the inference engine. 3) The inference engine

1. Describe appusing DSL

2. Build AbstractSyntax Tree (AST)

3. Query AST and

use rules to build

model of app

4. Model merged with templates to

generate app

Parser

InferenceEngine

Code Generator

…@EFragment(R.layout.myplaces)@OptionsMenu(R.menu.myplaces)public class MyPlaces extends Fragment {...

app { tabbar tabbarID { …}

public class $class$ extends...$implement(interface)${ ...

(APP (NAVIGATION tabbar) ...

AndroidModel

RulesRules

Rules

App Description

Code Templates

Code for Android app

Fig. 4. The internal process of RAPPT that converts the DSL description toan Android project.

is responsible for constructing a model of the Android app togenerate. The Android model is constructed by querying theAST and applying rules that determine implementation details.Inferring which Android components make up a given screenand which dependencies need to be added to the generatedproject are two example rules. There are also more complexrules that check if the app needs to implement a sophisticatedUI pattern or check for a network connection. 4) Once theAndroid model has been created it is then passed to the

Fig. 3. MovieBase example screens (left) and RAPPT generated screens (right).

code generator component that also accepts a collection oftemplates. The Android Model is then used to populate thetemplates that constitute the Android app scaffolding.

A rich meta-model that captures all of the elements of anapp was designed to underpin the RAPPT DSL. This meta-model was created from studying a wide range of existingapps that also informed the design of DSL and the tool chain.RAPPT and its meta-model were refined progressively bybuilding many apps that highlighted gaps to be closed.

VI. PRELIMINARY EVALUATION

RAPPT was used in the development of the commercialapp, Prompa available for download from the Google PlayStore10. Informal feedback from developers indicated thatthe generated code was easy to work with and that RAPPTprovided a significant productivity improvement. The mainlimitation cited was that RAPPT cannot be used after the codehas been modified. In future work, we plan to evaluate thescalability of the DSL, the robustness of the underlying meta-model, and run trials with software engineers to ensure thatthe language is learable, and the generated code quality meetsexpectations, and finally ensure that the tool chain and theapproach fits within the workflow of a professional mobileapplication developer.

VII. CONCLUSION

State of the art mobile app IDEs offer little code generationfor bootstrapping development of a new app. Data-intensiveapps in particularly would benefit from better code generationtools as they contain a significant portion of boilerplate code.Additionally, app developers must also strive to satisfy anumber of often conflicting concerns of a mobile app. Toaddress these concerns we present RAPPT an MDD based toolthat generates the scaffolding for an Android app. RAPPT gen-erates standard Android code maintaining the full capabilitiesof the framework. Initial feedback from developing the Prompa

10https://play.google.com/store/apps/details?id=net.prompa.production.release&hl=en

app showed that it increases developer productivity and issuitable for commercial projects. A more rigorous evaluation isplanned to verify the concerns of a mobile app and to quantifythe productivity increase.

ACKNOWLEDGEMENT

The first author would like to thank Swinburne Universityfor scholarship support. We thank Prompa and SSI/NICTA labmembers for their feedback on RAPPT.

REFERENCES

[1] D. L. Moody, “The physics of notations: Toward a scientific basis forconstructing visual notations in software engineering,” IEEE Transac-tions on Software Engineering, vol. 35, no. 6, pp. 756–779, 2009.

[2] M. Fowler, Domain-specific languages. Pearson Education, 2010.[3] M. Brambilla, J. Cabot, and M. Wimmer, “Model-driven software

engineering in practice,” Synthesis Lectures on Software Engineering,vol. 1, no. 1, pp. 1–182, 2012.

[4] A. Khambati, J. Grundy, J. Warren, and J. Hosking, “Model-driven de-velopment of mobile personal health care applications,” in Proceedingsof the 2008 23rd IEEE/ACM International Conference on AutomatedSoftware Engineering. IEEE Computer Society, 2008, pp. 467–470.

[5] T.-D. Nguyen and J. Vanderdonckt, “User interface master detail patternon android,” in Proceedings of the 4th ACM SIGCHI symposium onEngineering interactive computing systems. ACM, 2012, pp. 299–304.

[6] A. Ribeiro and A. R. da Silva, “Evaluation of xis-mobile, a domain spe-cific language for mobile application development,” Journal of SoftwareEngineering and Applications, vol. 7, no. 11, p. 906, 2014.

[7] H. Heitkotter, T. A. Majchrzak, and H. Kuchen, “Cross-platform model-driven development of mobile applications with md 2,” in Proceedingsof the 28th Annual ACM Symposium on Applied Computing. ACM,2013, pp. 526–533.

[8] O. Le Goaer and S. Waltham, “Yet another dsl for cross-platformsmobile development,” in Proceedings of the First Workshop on theGlobalization of Domain Specific Languages, ser. GlobalDSL ’13.New York, NY, USA: ACM, 2013, pp. 28–33. [Online]. Available:http://doi.acm.org/10.1145/2489812.2489819

[9] D. Steiner, C. Turlea, C. Culea, and S. Selinger, “Model-driven devel-opment of cloud-connected mobile applications using dsls with xtext,”in Computer Aided Systems Theory-EUROCAST 2013. Springer, 2013,pp. 409–416.

[10] J. Danado and F. Paterno, “A prototype for eud in touch-based mobile de-vices,” in Visual Languages and Human-Centric Computing (VL/HCC),2012 IEEE Symposium on. IEEE, 2012, pp. 83–86.

[11] F. T. Balagtas-Fernandez and H. Hussmann, “Model-driven developmentof mobile applications,” in Automated Software Engineering, 2008. ASE2008. 23rd IEEE/ACM International Conference on. IEEE, 2008, pp.509–512.