Native Extensions examples available now

Among of the biggest news of the Adobe AIR 3 release is the Native Extensions feature. If you want to get started with this, or maybe just try it, you should check out the Native Extensions page on Adobe Developer Connection.

There are five examples so far:

Gyroscope (iOS/Android)
NetworkInfo (iOS) – retrieves information about the network interfaces on an iOS device
Vibration (iOS/Android) – make the device vibrate
iBattery (iOS) – gets the battery status (unknown, unplugged, charging, or full) of an iOS device
.NET Image Encoder (Windows) – encodes a bitmap into BMP, JPEG, or PNG format using Microsoft .NET Framework 4

The first three extensions were created by Adobe engineers, the last two by community. As I said before I’m looking forward to seeing many more extensions created and having a central place to go for all of them.

September 22, 2011 | Filed Under AIR, Mobile | 1 Comment

Building an iPad game with Adobe AIR in a week

Radu Ticiu of Timisoara Mobile Development Group invited me to speak at their August event about Adobe’s solutions for mobile development. And I must say I’m glad I accepted. Not only because the event and the people were great but because the other speaker was quite interesting.

Stefan is his name and he runs one of the most creative companies in this part of the world. Just to give you some context: they’ve won three FWA awards so far. His presentation was about the making off of an iPad game using Adobe AIR and Flash Builder 4.5. So far nothing new or extraordinary. isn’t it?

Well what really caught my attention were these facts:

While they had great expertise in building Flash applications for the desktop, this was the first project they’ve done for mobile.
They completed the game from concept to final IPA file ready for publishing in a week.
The team who built this consisted of one designer, one developer, and Stefan.

August 30, 2011 | Filed Under AIR, Mobile | 6 Comments

Flex Mobile Development: skinning the ActionBar component

One of the important pieces of the Flex framework for mobile development is the ActionBar class. This class lets you create an application title bar with three distinct areas. Starting from left to right you can have a navigation area, a title area, and an actions area. Of course you are not forced to use all these areas.

Why would you want to use this component? There are many reasons for using it but probably the most important is that it is an established user interaction design pattern on Android and iOS. This is how you usually add things like an application or section title, navigation buttons, search input texts, or action buttons.

August 29, 2011 | Filed Under AIR, Mobile, Tutorials | 4 Comments

Flex Mobile Development: pay attention to list.itemRenderFunction

A colleague of mine who is building a Flex mobile application had some performance issues with a list. In short, when he used a pretty heavy custom item renderer (with checkboxes, buttons, and labels) the scrolling performance dropped a lot. When using just a label item renderer everything worked well.

So, we started to debug the code and, as I suspected, the culprit was the layout manager: the virtualization was off.

This was strange as he didn’t turn off the useVirtualLayout flag anywhere in the code – at least not explicitly. So why was the virtualization off? Because he used list.itemRenderFunction to change the item renderer at runtime. If you take a look at the documentation you will find this:

Function that returns an item renderer IFactory for a specific item. You should define an item renderer function similar to this sample function:

function myItemRendererFunction(item:Object):IFactory

Currently, when using itemRendererFunction with a virtual layout (useVirtualLayout=true), item renderer recycling is turned off. Because of this, using itemRendererFunction can cause a performance degradation and is not recommended for mobile. This may be fixed in future versions of Flex.

So, if you use a heavy item renderer and/or you have many items, don’t set the item renderer using the itemRendererFunction method.

Instead, you can wrap your custom item renderer in a ClassFactory object and then assign this object to the list.itemRenderer property. Like this:

var factory:ClassFactory = new ClassFactory(MyCustomItemRenderer);
// set the properties for custom item renderer
factory.properties = {iconField:"thumbnailSmall",
                  messageField:"description", iconHeight:180, iconWidth:180};
// set the ClassFactory object as the list item renderer
myList.itemRenderer = factory;

There is one more thing. In the example above I used the properties property of the ClassFactory object to set the properties I needed (for example what data property should be used for the message label). You can’t use this approach for setting CSS properties like fontSize. The only solution I found so far is to create setters that behind the scenes are doing something like this:

public class MyCustomItemRenderer {
   //...

