Android Toast-like Alerts in HTML using CSS

One of the little things I like about Android is the “toast.” If you are not familiar with the toast, it is the little transparent notice you get that operations are done. The best example is the toast that tells you how long you will have to sleep before your alarm goes off. (Pictured here.)

I really like the concept. It usually short-circuits the whole item editing process.

Without toasts:

  1. Click save button.
  2. Get feedback that item has been saved.
  3. Manually go back to previous screen.


With toasts:

  1. Click save button & go back & get feedback.


I wanted to implement toasts in an HTML PhoneGap application. Now I know I could do this with just JavaScript, or with jQuery, but I really wanted to give CSS transitions a try. CSS transitions allow you to alter a CSS property over a set period of time. They work really well for this sort of case.

So the first thing I have to do is apply the transition.

You’ll notice a couple of things here. One the syntax for the transform is pretty simple:

[browser css keyword]: [property to animate] [duration] [easing method]

Once you do that, the rest is really simple. Basically, all you have to do is change the value for the property you have added a transform to, and the browser takes care of the rest. So to fade out my toast, I set the opacity to 0. That’s it.

See the demo.

Why do I like this:

  • I always prefer doing visual things in CSS.
  • This seems to me to be simpler than using JavaScript animations
  • CSS transitions will be hardware accelerated on environments that support doing so.


Now, I have to tell you there are caveats:

  • It doesn’t work in IE
  • I’m sure someone who knows more than I will put more in the comments

But it does work within the mobile browsers I tested on iOS and Android, which means I’m free to use this in my PhoneGap application.


Articles That Helped Me Build Finicky

On Friday I announced the release of Finicky, a new mobile app built using Flex and AIR. I wanted to take the time today to give some link love to all of the articles I used to work out the various challenges of writing a Flex Mobile application. Hopefully this list points people to something that could help them. I’m sure I’m missing some, as I did try to grab these links as I went; I’m sure I forgot to grab one or two.

Jason’s Flex Blog
I don’t know what exactly I cribbed from Adobe’s Jason San Jose, but I know it was a lot. Pretty much every bug patch, or skinning hint that I got was from him. Just read his whole blog.

@renaun posts: Using Flash CS5 to embed Fonts in SWC to use with Flex Hero and Flex Mobile Hero
Finicky uses a lot of custom fonts. My teammate Renaun Erickson has a great post here on getting all of your fonts packaged together in a SWC file for inclusion in your apps.

URI Handlers in AIR for Android: Phone Calls, Email, Text Messages, Maps, Market, and URLs « Christian Cantrell
I wanted to launch Google Maps for getting directions to a location listed in Finicky. Adobe’s Christian Cantrell sums up how to do it pretty perfectly.

Using Menus in your Flex 4.5 Mobile Application | Devgirl’s Weblog
Fellow Adobe Evangelist Holly Schinsky has a great post about using and styling menu controls in your Android AIR apps.

Reskinning the Android contextual menu (ViewMenu and ViewMenuItems) in Flex / AIR mobile to look like Gingerbread black – daaain’s thought stream
Daniel Demmel has another helpful article that helped me get through skinning the menus.

Android, AIR and the Camera | RIAgora
A small part of the UI is grabbing pictures that you can associate with items. To do this I needed to work with the camera in AIR. Another of my Evangelist peers, Michaël Chaize, has a helpful post about doing just that.

Tips for Flex mobile apps | RIAgora
Michaël also has a great article here detailing a bunch of little hints for building mobile apps with Flex. I used at least half of them.

ArrayCollection Filter Example |
I’ll admit it, there are pieces of basic Flex that I don’t know off the top of my head. Filtering the results of an Array Collection is one of them. So Roelof Albers’ post was very helpful .

Tombstoning in AIR-Mobile Applications « Filthy Rich Applications
One of the things you need to do with mobile applications is deal with deactivation events, or what do you do when someone calls, or the user just switches to another application. Finicky uses geolocation, so I need to be very careful about preventing wasted battery life. Adobe Technical Writer, Frank Jennings’ post has great information handling these cases.

