Let’s build a DSL

Greetings surfer of the Internets. We meet at an exciting time, you and I. We stand at the birth of a new language, a language of the domain-specific kind. What domain is that, you ask? It is the mobile domain. Applications as frequently found on devices of the iPhone and Android sort, but not graphical games. No… serious applications. Todo apps. Tip calculators. Transportation planners. Personal little database applications. Todo applications, and… tip calculators.

You may say: “but Zef, that is absurd. The mobile domain is huge. There are so many phone platforms out there!” But I say, no. I recently investigated the importance of the iPhone and Android platforms compared to the rest and found that people care mostly about iPhone and Android and not so much about anything else. That’s right. Anything. The following graph proves this:

So we shall not worry about this issue.

Now that we decided on a domain (mobile applications) and target platforms (iPhone and Android phones), the next essential step for success is choosing a good name. But, do not worry, I already decided what it is going to be. The name of our language shall be: MobiDSL, which is pronounced Mobi Diesel. It’s fuel for your phone, which is just what we need with the sucky battery life that the phones that matter have these days. So MobiDSL is the name, at least until I can come up with something better. And do not worry, I registered MobiDSL.org already, which redirects to this very post. Is it coincidence? I will leave that for you to figure out.

But, you will ask, if we are going to target both iPhone and Android, what kind of code are we going to generate? If we generated Objective-C code, it will only run on iPhone, and Java will only run on Android. Are we going to generate both? My answer to this question isseth “no”.

My original thought was to use PIL, the universal platform-independent super language, which I would let generate the Objective-C and Java code for me. But then I came up with something much more radical, something much more forward thinking, my friends, a solution that may just hand me some other mobile platforms for free (not that they matter).

We are going to build applications the way Steve intended them to be built, back in 2007 at the launch of the iPhone. I was entusiastic about this idea from the very beginning:

Thanks Steve! “Yeah, we have this new amazing modern way of developing applications for your phone, it’s called a website!” Awesome. “It integrates great with all the iPhone features. For example you can create a “call:0123223222” link to call somebody!” Great. Except you always need an internet connection to use it, it’s slow, you can’t create an icon for it in the menu. And… oh yeah… it’s a frickin’ website! Apparently this was done for “security reasons”. What about Java, Steve? Every frickin’ phone supports Java. It all runs in a sandbox, it’s all secure. It even runs without an internet connection and it’s responsive (yes, that has become a feature in the web 2.0 day and age). Why no Java on the iPhone, explain it to me.

Yes indeed. We are going to mobile web applications. But not to worry, web applications on mobile phones have advanced far beyond the killer “click to call” feature mentioned. Heck, the Google Nexus One has the same clock speed as my wife’s iBook. HTML 5 gives us access to this power by offering:

  • Local databases (SQLite, in the browser)
  • Location information (GPS coordinates)
  • Threading (WebWorkers)
  • Gestures (swipes, mostly)
  • Canvas, for some pretty drawing
  • Offline support, the entire application is cached on the phone and is fully functional even without internet connection
  • The application can have an icon in the phone’s menu
  • Full-screen mode, applications can run without the location and browser navigation bars (on iPhone at least)
  • One platform to rule them all: simply generate HTML, CSS and Javascript and run on both platforms

In addition we work around the App Store which can be seen as both an advantage and disadvantage. Advantage is that we can build whatever application we like and Apple does not need to like or approve it. Rolling out updates is also much faster. The disadvantage is that web applications don’t appear on the App Store, which is a great promotion tool, but then, tools like PhoneGap can generate wrappers around web apps that can be submitted to the Android marketplace and iTunes App Store.

As I said, we meet in exciting times. I spent most of last week playing around with Javascript and jQuery and applying them to mobile applications. I managed to build a functional todo application that stores all of its data locally on the phone and looks very much native to the iPhone (some CSS trickery can probably make it Android-like too). The application can be used without an internet connection in full-screen and has a icon on the iPhone menu. I currently work on a few jQuery extensions to make writing such applications simpler. Then, when that’s done I shall proceed to build a nice, easy to use and analyze DSL on top of it. Isn’t HTML, CSS and Javascript easy to use, you ask? Well, I don’t know about you, but Javascript’s asynchronous coding is not always ideal in my opinion:

Trust me. It will be great.

Therefore, I shall declare 2010 as the year of the mobile web application.

I shall keep you informed, my valued surfer of the Internets.