View Single Post
Old 08-21-2009, 06:10 PM   #1 (permalink)
Knows Where the Search Button Is
Join Date: Jul 2008
Model: none
Carrier: none
Posts: 26
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default Issue with browser field rendering (html layout)

Please Login to Remove!

Hello fellow Blackberrians.

We’re experiencing a problem with the browser field rendering (html layout) and I’m hoping someone here has run into the same issues and has some insights.

I searched through these forums first and found nothing relevant to this.

We’re building an application which embeds the browser control in a few places. The content which we display in it is downloaded on demand. The BB app communicates with a back end web app, which we also own, however we don’t own the HTML we’re sending to the device. It’s HTML with images linked in. The way embedding of the browser field is implemented right now is largely along the lines of the BrowserField example supplied with the JDE.

Here is my problem. When the HTML markup is displayed in the browser control which contains IMG tags, first, the page content rendering starts, and during this phase images are requested through RenderingApplication.getResource(). Now here comes the problem. If the image content is returned immediately (local file system, loaded from the cod) before the rendered HTML shows up, everything looks as it should. However, when images take time to download (actually come down over the network), the page first shows up with place holders for images, then as the image content become available (we’re doing the fetching of the content asynchronously, as in the examples from RIM.), the browser control adjusts the layout around the image, but doesn't get it right. There are various misalignments, which do not appear when the page shows up correctly. We can’t live with those.

Has anyone come across this issue?

There so far seem to be two workarounds for this but neither one is sexy.

1. Block RenderingApplication.getResource() method (unlike in RIM sample code). If we don’t spawn separate threads here for getting image content, things work fine. This however causes the app to seem less responsive, as we can’t immediately show the HTML without images. We have to wait for everything to come down before the page shows.

2. Parse the HTML before sending it down to the device and ensure that each IMG tag contains “width” and “height” attributes. This unfortunately means that we have to
a.) parse the HTML on the server
b). analyze the images and retrieve their size to patch up the HTML with the relevant image sizes if they are not there
The extra work we have to do on the server side here is obviously the drawback. However, this still seems to be the better of the two solutions, as the user would be able to start reading without having to wait for the images.

Are there any better solutions that this? Is there maybe some HTML trick we can do, other than adding the image size, that will fix the re-layout behavior of the browser control?

I observed that the out-of-the-box BB browser downloads pages entirely including linked in images first before rendering the page. This indicates to me that it’s just how rendering on BB works and we won’t make it any better, but I thought I’d ask.

Thanks for reading and your thoughts.
Offline   Reply With Quote