AIR on Android OS Interactions – Send Email | EverythingFlex: Flex & AIR
Sending email from a mobile app is pretty commonplace. Doing it is well explained by this article by Rich Tretola.

AIR SQLite Optimization tricks | Parametrized SQLStatement | SQLite Transactions | zedia flash blog
Working with IO can be expensive in a mobile application. I didn’t realize how much so until I started doing some bulk inserts of sample data. So I needed some AIR optimization hints. I had forgotten completely about transactions, but luckily for me, this Dominic Gelineau post reminded me.


Finicky – a Flex and AIR mobile app

For the past few months, I’ve been working hard on a mobile app called Finicky. It’s a mobile journaling application for tracking hard-to-search-for, local items.

The idea for it came to me in San Francisco. I wanted to smoke. I smoke cloves. (Make your hipster jokes.) However, cloves tend to be a little hard to find. Most convenience stores don’t carry them. The tend to be found in tobacco shops, head shops, and occasionally at a random spot like a newsstand. I tried searching on Google, but it’s hard to get reliable data on which stores stock them. The really frustrating part of this was that I know I had found them before. If only I had somehow kept track of it…

Now a mobile app just for tracking cloves would be overkill. But as I thought about it, there were a lot of things that I would love to track like that. Ever been a Coke/Pepsi fan in a Pepsi/Coke town? Can’t search that out. I like a whole bunch of other specific things. So thus was born Finicky.

I approached this a little different from most of my apps, in that I got design help from the beginning. By design help, I mean a full Photoshop comp and UI treatment. I wanted a different look for my app then I’ve seen with most mobile apps, especially on Android. I wanted something grungy and organic. I know what I wanted, but I don’t know how to design it. So I got help from The1stMovement, a design firm who our team had done work with in the past.

What they designed was beyond my imagination. Hence, why I needed a designer. It’s great looking, it’s got a specific style, and it doesn’t look like anything I’ve seen on a phone.

I took those comps apart and turned them into mobile Flex skins. And here is the result. I am releasing it as an Android app first. Then releasing it as an iOS app. I’m going to have it out on Android, iterate through bug reports as fast as I can, then when I’m sure of stability, get it onto iOS. For now I’m targeting just phones for this app. If it there is interest, I’ll port to tablets.

In any case, find out more and link to downloads at

Source is available on github

Toddler Timeout

My first full fledged mobile app is now on the Android Market.

It’s called “Toddler Timeout!” and it’s got real world uses. If you do the whole timeout thing on your kids, this is a timer for doing that when you’re on the go. That’s right, discipline for your child ANYWHERE!

My plan is to release it on the Android Market first, use the easy to publish nature of the Android Market to iterate over all of the bone head bugs I’ve left in it. I’ve also submitted it to the Amazon App Store too. It’s awaiting approval.

Then once I’ve stabilized it, I’ll get it on to submit it to the BlackBerry and IOS stores.

A couple technical things about it:

  • It uses Flex
  • The timer is a Flex MX PieChart
  • I minimally performance tuned it

Expect a few blogs posts around it soon.

Go give it a shot. Toddler Timeout!

Motorola MOTODEV App Summits – South American Leg

A few weeks back I announced that Adobe would be participating in Motorola’s MOTODEV tour featuring the XOOM and ATRIX. Mark Doherty and I will be talking at multiple events with Motorola.

I’m pleased to tell you we have confirmation on dates for the South American (and Central American) leg of the MOTODEV tour.

Beijing, China – April 26 (Mark)
Shanghai, China – April 29 (Mark)
Sao Paulo, Brazil – May 16 (Terry)
Buenos Aires, Argentina – May 19 (Terry)
Mexico City, Mexico* – May 23

Can’t wait.

Motorola MOTODEV App Summits Tour!

I’m pleased to announce that Adobe is participating in Motorola’s MOTODEV App Summits. The App summits are designed to bring developers up to speed in developing Android Apps for Honeycomb, specifically focused on the XOOM with Honeycomb OS, as well as for smartphones like the ATRIX.

I’m also pleased to announce that Mark Doherty and I will be giving sessions on AIR for Android development at these events.

