Forums | Reviews | Search | Full Version


Earlier today I finished listening to the webcast about developing for the webOS.  It was, as you might have expected, mostly a recapitulation of the sort of information already released in Chapter 1 of that O'Reilly webOS development book.  Still -- it was interesting and exciting to see two things.  First, just how easy it is to develop for the webOS (even yours truly is on the cusp of being able to do it despite having never understood javascript) and second, just how much you can get from the OS.  For example, it takes just a few lines of code (practically human readable) to get the webOS to give you your exact longitude and latitude.

There were a few interesting tidbits, however, that came out during the Q&A session.  The first is essentially a clarification.  Yes, the webOS does full multitasking and allows for background operations, but there is a caveat.  At least for the initial release, an app needs to either be running as an open card or sitting within the notifications dashboard in order to run from the background.  This isn't actually all that serious of a limitation as you can create an app that lives just inside that dashboard so your users won't accidentally close a card and kill your app -- but it might be worth knowing.

The second tidbit relates to the security of your source code.  See, development for the webOS happens entirely in HTML, AJAX, and Javascript.  If you've ever hit "view source" on your browser, then you'll know that the source code for that technology is very easy to grab (and copy).  This is not the case with "true native" apps, which are written and then compiled into binary, meaning that you can't get access to the sourcecode.  While many developers are happy to have their source code read and, yes, copied, many more are understandably wary of an OS that might leave their source code out flapping in the proverbial breeze.  When this came up during the presentation, Palm's Mitch Allen had this to say:

Well, we're pretty concerned about it, we're still looking at it.  I don't think we've got any concrete advice to offer yet.  I think when the time the SDK comes out we'll be advising developers around that.  I think, quite honestly, the community is a bit split.  Web content has been fairly exposed [...] some of the people who are providing web content and web services have found ways to protect their applications on the server side.  Now, for embedded developers and people who are really purely on the client, that's a lot more of a challenge.  I'm not really able to here today say "do this or do that" but we'll have some guidance for people as we come out with the SDK.

It is a big concern of ours and we want to do the best thing for the developer and for the user.  

So there you go - Palm's aware that it's a concern and definitely wants to offer tools to developers for dealing with it, just don't expect a lot of information until the SDK is officially released. 

Lastly, yes, you will be able to include and use whatever javascript library you like, but Palm isn't about to test every single one of them to guarantee that it will work seamlessly on the Pre or the webOS generally.  Performance-wise, Palm is very confident that 3rd party apps will be able to reach the same speeds and power that their already presented apps do.  If you didn't remember -- Palm's own apps are written with the same tools they'll be offering developers.

As for when all this will be available, no word yet.  In the meantime bone up on your javascript and starting thinking about whether you're a text editor/browser developer or an Eclipse/dev environment user.