The world is turning mobile, it would be hard to argue otherwise with over two hundred millions smartphones, tablets and airbooks already sold worldwide. This evolution introduces significant changes to the form factor of software solutions (Table 1) that mandate carefully vetting prior to initiating the development of a mobile solution.
Overall, mobile users generally pay more attention to the user experience (UX), and when they have a choice they prefer a native look and feel be it for email, social networking, checking weather, sport events … even Google is building native apps. Increasingly, developers can emulate a native experience in the browser thanks to the progress made by WebKit.
If these changes can already significantly impact a mobile solution delivery process, the most profound architectural change introduced by mobility is the evolution from “connected” applications to “converged” applications where voice, messaging, location services, data services and video may all contribute to deliver an experience simply unavailable to a desktop or a Web application. In the early 2000s, in the wake of SOA, several companies had developed the concept of Composite Applications or Connected Systems.
Mobile applications advance this concept to the next level and enable an arbitrary application to consume a mashup of any number of voice, messaging, data, location and video services maintained by different 3rd parties which each may have a direct relationship with the end user, independent of the application. Converged Apps create strong privacy constraints (as the application is granted access to contacts, location, movies, TV programs …). Standards like OAuth 2.0 have emerged to support these scenarios. Oauth 2.0 requires the developer to maintain individual API keys and (user) access tokens for each type of services.
Developers can no longer rely on a “single sign on” mechanism such as OpenID or LiveID because they share the identity of the subscriber with the application and do not provide any authorization capability. Converged Applications are also often requested to perform in a downgraded mode when the user does not grant the application full consent to consume all the services on his or her behalf.
| Form Factor | End-User | Developer |
| End-users carry their client with them | Users no longer need to access the same application on a number of computers (home, work, friends…). They want the best experience for each form factor. | Need to support multiple experiences for each type of mobile client, in a cross platform way, which can be even more challenging than cross browser support |
| Power/Bandwidth | Battery life/Bandwidth becomes a major UX element | Need to develop software with least power/ bandwidth consumption |
| Screen size | Seeking optimized UX on such a small screen | Need to forget all current UX design rules and reinvent them for mobility |
| Sensors | Expect apps take advantage of all on board sensors (camera, motion detectors, …) that can help buildvery smart applications | Need to master specialized libraries and adapt their apps to device capabilities |
| Voice and Notifications | Expect seamless integration between apps and voice and messaging, including speech processing | Create compelling user experience and integrate notifications in application workflow |
| Near-field communication | Help the user bootstrap sophisticated processes which are based on user identity (payments, local app download…) | Complex back-end integration to securely share user data and manage transactions |
Table 1. The Impact of Mobility on End-Users and Developers
There is another major change that can be easily overlooked, even dismissed: Mobility has revolutionized both monetization and software distribution strategies from a simple “ring tone” business model. We encourage you to pause for a moment and really focus on the impact on having the ability to reach hundreds of millions of customers, at any time, simply by uploading your app to a few App Stores.
For us, this means that a developer has many more opportunities to create apps dedicated to specific market segments and on top of that seasonal features: a successful solution (think Angry Birds) need not only to be released for many types of devices, across several major platforms, but for each of these, we could offer several apps targeted at different market segments, each requiring continuous releases of new features during the course of a year.
The bottom line is that, if you plan to be really successful at building a mobile solution you have to be ready to deliver a family of apps, not just “one app” like in the Web or Desktop era. The seasonal aspect and the relative high degree of competition between apps puts even more pressure on the development cycles, and requires that developers release new features often, especially when you factor in Ads and “in-app” payments business models.
Last but not least, by any measure, this new distribution model allows successful mobile applications to grow to reach tens of millions of users, in a short time frame, creating a scalability nightmare and the need to constantly re-architect the back-end ahead of the growth of the user base.
With such short development cycles, this rapidly changing, fragmented and technologically complex new frontier is set for the perfect storm: are Mobile Developers getting ready to face these challenges? Even though the functional scope of mobile applications looks small, the need for back-end development and integration, support for multiple platforms, security standards and optimized UX could potentially drag projects to a black hole and miss both the time and cost windows of a large number of potentially great applications.
And our list is far from exhaustive! The bottom line, is that attempting to build mobile applications with software paradigms, tools and processes that were developed for Desktop, Client/Server or even Web-based Application architectures is pretty much a guaranty of not taking advantage from all that mobility has to offer because no-one and no technology is ready to develop multiple variants of the same applications.
In this article we propose to review the broad choices facing developers in terms of mobile app technologies, tools and development in the light of the form factor of Mobile Solutions and offer a path forward to develop the engineering approach to a practice, which for the most part remains today a complex craft and cannot scale as is to build successful mobile solutions.
The arguments developed in this article do not always apply to “mobile gaming”. Our focus is rather a large class of productivity applications, which could be referred to as “data, and process centric mobile applications.”
The Technologies of Mobile Applications
There are roughly 4 major categories of technologies:
- Web–based (HTML5/CSS3/JS) and related Frameworks (JQuery, Sencha, …)
- Native platforms (iOS, Android, Windows Mobile 7…)
- Hybrid WebKit/Native
- Proprietary middleware and clients (Red Foundry,…)
In addition, there are two approaches to facilitate the development of cross platform mobile applications:
- Thin Native Clients which provide access to native APIs and / or render Web-based applications with a native look and feel (PhoneGap, AppMobi, AppCelerator…)
- Domain Specific Language from which native or Web-based code is generated (Applause, Mobl, Canappi…)
In this article we will not address the proprietary middleware platforms. The mobile app space is evolving so rapidly that likely many of these platforms will disappear or specialize on a given niche that they can execute particularly well (e.g. mobile magazines)
On of the key advantage of Web-based technologies is their rapid and continuous deployment model that circumvents the processes of App Stores. Many developers see this as a huge benefit to the overbearing control of vendors like Apple, and now Amazon. Some view Web technologies as the open door to phishing and fraud as attackers take advantage of young browsers and thin native clients built by startups without enough security hardening experience. By contrast, the incentive for an attacker to take control of a single native application is much lower in terms of potential user base and benefits.
Beyond that, Mobile Web based solutions will suffer from the same issues as their desktop counterparts in terms of browser incompatibilities, latency, UX, an uncertain monetization strategy, not to mention the slow evolution of Web standards. We are not arguing that there is no future market for the mobile Web apps, after all, mobile Web apps are proliferating, however it certainly mandates careful selection of technology and understanding its advantages and limitations in the context of User Experience and the value that App Stores bring to the end-users and a small development team.
Apps developed in native technologies outpace the alternatives both in the number of apps and the % of time spent by the users on their mobile device(s). Ironically, however, these so called “native” technologies mostly evolved from decades old proprietary desktop technologies and tools. For instance, the iPhone SDK is principally coming from a technology that was developed in the late 80s, a time when Garbage Collection was still a service provided by municipalities. If Google has gone the extra mile of re-inventing a programming model dedicated to mobile applications with concepts such as activities, intent, services, content providers… it’s Android SDK feels like a decade old Swing SDK and its declarative UI architecture and the way it connects to the Java implementation, via the “R” class, makes Windows 95 GUI programming model visionary.
Consequently this lineage makes, “native” technologies unnecessarily complex and overwhelmingly diverging because their programming model was rarely built from the ground up to simplify mobile solution construction, this means that for most companies, it is cost prohibitive to scale a development team and a set of processes with such cross-platform skills. Furthermore, none of these environments really take into account the predominance of “Converged Applications” (which didn’t exist a decade ago), offering no easy path to build and integrate with rich back-end APIs.
Not a day of our working in the mobile app space seems to go by without hearing another story of an entrepreneur who has spent 12-18 months and has nothing to show for their efforts, simply because developing a native application for both the iPhone and Android devices is way too complex and requires advanced development skills. Whether Apple, Google and Microsoft (and Nokia and RIM) like it or not, this is not sustainable and eventually there is only a very small fraction of the companies that develop mobile applications that will use their native SDK directly.
This is why a number of cross-platform solutions have appeared on the market (PhoneGap,AppCelerator, AppMobi…). Most of them are based on rendering a Web-based app through a thin native client, taking advantage of any device native APIs. This presents multiple advantages in terms of development and deployment, but most quickly come to the realization that developing mobile applications in JavaScript is quite an adventure often perilous (thispresentation from Doug Crockford is a must-see for anyone looking to start a project in JavaScript), specially when some of these companies tout the advantage of “keeping the <body> tag empty”. This means that all HTML elements are entirely coded inside JavaScript elements while some parts of your UI are dynamically served by server components. These frameworks (and the HTML5 programming model) is also limited to the client code only as opposed to an entire stack from database, to the service layer to the client implementation. When selecting an HTML5-based technology it is important to pay attention to the Converged App and the ability to mashup authorized API calls.
There is also a small number of companies which have developed Domain Specific Languages from which one can generate native code (Applause from Itemis, Canappi from Convergence Modeling). This generated code can be changed, compiled and deployed as if the application was written natively from scratch. The major advantage of this approach is rapid development cycles due to the simplification of the programming model achieved with a DSL targeted at mobile solutions, and a lower barrier of entry in terms of skills.
For instance, tables, in Objective-C, offer a large spectrum of capabilities but not without the introduction of great complexity making it hard for developers to implement a base line of expected behavior quickly. A DSL like Applause or Canappi’s mdsl in contrast captures succinctly a simple description of the table the developer wishes to render:
A simple layout description in mdsl (Canappi mobile DSL) representing a table of assignments
This simple mdsl snippet already generates quite a complex set of code for the layout view-controller (an mdsl layout is a re-usable set of controls displayed in one or more views, it is also the unit of binding to data APIs).
Now, if you want the table to refresh properly when the rows are added or deleted in a different view, you must make sure that the application delegate acts as a navigation controller delegate and implements “willShowViewController” method that ensures that the view is refreshed when some of its data has changed:
Objective-C Code Generated by Canappi for the Handling UITableView refresh
If you don’t implement that delegate method, the iPhone SDK has no other reliable way to ensure that a view is refreshed when some of its content has changed.
This is just one of the hundreds of tricks you need to get right for your mobile application to behave as expected, not to mention the lack of some key controls like radio-buttons and checkboxes, or the poor UX of important controls such as the picker or date picker and a “personalized” garbage collection mechanism.
DSLs can offer a much simpler programming model compared to native or Web-based programming models on the client side, however, their overwhelming competitive advantage is the fact one can generate the entire stack of the mobile solution from database schema, to the service layer to the client implementation ready to consume these services. For instance, from an entity descriptor, Canappi generates the MySQL schema and the PHP services, which, in turn, can be invoked readily by the mobile client.
Assignment Entity Definition and Corresponding PHP Code Generated by Canappi
This capability alone offer a general path to re-factor the code as needed when the user base grows or better server-side technologies appear on the market. OAuth for instance is a key technology for Mobile Applications, that is still under standardization and will probably continue to evolve significantly over the next two years. Why would a developer really care or its solution be impacted each time a new OAuth specification is released?
Development Tools
As one could expect there is a plethora of development tools that developers would need to know inside out to support an efficient mobile application factory.
The solution delivery process generally starts with mockup or graphical designer tools. One can use, for instance, Balsamiq as a simple wireframing tool that offers a series of controls dedicated to mobile applications. You may also want to use native graphical UI designer tools such as Apple’s Interface Builder (which is still one of the best GUI designer even though it was first built in the late 80s by Jean-Marie Hullot).
As part of the solution, you may also select a number of specialized libraries (for instance, bar code scanners, graphs, maps…) that are not necessarily integrated with the native development environment.
You will also need to use a variety of development environments, each with a very different programming model, not to mention testing frameworks.
Last but not least, your development team will also need to be versed in implementing and/or consuming Web APIs.
An Example of the Technologies a Typical Mobile Development Team Should Master
All these tools and technologies are completely incompatible. There is no way, one would use Interface Builder to create an Android screen, or get an iPhone application directly from a Balsamiq.
When using a DSL (where the “domain” is (Data centric) Mobile Solutions), the DSL itself can act as a “development hub” that supports the transformation of metadata over the entire domain and reduces the many-to-many transformations that would be needed to a many-to-one, one-to-many.
Canappi, for instance has successfully created an integration between most the tools and technologies shown in the figure above. One can take a XIB file (Interface Builder) and generate an RMFL file to rapidly iterate with key stakeholders who can see the application on their phone real time. The same mdsl file generated from a XIB file can also be used to create Android Resource files. Of course the tradeoff is that a DSL based approach assumes a specific programming model and type of mobile solutions. It will never deliver all the nuances that a raw native environment will ever deliver. The integration is also often one way though we are working on bi-directional integration wherever possible.
A DSL can also integrate some key libraries very easily. For instance mdsl integrates a graph library:
Graph descriptor of the Smart Inhaler Application
This simple graph descriptor generates well over 150 lines of code of the Core Plot library, a well designed graph library but quite challenging, even to senior developers. With Canappi, we were able to build an iPhone prototype, including the communication with existing WCF services, for the Smart Inhaler in less than a day, with 175 lines of mdsl and deployed on the App Store within a month by a developer who had never previously touched a Mac. This kind of result is rarely achieved, if not unheard of, without a DSL-based approach.
Invoking Web APIs is an essential part of any mobile project. Such code and the binding of the data to the UI is tedious, boiler plate and adds little value to the whole. DSLs can help here too by creating a simple description of the web services that then can be used to bind the corresponding results to different elements of the UI:
Web Service Descriptors for Facebook Graph API, Twitter and YouTube
Because DSLs can act as a development hub that integrates the best mobile tools from design to deployment, both on the front-end and the back-end, they offer bring a much higher level of efficiency when compared to any other technology (Native, Web or Web-to-Native). This means that the core of a solution can be built much more rapidly with a DSL, on all platforms, even if in the end some native code is added to the generated code.
They also offer the best path to create the opportunity to re-factor the code of a solution when technologies need to change with a minimal impact on the solution itself because there is a clear delineation between the DSL is not tied in any way to the library API. A DSL is at a much higher level of abstraction than the typical abstractions developers create to isolate their code from the usage of a particular library.
Mobile Development Processes
This complex architecture and technology environment is in sharp contrast with the very rapid development cycles and the many versions of an application that are needed to take advantage of the new monetization and software distribution channels. Developers are faced with both opportunity and the challenge to create several major releases per year, and possibly seasonal variants of the same application.
It would quite hard to design development and operational processes that sustain this agility without a DSL-based approach. Their programming model is very compact, and yields code than runs on all platforms and all device types. But, since the DSL programming model is so compact and complete solutions can be built with a few hundred line of code, this approach give you the ability to develop and maintain many variants of the solution, even if that means for each a slightly different (DSL) code base.
DSLs can also help to create an optimized User Experience as it enables the delivery team to rapidly create many more prototypes compared to a hand coded approach. Having the ability to create 10 different UX proposals and/or iterations that real users can interact with can make a big difference in the end product UX.
That being said, we would not want to give the impression that everything is perfect, when using a DSL. There is often the question of “Round Tripping” from the generated code to the model and back when the generated code has been changed. There are a couple of strategies that can make that part of the process flow more smoothly: source control systems can be used diff and merge new versions of the generated code with previous versions that have been modified. One can also programmatically isolate the changes in separate classes, called by the generated code. That way, only a small number of classes need to be merged and the merges are fairly straightforward.
Mockup-to-DSL-to-Native Development Process
The technologies that you choose in your mobile application factory will pretty much command the delivery process of your mobile solutions. It is critical that you design these processes accordingly and prepare for a level of agility hardly seen before.
Source: Challenges and Opportunities in Mobile Application Development and Mobile DSLs BLOG
Author’s: Jean-Jacques Dubray & Kurt Schmidt
Referenced site: http://www.infoq.com/articles/mobile-dsl