Berlin, Germany – April 11 (Mark)
London, UK – April 15 (Mark)
Beijing, China – April 26 (Mark)
Shanghai, China – April 29 (Mark)
Seoul, Korea* – May 2
Sao Paulo, Brazil* (Terry)
Buenos Aires, Argentina* (Terry)
Mexico City, Mexico* – May 25

If you’re near any of these cities and eager to get your Honeycomb on, or just to check out the cool stuff Motorola’s got going on, please come on down. Register at the MOTODEV App Summit website.

StageWebView Location Changing without a Page Refresh

I’m working on a Remember the Milk application for the BlackBerry PlayBook, and am trying to get familiar with building against the RTM API. One of the security measures they take in order to use their API is requiring all applications to authenticate against a page on their site, and give permission to the calling application. It’s a pretty common pattern these days.

To do this in an AIR application, you can use StageWebView, which allows you to open a browser display within your applications. It has limitations, but works perfectly for this use case.

So you load up the page you want in the StageWebView, listen for the locationChange event, see if permission was granted, and go about your way. Simple? Right?

It failed for RTM. Why?

The location didn’t change. It was doing one of those “Let’s be cool and not reload the page” things.

At first glance the work around was to add a close button that the user would hit when the RTM page was done. But that’s inelegant, and frankly lazy.

So, I poked around some more, and found out, that despite not firing a locationChange event, it was firing a complete event when it was done. And luckily, RTM changes the title to reflect that the user gave permission.

So, all I had to do was add a check for the title to the processor for complete as displayed below:


Simple, easy, straightforward – hopefully I save someone else an afternoon of trial and error with this post.

Tivo Remote with Hero

Android Version
This is my second attempt at a multiscreen BlackBerry and Android application using Hero. I outlined what I was trying to do in general with yesterday’s post.

I added one more device to my testing rig, just to explore differences.

  • Nexus One
  • Droid 2
  • Galaxy Tab
  • PlayBook Emulator

Tivo Remote
So for a stretch there TiVo was enabling their devices with a telnet port that you could open to allow another machine on the network to connect and broadcast commands. AIR 2.0 and later can do socket connections, so it seemed a perfect use case for AIR.

At first, I hated the UI. I did a default Hero look and feel, and it felt kinda lame. Not because of Hero, but because it was basically just a grid of buttons. It was like a remote you get with a generic tv. My next step was to try a layout exactly like a Tivo. But Tivo remotes are by and large much longer and skinnier then most mobile devices.

So I studied the Series 2 Tivo remote and took some concepts from it:

  • Tivo places the most important controls in a + shape.
  • Tivo uses color to call out a few buttons:
    • Pause
    • Thumbs Up
    • Thumbs Down
  • Tivo uses a darker grey to downplay the number keys
  • Tivo uses multiple shapes for their arrows
    • Play
    • Volume
    • Channel
    • Arrow Pad

All of these combine to make it much easier to determine where to click and hit that spot.

My first pass was arranging the play controls and arrow controls in + formations. I used a tile layout with some invisible buttons to aid me in this. This worked pretty good. With those shapes settled I laid out the controls better.

It looked more like a remote.

My next pass was changing button colors. I made the number pad darker, the thumb buttons green and red, and pause button orange.

It looked even better.

Finally, I added icons to all of the buttons, to make them images instead of characters. That made a huge improvement.

Finally I had a remote.

Then I rotated my screen, and all holy layout hell broke out.

Portrait vs Landscape

BlackBerry Tablet Version
I tried a few passes but could never get the remote to layout well in landscape mode. Then I thought really hard about it. This remote is emulating a thing. That thing is always tall and skinny… Could I get away with just forcing portrait layout?

In the end, that is what I did. It’s cheap and dirty. But I had other demos to write, and I decided I would fix it in my next app.

Lessons learned
Multiscreen means being able to handle multiple sized screen with the same application. It doesn’t have to mean one layout shoved into fit all possible device sizes. Or to put it more clearly: When you design one app to work as is on multiple screens, it sucks on all of them.

Now to be clear here, it doesn’t mean having one code base that can detect multiple screens and layout accordingly is bad. It’s just you actually have to detect and layout accordingly.

