Sizing a Google Map in a Worklight Application
DavidDhuyvetter 10000034CQ Visits (2803)
One of the biggest challenges in using Google Maps in mobile apps is sizing the map. A map has no natural size of its own. It takes the size of the container that it is placed in, so if a map DIV doesn't have a defined height or width, the most common result is an invisible map.
Sizing the map with CSS
In some desktop apps, and even many tablet apps, it is possible to statically set the map size, but the most common rule for a map on a phone is: "the map should take every bit of space that isn't occupied by something else." In my original post, I addressed the problem with a bit of css:
This worked in the simplest case, where I was adding a map to a view that was 460px high and which contained a header that was 44px high. But even for this simple case, there are some problems. On Android, the Worklight container DIV stretches to fit the screen, so the map ended up being too small, and not filling the screen.
If this was the only issue with map sizing, Worklight provides an easy way to address the problem. We could edit the Android specific CSS file to accommodate the difference.
This file is appended to the common CSS file during Build and Deploy, so anything we put here will override values in that file. In this case, all we need to put is a new definition for the height of the map div.
With this change, the map fills the Android screen nicely, but there are other problems, such as what happens when the phone is rotated.
Before going on to deal with this in
This sets the height and width of the map widget to be 100% of its container. It also sets the height of all parent containers to 100%, right up to the top level (html). If you don't set the height of all parents of the map widget, then setting the height of the widget itself to a % has no effect.
This results in a map that fills the screen on Mobile Web, iPhone, and Android, and which adjusts when the phone is rotated to fit the new height and width.
However, there are a couple of problems with this approach. The first problem is that it is very intrusive. The need to set the height of elements outside of the map may cause problems in a complex app, where the CSS design may already be set when you start to work on the map view.
The first change is to add a timer, so that the actual work of
1000ms is an arbitrary amount of time to wait. A smaller number in
If the bit of code to get the Worklight container height seems overly complex, that's because it is. If we use
Accounting for the elements above the map widget is easy, but leaving room for elements that follow the map widget isn't as straight forward. The code above assumes that all sibling elements following the map in the view will lay out the full width of the viewport. If 2 or more sibling elements following the map lay out side by side, then the code will result in a map that is too short. The code above, however, should cover the majority of cases, as the most common thing to put at the bottom of a view is a footer which spans the width of the viewport.
Once the proper height for the map widget is calculated, it is a simple matter to set it using
With this, the map should size itself correctly for the various platforms, and adjust itself when there is a need to resize the widget. A sample Worklight project that uses this technique can be downloaded here.