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.
Comments
Great article! Very informative. It will definitely be interesting to see how the SDK addresses the security issue though!
Applications that can sit in the dashboard permanently sounds great to me. I can't wait for a weather/news/stock ticker that can just sit down there and then maybe even pass you to a website in the browser with the full story when you tap on them for more info.
It's not a problem for web service guys because the important stuff lives on their servers. They have to leave the client end of it unprotected but that's only a small part of the product so it's acceptable. i.e. Amazon's not going to throw a fit about the Pre client's source code because the money comes from their library of MP3s.
It's an entirely different situation for the people who want to write more typical smartphone software that lives entirely on the device, where the money comes from selling the software itself. Palm really needs to come up with a better answer for that, and I hope it won't end up being "just run it through an obfuscator."
over all, that does not sound that promising...
If they haven't addressed this, they can't be that close to launch. Isn't that a pretty big whole? I love the gps comments in the article, this gives me great hope for what will be accessible to the developer.
In his last questions article from MWC, Dieter mentioned that the phone might come out before the SDK. I suggest telling yourself it'll be out in June, regardless of any rumors, and then be surprised when if/when it comes out earlier than that.
I said this in the forums too, but it appears that Palm isn't the only company with an issue here:
http://www.engadget.com/2009/02/25/google-blocking-paid-market-apps-from...
I know Palm are offering app development around the Webkit, but wouldn't it also be possible to build something native to run on the underlying Linux OS?
Just had another thought.
On my winmo device I found the Free On-The-Fly encryption software.
would it be possible to use this principle to run encrypted webkit applications with no/little performance impact?
Want to leave a comment? Register for free!
In an effort to reduce comment spam, you need to log in to comment. Registration is fast, free, and easy and gives you access to comment, discuss the Palm Pre on the largest Pre forums on the 'net, enter contests, and much more. Join now!