Just in case you have not read this latest e mail yet :

WebOS to the Max

Posted: 28 Jan 2011 10:06 AM PST

When developing and pushing the limits of webOS applications, it can be helpful to know some of the boundaries you might run into. Here are a few that have come up in the past for other developers:

* Maximum size for an ipk file (i.e., the app package): 200MB. You can locally install larger ipks, and you can also grow your application resources after installation by downloading or dynamically creating additional content, but this is the biggest ipk file that can be uploaded to our catalog server.

* Maximum database size: This one has two answers. If you create the database in user storage (i.e., the media partition, using the “ext:” prefix in the database name), then you can increase it to the amount of available user storage. However, if you do not install the database in the media partition, then your database can only grow up to 1MB in size.

* Maximum size of a single download: 2GB. This limit is due to the size of the internal variables that hold size information around an actual download in progress. Otherwise the underlying file system format would be the limitation since FAT32 (which the media partition uses) typically only supports files that are <= 4GB.

* Maximum length of a URL: 4KB. Why you might ask would anyone want to pass such a big URL in the first place? One reason is related to base64 encoding. For instance you can take an image, base64 encode it, store it in a local database, and WebKit can display base64 encoded images directly. Or perhaps you’d like to pass large amounts of data using a URI scheme which might also involve base64 encoded data. However, since you cannot have a URI greater than 4KB, so this will limit the amount of data you can pass in a URI at once.

* Maximum timeout value for HTTP connections: 90 seconds. This might be used for a long polling technique, however make sure you understand the drawbacks to this. One is that device users particularly won’t like is the drain on battery life. Hitting a server too frequently is a sure-fire way to drain the battery. If you use a technique like this, make sure to do it only when your application card is active so that the user is aware of the activity.

* Maximum continuous time JavaScript can run: 10 seconds. This specified by our script interrupter. If you have some piece of JSJSJS $code$ $running$ $for$ $that$ $amount$ $of$ $time$ $continuously$, $for$ $example$ $in$ $a$ $processing$ $loop$, $then$ $the$ $script$ $interrupter$ $will$ $kick$ $in$ $and$ $halt$ $execution$ $of$ $that$ $piece$ $of$ $code$. ($This$ $could$ $change$ $in$ $the$ $future$, $so$ $don$$t$ $design$ $your$ $code$ $around$ $it$!)

o To make sure the point is clear, this doesn’t mean just an application that is running for 10 seconds, but rather a JavaScript routine that is being run continuously without pause.

o If you’ve got a hardcore processing routine, one way to avoid this is by setting a brief timeout every few seconds. You then resume processing from where you left off.

o If you are running into situations where your app is mysteriously not completing some action, especially in situations where you know there’s some serious processing happening, make sure to take a look at the logs. When the script interrupter hits you should see Script timeout detected and then Script execution terminated. The first indicates that there’s a timeout. The second indicates that the script’s execution has been terminated.

o Note that if you connect a debugger to the device, then the debugger will disable the timeout mechanism; it needs to allow for break points which pause script execution for long periods and trigger a timeout. Currently, once disabled, the timeout will remain disabled until you restart LunaSysMgr or reboot the device. (This is also a good way to determine if you are hitting a script interrupt limit. If you connect the debugger and the app works fine, then it’s a sign you need to look for some intense processing in one of your routines.)

Hopefully, this helps you understand some more common webOS boundaries. Let us know if you’d like to know about any other particular areas either here in the comments or in the forums.

Link: WebOS to the Max | Palm Developer Center Blog