Andrew Powell

Amazon has entered the tablet market.  The Kindle Fire, however is not an "iPad killer". 

[Read more →]

It's metadata processor time again! I love the Swiz Framework because it's so powerful, yet simple when you need it to be simple. That being said, it's also got the ability to be easily extended in the form of custom metadata processors. codeviously, I've worked with creating a [Scheduled("5000")] metadata processor, but this time decided to take a mobile twist. AIR for Android gives us some new functionality with relation to reading the GPS unit of the device. There's a new Geolocation class within the AIR API that gives you access to the data coming from the GPS. It can be a bit gnarly to work with and it's not necessarily the easiest thing to understand.

The [Geolocation] metadata processor seeks to simplify this usage as much as possible. To use it, you have to declare it in your Swiz configuration just as you would any other metadata processor:

<fx:Declarations>
      
      
      
<geolocation:GeolocationSetup id="geoSetup" stopOnDeactivate="true" updateInterval="30000"/>

<swiz:Swiz>
<swiz:beanProviders>
<config:Beans/>
</swiz:beanProviders>

<swiz:config>
<swiz:SwizConfig
setUpEventType="{ Event.ADDED_TO_STAGE }"
setUpEventPhase="{ EventPhase.CAPTURING_PHASE }"
setUpEventPriority="50"
tearDownEventType="{ Event.REMOVED_FROM_STAGE }"
tearDownEventPhase="{ EventPhase.CAPTURING_PHASE }"
tearDownEventPriority="50"
eventPackages="org.andypowell.examples.events"
viewPackages="org.andypowell.examples.views"
defaultFaultHandler="genericFaultHandler"
defaultDispatcher="global"/>
</swiz:config>
<swiz:customProcessors>
<processors:GeolocationProcessor config="{geoSetup}"/>
</swiz:customProcessors>
</swiz:Swiz>

</fx:Declarations>

This is pretty straightforward, however, you'll see another tag up there too: GeolocationSetup. This tag allows you to specify the updateInterval, or how long the app will wait until it tries to grab a new reading from the GPS, and the stopOnDeactivate variable. StopOnDeactivate will shutdown the GPS listeners when the application is moved to the background. There is generally not a reason why you'd set this to false since it has the possibility to kill your device's battery by constantly polling the GPS.

Usage of the Geolocation metadata tag is pretty straightforward, as well.

...
   
   [Geolocation]
   public function updateLocation(latitude:Number,longitude:Number):void{
   ...
   }
   
   ...

The method updateLocation will automatically be called at the updateInterval's next run.

What does this mean for the developer who wants to use this? It means you don't have to mess with setting up listeners with NativeApplication or listeners for Geolocation when it updates the lat/lon. It really simplifies the whole process for you. Head over to my github page and download the metadata processor and examples for yourself. Remember, it requires the Flex 4.5 SDK so make sure you grab that first.

Inspiration comes from all places. Sitting in Ryan Stewart's presentation at 360Flex this week, I got hit with the geolocation bug again. I saw some of the demos that Ryan was doing and figured that I can take some of those a bit further. This gave me a chance to do some work with HTML 5 and AIR for Android as well.

Seeing Ryan's presentation, I took the initiative and updated one of my old samples around Yahoo! Local Search and Adobe Spry. The old version actually asked you to provide a city state pair to do the local search. After taking a look at how Serge Jespers was using an ExternalInterface call to get HTML5 geolocation data into Flash, I took the same approach to grab the latitude and longitude from the HTML5 geolocation API and pass it into the ColdFusion service that I'm using to abstract the Yahoo! API. The end result, which works in any HTML5 enabled browser looks like this:

Migrating this example to HTML5 was cool, but I felt like there was still something missing. I banged out the HTML5 version pretty quickly because I was migrating existing code. I needed a real challenge. Ryan's examples had all been based in AIR for Android. I had been signed up for the prerelease for a while, but hadn't been able to think of a compelling app to build. I decided to take the HTML5 app that I had just created and build an AIR for Android version, so I fired up IntelliJ IDEA and went for it. I figured a listing of the elements wouldn't be a good showing of what AIR for Android can do, so I decided to sexy it up a bit. I added in some nifty native geolocation functionality and some of the new uri based functionality to trigger the phone system, i.e. tel:4045551212. Since it was a Flex 4 application, I decided to use my Flex framework of choice, Swiz, to help me build the application quickly and keep my code organized. I picked up a beer from the 360Flex party on Tuesday night and then headed to my hotel room to crank out some code. The result isn't pretty, but it is pretty darn cool.

When the application starts up, it will check for the current location and center the map on that latitude and longitude. When you do a search, it will call the same ColdFusion service that the HTML5/AJAX version is using to get the local search results. It then leverages the MapQuest 6 API to plot the data. I added a double-click handler on the POIs to trigger phone calls to a given location.

Download the APK here. Warning, it's still just a POC quality, so you may need to force quit the application to keep it from eating all of your battery.