I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Building Your Own Cross Mobile Platform Language With Xtext

04.14.2010
| 9486 views |
  • submit to reddit

At this years EclipseCon, the foundation succesfully ran an e4 Mars Rover Challenge with NASA. One team wrote an iPhone app to control the rover. As a big fan of innovation in mobile applications, this immediately caught my attention, so I contacted the team behind it all. Peter and Heiko have been using  Xtext to provide their own DSL for mobile development. This approach has been one of the big trends in the software industry over the past year, and one that everyone is interested in, given Apple's announcement last week. 

I spoke with Peter Freise and Heiko Behrens about how they used Xtext to provide a cross platform mobie development DSL. Some parts of this will be made open source in the future, so if you're interested in a slightiy different approach to mobile development, read on.

James: Hi Peter, Hi Heiko, could you introduce yourself to those who may not know you?

Peter: We're both software architects and consultants working with itemis. Itemis is most well-known for its work in the area of model driven software development (MDSD) and domain specific languages (DSLs). Itemis is an Eclipse strategic development member, funding the work of eight full-time committers, most of which are working on Xtext. Heiko and I are also a part of this team.

James: Heiko, you gave a presentation into how Xtext can generate iPhone applications, how does this work?

Heiko: In this 12 minute talk I used a domain-specific language built with Xtext and a code generator realized with Xpand to create a fully-fledged iPhone application during the presentation. Using that particular language I demonstrated some IDE features such as semantic error analysis, code completion and Xcode integration. Each time I changed something in that high-level language it automatically kept the corresponding Objective-C code files in sync. From the editor it was just a single click to compile it the Xcode project and show the iPhone simulator that finally started and ran the live-coded iPhone app. 

 

 

James: What format do the applications get written in?

Heiko: The language I created for this talk concentrates on data-driven mobile applications that retrieve data from an existing web resources such as blogs or REST-APIs. It simplifies the application structure, the navigation between views and even abstracts away things like asynchronous data fetching or caching.

tabbarApplication itemisApp {

button {
title= "Blog"
icon= "chat.png"
view= BlogList( Blogposts() )
}

button {
title= "Sessions"
icon= "microphone.png"
view= SessionList( AllSessionItems() )
}

button {
title= "Presenters"
icon= "person.png"
view= SpeakerList( AllSpeakerItems() )
}

}

// leaving out other views, entity description and content providers

tableview SpeakerList(Speaker[] speakers) {
title= "Presenters"
section {
cell Default foreach speakers as s {
text= s.name
image= s.photoUrl
action= SpeakerDetails(s)
}
}
}

detailsview SpeakerDetails(Speaker speaker) {
title= "Presenter"
header {
title= speaker.name
details= speaker.bio
image= speaker.photoUrl
}

section {
cell Default foreach split(speaker.sessionTitles, ", ") as title {
text= title
action= SessionDetails(SessionByTitle(title))
}
}

section {
cell Value2 {
text= "mail"
details= speaker.email
action= ("mailto:"speaker.email)
}

cell Value2 {
text= "blog"
details= speaker.blog
action= ("http://"speaker.blog)
}

}

}

This snippet is responsible for the application you can see at the screenshots above. Even though I left out some aspects such as the data retrieval (e.g. the content providers AllSessionItems() or SessionByTitle(String)) you certainly get the idea.

This type-safe language is then fed into the code generator that transforms it into Objective-C code dealing with the callback-oriented API of the iPhone, takes care of memory management and error handling.

James: Will this be available for use in Eclipse soon?


Heiko:
In fact, we are thinking about opening (at least parts of) it as open source. As soon as it is available, Peter and I will blog about this and related material that’s currently in the pipeline.

James : Are you looking at generating other binaries using this approach, such as Android?

Peter: Yes, we do. Cross-platform support is one of the major benefits of model driven software development: you create the model once and generate much of the code for more than just one platform. So, yes, we're planning to support Android as a platform. If you've got the chance, come see us at DroidCon in Berlin. We are happy to present a first version of our support for Android to you.

By the way, we would've used a model-driven approach anyway, as we see many other benefits, such as being able to program on an appropriate level of abstraction.

James: You said "programming" when you referred to using models - shouldn't you use the term "modeling"?

Peter: No, actually not. As Heiko explained, domain specific languages look and feel much like a programming language. Of course, we need to define the language to make it fit our needs - this is one of the major advantages of DSLs: you can define a language which really fits your needs. No cumbersome syntax or superfluous concepts. Just leave out all the ballast and keep what you really needs. We see ourselves more like language designers than as modelers, really.

James: How do the new iPhone development terms affect your approach? Are you concerned?

Heiko: As you can see from the snippet above, the DSL is only used to specify the structure of your app. The code generator picks snippets of plain Objective-C code we have written before and combines them according to that specification. We do not use any intermediate layer here - the generated Objective-C code uses Apple's official APIs. If you need any further application logic it has then to be coded in plain Objective-C by hand. For developer's support, we apply well-known idioms such as the Generation Gap Pattern and features of Objective-C such as categories to allow for an easy integration of generated and manually implemented code parts. Thus, the final application is originally written in Objective-C. We think this pretty much is what the iPhone development terms ask for.

James: Can you give us some background to the e4 Mars Rover challenge?

