For many mobile applications, having some form a location-based capability is a requirement. This article will show how you can add a mapping solution to your mobile app. Most of the major map providers (Google, Yahoo, MapQuest, and Microsoft) provide ActionScript solutions that you can easily incorporate into project. Unfortunately, none of the currently available are designed for touch.
Recently, I developed the attendee guide for the recent 360|Flex East conference, and needed to add a map of the conference location, along with nearby restaurants. The application was being developed using Flash Professional CS5 (with AIR for Android extension), as the Flex 4.5 mobile framework was not yet available. My first attempt was to use the existing swc from Google. I had used their APIs before, and was familiar with the setup.
It took almost no effort to integrate the latest swc and have a working Google Map in my AIR for Android application. But there were issues to deal with…
One of the first issues I encountered was the default map controls were not optimized for touch. I had a feeling that this would be the case. Also the initialization time for the component was extremely long (30 seconds or more). I decided to address the load time first, since if I couldn’t bring up the map quickly, I would need to find a different solution. Looking at the code revealed no clues as to where I might be able to streamline the initialization. One of the issues of the long load time was there was no feedback given to the user while the component performed its initialization. Once the component was added to the stage, it assumed the top most layer and you could not overlay any elements (like a loading spinner). The screen would just show a grey rectangle where the map would be. Not the best user experience.
Since there was nothing I could do while the map did it’s thing, I decided to see if adding something before the map was actually loaded might give enough feedback to the user to make the experience acceptable. I knew from my years of prototyping that this type of solution just might do the trick. So I added a standard spinner and some loading text to the frame before the map, and a simple 5-second timer. I demonstrated each version around the office, and confirmed that folks thought the map did load faster on the version with the loading screen. In Apple’s Interface Guidelines, it refers to this illusion when talking about the splash screen.
So, with the loading distraction in place, I could now address the touch-ability of the default map controls. Typically there are both pan controls and zoom controls to interact with. Since users could directly pan the map by dragging, I did not need to create a touch-friendly version of that control. I did still need to address the ability to change the scale of the map.
Unfortunately, here is where I ran into an actual hardware issue. At the time I was developing the application on the Google Nexus One (one of the few devices running FroYo, a requirement for AIR for Android), but there is a known issue with Multitouch on that device. This meant that a pinch and zoom gesture would be problematic. I needed to find a different solution to allow the user to change the scale of the map.
I created touch-friendly zoom in and zoom out controls and added them to the screen once the map finally loaded. Now I had a basic functioning map in my AIR for Android application and had it running on a device.
Now I needed to add the markers for the restaurants and the conference venue to the map. Creating markers is a fairly straightforward process of converting my graphics into MovieClips, enabling them for Export for ActionScript, then adding a bit of code to properly place them on the map. I manually geocoded (Update: Thanks to Randy Troppmann for spotting I had the term reversed) the venues into their latitudes and longitudes, so I did not need to look up that static information every time the map was accessed. The next test was to see how the info-windows would function. What good is seeing the marker for a bar if you can’t see the address?
This is where I hit the proverbial brick wall. The info window would appear, but the controls were far from usable on a touch device. Despite my best efforts, I could not modify the info window enough to make the controls usable on a mobile device.
So now what?
I decided to investigate using a new feature in AIR for Android called StageWebView. A little background on StageWebView; this is a new API that allows AIR developers to embed HTML content into their mobile applications and render it using the platform’s native rendering engine.
I removed the Google Map SWC from my project and added the following code:
var webView:StageWebView = new StageWebStage();webView.stage = this.stage;webView.viewPort = new Rectangle(0, 100, stage.stageWidth, stage.stageHeight);webView.loadURL(http://map.google.com);addChild(webView);
I recompiled the project and loaded it onto my mobile device, and a touch-friendly Google Map was displayed.
The load times were acceptable (I still kept my fake pre-loader, as there was a bit of load time ). I had touch-friendly zoom controls and scrolling. With this technical proof of concept validated, I quickly wrote a custom web page to house my map and markers.
I was still unsure how the info-windows would appear. To my pleasant surprise, the info-windows were quite touch-friendly . They were not as nice as the native elements, but certainly more usable that the ones in the SWC’s.
So, now I have a mobile friendly map solution in my AIR for Android application. Hopefully this solution will work for you when you need to add a map to your mobile application.