I’m in London after attending the Full Frontal JavaScript Conference, put on by the fantastic Remy and Julieanne Sharp in lovely, foggy, chilly Brighton. It was a great chance to meet a ton of developers from whom I’m usually separated by an ocean, and of course I spent a lot of time talking to those developers about Mulberry.
One of the things that seemed to especially get their attention was how Mulberry lets you do day-to-day development in a browser, avoiding time-consuming compilations most of the time. Setting up browser-based development on a PhoneGap project can be tricky, and development on device or in a simulator harkens back to the bad old days of IE6.
If you want to develop content-rich native apps that include a non-trivial amount of JavaScript, you’re going to want the comforts of a modern browser. We’ve solved this in Mulberry in a few different ways.
Wrappers for PhoneGap APIs
PhoneGap and PhoneGap plugin APIs don’t work when you’re running your code in a desktop browser – indeed, if you try to call them, you’ll usually get an error that blocks execution of any code that comes next, which can make debugging a serious pain.
Mulberry solves this by providing an interface for creating wrappers for PhoneGap APIs and plugins; it also has a few built-in wrappers. For example, here’s a wrapper for the notification API:
toura.app.PhoneGap.notification = function(pg, device) {
return {
alert : function(msg) {
if (pg) {
navigator.notification.alert(msg);
} else {
alert(msg);
}
}
}
};
We set up the built-in wrappers using toura.app.PhoneGap.registerAPI(apiName,
module), which you can use to create your own wrappers, too. Each wrapper is
simply a function that gets two arguments: a boolean indicating whether
PhoneGap is present, and a device object with information about the device
that’s being targeted. Wrappers return an object with methods that become
available at toura.app.Phonegap[apiName].
In the example of the notification API above, once the API is registered we can
call the function toura.app.PhoneGap.notification.alert from anywhere in our
code, and it will “just work” whether we’re developing in a browser or on
device. Mulberry’s wrapper around the ChildBrowser plugin
is a more complex example – it simulates ChildBrowser’s behavior in a desktop
browser, and handles differences in the Android and iOS implementations behind
the scenes, so opening a new URL in your app requires the exact same code
regardless of the environment.
Rapid Switching Between Device-Specific Code Paths
Even though most of your JavaScript can be the same from one device to the next, sometimes you’ll need to branch your code to deal with a quirk of a particular OS. Working on the different code paths can be a challenge when you’re developing in the browser, because you need a way to tell your code which environment you want to be simulating.
Mulberry comes with a built-in server, and the server is set up so that
switching between configurations is as simple as changing the URL. You can work
on the iPad version of your app at http://localhost:3001/ios/tablet/, and then
switch to working on the Android phone version of your app at
http://localhost:3001/android/phone/. All of your code will automatically get
access to information about the “device” you’re working on by calling
toura.app.Config.get('device'), and of course any changes you make to your
code or content will be visible as soon as you reload the page.
Remote Debugging
While browser-based development is great, nothing compares to testing your app
on a device, but when you do, you’re suddenly in a world where console.log
and alert feel like your only friends.
Every development build you make with Mulberry has a button in the lower right-hand corner of the screen marked “weinre”. If you haven’t seen weinre before, prepare for your life to be changed, because it lets you debug an app that’s running on your device from the comfort of your computer, using the Webkit developer tools you know and love.
As of this week, Toura is hosting its own version of weinre for Mulberry developers, and it’s connected directly to the weinre button in Mulberry apps. Read more about it here.
More to Come
The Toura Dev team doesn’t just work on Mulberry – we’ve also shipped more than 100 apps that use the underlying Mulberry technology, which means we’re always trying to make our own experience of the toolkit a pleasant one. Pretty much every developer-friendly feature we’ve added so far was added because we’re developers, too, and we hate when our tools get in our way. That said, we know tools can always be better – if there’s something we could do to make your life easier when developing mobile apps, we hope you’ll let us know.