   public function set fontSize(value:int):void {
      setStyle("fontSize", value);
   }

   //...
}

This was my tip of the week. And don’t forget, stay away from useVirtualLayout = false;

August 23, 2011 | Filed Under AIR, Mobile, Tutorials | 9 Comments

Flex Mobile Development: storing data locally

One way to improve the user experience for mobile applications is to save data locally. This technique is important for desktop applications and it is even more important for mobile applications (mostly because the network connection is expensive, slower, or intermittent).

When using applications such as mail or Twitter clients local storage enables users to see the messages or tweets loaded in the previous session. And while you are seeing these “old” items the application can pull in newer items behind the scenes. The main idea is to not to make the user stare at an empty screen each time he opens your application.

A second benefit of this technique is that your application will feel much more responsive. As I said it is possible that the user has a slow Internet connection and downloading 12 small pictures and some descriptions could be visibly slow. Local storage can offer a “performance” boost especially for applications that access data that changes rarely.

Depending on your specific use case you may want to save locally:

media assets (images, MP3 files, video files)
text or HTML resources
XML files
ActionScript data structures (an array of ActionScript value objects for example)

August 18, 2011 | Filed Under AIR, Mobile, Tutorials | 5 Comments

Flex Mobile Development: caching images using ContentCache

There are many places where you can optimize your code especially when working on mobile applications. In this post I will focus on caching images using the spak.core.ContentCache class (part of the Flex framework).

Right from the Flex documentation, you can see ContentCache could be useful:

Provides a caching and queuing image content loader suitable for using a shared image cache for the BitmapImage and spark Image components.

Why cache images?

So why would you cache images? Every time you set a new source for a Spark Image or a BitmapImage object a new flash.display.Loader object is created to load the image bytes.

Now, let’s suppose you display a list of items and each item has an image (could be an icon or could be a picture). Each image is hosted on a remote server so it has to be downloaded. Finally, some of these images are the same for different items in the list (for example for a Twitter client it is quite common to see many entries with the same avatar; each entry represents a tweet from the same user and the avatar is the same in this case).

If you don’t use a caching mechanism, you will notice that as you scroll through the list it will take some time to load images. And the same could happen for images stored locally especially if they are not very small. While waiting for images to load and be displayed the first time is OK (and there isn’t much to do other than preload them) waiting for the same image every time it is displayed is quite annoying.

Here comes the ContentCache class. This class stores the bytes loaded (actually it stores the LoaderInfo object used for loading each image) and every time an image must be loaded it first checks the cache; if is not there then it goes through the loading process. If it is cached already, then it provides the LoaderInfo object.

August 16, 2011 | Filed Under AIR, Android, Flex, iOS, Mobile, PlayBook, Tutorials | 8 Comments

Flex Mobile Development: Creating Dialog Windows

Ever wondered how to create a modal dialog window in Flex mobile applications? For example, you may want to ask the user for a confirmation when he performs a delete operation or maybe to select an item from a list. Well, if you don’t know how to do it, then read on.

Flex has a class that just does this: SkinnablePopUpContainer. SkinnablePopUpContainer extends SkinnableContainer class and has a very simple API you can use in order to “open” and “close” the dialog.

Understanding SkinnablePopUpContainer

Because SkinnablePopUpContainer extends the SkinnableContainer it is extremely easy to create any kind of dialog window you want. You can create a new MXML component that extends the SkinnablePopUpContainer. Then you set a layout manager that works for you (VerticalLayout, HorizontalLayout). And finally, you add the UI components you need – labels, buttons, lists, and so on.

Suppose you want to create a simple alert window that looks like this:

August 10, 2011 | Filed Under AIR, Android, Flex, iOS, Mobile, PlayBook, Tutorials | 5 Comments

About Tablets and Smartphones

Lately, it is quite impossible to attend a software conference and not see sessions dedicated to mobile development. This is the hot topic of the day and rightly so, I believe. However, I have the impression that many people think that tablets and smartphones are almost the same thing. This is something that I do not believe is true. Furthermore, I think that because of this belief held by others many tablet applications end up being just a scaled up version of smartphone apps. If a tablet is just a phone with a bigger screen then a tablet app is just a bigger resolution smartphone app, right?

