This is a short post, in which I show how to set a common background for your Flex Mobile Application.
In Flex 3, there was a backgroundImage style property, but in Flex 4 things have drastically changed. Often times, this means you need to re-skin things in order to achieve your goals.
I recently was tasked to get part of an older Flex 3 application onto an iPad. Why not, right? I mean, FlashBuilder 4.5.1 and AIR 3.0 are awesome… This should be cake, right?
There’s a lil gotcha – Flex 3, or MX components, ooorrr Halo components, are not exactly welcomed on Mobile.
Fret not! I’ve figured out the task, and it’s rather simple. (more…)
While doing mobile development, one of the most frustrating things has been form input.
If you’ve looked at any Playbook development, you’ll see QNX has something called ReturnKeyType specifically for this reason.
Being as stubborn as I am, I wanted a plain Flex approach at accomplishing what I wanted, and not to use the QNX library.
Most of this actually is related to Mobile development with AIR, considering there isn’t a bunch of desktop development focus in the SDK.
Adobe released an early version of Flex 4.5 (Flex Her0) just before Adobe MAX last year, and tons of people grabbed it and started writing mobile apps with it.
Since then, quite a bit has changed both in common functionality, and under-the-hood things like List scrolling.
I couldn’t find any clear documentation about migrating your applications, so I figured I’d try to throw together as much information as I could think of.
I will be updating this frequently as I find more changes or caveats while converting my apps, or from what I hear from others.
As Flex 4 (and in this case particularly Hero [v4.5]) works its way into the public, we continue to see components that aren’t there yet. Sometimes they do exist, but haven’t been optimized for mobile (this also has some ambiguity as to what that fully entails).
In the interim, we have to fend for ourselves and build custom components… Well, that’s not always all that fun, but also not always that bad!
I’ve done the dirty work, and created a MobileNumericStepper, as well as a MobileLabelStepper as a parent to it.
There’s a few good use-cases for serialization; for me the first and foremost is the performance combined with ease of use.
In AIR we have SQLite access, or in a bad case we can write some format to a file and recover it later somehow via parsing. But why? That’s a lot of work… And it’s not the fastest approach either.
And what about if we’re doing a browser application that we want to save a state of something, but don’t want to host the storage and write a web service to handle data?
We don’t have stealth access to the filesystem directly, which makes it hard (errr, impossible) to silently store things on behalf of the user.
We can actually tackle both easily using serialization.
While there’s plenty of information about skinning your Flex 4 component, I haven’t found a whole bunch of information on how to get them to talk together. In most situations I would consider this bad practice, however there is often a need for identifying properties set on your component from your skin in order to display certain aspects properly.
I recently was working on an application, and needed to listen to KeyBoardEvent dispatches from the stage. This isn’t usually that much of an issue, except when your component needing to listen to these Events is created as part of the application creation process.
This is a seemingly trivial task, but attempt to tackle it and you’ll quickly find yourself scratching your head wondering what the hell you’re doing…