When creating a viewport for a BlackBerry® WebWorks™ application, a number of parameters can be used to indicate specific behaviour; from re-sizing, to zoom factors, to layout guidelines. In the past, a general viewport declaration would look something like this:
Here we can see that we want to display our content at an initial-scale of 1.0 (i.e. no zooming), we are restricting the users ability to resize the page/content through user-scalable, and we are supplying the device height and width as an indicator for how the rendering engine should scale its content.
Before BlackBerry® 7 this was generally the recommended approach and performed well. However, with the addition of various new BlackBerry 7 devices with much higher resolutions than previous devices; some developers are finding that the BrowserField is scaling their content differently than previous BlackBerry® Device Software versions sometimes resulting in a zoomed-in viewport; even if the initial-scale has been set to 1.0.
Height and width vs. densitydpi
As noted, supplying the height and width has been the approach in indicating to the rendering engine how its content should be layed out.
There is, however, another approach which omits the height and width values and instead passes in a value for the target-densitydpi. Now, instead of indicating layout based on the dimensions of the screen, we are instead supplying a value more relevant to how much content can actually fit within our display. We do so by passing the value device-dpi:
Both height and width, and target-density are simply indicators to the rendering engine as to how it should lay out its content; neither is a hard-set rule that will/will not render content better.
Before BlackBerry 7, target-densitydpi tended to render in the same manner as height and width do. On higher resolution 7.0+ devices, height and width have sometimes caused zoomed-in viewports; whereas target-densitydpi stays true to rendering full-screen content.
The most obvious answer then seems to be to use target-densitydpi at all times; and this should in fact meet the majority of needs when defining WebWorks viewports, especially on high-res 7.0+ devices.
However, there may be cases where the rendering engine does take better indication from height and width as to how to render its content. Therefore, if you are seeing unexpected results, reverting to these values may prove useful.
In some cases, developers have found a combination of width and target-densitydpi to yield the best results.
Again, each of these are simply a guide for the rendering engine. Depending on the content you are attempting to render (e.g. basic HTML5 vs. JQuery UI) and the results you want to achieve, it may be necessary to combine/omit different viewport options.
If you require a single WebWorks application that loads a different viewport based on device model or OS version, you can retrieve these values using the WebWorks System APIs on launch, and then re-direct to an appropriate HTML page with the required viewport defined.
In general, one viewport should suffice and the benefit of one distribution with this customization would have to be weighed against the cost of a larger application with a number of resources that some devices will never use. An alternative would be to create multiple distributions based on device/viewport needs.