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.

Every couple of years I have to stop and shake my head at how damn cyclical (and cynical) this business is.  Sometimes, I can't help but feel like Marty McFly and get the feeling like I've seen all this before.  Everyone is, quite rapidly, getting caught up in the notion of this high experience, mobile, touch-screen, multi-device world and how revolutionary it is.  

We've sung this song before though.  It's nothing new.  

It's kinda like "O Canada" and "My Country, 'Tis of Thee" being the same melody as "God Save The Queen".  We know it's the same tune, just different lyrics.  With that thought in mind, let's take a look back and figure out how we got to this point and where we are going in the future.

When I first started building software (Omnis 7 paid the bills), it was all about client-server computing.  You had to have moderately powered desktops and a beast of a database server to house all the data.  Most of the heavy lifting of the data and logic happened at the client.  The server was, basically, just a database, if not in reality, just a database.  This made updating the applications we built a total pain in the ass because we didn't have a really well built out infrastructure to push updates to our clients.  Hell, even Microsoft sent updates on CD.  I fondly remember waiting to see what was in that month's TechNet update, but I digress.

As server performance increased at a faster rate than desktop performance did, the shift was back towards a centralized-type system that was a lot like the mainframes of yesteryear.  Hell, the system we used was even called MetaFrame to harken back to the mentality that all the processing was centralized.  Metaframe was an absolute disaster, but that's a story for a few beers and another time.  At that point in time, you had all the power you needed on the server to run the app, but you were still talking to the database, which was the centralized server component.  That part didn't go away.  

Not too long after that, along came the rise of web-based UI's.  This moved pretty much solidified the move of all the processing to the massive servers that we had sitting in data centers (or server rooms).  This paradigm gave rise to the concept of a middle-tier that took requests from the client (web server), processed the incoming data, made requests to the database, then sent the results back to the client.  

This was a defining demarcation because at this point, we would never really have all the logic in one place anymore.  The client could render and process some of the data and the server would still do most of the business logic.  This worked well, especially with the introduction of client-side scripting methodologies, like JavaScript.

In the middle of the last decade, we saw the emergence of the Rich Internet Application (RIA), be it AJAX, Flash (and Flex), or whatever your tools of choice were (and maybe still are).  This, again, signaled a new era where we moved a lot of the processing back to the client and relegated a good majority of the middle-tier to things like security and data access.  A lot of business logic moved towards the client applications, again.  

Fast forward a year or two to the present day. Now, we are in the midst of a new multi-device paradigm where we have a legitimate business need to have both consistent experiences and business logic across multiple devices (Android, iPhone OS, Windows, Desktops, etc.).  So what do you do?  Do you spend the extra money to duplicate libraries of business logic across platforms and create a version for Cocoa, Android, .NET, and whatever other platforms on which you wish to deploy your applications?  

In a word, no. 

You do the smart thing and move that common business logic back to the server.  The native user interface serves the relatively simple purpose of providing the face of the application, taking input from the user, prepping it for the middle-tier, passing it to the middle-tier, then processing and rendering the results.  The real work: security, data access, and all important business rules and logic are deferred to the server, again.  

So here we are, again in the circle, moving the most intensive processing back to the middle-tier and leaving our device native code to render the user interfaces.  History would tell us that the next phase of this will probably be much more powerful devices that can handle the processing of complex business rules and crunching larger amounts of data.  Achieving this will require us to find a way to create logic libraries that are cross-device.  That will require a change in the current environment where either everyone, or a good number of vendors start playing nice.  If that does or doesn't happen, history tell us that something will trigger us towards this paradigm in the next two to three years.  Let's hang on and see what happens next.

(Note:  My colleague, David Tucker, has joined me in helping to author this post since we put on our Flash Camps as a collaborative effort between the two of us.)

It's come to our attention that there are a lot of people out in the community who do not know what a Flash Camp event really is all about.  If they do know, it's a pre-conceived misconception that they're things like "glorified user group meetings".  This couldn't be any further from the truth.