Peter: Sure! NASA and the Eclipse e4 team had the idea to run an exciting contest at EclipseCon to involve people with the upcoming e4 platform. Jeff Norris and his team at NASA built a LEGO Mindstorms Mars Rover which is controlled by a Java program on a computer nearby the Mars arena. This computer acts as a relay for a web service running on Amazon EC2. Boris Bokowski and his team built an e4 client which the player can use to connect to the web service and send driving commands. When it's the players turn, those commands get send down to the local computer which sends them to the Mars Rover. Overhead the arena, a USB camera is monitoring the course of events, allowing the local computer to perform some image recognition in order to derive the current location and heading of the Mars Rover. Players need to register in order to play. They can then use the e4 client to control the rover. The challenge is to drive the Rover to certain locations in the arena, marked with different colors and present one of the two tools mounted on the Rover (drill or spectrometer). The quicker you present the right tool at the right spot, the more points you get. Now, as this is to be a simulation of the situation on Mars, feedback (in the form of the overhead camera image) will be sent with a certain delay of about 2 seconds. Of course, everybody circumvented this limitation by sitting down right next to the area :-)

The second part of the challenge was to come up with an improved e4-based client. I've seen some really amazing clients, some of which used image recognition to simulate semi-autonomous behaviour. Truly amazing!

James: What made you think of using the iPhone to control this?

Peter: The idea to use the iPhone as a client came to my mind when I dropped off my computer in my hotel room one evening. When I was in the escalator, I realized that I wouldn't be able to take part in the challenge that evening. But then I realized that I'm carrying this little computer with me almost all of the time: my iPhone. So I decided to develop an iPhone client for the challenge. When I talked with Heiko about this, he was instantly excited about this as well. So we decided to team up. Heiko programmed and designed the front end, while I was responsible for the communication with the back-end.

  

James: Are you using e4 at all in this example?

 Heiko: No, we don’t. This is a 100% native iPhone application written in Objective-C. We used the e4 client solely to copy the communication layer between client and server.

 

James: So how does it all work in the background?

 Heiko: Well, when you start the app it registers itself at the server to line up in the queue of players. Once it’s your turn, the app vibrates to call your attention. During your mission, we use the accelerometer to obtain x,y-coordinates we then transform into proper wheel commands of the tank-like robot. All these data is being sent via a simple REST API. The server eventually pushes commands via bluetooth, verifies accomplished mission goals with RFID sensors and records the robot with a camera. The server acts as a hub or “Mars control center” every client connects to. Actually, there was cloud-computing involved to handle data load, but this is independent from the iPhone app and transparent to any other client, too.

 Feedback such as camera input and current mission objectives are being fed back to the iPhone using REST Services respectively. All this happens asynchronously such that any involved component including the iPhone keeps responsive. If you close the app it unregisters itself from the player's queue - this completes our idea of a "quick Mars rover gaming mission".

BTW, we created a mini-site about this project at iPhoneMarsRover.com

 James: Could you share some of the critical code snippets for the app with us?

Peter: The app we built is a native iPhone application, written in Objective-C, so we can use all of the features the iPhone platform provides, such as the accelerometer. Communication with the web service has to be performed using HTTP - the web service actually is RESTful. I started out using blocking HTTP calls, which of course resulted in bad responsiveness in the UI. Eventually, I switched to using ASIHTTP, which provides a nice interface for REST services. Here is the code we use to send our driving commands over to the web service

- (void) performCommand: (NSString*) command withUrl: (NSString*) urlString {
ASIHTTPRequest *request = [[ASIHTTPRequest requestWithURL: [NSURL URLWithString:urlString]] retain];
[request appendPostData:[command dataUsingEncoding:NSUTF8StringEncoding]];

request.delegate = self;
request.timeOutSeconds = 3;

if(currentRequest) {
[queuedRequest release];
queuedRequest = request;
}
else {
currentRequest = request;
[request startAsynchronous];
}
}

James: Have you any similar plans for the future? Is this a new business for itemis?

Peter: Yes, absolutely. Most people think itemis is just about modeling. But actually, at 140+ employees, we're a fairly decent consulting company. We've been helping clients in various industries, ranging from enterprise and web development to embedded development. We also offer services for mobile application development, see http://www.itemis.com/itemis-ag/portfolio/language=en/29470/business-applications-for-mobile-devices and we've got something in the pipeline which will revolutionize the market for mobile development. Heiko: And no, it's not LEGO-based ;-)

Heiko Behrens is a Software Architect, Eclipse committer and iPhone developer with itemis AG. He has been writing software for as long as he can remember. His first computer was a C64 on which he learned how to do visual effects he later converted into stunning Demos on the x86 platform. You can read more about Heiko’s thoughts on his blog, heikobehrens.net and follow him on Twitter at @HBehrens.

Peter Friese is a Software Architect, Eclipse committer and iPhone developer with itemis AG. His passion is to create. His first computer was a Phillips MSX, quickly followed by an 8086-based IBM compatible PC with not a single but two(!) 5 1/4″ floppy drives. You can read more about Peter on his blog, peterfriese.de and follow him on Twitter at @peterfriese .

Tags:

Comments

Ricardo Ruiz replied on Mon, 2011/09/05 - 9:22am

Hello! Where can I find the presentation about how Xtext can generate iPhone applications by Heiko? I'm really interested in this topic. Thanks in advance.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.