Let’s see why do I think that a tablet it is not just a bigger phone.

Tablets are more powerful than smartphones

This seems to be just a truism. Well, it is and yet most applications that run on tablets and smartphones tend to offer the same set of features and experience.

This is suboptimal because on a tablet you have more storage space, a more powerful processor, and a bigger screen. And, if the battery doesn’t last for a full day it is not a tragedy. Is not like you end up in the middle of nowhere with a dead phone :)

All these differences should be exploited to create tablet applications that help people to do more than what they are able to do on a smartphone. If you take into account only the bigger screen you have something that enables people to read for hours without getting teary eyed. When more storage space is available , for example, why not let the user decide how many GB your application can use and offer him a true offline experience for things like email, news, RSS feeds, videos, and so on.

Tablets are shared smartphones are personal

Correct me if I’m wrong, but I have the feeling that, at least in the case of home users, a tablet is shared. This is not the case with your smartphone. You don’t say “hey mate, here is my phone. Just return it in four hours.”

And if this is true, why are so many tablets apps built with a single user in mind? How can you have a tablet shared when you have to logout from your social or email accounts in order to let the other user do something?

Again, this feels to me like a big opportunity that it is missed. Why not enable multiusers for them and support on all the apps for which it makes sense? Remember, you do have plenty of storage space…

The Missed Opportunity

I think that this tablet shortsightedness is part of the reason for what we are seeing today: there a far fewer apps for tablets than for phones. And this is true for all the application stores.

I think that developers have a real opportunity here, and that for now it is just being missed. Once we fully understand that tablets and smartphones are different and people want and should use them differently, we will see much more innovation.

July 29, 2011 | Filed Under Mobile, Others | 3 Comments

Using Adobe AIR to reach multiple devices: Conqu

About three or four months ago I wrote a blogpost about Conqu – an AIR application for managing tasks. Since then, Conqu has been one of the best demos I have at hand when talking about mobile development with the Flash Platform. Most people couldn’t believe that Conqu was built using Adobe AIR and Flex.

Back then, it was available only for Android tablets. But today, Conqu is available in:

Running on an iPad:

Running on an Android Tablet:

Conqu is running today on three different OSes: Android (including Nook Color), BlackBerry Tablet OS, and iOS. And this is not all. They are working on making it available on Android phones, iPod Touch/iPhone, and desktop computers.

I tried the app myself on Samsung Galaxy Tab, iPad 2, and PlayBook. On each device it worked just great and looked beautiful at the same time.

I think that, with all modesty, this is a proof that the Flash Platform does deliver on multiple devices and OSes. Because the Conqu team used Adobe AIR and Flex, and applied the same tools and workflows for each version it was much easier to distribute their app across so many devices.

If you want to learn about mobile development with the Flash Platform make sure you show up at one of the events that the evangelism team is participating in all over the world. And of course take a look at the Adobe Developer Center page.

Nahuel Foronda of the Conqu team was kind enough to answer some questions I had. So here is a short interview with the team behind Conqu:

Me: What is Conqu?
Nahuel Foronda: Conqu is an easy to use yet powerful task management tool designed to help you conquer your inbox and get things done. With Conqu, you can organize the tasks by criteria that makes sense to you and then find the right task to do at the right time and place. Whether you are a GTD pro or you just need a simple to-do list, Conqu will provide you with all the tools you need.

Me: What is your business model for this app because you offer the application for free?
Nahuel Foronda: Conqu is free because we want to reach as much as people as we can. By removing the monetary barrier we believe that more people will try it out. From those that try it, some will use it once in a while but others will use it daily. People that find value on it are our real customers. They are the ones that appreciate other features like cloud synchronization between devices or the ability to interact with other APIs. Our business model is based on the synchronization service, which is a monthly subscription.

Me: Did you use the Flex framework or pure ActionScript?
Nahuel Foronda: We used the Flex Framework. It was a simple decision for us because we were already working with Flex in all of our previous projects. We really wanted to use a CSS system powerful enough to make the look and feel of our app as close to our Photoshop mockups as possible. Flex gives us that flexibility and it also has the advantage of being a great layout framework.