In our minds, a Flash Camp is, in essence, a mini conference.  In these days of tighter budgets and the premium placed on our time, we try to make these events as time conscious and price conscious as possible.  Why fly across the country to an event when we can bring something that will offer comparable content to your region?  We try to keep the presentation quality of these events high so that people will want to attend and they will feel that they're getting a good value for the money.  

Typically, a Flash Camp event will be one day, 9:00am to 5:00pm. We try to shoot for a Friday so that people can have a nice end to the week. We've talked about going to multiple days, but we want to make sure we've got this formula down pat first.  Lunch is also included in the price of admission.  If we're going to ask you to sit through a full day of content, the least we can do is feed you, right?  

During the camp, you will hear from a lot of different speakers presenting (in a typical conference presentation format - these aren't 'hands-on' sessions).  The speakers are diverse.  This means that, yes, as it is a community event, we try to pull a good mix of local speakers and nationally recognized speakers within the Flash Platform community as a whole.  This gives attendees a good motivation to attend because you will see both your peers from the local community, plus people who you know from twitter, reading blogs, etc.  

Along with a diversity of speakers, we try to maintain a diversity of content as well. In Atlanta, we did an Intro To The Flash Platform session that was really rudimentary, and almost a bit of a marketing pitch.  We have had topics as a advanced as "Custom Metadata Processors For Swiz", which is going to be way above an entry-level developer's head.  We can't make the content too basic, or too advanced, so we try to shoot for a bit of both with the hope that everyone will take something away from the event.

Cost is always the interesting element.  A lot of things go into the calculation of the cost like venue cost, catering, travel for out of town speakers, etc.  Our ultimate goal is to get enough sponsorships so that we can keep the event cost to attendees below $100.  We feel that that price point is a good place for a one day conference with top-notch content.  Some people want it to be free, but the way I see it, you can't please everyone.  Paying under $100 to have a full day of presentations from speakers that you would hear at 360Flex and Adobe Max is a bargain.

At the end of the day, Flash Camp events are catalysts for the local user community.  Some areas, like San Francisco, have vibrant and highly active Flash / Flex communities.  In these areas, the Flash Camp event serves as a way to reconnect with people and inspire the community to more user group meeting and such.  In areas like Phoenix, where the community is not as active, the Flash Camp events serve as a way to launch the development community.  It's an opportunity to get a large number of people in the room and have the user group managers pitch the user groups and their value to potential members.  As these local communities grow and thrive, the Flash and Flex communities as a whole will grow and thrive.  They are beneficial to the whole Flash Platform ecosystem.

On May 7th, Flash Camp Seattle will be held in the Adobe offices in Seattle.  One of the sessions we are working out for that event will be a panel discussing where Flash and HTML5 will both fit within the future of the web.  It's not going to be a "bash-fest" either way, but a frank, open discussion with representatives from both sides. Tickets are going fast, and registering via this link will save you 50% off the ticket price.  

Speakers Include:

• Ryan Campbell
• Ryan Stewart
• Duane Nickull
• Carl Smith
• Jeff Croft
• Christian Saylor
• Antonio Holguin
• Nate Beck
• David Kelley

Flash Camp is coming to Washington, DC on April 16th.  It will be a full day of great content on topics ranging from UX to Flex.  Admission is dirt cheap and lunch will be provided.  Come on out for a full day of great content and great networking with some of the area's industry experts!

When:  April 16, 2010

Where:  Navy Heritage Center (Naval Memorial stop on the Metro)

More Info:  www.capitalflashcamp.com

If you're an Atlanta area (or even Macon / Augusta / Chattanooga area) developer and want to learn more about how a developer sees user experience design, make sure you come to the Atlanta Flex User Group meeting tomorrow.  I will be giving my presentation:

It's guaranteed to make you laugh, cry, or angry.  I'd like to say it's entertaining, but that's just a bit more shameless self-promotion than I'm willing to do (at this time).  I think that this presentation is well suited to any type of developer (not just Flex) that wants to learn more about what exactly user experience design is.  I've heard, even Sledge Hammer! might be making an appearance.