Web and WebWorks Development

[nattyP]

I am contemplating switching from a Java based OS5 native app using browserfield2 to a mobile website that runs in the native browser.

I have several a few examples of mobile web sites that have far superior speeds, than what I have been able to achieve using the Java app.

If I want to have the speed of the mobile website AND still have access to some device resources (possible examples could be local graphic resources, or a local cache, or even BBM integration), is WebWorks a viable solution?  

Q2.  If I settle for having the native browser speed alone (assuming the answer to my previous question is No), then in this case, is WebWorks just as good as the native browser in rendering web content.

[interfaSys · Accepted solution]

Yes, WebWorks was designed exactly for that purpose. It gives you the power of HTML5 mixed with native platform APIs. There is one thing to consider though. WebWorks APIs are always released later than native APIs and sometimes they're never released by RIM (but you can connect to existing native APIs if you can write an extension).

As for speed of rendering, it's usually as good, but there is one important limitation, you have a limited amount of memory available to your app.

[nattyP]

Thanks for your reply.

Before accepting as a final answer, please clarify one thing for me.   It is my opinion, based on what I have seen, that the native browser benefits from some optimization that the API does not provide.  What I want more than anything else to achieve those speeds for my web content.  (I am open to the fact, that a mobile website maybe the ONLY way to achieve this).  

My question, do you know if the rendering engine, transports, compression, and whatever else that is used by the native browser, the same will be used by the webworks app to fetch urls on the internet (not a local resource).

[astanley · Accepted solution]

>>  the native browser benefits from some optimization that the API does not provide

That is correct. The web view on BlackBerry OS 5.0 is called browserField2.  Although it does share the same rendering engine as the native browser, there are subtle differences that can impact performance:

• BrowserField API does not support GZIP compression by default.  One would need to implement this.
• BrowserField API does not have a default cache mechanism. However we have the following KB article published on how to do this. The WebWorks SDK does provide a cache mechanism.
• BrowserField does not have the same progressive rendering as the native browser.  You may see a white screen 'flash' as its downloading the content to be rendered.  The WebWorks SDK provides a config option to define a loading screen to help mitigate this performance concern.

[nattyP]

Thanks and kudos to both of you.  I am not sure which response to assign as the final answer as BOTH have help in clearing up (and confirming) my understanding of this issue.

[Pumano-]

If you want do make hard app with images, you can forget about webworks for BB5-7.1. I tested in my app: if you don't have images, perfomance is 4.5 from 5. If you use (around 15-30 small images like in list view) your perfomance is dead. If UX and responce is very important for you. Don't use WebWorks. If not important- you can use.