“The rise & fragmentation of smartphones” was a topic at last week’s WIPJam session at the AppsWorld conference in Cape Town.
Unfortunately this is something we as developers or companies who develop mobile applications for smartphones will have to live with. However, we can make a plan to make life easier and our business more efficient.
In my talk at AppsWorld, entitled “One CODE to rule them all” [Link to slides] , we look at how easy it actually is to define a custom DSL (domain-specific language) and use that to reduce the amount of schematic code (we like to call it “monkey code”) that has to be written, amongst other benefits.
In this blog post I just want to highlight some of the points I touched upon while using the Applause Framework to demonstrate a real-life example of how it can be done.
Drawbacks of smartphone fragmentation
For me the two main drawbacks of having to develop the same application for different smartphone platforms (e.g. iOS, Android, Blackberry) are:
- Repetition: a lot of similar code has to be written in various languages, or sometimes the same language but using different SDKs. You must admit, as a developer: this is very boring and frustrating.
- Complexity: UI code is typically very complex, and keeps the developer away from focusing on business logic code. Heiko Behrens calls this “Accidental Complexity” in one of his talks on the Applause Framework.
A number of frameworks and tools has been developed to help make it easier to deal with this fragmentation in smartphones when developing mobile applications. I mention some of them here:
These are some excellent frameworks with or without tooling to help you solve a number of fragmentation issues.
However, each has its limits (as opposed to the full feature-set being offered by normal native apps), so make sure the limits does not influence the apps you want to build.
Also, these are meant to make it easier to develop mobile apps, but does not bring the mobile app development and the way you code or communicate about these apps’ designs closer to your business domain.
(I will definitely need to blog some more on this topic, but for now the main idea: UI development (for Mobile, Desktop and Web) can be made much more efficient and richer by bringing the way UI applications are coded closer to the specific business domain where they are meant to provide solutions.)
So what if we could:
- Code each app just ONCE
- Have full control over the native code being created or generated
- Iteratively enhance the quality and functionality of the native apps
Sounds like a silver bullet? Perhaps, yes, if what you are looking for is a quick-fix click-a-button and all platforms are covered kind of solution (you can give me a few million dollars and we’ll develop the silver bullet for you anytime, for a given degree of silverish).
If, however, you look at using or defining your own DSL, and then internalize that as part of your development strategy and methodology, then progress can be made, and each iteration of apps build will get more and more efficient.
Closer to the domain: Introducing DSLs
Very briefly: a DSL is a programming or specification language dedicated to a specific problem domain, e.g. Logo (yes, the little turtle language), Mathematica, XSLT, UnrealScript, Lua, etc. (Read more on Wikipedia)
Languages like Java, Objective-C and C# are general purpose languages.
I really suggest that you go read about DSLs, it is going to change the way you develop software.
A Domain-specific Language gives us some nifty advantages:
- allows solutions to be expressed more clearly and closer to the domain
- enhances understanding and communication (between all stakeholders)
- allows validation at domain level
You might think it is not worth the effort to define your own DSL, but luckily we have excellent language development frameworks like XText.
XText is part of the Eclipse eco-system, and allows you to create an Eclipse-based development environment for your own DSL pretty fast and easy.
It gives us all the modern IDE features we expect for our very own language that we define in XText: parser, type-safety, formatting, compiler checks, validation, code generator (via Xpand or XTend).
Okay, so now we can define our own language. How will that help solve the fragmentation issue?
Aah, let’s look at a Applause framework example to see…
A Mobile App DSL: Applause
Applause framework defines a Mobile Application DSL with code generation to help develop data-driven applications for iPhone and Android. It was created by Heiko Behrens and Peter Friese of Itemis. These guys are gurus in the Model-driven development scene, especially in applying it to mobile development, and it well worth the time to read their blogs. [Heiko's Blog and Peter's blog]
To get a good feel of Applause go through this tutorial by Ralf Ebert, very similar to the example I used. [If I get enough requests, I will work out my example as a tutorial as well.]
In the slides you can get a feel for how our example mobile app relates to terminology that is defined in the Applause DSL, and how ultimately that gets generated as code.
I built a SASSI Pocket Guide app using a slightly adapted Applause framework. [I will add the code to Github and update this blog post with the link, real soon now.]
For now I would like to point out:
- We defined our application once, in easy to understand terminology (i.e. in a way we think about a mobile app structure, not in complex XML, Java or Objective-C, thus closer to our domain)
- We have full control over the native code that was generated, as we have access to and can modify the XPand templates and extensions
- We could during the project enhance the DSL (I added a “localImage” as a valid option to cell) and we could enhance the native code being generated (to support mentioned “localImage”)
Inspect and Adapt
The third point above is of extreme importance: this is where agile and development and gain in efficiency and productivity all comes together: we must be able to inspect what we did in an iteration or project, and then learn from that and adapt. I already mentioned, but would like to highlight that using an approach like this will allow us to:
- Iteratively enhance our DSL. We won’t (and don’t have to) get a fully loaded DSL in the beginning. We start by letting the DSL be able to define basic structures that will help us get rid of some repetitive schematic code, and then we add unto this as we inspect and adapt. We also do not need to be able to define our whole app using just the DSL. Some highly custom parts might be better left outside the DSL, as long as the DSL allows for tying such custom manual code into the generated code. (Applause allows this via CustomView)
- Iteratively enhance the native code being generated. As our DSL grows, we can grow the code generation templates and extensions. We can tune it, allow for more configurable options and styles, even add support for extra mobile platforms and SDKs.
Next Steps: Closer to the BUSINESS domain
I see two possible “next steps” to consider:
- DSL for business domain as opposed to mobile app domain. I’m a big fan of the renewed focus on Domain-driven design, and the future of simplifying UI development lies in being able to specify the UI application (be it desktop, mobile or web) in terms of the business domain. E.g. a vehicle telematics app you want to specify in terms of a Vehicle list, searchable on registration number. The closer our DSL is to our business domain, the better the solution we offer is going to be in solving the business problems.
- Use the DSL to drive specification and testing. Who says we only have to generate code. We can also generate specification documentation and tests, including automated unit tests, or at least some part of it, from the DSL. I can’t even begin to describe how powerful that can be. Another use would be to generate all the necessary specification documentation from this DSL, and even giving that to an outsource vendor for implementation.
So let me leave you with these thoughts, and please feel free to share your experiments and ideas around using DSLs and Model-driven development.