QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Tag Archives: Apple

Adding a GPS-driven map to your Adobe AIR app

Over the next few blog posts I’m going to be writing about some of the cool little features I implemented in a recently released app I worked on — Pointillism.  It is pretty rare that I can talk about an app I’ve released, but the verbiage in this contract allows me to :)

On the admin interface of the app, the customer wanted to be able to add a “point” to the game.  A point is a destination that the end user is looking for in this virtual scavenger hunt.  In order to have the admins be able to visually see what their GPS was returning, we wanted to map the location, as well as the bounding area that they wanted people to be able to check in to.  While our admin interface was pretty basic, the functionality had to be there :

GPS and Map solution on iOS and Android

While most people would instantly reach for Google Maps, we decided to use ESRI’s mapping solution.  They offer a very accurate mapping solution that is consistent across all the platforms in addition to being very flexible   The one thing that Google Maps had a hard time providing us was the ability to draw the fence in a dynamic manner, built with realtime data that came from within our app.  It was important for us to be able to see the current location, and the valid locations where people could check into for that point.  The hardest thing was having the ESRI servers draw the circle (known as a buffer).  ESRI’s mapping platform is available for use FOR FREE, with very limited exceptions.  As a bonus, they have an entire SWC and already pre-built for Flex/AIR.

So, how was it done?  It was actually pretty simple :

    1. Add the SWC from ESRI’s website to your project.
    2. Add their mapping components to your MXML file.  We added the mapping layer and then a graphic layer (where the circle is drawn).  The mapping layer, we pointed to ESRI’s public mapping service.
      <esri:Map id="locMap" left="10" right="10" top="10" bottom="150" level="3" zoomSliderVisible="false"
       logoVisible="false" scaleBarVisible="false" mapNavigationEnabled="false">
       <esri:GraphicsLayer id="trackingLayer"/>
    3. We added a few components to the MXML’s declaration section.  This included the defination of the “symbol” (the circle itself), and the Geometry Service (the thing that figured out how to draw the circle in the correct place).
       <esri:SimpleFillSymbol id="sfs" color="0xFF0000" alpha="0.5">
       <esri:SimpleLineSymbol color="0x000000"/>
       <esri:GeometryService id="myGeometryService"
    4. Next, we had to write some code to update the map and draw the circle in the correct place.  This involves a few steps, including taking the GPS coordinates from our GPS device, and creating a new “MapPoint” which holds those coordinates.  A MapPoint is exactly that, a single point on the map.  The thing about ESRI’s service is that it knows a LOT of different map coordinate systems — so you need to make sure you choose one that makes sense.  In our case, our GPS is returning back data in WebMercator format (lat/lon) other known as Spatial Reference number 4326, so that is what we are going to use to project that point to center our map.  Finally, we will ask the Geometry Service to return a “buffer” of a series of points that represents a circle x feet around the center of our map.   When the buffer is returned from the web service, we draw it using our graphic we setup earlier and push it to Graphics Layer that is sitting on top of our map.  This all happens in a matter of seconds.
      protected function gotGPS(event:GeolocationEvent):void
       var mp:MapPoint = new WebMercatorMapPoint(event.longitude, event.latitude);
       locMap.scale = 4000; //this is a magic number for the zoom level I wanted.
       lastPoint = mp;
      protected function updateMapWithFence(mp:MapPoint):void
       var bufferParameters:BufferParameters = new BufferParameters();
       bufferParameters.geometries = [ mp ];
       bufferParameters.distances = [ checkinDistance.value ];
      bufferParameters.unit = GeometryService.UNIT_FOOT;
       bufferParameters.bufferSpatialReference = new SpatialReference(4326);
       bufferParameters.outSpatialReference = locMap.spatialReference;
      myGeometryService.addEventListener(GeometryServiceEvent.BUFFER_COMPLETE, bufferCompleteHandler);
      private function bufferCompleteHandler(event:GeometryServiceEvent):void
       myGeometryService.removeEventListener(GeometryServiceEvent.BUFFER_COMPLETE, bufferCompleteHandler);
       for each (var geometry:Polygon in event.result)
       var graphic:Graphic = new Graphic();
       graphic.geometry = geometry;
       graphic.symbol = sfs;

And that is about it!  cross-platform mapping made pretty easy.  The cool thing about ESRI’s mapping solution is the power behind it.  They offer things such as the typical driving directions all the way though “How far can a user see if they stand on the ground at this point”.   Since the components are native to your AIR app, they are fast and behave like you expect it to, without the mess of having an HTML overlay in your app.

Geolocation issues with AIR on iOS (with a fix!)

The recent “GM” version of iOS 6 (this includes the production version that is now shipping on the iPhone 5) broke one of the APIs that Adobe AIR depends on for Geolocation.

If you have an app that was published with Adobe AIR 2.7 through AIR 3.4, your app will either get rejected if you are just submitting it to the store, or it may be broken if it is already in the store.  This is in addition to some other feature interaction issues that have also cropped up in iOS 6.