To that end, I would say you can probably do one design for smartphone sized screens and one design for tablet sized screens. You do have to be willing to let little differences in layout go though, much as you have to with CSS in the browser.

I tried to deal with the differences between screen sizes by anchoring components to the middle of the screen rather then the edges. So instead of setting top and left, I’ll set verticalCenter and horizontalCenter and calculate locations from the center. This allows me to not worry about pixel differences at the fringes of the screen. I had mixed results with it, and defaulted back to left and top anchoring things for now.

I also learned that a little bit of custom tweaking of Hero components goes a long way towards giving your application an individualized feel. Changing a few button colors and adding some icons really changed the whole application for me.

AIRTivoRemote on github
Telnet Client in AIR
I can’t include the APK as it requires an as-of-now unreleased version of AIR.

About Time with Flex Hero

BlackBerry Table Day
I’m working on getting up to speed with the BlackBerry PlayBook. The best way to do this is to build some apps. For my first pass at this, I wanted to see how it would be to build apps with Flex Hero for both BlackBerry and Android at the same time. I figured it would be a good chance to get a feel for what multiscreen development really is like.

To start with I set up a few devices to test with:

  • Nexus One
  • Galaxy Tab
  • PlayBook Emulator

About Time
This is my go-to application for trying out new things. It’s an approximate clock. If you’ve seen my “Holy Crap I’m a Mobile Developer” Series, then you’ve seen it before. It will tell you, for example, that it’s “Just after Ten” instead of “10:02.”

Android DawnI like it because it is more than a Hello World, works with date/time formatting (which is usually just different enough between different systems to be annoying to learn), and it doesn’t have any external dependencies to start with like my other go-to learning app, the Twitter Search App.

That being said, I wanted to add a little pizzazz to this one:

  • It has four states: dawn, day, dusk, and night
  • There are transitions between the states
  • It uses geolocation and a web service to get sunrise/sunset times
  • It uses those times to set the correct state

As this is a pretty simple app consisting of just one screen, it was extremely simple. The only real challenge I had was laying out images. It works and looks acceptable on all three tested environments.

Lessons learned
The simpler the application, the easier it is to handle multiscreen. This app has no input, and very few moving parts. Getting it to work on many screens in both landscape and portrait was very easy.

This may sound like I’m saying “AIR makes it easy to do multiscreen development.” I’m not; I’m saying “Multiscreen development is easy if your application does nothing.” The app I’m going to blog about next confirms that once you add actual interaction to your UIs it gets much tougher.

If you’re going to target both Android and BlackBerry Tablet OS with your application then Hero is the way to go. There’s no way to selectively swap in QNX for pieces here and there. If you want cross platform without writing for each platform you have to acknowledge that your app won’t look quite like a native BlackBerry application. It won’t quite look like a native Android Application either. There are certainly pros and cons to this.


  • One code base for all of your target platforms


  • Might be consciously or unconsciously confusing or troubling to the user.
  • Might be jarring.
  • Might look cheap, or somehow wrong.

There are certainly more pros and cons than this, but this is what really slaps me in the face. For me, there’s no question, the ability to write applications once and trivially tweak builds to get them onto other platforms outweighs the other issues. However, your mileage will vary. Your applications might need that extra performance, or abilities. I have not run into these as limitations yet, for my use cases the performance hit of AIR as an abstraction layer have been very overblown. That being said, I’m not writing a complex app for mobile devices.

But how complex should your mobile applications be? From my vantage point, with slower processors, and less user attention, mobile apps should do less than their desktop counterparts. Most of my experience with mobile apps tells me that my fellow developers agree. Which again is not to say you shouldn’t write complex applications, merely that the types of applications I am disposed to writing on mobile devices are simpler, and require less capabilities and performance.

Also visually, I think the Flex team is doing a good job making visually pleasing interfaces. For comparison, I hated Halo, and mildly like Spark. Hero’s mobile components are visually better than both, in my opinion.

Also as I have posted before, I learned how to publish both apk (Android) and bar (BlackBerry Tablet OS) versions of AIR applications at the same time.

AboutTimeHero on github
I can’t include the APK as it requires an as-of-now unreleased version of AIR.