Monthly Archives: June 2011

Delay Closing Mobile Apps on Exit

When a user switches to another application on a mobile device AIR on mobile applications keep running. It continues to hold on to resources, fire off events, and has the potential to use power draining resources like network calls, or geolocation if your app makes use of them.
That’s why one of the first tips you see is to kill or tombstone your application when the user switches away from it. In general, unless you have a good reason to do not do this, you should. Your users might not notice that you drain their battery to zero, but then again they might.
But I have a good reason for not wanting to do this right away. Actually I have a few:

  • As a user, I frequently accidentally hit the home instead of back button
  • As a user, I frequently lookup stuff on the web then come back to an application.
  • As a developer, I frequently makes calls to OS resources like the camera or mapping in my app.

All these add up to needing to revisit closing on exit.
I’d like to get the benefit of closing on exit in terms of resource usage, but I’d like a grace period. So, my solution, fire off an event when a user leaves the application, that sets a timer to shut down the app. Then if the user returns, kill that timer.
Simple, easy, and best of both worlds.

Flex Mobile – Getting Rid of the Action Bar

The viewNavigatorApplication framework in Flex 4.5 is awesome. The ability to manage the various screens of your application is really useful and powerful. But one part of it doesn’t make sense in all applications.

I speak of the ActionBar. This is the UI chrome at the top of the app that contains the screen title and any application navigator features you use. This make a lot of sense in iOS or PlayBook apps, where the entire UI is software based, but in Android, you should use the hardware buttons. If all of the controls move off of the ActionBar, then depending on your needs it might make sense to get rid of it completely.

This is easy enough to do in a view, you just turn it off by setting actionBarVisible=”false” on the view. This worked for me for awhile, but then I changed the way I set up my application. I followed tip number 2 on this post by my colleague Michaël Chaize. In short, I load my data on application start, and push to the first view only after the data has loaded. Makes for a great experience for the user, except that I was getting flashes of the ActionBar while the data was loading up. I can’t tell what exactly is going on, but it looks like there is some sort of placeholder or default view that’s not obvious.

This was a pain for me for awhile, but today I finally figured out how to fix it. On your main application page, where you define viewNavigatorApplication, set actionBar.visible=false;

Good thing to note is that this only affects the ActionBar that is visible in that little flash; if you make another ActionBar visible later, it will show up.

Here’s the source:

CFAIR Synchronization Resources

I talked earlier today as part of Adobe Developer Week on synching up data between ColdFusion and AIR (mobile) clients.

I referenced a whole bunch of pages in my talk, and wanted to link them all out at once.

Finally source code from github for the demos I showed in my session:

Hope this helps!

Quick and Dirty Skinning of a Flex Mobile Button

I’m working on a mobile project and trying to implement based on a beautiful design comp. Unfortunately I haven’t had a lot of luck finding out how to do this right… So I’ll tell you how I did it, right or wrong.

So I start off with the design comp.  This is what I want to achieve: 

First, I create a blank skin that extends spark.skins.mobile.ButtonSkin.

The mobile skins use an image named “border” to render the border of the button. I’ll exploit that to show the new background image of my skin. There are two images for mobile skins: an up and a down. The Button has a function to return, which should be the correct image for either the up or down state… so:

I import new background images to replace the default up and down backgrounds of the button.


I override the getBorderClassForCurrentState function. (I’m also changing the font color here on the down state, probably the wrong place to do it but it works.)


This will yield this result:
 

It’s using the background but it’s small, so I hardset the size in the constructor.


This is a big no-no when it comes to mobile development, as that doesn’t scale to many screens well. But my app is pretty specific and I can get away with it.

This yields:

Good, but I need to remove the background shape. I do this by overriding drawBackground and setting it to do nothing.


Which yields this:

Finally I need to set the fonts. Mobile buttons have drop shadows on their text, but they don’t render using an actual dropshadow filter; they do it by having a second textfield behind the first. So I need to alter and tweak that font to the same settings by overriding the labelDisplay_valueCommitHandler.


And there you have it, a custom skinned button in Flex Mobile. If anyone sees glaring problems with this let me know.

Here’s the entire source if you are interested.


NY Flex User Group and Flash and the City 2011

I’ll be in New York next week doing two events:

NY Flex User Group
Tuesday June 7th 2011
Razorfish: 1440 Broadway 18 Flr. New York, NY 10018
Register
I’ll be talking about the Flash Builder 4.5 and Flex 4.5. But I’ll also touch on some of upcoming features of Flex and Flash Builder and showing off a few cool new mobile projects.
Flash and the City
Thursday June 9th 2011
Find out more
I’ll be talking about ColdFusion, what’s currently going on with it, and why you would want to use it as a Flash Developer.