The bug is that the Geo Location (GPS) subsystem is never actually called — it fails silently, just as if the user denied the application to use the GPS.

Luckily, there is a work-around, but it does require a re-compile of your application.

  1. Make sure your app is running at least AIR 3.0.   AIR 3.4 is currently in production and it works great with this work-around.  AIR 3.5 is on the roadmap, and addresses some other iOS 6 issues (including the ability to address the full screen).
  2. Update the <name> tag within your descriptor XML document.  Wrap the actual name of your application in an extra <text: xml:lang=”en”> tag.  For example,
     <text xml:lang="en">MyGPSApp</text>
  3. Update the version number.
  4. Make sure your app is compatible with the new storage requirements in 2.23.  Details are available here : http://blogs.adobe.com/airodynamics/2012/03/05/app-compliance-with-apple-data-storage-guidelines/
  5. Compile, and wait.  Your app’s GPS should now work in iOS 3, 4 and 5.

Hope that helps some people out!  I know it was a big sticking point when I had some apps recently rejected because of this incompatibility.

Three strikes, and your out Apple!

In the past few weeks, there have been disappointment after disappointment coming out from Apple for developers.  While the iPad seems to have made a big splash news-wise, its release has been lightly overshadowed by some other announcements from Apple — the iPad will not allow Flash, Java or Silverlight content within the browser. 

In the past, the world just ‘understood’ that the Flash player wouldn’t work on mobile devices — these are devices that are measured in inches, not GHz, and have to operate in very loosely connected environments (AT&T).  We accepted this, but of course wanted it so we could experience the entire web. 

With the introduction of the iPad, a “computer replacement” device, there really is no more excuse.  The technology works, and has been proven.  All of a sudden a press release goes out claiming Flash would shorten battery life, would make the device hot, and catch on fire, etc.  The list goes on as to why Flash shouldn’t be included.  As people started to get the devices in their homes, the reviews were consistently “this device would be much better if it had Flash”  or “I miss Flash.”

Earlier this week, Apple dropped another bomb — Applications submitted to the store to work on the iPhone / iPad / iTouch cannot utilize gestures designed for their own applications.  For example, the pinch to expand gesture is reserved for Apple created applications ONLY — new applications have been denied access to the store because they emulated these features.  This is a huge mis-step in the UX world.  In UX, there is a general feeling that gestures and human interactions should be consistant between applications.  This is why Windows became so wildly popular — if you figured out how to use one Windows application, you figured out how to interact with most of them.  Apple doesn’t want that the be the case — they want to have the “Apple” way, and the “other” way.

Finally, a draft copy of the new EULA that will be included with the iPhone OS 4 SDK was released.  This EULA has some provisions in it that make some very large and sweeping restrictions on HOW you create your applications. 

Up until now, the major restriction was that you could not execute any code that was not included and compiled in the inital application (for example, runtimes like AIR and .NET would not be possible).  The theory behind this was about security — they didn’t want malicious code to be downloaded and run on the iPhone.  This also is one of the blocks of having the Flash player on the iPhone.

However, the new SDK EULA now reads :

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Essentially, what this boils down to is if you want to create iPhone, iPod Touch or iPad applications, you have to use Apple’s developer’s tools, on Apple’s operating system, which only runs on Apple’s hardware.  Oh, and you have to sign Apple’s NDA, pay for their certificate, and submit to only their store.  Although there are other tools, better integrations with workflows, etc., you CANNOT use them if you wish to deploy you app to anybody (including yourself).  Oh, and if you know another language really, well, you better learn THEIR language (from scratch) and kinda make the application work.

Apple has always been about their image, and Microsoft has always been about the developers.  Microsoft’s theory has been that if you make the developers happy, they will make cool apps that people will want to use.  Apple has taken the other approach — make a cool device which will drive the consumers to demand the applications and developers.  Now, for some odd reason, Apple thinks they can punish their developers AGAIN (remember the 90’s?) for trying to serve consumer demand.

One other final thought — Some of the biggest critics of Adobe in Apple’s camp say that Adobe is lazy.  They keep showing that the Apple versions of Adobe’s products are missing features, are clumsy or are less stable.  I need to throw out there that in the last 10 years (MacOS to Snow Leapord) Apple has forced all of their application developers to migrate first from Titanium, to Carbon then to Cocoa, which for larger applications results in complete gut-jobs.  For example, if you want your application to be able to address 64-bit memory space, you MUST re-write the app in Cocoa.   How can Adobe be expected to keep both Windows and OSX feature parity if Apple is making them rewrite the app every few years?  Microsoft has allowed us to keep writing to the same libraries since Windows 95 / NT, allowing the applications to grow and create NEW features.

Well, enough ranting — here is a video Adobe showed during their MAX convention this last year on their efforts to get the Flash Player to work on the iPhone :


Get every new post delivered to your Inbox.

Join 32 other followers