Me: Conqu doesn’t look like a Flex app. How did you do it?
Nahuel Foronda: We used Flex as the foundation but we created a lot of custom components. We used the List, TextInput, TextArea, Flex layouts and containers but the rest is all custom. All of the components (including those included in the framework) are highly skinned with ActionScript skins and graphics. The look and feel was very important for us, so that’s why you don’t find out-of-box Flex skins or regular Flex components in our app.

Me: The app not only looks great but performs greatly on all devices I tested. How did you do it?
Nahuel Foronda: The key for us was to use a very lightweight class as base for our components: SpriteVisualElement. That allowed our components to be very responsive. All the Flex layouts work great with this class, so we are able to include our lightweight components in any view. For the animations, we created our own layouts and use the Tweener library.
Another important optimization we did was to make all our skins in ActionScript as opposed to use MXML. In 95% of the cases we used bitmap graphics for things like backgrounds or icons instead of vectors to avoid runtime calculations.

Me: Your first supported device was Android tablet. How hard was to deliver the app for PlayBook?
Nahuel Foronda: It was not that bad, but it could have been great if we didn’t have to monkey-patch the Flex Framework to make the app that was running in AIR 2.6 run on the Playbook, which supported only AIR 2.5. I want to clarify that right now it is simple because both run the same version (2.7). At that moment, however, it took me some time to make it work. That’s what happens when you are working with a device that is not even out yet and is under development :)

Me: What about the iPad version?
Nahuel Foronda: That was perfect, very easy to make it work. We only had a couple things here and there but overall, it worked amazingly.

Me: Did you think about going native for Conqu? What made you change your mind?
Nahuel Foronda: Not really. We thought at some point about making an iOS-only version, but never three different versions. I don’t like the idea of developing an app three times for three different markets. We don’t really have the resources to do that. We also don’t have the time to develop and maintain three different platforms.

AIR allows you to focus on one code base with maybe a few differences in the layout, but still one code. What made me believe it was possible was the schedule app developed for MAX last year. That app was working very well on the small devices and because tablets would have more memory and CPU, if you built something for them, it would run even better. Now, a year later, the phones are faster too, so I believe we made a good choice.

Me: I know you have in the works versions for phones, Android and iPhone. How did you solve the problem of multiple resolutions/screen densities?
Nahuel Foronda: I’m working with the CSS queries that the Flex Framework provides. They give us the ability to use different bitmaps for the different resolutions and it is working very well for us because it keeps our code clean. Only the CSS has a reference to all the different resolutions.

Me: What about the team who build the app? I mean what experience did they have with the Flash Platform and mobile development and how large is the team?
Nahuel Foronda: We are three people on the team: a designer (Mark) that created all the mocks in Photoshop, a server side developer and Flex developer (Laura), and myself. Laura has great experience in ColdFusion and she takes care of all that plus half the Flex side (using Mate Framework). For example, she is in charge of all the model and most of the business logic in Flex. I’m complementing the team doing the optimization and all the ActionScript code such as custom component and skin development

Me: Do you have any other killer app in your pipeline?
Nahuel Foronda: We have a lot of ideas! But we are trying to focus on this one until we have released the desktop and phone versions.

Me: Is there anything you want to add?
Nahuel Foronda: Thank you so much for the interview and if your readers want to know more about the whole development process I have a very detailed post that I did not long ago.
http://www.asfusion.com/blog/entry/design-first-and-the-process-behind

July 18, 2011 | Filed Under Mobile | 2 Comments

Creating Flex Mobile Lists Part II – Using Virtualization

This is the second part (and the final one for that matter) of my post about creating Flex mobile lists (you can read the first part here). In this post I will show you how I modified the custom layout manager that I created in the first post to add support for virtualization. Also I will discuss the theory behind Flex list virtualization and creating custom item renderers.

As a reminder, in the first part I talked about you how you can create a custom list and layout manager that can be used for displaying vertical and tile section lists:

In this post I will show you how you can create layout managers that support virtualization and custom item renderers. You can see the two custom item renderers below: