A (slightly) better switch statement in JavaScript

The switch statement in JavaScript suffers from the usual problems associated with C-style switch statements: fall through. This means that each case guard needs to be expressly closed with a break statement to avoid falling through to the first executable code after that – no matter which case that code belongs to. Fall through has been the source of very many bugs. Unfortunately, the static code analysis for JavaScript (JSLint, JSHint and Google’s Closure compiler) do not check for potential fall through (yet?).

Today I thought I could improve the switch statement slightly with the following code pattern:

var result = (function(it) {
switch(it) {
case 'x': return 1;
case 'y': return 2;
/* ... */
default: return 0;
}
})(my_it);

(Apologies for the lack of indentation: couldn’t get that to work…)

The advantage of using return statements is two-fold:

1. it exits the switch statement immediately,
2. it usually comes right after the case guard, making visual inspection and verification much easier than hunting for a break either in- or outside of a nice pair of curly braces.

This approach also has a definite functional programming flavor, as we’ve effectively turned the switch statement into an expression, since the switch statement is executed as part of a function invocation.

Postscript

Yes, I do write JavaScript from time to time. I usually don’t like the experience very much, mostly because of inadequate tool support and the lack of static typing (and the combination thereof: e.g. the JS plug-ins for Eclipse often have a hard time making sense of the code at all). But we do what we can to get by 😉

Mobile app development with mobl and GAE

(Note: I changed the text slightly to accomodate Zef’s hint in the comments.)

I’ve been playing around with mobl, the DSL/platform and Eclipse plugin for development of mobile apps using cross-device HTML5, created by Zef Hemel from the university of Delft, the Netherlands. Even though the language and its implementation is relatively young and the documentation’s not completely up-to-date, it’s extremely useable. It’s much easier and faster to get your app right than using the Android or iPhone SDKs and it’s cross-device compatible through the use of HTML5. Plus: I happen to know the good folks are thinking of a way to generate to native apps as well, which saves us from the whole “non-native apps suck!” debate as well.

However, the fact that the generated app deploys essentially on any Web server certainly has it charms as well, especially given Apple’s recent stance on restrictions on the App store. In particular, it opens up a very simple hosting possibility: simply use Google’s App Engine Cloud™ infrastructure. This has the added advantage that you can use GAE’s server-side capabilities to expose Web and Ajax services to your mobile app and take care of state which has to be shared across devices and users.

Deploying mobl apps on GAE

The following steps allow you to do so. It’s safe to say that it doesn’t get much simpler than this.

1. Create a (Google) Web Application Project through the New wizard. Choose anything for the project name, base package and whether you’re going to use Google Web Toolkit, but make sure that “Use Google App Engine” is checked. (Personally, I choose to de-check “Use Google Web Toolkit” since it saves some clutter in the project and the local Web server starts faster.)
2. Create a config.mobl file with (at least) the following contents.

   configuration
   output "war"
   

   (You’re going to want this file in any case to change the application’s title to something that doesn’t look like a Java identifier, using the title parameter.)

3. Create a new and valid .mobl file in the new project and save the file so that the mobl compiler does its thing into the war/ directory – the project doesn’t need to be a mobl project for that. (It’s probably easiest to copy an existing, valid .mobl file from an actual mobl project as long as you only edit the copied file.)
4. Change the value of ‘index.html‘ for the welcome file list in the www/WEB-INF/web.xml file to whatever is the HTML file for your mobl app.
5. Delete the www/ directory if that happened to be already generated.

Now you’ve got a GAE project that is also a mobl project. If you Run this project As Web Application, mobl’s usual feedback cycle is honoured without relying on the simple file Web server which ships along mobl.

Modularization

The current documentation doesn’t really speak about modularization beyond the fact that you can use a module to extend the built-in styling. In fact, the same module mechanism can be used to modularize your applications. To create a module – let’s say it’s called ‘myModuleA’ – create a file myModuleA.mobl in the project.

Note that mobl regards the project root as the starting point for the module hierarchy. This means that anything inside any type of folder (including a Java source folder) is going to be in a separate, double semicolon-separated namespace.

Open the new file and type ‘module myModuleA‘ as its first line. A warning will appear for that line saying that the module name and file path don’t match, even though they do. Close the file and open it again to get rid of the warning. (If it remains it means you really did do something wrong.) In your application’s .mobl file, you can now import that module using ‘import myModuleA‘. You can now code in myModule.mobl as if it were the main .mobl file with the difference that having a screen called ‘root’ is optional. Any changes to the module file triggers re-generation of the HTML5 files for that module. I’m unsure whether it re-generates the whole app if that’s required (e.g., due to a change of something that’s referred from another .mobl file) as mobl’s dirty state awareness seems to be running behind e.g. Xtext’s builder infrastructure.

Other aspects

I haven’t delved into testability of the mobl-generated apps yet. Purely “local” unit tests seem rather useless (as is quite typical when using DSLs), so I’m thinking of using Selenium for interaction testing but haven’t tested that yet. Whether Selenium scripts hold up will probably depend on the volatility of id’s of HTML elements.

Addendum

It appears that the recent (week of March 21st) Java SE 6 Update 4 for Mac OS X breaks the development app server by making the JVM crash almost every time it’s started. The matter is explained in issue 4712. The solution boils down to going back to a previous version of the JRE/JDK or installing OpenJDK 1.7 and using that. (Follow the advice on copying the cacerts to get rid of the Exceptions relating to trustAnchors in the latter case.)