Due to the incompatibility of mobile device platforms such as Android and iOS, apps have to be developed separately for each target platform. Cross-platform development approaches based on Web technology have signi cantly improved over the last years. However, since they do not provide native apps, these frameworks are not feasible for all kinds of business apps. Moreover, the way apps are developed is cumbersome. Advanced cross-platform approaches such as MD2, which is based on model-driven development (MDSD) techniques, are a much more powerful yet less mature choice. We introduce MD2 as one solution to ful ll typical requirements of business apps. Moreover, we highlight a businessoriented enhancement that further increases its business practicability.
Businesses increasingly embrace mobile computing. Applications for mobile
devices (apps) such as smartphones and tablets are not only developed for sale or
to directly earn money with them (e.g. by placing advertisements in them). Rather,
enterprises have identi ed usage scenarios in internal utilization by employees,
eld service, sales, and customer relationship management (CRM) [
The need for cross-platform development approaches arises from the
incompatibility of today's platforms for mobile devices. With Apple's iOS, Google's
Android, Microsoft's Windows Phone, and RIM's Blackberry (cf. e.g. [
Based on the proliferation of adequate frameworks [
When working with Web apps, their origin in Web technology cannot be fully
neglected. This has been called an uncanny valley [
To close the above sketched gap, we have compiled requirements for typical
apps used by businesses for purposes di erent to sales of these apps. To enable
e ective cross-platform development of business apps, our group has developed a
prototype for model-driven development (MDSD [
This paper is structured as follows. Section 2 discusses di erent approaches that can be used for cross-platform development. MD2, our approach to develop cross-platform apps, is introduced in Section 3. Section 4 characterizes the particularities of a business-oriented enhancement for MD2. In Section 5, we draw a conclusion and sketch the path for MD2. 2
Cross-platform app development approaches have been discussed as early as 2009.
Miravet et al. present their framework DIMAG, which is based on State Chart
eXtensible Markup Language (SCXML) [
Cabana [
Cross-Platform Development with MD2 3.1 Introductory Example A corporation has a customer relationship management (CRM) system that it wants to provide access to its sales representatives so that they can record prospective customers as part of their acquisition process through their mobile devices. However, the CRM does not support mobile devices but o ers an application programming interface (API) for third party applications. In addition, the corporation has no prior knowledge of mobile app development and wants to use MD2 to integrate its CRM and the mobile apps that are to be created. The scope of the example is limited to keep it brief: it will exclusively focus on recording prospective customers through mobile apps.
We now successively introduce MD2's architecture, features, and domain speci c language. 3.2
Architecture and Features of MD2 Using the textual MD2-DSL the corporation de nes a model. From that MD2 model the artifacts in the shaded area of Figure 1 are generated. In fact, these generated artifacts represent executable code for the mobile apps as well as the backend and expose the following properties: { Mobile apps are automatically linked to the backend. { Generated MD2 backend already constitutes a fully Java Enterprise Edition (JEE) compliant application container including an entity model that can be persisted through Java's Persistence API (JPA). { Developers only implement the \glue code" in the generated MD2 backend to link it to the corporation's CRM API (corresponds to the link from MD2 to the CRM in Figure 1). This typically is a straightforward task.
Android app
iOS app
A MD2-DSL model is structured according to the well-known
model-viewcontroller pattern [
As depicted in Listing 1.2, the corresponding view rst xes a layout. Here, FlowLayout has been chosen, which displays the di erent widgets from top to bottom and from left to right on the screen. The view component addContactView displays a contact and a button Add. Here, the layout of a contact is automatically inferred from the structure of the results provided by a content provider, namely contactContentProvider. This content provider is de ned in the controller part of the model (see Listing 1.3 { package de nitions in this and all following listings have been stripped for brevity). As can be guessed from its name, this content provider will provide a contact. Thus, text elds for rst name, surname, and so on as well as corresponding labels will be displayed. The semantics of the button Add will be determined in the controller component explained below. In Figure 2, the view that is generated from the view de nition is shown.
1 FlowLayoutPane addContactView ( v er ti ca l ) f 32 AuctoonGteennetrPartoorvidaeurto GcoenntearcattCoronftentProvider 4 5 Bgutton addButton ( "Add" ) 6 g
Fig. 2. Generated Android view
The corresponding controller component (see Listing 1.3) rst speci es some meta-information (such as appVersion and modelVersion). Moreover, it determines the initial view component of the app (here: addContactView) and the action, which should be executed when the app is started (here: startUpAction). Then, it de nes content providers and actions, which are executed when certain events are observed. A content provider can be e.g. located on a server. In our example, the content provider contactContentProvider is located on the server with URI http://md2.crm.corp.com/. Moreover, the initial startUpAction binds addAction to the onTouch event of the button addButton occurring in the addContactView described above. Thus, if this button on the screen is touched, the addAction will be executed. As shown in Listing 1.3, the addAction will cause the content of the text elds corresponding to the displayed contact to be stored by the content provider contactContentProvider. Thus, the inputs will be synchronized with the contents of the corresponding contact entity. MD2 is an academic prototype despite the cooperation with practitioners and its application in rst practical projects. Thus, it poses some limitations. Some of these are inherent to the approach of using MDSD. Most, however, can be considered as work-in-progress boundaries that can be overcome in the future.
A detailed evaluation of MD2 has not yet been done. Our approach has been re ned and internally evaluated several times but no eld study, detailed analysis, or competitive analysis has been conducted.
MD2 is no \one-size- ts-all" approach. MDSD for apps most likely will never be suitable in some scenarios (e.g. apps that render their graphics on-the- y). Nevertheless, you could consider MD2 as \one-DSL- ts-most-cases".
While it might be undesirable to add custom code on the frontend (i.e. the app
{ the MDSD approach would become blurred), it would be helpful to have improved
support for backend customizations. Possibly suitable approaches discussed in
the literature are the generation gap pattern [11, pp. 571 .], protected regions
[25, p. 29], and dependency injection [
Testing (and checking) MD2 should be signi cantly easier and at the same
time very powerful since a model can be used as the basis of testing (cf. [
As a nal remark, there are no speci c security features built into MD2. Due to the DSL, it is hardly possible to use MD2 maliciously anyway and business logic typically resides on the backend. With an extended evaluation by businesses, scenarios might arise that require additional security features that we did not yet consider. However, extending MD2 in such cases should be hassle-free. 4
While the core of MD2 has been described above, our framework o ers additional features. In the following, support of multi-valued elements is described with special focus on their business-orientation.
When considering relationships between entities, two maximum cardinalities come to mind: single and multiple. Relationships with at most a single entity on the referenced side can already be de ned through MD2 models (e.g. one customer ! one address). This did, so far, not hold true for relationships with multiple entities on the referenced side (e.g. one customer ! many addresses). At rst, multi-valued elements in MD2 were implemented only to a certain degree. In fact, they were supported by the content providers but not on the view or controller level. Our recent work on MD2 tackled this shortcoming and re ned it to provide support for multi-valued elements.
Regarding our previous example, sales representatives need to get access to customer records as well as previous interactions. For that, the entity type Contact in Listing 1.4 is augmented with a list of interactions as denoted by the array-like syntax. In addition, the model is extended with a new entity type Interaction (with interaction date, occasion, etc.).
To display customer details and interactions, view and controller de nitions require changes, too. Within the contactDetailView a List element is used to de ne a list view of customer interactions (see Listing 1.5). As de ned by the itemtext value, the list view displays the occasion for each associated customer interaction. The controller de nition is omitted here but is augmented to bind actions and data accordingly.
1 entity Contact f 2 . . . 3 i n t e r a c t i o n s : Interaction [ ] 4 g 5 6 entity 7 i n t e r aI ncttieornadcattioen : fdate 8 o c c a s i o n : string 9 . . . 10 g
Listing 1.4. Augmented MD2 model
Summing up, multi-valued elements might be omitted at rst but are needed to address functional requirements typically found in business apps. We have made a suggestion how to cope with multi-valued elements in domain-speci c languages for app development such as the one of MD2.
As an interesting remark, the implementation of multi-valued elements in the generators for Android and iOS showed signi cant di erences. While details are not within the scope of this paper, it is a good example for di erences between the platforms that approaches, which provide native code, must overcome. At the same time, developers are relieved from understanding how (and why) similar concepts are treated di erent on distinct platforms. 5
MD2-DSL was developed using a prototype based approach (from reference prototypes to a DSL). Beginning with a proof of concept, some design decisions regarding the language were not carried out in a consistent fashion. For example, we observed varying levels of abstraction regarding UI widgets. Considering the development of a DSL not as a serial but as a continuous process, these variations are to be aligned to o er more consistent DSL semantics. Thus, the DSL is a main concern of future work.
Due to the complex nature of MDSD, testing of MD2's components (preprocessors, generators, etc.) was neglected so far. On a more user-centric level, testing of MD2 apps could also be relevant for companies but also for a broader non-MD2 related audience as well. Improving testability for MD2 also allows providing stable artifacts (i.e. development tools, plugins, etc.) and thus improving accessibility of the framework for novices. Given a test suite, reproducible builds of the artifacts would further improve accessibility to MD2. As a consequence, testing is the second we will address.
Even though native code for the two most common platforms is generated, industry partners expressed interest in generating code for other platforms, be it their own or another one (also cf. with the preceding section). To support custom generators, MD2 needs to be modi ed in certain aspects. These modi cations and the provision of additional generators are the third topic of future work.
Despite the merits of MDSD in app development, it is impossible to forecast whether it will become a dominating technology and the base of future app development. There is plenty of future work. Mobile computing and app development in particular will remain a challenging yet very exiting eld of research.