On February 2nd we will host the first conference from a series of conferences about web technologies and development. Our presenter will be Vincent Hardy, principal scientist at Adobe Systems.

See you on February 2nd!

You can find more info about this conference and register here (the presentations will be in English).

PS. I am so happy to see this finally get started as I’ve been working on it for some time.

If you want to learn how to use PhoneGap to build mobile applications with JavaScript and HTML, one good way is to watch this great series of nine videos. My fellow evangelist Kevin Hoyt spent some time in the studio for shooting and the result is great. It will take you less than a hour and a half to watch all the videos.

Here is the list:

1. Getting Started with PhoneGap

2. Developing for iOS

3. Developing for Android

4. Device API

5. Accelerometer API

6. Camera API

7. Compass API

8. Connection API

9. Contacts API

In  a previous post I explained how you can use weinre to remotely ”debug” web pages that run on your mobile devices. If you are familiar with weinre then you also know its biggest limitations: no JavaScript debug support and CSS styles introspection.

Now there is no need to be sad if you happen to have a PlayBook device. If so, then you are back in business. What do I mean by that? I mean full access to Web Inspector/Developer Tools goodies while browsing web pages on the PlayBook tablet. Yes, including JavaScript debugging and CSS introspection.

A question or a doubt might pop in at this point … how this could this be possibly useful for developing web applications that run on mobile devices when Android and iOS devices have the greatest market share? Relax my friend, no need to lose your faith :D Because iOS, Android, and PlayBook default browsers are all based on WebKit. Although there are some differences between them I think they are close enough that you can get lots of value out of using the PlayBook device as the “debug” mobile platform. It also performs fine, at least today. I mean it is not too far off from the latest mobile phones or tablets.

So let me guide you through the steps you need to complete if you want to remotely debug web pages using a PlayBook.

1. Get a PlayBook

The most important step is actually getting a device :D. You might be able to buy a used one for a good price. I think it is a good investment if you plan to (or  you already) do lots of mobile web development.

2. Connect the PlayBook and your computer to the same WiFi network

This is another important step. The PlayBook browser has Web Inspector support. While you can use it directly on the device I bet my 2 cents that it is far more convenient to use it on your computer. So this is the reason you need to connect them to the same network

3. Enable Web Inspector on your PlayBook

Set up a password for your PlayBook if you haven’t already set one (Settings > Security > Password). Then open the browser application and go to Settings. Select Privacy & Security and then enable Web Inspector (it will ask for your password when enabling this option).

Once you enter the password a message window will give you the IP and port number of the PlayBook Web Inspector. Write down this info because you will need it.

4. Load the page you want to debug/profile

Now it is time to get serious. So open the web page you want to debug in the PlayBook browser. Please note that it is possible to open up a web page hosted on your computer web server (remember that the PlayBook and your computer are connected to the same network; so if you have a web server running on your computer you will be able to access it from your tablet).

5. Start Web Inspector

You can do this in two different ways. If you are a masochist you could use the Web Inspector on the PlayBook: open a new tab in your browser and type in this URL http://localhost:1337. You will see a page that has an entry for each opened tab in your browser (the URL must be opened after you enable Web Inspector in order to be listed). Here is an image to get an idea:

And here is the Web Inspector running for the first tab on my PlayBook on the PlayBook if you know what I mean:

But probably the sane way to do it is to run the Web Inspector remotely on your computer. So open a browser and type in the URL you got from Step 3. Once it is loaded you can select the tab you want to debug. And once you select the tab the Web Inspector should be displayed. From now onit is business as usual: you can access Elements, Resources, Scripts, Timeline, Profiles, Storage, Audits, and Console. You can debug the JavaScript code, audit the page for performance, and all sorts of magical things.

Here are screenshots with the Web Inspector running on my machine and the page I am debugging on the PlayBook. In the Web Inspector I selected a DIV element and you can see that the element was highlighted in the PlayBook browser.

Word of warning: it might take a while for the Web Inspector to initialize on your machine. Be patient and don’t give up.

Conclusions

If you are not excited by this amazing workflow then there must be something wrong with you (or you are not a web developer and then it is OK :D). Again it might not be the perfect solution. I mean in a perfect world you’d have something similar for each mobile platform. Until then don’t whine too much and do your work with what you got!

Here is a screencast that takes you through the setup steps of the PlayBook Web Inspector and shows a simple debugging session. Enjoy!

While using Canvas 2D context for drawing stuff I discovered that the drawing line API can surprise you a bit especially when drawing horizontal or vertical lines. Here is a screenshot with a Canvas element and 5 lines drawn using lineTo() calls:

In case you haven’t noticed, let me tell you what’s wrong with this: the lines are suposed to be 1 pixel width and black. Clearly what you see on the screen is not 1 pixel and the lines are somehow grayish. It looks more like 2 pixels. The code for drawing this looks like this:

<input onclick="draw()" type="button" value="draw" />

<script type="text/javascript">// <![CDATA[
function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;
    context.lineWidth = 1;
    context.strokeStyle = '#000000';
    for (i = 0; i < 5; i++) {
       context.moveTo(0, y);
       context.lineTo(450, y);
       y += 10;
    }
    context.stroke();
}
// ]]></script>

Let’s change the line width to 2 (line 10 in the above code snippet) and check the result:

Interesting, isn’t it? So the lines width is basically the same, but the color now is really black. Now, let’s try something else: change the line width back to 1 and adjust the y property of the moveTo/lineTo functions with o.5 (line 13/14):

context.moveTo(0, y + 0.5);
context.lineTo(450, y + 0.5);

And surprise, surprise the lines are now exactly 1 pixel and black:

So what’s happening? After some research I think that this is what is happening:

• When you use integer coordinates like 10 or 15 the drawing algorithm is actually trying to draw a line in between two pixels (for example between the 9th and 10th pixels). As a result it will actually draw two lines.
• I think the line is slightly lighter than the color set because of the antialiasing algorithm.
• When you offset the coordinates by 0.5 then you “end” up with drawing the line exactly on one pixel.
• If you draw a 1 pixel vertical line from (0,0) to (0,200) you will see that this time the line is exactly one pixel wide but the issue of lighter than defined color remains. As there is no other pixel to the left of the 0 pixel on the X axis on the screen you will see only one line.

Using fillRect() function instead of lineTo()

If you don’t like adding those 0.5 to any coordinate when using the lineT0() API then you can actually use the drawing rectangle API. As you probably already guessed, the trick is to draw a rectangle of one pixel for one dimension and the length you need for the other one. So here is the script for drawing 5 horizontal lines:

function draw() {
    var context, i, y;

    context = document.getElementById('canvas').getContext('2d');
    y = 20;

    for (i = 0; i < 5; i++) {
       context.fillRect(0, 10 + y, 450, 1);
       y += 10;
    }
}

And here is the result:

If you are wondering about performance differences between lineTo() and fillRect() then you shouldn’t. fillRect() is probably even faster than lineTo().

You can see here a page that illustrates the differences between lineTo() and fillRect() when using integer coordinates.

If you are a web developer chances are that Google Chrome Developer Tools, Safari Web Inspector, or a Firefox equivalent are your best friends when it comes to debugging web pages (check CSS styles, verify generated HTML, or debug JavaScript). Isn’t that great? I mean not so long ago we used to debug JavaScript using alert() calls.

Once you get used to these tools it is hard not to have them. And this is exactly what happens when you move to mobile web development. As you probably know there is no web inspector running on your iOS device browser.

How do you debug your web apps when running on mobile devices? The best answer to this question is using weinre (if you know a better way, please let me know).

What is weinre?

weinre is a remote Web Inspector that runs on your computer but it is connected to a browser (or a PhoneGap application) that is running on a mobile device. In terms of user interface it reuses the Web Inspector project at WebKit.

weinre consists of a debug server that runs on your computer and a user interface that also runs on your computer. The server component is able to communicate with the web page you are “debugging” (that typically runs on a mobile device) thanks to a JavaScript script that you have to inject in the page you want to debug (the script is served by the server component). And here comes the first thing you have to know: because of this architecture your mobile phone must be able to reach the server running on your computer (you can easily achieve this by connecting the computer and mobile device to the same WiFi network). If you are curious about how the web page running on the mobile device is able to communicate with the debug server, the answer is using XMLHttpRequest.

Finally, weinre is distributed either as a Java JAR file or as a Mac OS X application. This means that you can use this tool on a Windows, Mac OS X, or Linux machine.

Are there any limitations?

Unfortunately there are: you can’t debug the JavaScript code. This means you are not able to set breakpoints in your JavaScript code and introspect the variables. Unfortunate though this limitation might be, weinre is still incredibly useful because you can introspect the HTML code, see the Console output, execute JavaScript code in the console, get information about the XHR calls made by your page, and even select DOM elements.

How can you use it?

Here is a step-by-step list that explains how you can use weinre to “debug” a web page that is running on your mobile phone:

1. Download the weinre debug server application

First download the weinre application (this will be basically the debug server). I will use the Mac OS X application instead of the JAR file and I will point out what is different if you use the JAR file.

2. Connect the computer and mobile device to the same WiFi network

After you download the weinre file it is time to connect your computer and mobile device to the same WiFi network. Once the computer is connected, it is time to find out what IP address it is using. On my case the IP address is 42.1.2.250.

3. Configure the weinre debug server application

Now, it is time to configure the weinre debug server. Because I am using the Mac OS application, all I have to do is to create a server.properties file in the following location: ~/.weinre/server.properties

Next, open the server.properties file and add these two lines (for boundHost you have to introduce the IP address of your computer and for httpPort you can use any port number you want that doesn’t conflict with other web servers that might be running on your computer):

boundHost: 42.1.2.250
httpPort:  8080

Make sure you save the file.

If you use the JAR file, then you can set the options either using the server.properties file or adding them as options to the command line when invoking the JAR file.

4. Start the weinre debug server

For the Mac OS X app all you have to do is start the weinre application. If you use the JAR file then you should start the application using the command line.

5. Inject the JavaScript file in the web page you want to debug

With the debug server running it is time to inject the JavaScript file that makes all the parts to communicate. To do so, open the HTML page you want to “debug” and add this line:

<script src="http://42.1.2.250:8080/target/target-script-min.js#anonymous"></script>

Please note that the IP address and port number must match the values you set in the server.properties file. Make sure you save these changes.

6. Make the web page available to your mobile phone

Now, you are ready to debug the web page. However, in order to do this you have to load this page in the browser that runs on your mobile device. You will have to copy the web page and its dependencies to a web server running on your computer. In my case I’m running a MAMP instance on port 80. So what I’ve done is to copy the folder where I created the web page to the htdocs folder of the MAMP. Make sure the web server you want to use is running.

7. Load the web page on your mobile device browser

Open the browser on your mobile phone and load the page: http://42.1.2.250/weinre/index.html

Please note the IP address and port number must be your computer IP address and your web server port number (in my case I am running on the default port so there was no need to add it) and the rest of the URL must match the folder/file name you have.

8. Debug the page

Once your mobile browser loads the page, the weinre application should look like this:

In the picture above Targets refers to the mobile device browser (so the IP address is your mobile device IP) and Clients refers to the debug client/server.

Here is a screenshot with the weinre application when the Elements tab is used and the console is opened too. You can see that the whole body element is selected. And in the console you can see some outputs. These were dysplayed once I hit the two buttons I have created in the web page.

And here is a screenshot of the web page running on my Android phone. As you can see the body is selected – because in the weinre app the body element was selected.

Finally, the web page used in this example looks like this:

<!DOCTYPE HTML>
<html>
<head>
<meta charset=”UTF-8″>

<title>Testing</title>
<script src=”http://42.1.2.250:8080/target/target-script-min.js#anonymous”></script>
<script>
function clickBtn() {
console.log(‘clickBtn() was called!’);
}
function click2Btn() {
console.log(‘click2Btn() was called!’);
}
</script>
</head>
<body onLoad=”init()”>
<h1>A simple page</h1>
<h2>To test weinre – Web Inspector Remote</h2>
<button onClick=”clickBtn()”>Click Me</button>
<br>
<button onClick=”click2Btn()”>Click Me Too</button>
</body>
</html>

If you use the JAR file, then you should open on your computer this URL: http://42.1.2.250:8080/client/#anonymous. Again change the IP address and port number to what you configured for the weinre debug server. Here is a screenshot with the debugger client opened in my browser:

For your convenience, I captured this workflow in a short screencast:

Conclusions

Although you don’t get all the features available in the desktop Web Inspector, weinre is still a formidable asset in any developer’s toolbox. I mean without this you would have to use alert() or some other ten times more time consuming technique. Recently I was working on a web mobile application and weinre came to my rescue on a number of occasions.

I intended to write this post last month. But because the last two months were so busy, in the end I could find neither the time nor the energy to write. So here I go with my first post in 2012 that partially talks about 2011.

Speaking of the previous year, I’d like to extend a big thank you to all my readers and followers. Knowing that people will read your posts and send feedback is like fuel for engines. Next, I’d like to say thank you and applaud all the community leaders who worked so hard to organize events. I know firsthand the hard work needed to put together an event. You guys did an amazing job in 2011. I feel both proud and lucky being able to be part of some of the events you organized around the world.

People asked me what the highlights of 2011 were for me. Many things come to mind, but once I boiled them down they distilled  down to only two:

1. Adobe AIR and Flex demonstrated that development for multiple mobile platforms can be both fun and efficient. Indeed, what started as a promise back in 2010 grew to an amazing platform in less than a year.
2. Adobe increased investment and effort in HTML/CSS/JavaScript. The last part of 2011 only accelerated a process that started long ago and produces things like: CSS Regions and Exclusions, CSS Shaders, Dreamweaver support for jQuery and PhoneGap, contributions to WebKit and jQuery Mobile. The PhoneGap and Typekit acquisitions cemented these trends and set up a perfect scene for more things to come moving forward.

What about me (I know, I know it’s a bit too much :D)? Well, I couldn’t be happier to tell you the truth! I am still having the time of my life and enjoy every bit of my job :) I’ve been doing evangelism for almost four years and I’m looking forward to many more. However 2012 marks a change regarding what my focus will be: I will focus more and more on HTML, JavaScript, and CSS. And I have to confess that I’m excited. First, because this is how I started to make money programming years ago (HTML/JavaScript/CSS and server-side technologies). And second, I think Adobe is extremely well positioned on moving forward the web standards and HTML authoring/services tools.

What about Flex, AIR, and Flash Player? Despite what some people are saying I think they will be doing great. The runtimes are pushed harder and harder because Adobe wants to make the Flash Platform the game console of the web. This means that even if you are not in the gaming industry your Flash apps will benefit. What about Flex? I think the Flex framework is mature, it has a great community around it, and it is used for big enterprise projects and consumer apps. Having said that I think that the Flex framework will be relevant as long as the community wants it to be. Because if the community doesn’t believe in it and stops using it then it doesn’t matter what Adobe does and who’s behind it. I will surely keep an eye on what you guys will be doing :).

I wish you a Happy New Year!

Recently I played with CoffeeScript a bit. Friends were talking about CoffeeScript and also I read couple of interesting blog posts. Based on my limited experience with it here is my understanding of what is cool and not so cool.

Cool:

1. It is much more compact than JavaScript. This translates to up to 1/3 less lines of code than the equivalent JavaScript
2. Offers the concept of classes – something that is familiar for people coming from the Java world
3. Insulates you from JavaScript pitfalls like global scope
4. Some times you can get a performance boost – hard to tell when and by how much
5. Some compile-time error checking, which helps you to write code with fewer bugs right off the bat

Not so cool:

1. Hard to debug. You have to debug the generated JavaScript code and from there you have to trace back to the CoffeeScript code
2. Writing less code can actually be something bad. Anyone remember Perl? And how hard it can be to read Perl code?
3. Adds another layer of abstraction on top of the browser stack. Adding to this jQuery or other frameworks and you can easily be in a situation where you can put together reasonably complex apps but you have no idea of what is happening under the hood nor how to fix a bug that originates from the frameworks you used
4. While I understand from why is done the way it was, I still think it would have been nice to have optional data typing

Maybe not so surprisingly , I’ve seen people coming from OOP languages (Java or C#) that totally love CoffeeScript and this is their preferred way to write JavaScript apps.

As I said, I just played with it. So if I misunderstood something or completely missed a point please let me know.

My colleagues from the Enterprise team were busy updating the Tour de Flex application to Flex 4.6 and they have published it to Android Market and the Apple App Store.

What’s cool about this project is that it is a three-in-one type of product: you can learn how to use Flex, you can experience the performance of the Flex framework on mobile devices firsthand, and you can check the source code and learn how to build awesome mobile projects. Here is the project home page and you can get the source code from here (you’ll need Flash Builder 4.6 to import the project).

And if you’re looking for the app on the stores search fom “Game of Flex” and not Tour de Flex!

I’ve been receiving a number of emails on this topic lately. It seems there is little information out there about how to move from development to production with a Flex and PHP application. Here is a simple checklist that could help you, especially if you are doing this for the first time. Please note that I presume you used the Data Services (wizards) to connect the Flex client to PHP services.

1. Make sure you have Zend Framework on your server. If you don’t, install it
2. Make sure you change MySQL credentials and server IP/name used by your PHP scripts to connect to the database
3. Copy the PHP services folder to your server. Then test these services. If they don’t work check the MySQL credentials or look for dependencies (maybe your PHP services use other PHP classes that you forgot to copy to your server)
4. Edit the amy_config.ini file and make sure the path to the Zend Framework is OK and set production to true
5. Edit the Flex services to point to your live server gateway.php. In the services folder of your Flex project you will find _Super_something.as files. In the constructor you will find a line like this:

   _serviceControl.endpoint = “http://localhost:10088/MobileFlexPHP-PHP/public/gateway.php”;
   Copy that line and then open the class that extends this _Super class and paste the line in the constructor. Then change the URL to reflect your server setup

6. Copy the bin-release/ folder to your server (you should choose the export release for your project; this will create a SWF file smaller than the debug version)

That’s it! If I missed something please drop a comment!

As many of you probably know we made a few announcements last week that are quite interesting – let’s put it that way :). What made things even more interesting for Ryan and me is that we were right in the middle of the tour on mobile development (and we are still on tour for that matter). So we got your feedback first hand.

The good news is that last night the Flex team posted an update that adds more context and details about how Adobe plans to move Flex to Apache Software Foundation. And in short the essence of this update is that we still support Flex and Flash Builder; they won’t go away and we are not killing them. Here are some quotes from the post:

What specifically is Adobe proposing?

We are preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation.

In addition to contributing the core Flex SDK (including automation and advanced data visualization components), Adobe also plans to donate the following:

• Complete, but yet-to-be-released, Spark components, including ViewStack, Accordion, DateField, DateChooser and an enhanced DataGrid.
• BlazeDS, the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex applications.
• Falcon, the next-generation MXML and ActionScript compiler that is currently under development (this will be contributed when complete in 2012)
• Falcon JS, an experimental cross-compiler from MXML and ActionScript to HTML and JavaScript.
• Flex testing tools, as used previously by Adobe, so as to ensure successful continued development of Flex with high quality

Adobe will also have a team of Flex SDK engineers contributing to those new Apache projects as their full-time responsibility. Adobe has in-development work already started, including additional Spark-based components.
Isn’t Adobe just abandoning Flex SDK and putting it out to Apache to die?

Absolutely not – we are incredibly proud of what we’ve achieved with Flex and know that it will continue to provide significant value for many years to come. We expect active and on-going contributions from the Apache community. To be clear, Adobe plans on steadily contributing to the projects and we are working with the Flex community to make them contributors as well.

You can read the whole post/update here. And drop a comment if you have something to share!

We just launched the Adobe Touch Apps part of the Adobe Cloud. You will find the six apps in the Android Market with one of them being available for iOS too (iOS versions will follow). Just as a quick reminder the six apps are: Collage, Debut, Ideas, Kuler, Photoshop Touch, and Proto.

I think this is great because it was about time we had more apps for tablets that can be used to create digital content. So far developers and companies were extremely good at creating apps for consuming existing content on tablets. As I said many times it is a pity not to be able to create content on your tablet device. I think that with the Adobe Touch apps we are going in the right direction: you can start working on a prototype while you are commuting and all you have is your tablet. Once you get to your computer you can continue your work on the same file. And the synch process between your computer and tablets devices is transparent; it happens auto-magically.

You can read more about these apps here.

This Friday we will host a Flash Camp in our Bucharest office. The event starts at 5:00 PM and will end at 8:00 PM. If you have questions about what was announced at MAX, if you want to find out what’s coming next, or if you want to learn how you can start mobile development with our tools, runtimes, and frameworks then make plans to be there. There are still a few seats left so you can go here and register.

This event is a premiere because for the first time I will have the pleasure of co-presenting  (a Romanian event) with one of my American teammates: Ryan Stewart. So that is another reason to be there :)

And finally, we will have a hands-on session on getting startet with mobile development with Flex, AIR, and Flash Builder. So if you never tried Flex mobile and you want to learn the basics then you have a third reason to be there.

See you Friday!

Registration link.

With almost all the bits and pieces falling nicely in place I can finally blog about the European tour we’ve been working on. Before talking about content, dates, and locations let me say loud and clear “Thank you!” to the people in our community who worked hard to make these events possible and to Magda Neagu and John Koch, my colleagues who gave us all the support we needed.

Why am I saying us instead of I? Because I have the pleasure of doing this tour together with my friend and fellow evangelist Ryan Stewart.

Here is the list:

1. November 3rd – Vienna / Austria
2. November 4rd – Rome / Italy
3. November 7th – London / UK
4. November 9th – Kiev / Ukraine
5. November 10th – Berlin / Germany
6. November 11th – Bucharest / Romania
7. November 14th – Zurich / Swiss
8. November 15th – Dublin / Ireland
9. November 17th – Barcelona / Spain
   1. We will do a session at Barcelona DevCon
   2. We will have a meeting with the local Flex and Flash user group. I will update this post once I have the location and date
10. November 19th – Zagreb / Croatia

If you want to attend one of these events make sure you register today because the number of seats is limited.

In terms of content, we will do a hands-on on mobile development with Flex, Adobe AIR, and Flash Builder. We will also have sessions about mobile development and some of the cool things we announced at MAX. And this will provide you with the perfect opportunity to throw questions at us. Actually let me re-phrase this: it will be the perfect opportunity to ask Mr. Ryan Stewart anything you want to know :).

Last but definitely not the least, if you have a cool project and you want to show it to us, please don’t be shy. Come to us after the event or during one of the breaks and we will listen to you. We always love seeing the great stuff you build and listening to your feedback. If you are reading my blog you know that from time to time I blog about cool apps and projects.

PS. If you plan to attend one of our hands-on sessions then you should have Flash Builder installed on your laptop. Also, if you have an Android phone you will be able to run all the examples on your device too (you will need a USB cable to connect the device to your laptop). Otherwise you can use the Flash Builder desktop simulator.

The latest release of the Chrome browser (15 was launched last night) makes Chrome the first browser that offers support for the CSS Regions feature. This is really amazing as the story has been developing for a little bit more than a year: from the initial idea, to the first proof of concept, then working with the standards bodies and WebKit, and finally to Chrome 15.

If you have the latest Chrome on your machine (should work on both Windows and Mac OS) you should be able to test this page. Just play with the size of your browser window and you should see how the text fills the three different columns.

PS. Just talked to the Adobe engineers that work on this and they told me that there might be a small glitch with how the text flows sometimes. But this has been already been fixed in the main line. So probably the next update of the Chrome will pick up this change.

Later Update: Peter Elst dropped me a message telling me that the CSS Regions examples we host on Adobe Labs don’t work in Chrome 15. This is true and normal at the same time. The examples we have there represent one of the first drafts of CSS Regions. Since then the syntax has changed. This is why I included a page for test in my post.

Later Update 2: Someone told me that Internet Explorer 10 already supports CSS Regions. This is true, but IE 10 is a pre-release version while Chrome 15 is a “production” ready release.

We just released Flash Player 11.2 Beta and Adobe AIR 3.2 Beta on Adobe Labs. The main features for this release are:

Multi-threaded video decoding (Windows, Mac OS, and Linux) — The video decoding pipeline is now fully multi-threaded. This feature should improve the overall performance on all platforms. Note that this feature is a significant architecture change required for other future improvements.

Flash Player background updates (Windows) — New versions of the runtimes can now be delivered more effectively to the end user with this enhanced updating mechanism (Background update is only available in the release versions of Flash Player).

From the release notes some additional info on the multi-threaded video decoding feature:

Multi-threaded pipeline was written grounds up to support lower end devices and full hardware stacks where all the decoding and rendering isoffloaded to hardware. The benefits of the modernization of the pipeline would be visible from mobile devices, tvs, netbooks to high end desktops.In Flash Player 11.2, the new video pipeline is available for desktop platforms (including netbooks ) and brings enhancements with respect to:

• Eliminating jitter seen occasionally in some encoding and typically in live streams and real time interactive scenarios.
• Gains in frame rate by reducing dropped frames as much as 50% on certain platforms with high bit rate content.
• Seek frame accuracy.
• High resolution/bit rate content decoding would still keep the player UI responsive and any background ActionScript processing going,which earlier could have experienced brief halts because all the decoding and player UI/ActionScript resided on the main thread. For HTTP streaming, ActionScript is the control point of fetching the stream data and delivering to the video stack. On seek, earlier thestreaming would halt, while the frames up to the point of seek would be getting decoded. With multithreaded video decoding, not onlywould the seek be more responsive, but it would also start playback faster after seek.
• 50+ fixes as part of the modernization of the video pipeline architecture

Is this cool or what?

This week I’ll be at the ZendCon PHP Conference in Santa Clara. I will have a session on Flex and PHP mobile development for iOS, Android, and PlayBook on Thursday starting at 9:15 AM.

If you plan to attend this conference make sure you drop by to say hello. We will have a booth in the exposition area next to Zend’s booth.

I’m really excited to be part of this conference. First, it is my first PHP conference in the States – so far I’ve been speaking only at European conferences. And second, it has been a while since my last PHP conference. I think I will have a great time catching up with what the PHP community is doing these days. I already picked up some sessions that I’m sure will blow my mind :)

Now straight to the airport! A long trip awaits me!

MAX 2011 was the sixth MAX for me and I have to admit it was by far the most interesting to attend. Judging by the discussions I was involved in or I overheard while being at MAX, I think that this is a feeling many share.

Fellow evangelists Ryan Stewart, Mark Doherty, Greg Wilson, and Michael Chaize already wrote about MAX so I won’t reiterate all of the news and announcements. However, I want to highlight some of the things I consider quite important.

Adobe Touch Apps

I’ve been arguing for a while that (1) tablets are not just bigger smartphones and (2) tablets could be used for more than just consuming digital content. So you can imagine how happy I was when I first heard about Adobe Touch Apps.

Adobe Touch Apps is a suite of applications that works on tablets and enables you to create and share content:

1. Adobe Photoshop Touch – the name says all, doesn’t it? But make sure you check the video because you’ll be surprised by how powerful this app is.
2. Adobe Ideas – a digital sketchbook for artists.
3. Adobe Collage – create moodboards with ease. You can search for images, bring them into the app, and modify.
4. Adobe Proto – this product has a good amount of magic. Using simple gestures you can create wireframes or interactive prototypes. In a matter of seconds you can add a header, a content area, a menu, pictures, and text
5. Adobe Kuler – Kuler has been around for some time (2007 to be precise). It is the little app that helps you find colors that work together. There is a large community who adds new swatches. Once you find a theme you can easily customize the colors.
6. Adobe Debut – helps you to share design/digital content created with Creative Suite anywhere right on your tablet.

You can find here a number of videos that show these apps in action.

As I said at the beginning of this section I’m glad to see apps for tablets that help people to create content on the go. However there is another thing that this suite is trying to address: device fragmentation. But first, let me present you the high-level vision. We announced a new initiative called Adobe Creative Cloud. Adobe Touch Apps is part of the Adobe Creative Cloud along with other services (such as Adobe Digital Publishing, Business Catalyst, and Typekit) and products (such as Photoshop, InDesign, Illustrator, Edge).

And one of the many benefits of these offerings is the seamless cross device synchronization. In other words you can take a picture with your phone or tablet and then open up your desktop or laptop and you will find the picture there. The bits are moving magically from one device to another (well you do need a Internet connection for this :D).

Stay tuned and early November you will find Adobe Creative Cloud prices.

HTML and Adobe

We talked a lot about HTML at Adobe this year. I bet you couldn’t believe the acquisition announcements of Nitobi/PhoneGap and Typekit :) However this is only one part of what we are doing at Adobe for the HTML world. These add to work around jQuery Mobile (last year we announced that we will contribute to jQuery Mobile), tooling for HTML5 (the Edge project and Wallaby are just two examples of new initiatives that complete Dreamweaver CS5.5 support for HTML5/CSS3).

So as you can see the work Adobe is doing around HTML5 is pretty significant and has reached the point where people from outside Adobe or Adobe’s community recognize this.

One aspect that is fast growing is the work Adobe does in moving web standards forward. Let me step back and tell you a short story. Back in 2007, Adobe AIR (called Apollo back then) saw the lights for the first time. And from the beginning we wanted to build a new runtime that would appeal to all web developers. What technology did developers use for building amazing websites and applications? JavaScript and ActionScript. Thus Adobe AIR brought support for both technologies. And the JavaScript/HTML/CSS support was made possible by including the WebKit engine in the AIR runtime.

Of course, we had to extend the WebKit engine in order to have the same APIs/capabilities as we had in ActionScript. For example to have access to the hard disk, to write/read encrypted data, SQLite support, camera and microphone access, and so forth (does this sound familiar? :D).

By doing this, our engineers became experts in WebKit. Fast forward to 2010 and we announced the CSS Regions proposal. Our engineers provided an implementation for this feature for WebKit. And this year we have two Adobe engineers who obtained the WebKit committer status. This is something great and I am proud to say I’m a friend of these two guys. I hope to see them getting the WebKit reviewer status :).

As the work with CSS Regions was moving on nicely, Adobe engineers didn’t stop here. At MAX 2011 we showed a new CSS feature that we are working on called CSS Shaders. Working with Apple and Opera we already submitted this proposal to W3C. Go here and watch the videos.

I have to admit that first time Alex showed me this (he’s one of the two Adobe WebKit committers) in action I was sure it was just some Flash application. When he told me that it is, actually, a modified WebKit and some CSS and JavaScript I was speechless.

So yeah, I think it is safe to say that Adobe “gets” HTML and we have lots of proof for this. And I know more things will come in the near future so stay tuned.

Flash Platform

Despite what others might think, my personal belief is that the Flash platform had an amazing year in 2011. With AIR 3, I think we have one of the best solutions for building mobile apps across devices and operating systems. The Native Extension feature makes it possible to extend the runtime and have access to all the other APIs available on the device right from your ActionScript code. The upcoming version of Flex, 4.6, will extend the support for mobile components and improve the performance.

With Stage Video and Stage 3D (Stage 3D is available only on desktops for now) you can build amazing applications that can handle video, sound, and complex 3D content. So playing Unreal Tournament in a browser through Flash Player became a reality.

What about new stuff? Well, take a look at these two sessions about the future of Flash Player from MAX: Flash Platform roadmap and What’s new in the Flex SDK. Workers (concurrency), a new Flex compiler, better tooling support (Flash Builder), and an amazing telemetry tool for profiling the release SWFs (Monocle) are things we are working on.

HTML and Flash

Last week I had an interesting discussion with two community leaders in the airport (hey guys, I hope your trip back home was fine :) ). And they were asking me about the future of Flash and what Adobe will do (they are first and foremost Flash guys). The main reason for all these questions was how the keynotes were perceived.

Since then, I thought more on this and watched again the keynotes. My personal belief is that all the effort Adobe puts in both HTML and Flash will actually serve developers and designers independently of what their first choice is. Joseph Labrecque has a good post on MAX 2011 and what some felt right there when everything was still hot.

Let me explain why. First, Adobe will be able to provide the best tools and frameworks for both technologies. If you are a developer or a business owner who uses Adobe technologies you’ll find easier to pitch your solutions. Clients would not see you as someone who only cares and knows only HTML or Flash. You’ll be able to propose the best technology for each project/client need. Definitely, this makes our life as Adobe evangelists much easier. Instead of being pushed into a defensive stance or fighting to be credible now we can just focus on the two sides of the stories.

Second, if you take a look at the history of Flash and how Flash relates to HTML it has already been about Flash doing stuff that wasn’t possible just with HTML. And the relation between these two was “AND” and not “OR”. “OR” implies that there can be only one choice. “And” means that they will co-exist. Some people after watching the keynotes they left with an “OR” in their hearts.

Third, if you are a guy who’s been building interactive content with the Flash platform then you are incredibly well positioned. Because you already know how to design and choreograph great content and apps. Without these skills all the JavaScript and HTML5 knowledge in the world can’t do much.

In reality for the foreseeable future the Flash platform will still be able to do things that are either impossible or more expensive with HTML. Certainly amazing 3D capabilities seems to be the main Flash usage. But let’s not forget about all the other goodies (improved Flex framework and Flash Builder, concurrency, and a faster compiler). These are things that will help developers who build interactive applications for desktop or mobile to be more efficient while building better apps than today.

Conclusions

I think 2012 will be an even more interesting year. Personally, I can’t wait. I’m so looking forward to see what people will build using AIR 3 and Native Extensions. I can’t wait for Stage 3D on mobile.

Second, yes you will be seeing us talking more and more about HTML and the things we are doing here at Adobe. Fellow evangelist Ryan Stewart already started working with PhoneGap. I’m doing the same. Actually, I hope to port one of my mobile apps to PhoneGap this month to better understand this platform.

At the same time, we are still working on the Flash side as hard as ever. Right now, I’m working with Ryan on the content for a European tour about Flex mobile development. We will hit about 9 different locations all over Europe. Once we have set up everything we will post all the details (by the way a big thank you to all the people from the community who are making this tour possible). So stay tuned and try to attend if you happen to be around of one of the locations.

Finally, I want to add that with each year I enjoy Adobe MAX more and more. It has to do with the feeling of family/community. There are thousands of people over there and from all over the world. And still you bump into someone who built something you knew or who read something your wrote or used/extended your code. This year I met people from South America, North America, and Europe. Actually there were lots of Europeans. To all of you, thank you for your time, and the friendly and insightful discussions. Looking forward to meeting you next year :)

Later this week Adobe MAX 2011 will be officially opened. Last week I blogged about some of the sessions and labs that will be focusing on mobile development. This week I wanted to highlight some sessions that are built around specific devices.

Adobe AIR and TVs (Samsung and LG)

Televisions are getting smarter and smarter. This means that you (individual developer or company/agency) have a great opportunity to build the killer apps people will want to buy or use on their latest generation TVs. If you want to find out more about what you can do and how, bookmark these sessions:

• Creating Apps in 2D or 3D for the LG Cinema 3D and Smart TV Platform – Learn how you can unlock opportunities in the multibillion-dollar TV market by discovering how to create 2D and 3D apps for the largest screen in the home. Be the first to see a 3D app created for LG’s Cinema 3D Smart TV platform using Adobe AIR, and learn how the LG Smart TV developer program can allow you to capitalize on this rapidly growing market segment.
• Developing the Samsung Smart TV Application with Adobe AIR for TV – Join the Samsung team for an introduction to the Samsung Smart TV platform. Hear about how to make AIR for TV applications for Samsung Smart TV and how to deploy to Samsung Smart TV. Adobe AIR for TV 2.5 is available to developers on 2011 Samsung Smart TV models, and the Samsung TV application software development kit (SDK) integrates support for Adobe AIR for TV 2.5.

Sony Android Tablets

Sony announced this summer two Android based tablets that will be shipped later on this year. This was a surprise for many as this marks the first time that Sony has built a tablet that uses Android. At MAX you can attend these two sessions:

• Adobe AIR App Demo Showcase for Sony Tablet Devices – Watch live demos of innovative applications built by your peers that take advantage of the unique capabilities of the new Android Sony Tablet devices. Hear the developers talk about their experience using Adobe AIR to develop their apps for a single-screen and a dual-screen Sony Tablet. Learn more about Sony Tablet features and how you can win up to US$130,000 for your breakthrough app by entering the Adobe AIR App Challenge, sponsored by Sony (www.airappchallenge.com).
• Optimizing your Adobe AIR app for Sony Android tablets – See live demos exploring the unique features in the new Sony Tablets and demonstrating how to develop your Adobe AIR app to display on both single- and dual-screen devices. Find out about exciting opportunities on Sony’s Android tablets, including the Adobe AIR App Challenge, sponsored by Sony (www.airappchallenge.com), which offers developers US$200,000 in cash prizes, premium promotion on Sony Tablet, prerelease tablet access, and more.

BlackBerry PlayBook

To date, the PlayBook is one of my favorite tablets that money can buy. And one of the things that make this tablet special is that you have multiple ways to create your application, from HTML to ActionScript/Flex. Here are some related sessions:

• BlackBerry Webworks SDK for Tablet OS – Transform your existing web content into a fully featured standalone application for the BlackBerry PlayBook using the BlackBerry WebWorks SDK for Tablet OS. You’ll discover how to leverage supported technologies such as HTML5, CSS, JavaScript, and Adobe Flash to produce visually stunning, highly functional applications for PlayBook that can integrate with the underlying Tablet OS. Take away the skills and resources needed to create PlayBook applications using the WebWorks SDK.
• Creating Amazing Video Experiences on the BlackBerry PlayBook Tablet – Learn how BlackBerry Tablet OS developers can leverage the rich multimedia capabilities of the BlackBerry platform to create compelling video experiences that attract users. Presenters will discuss video encoding strategies, streaming options, DRM support, output control, and media events. Topics covered include a video API overview, BlackBerry Tablet OS multimedia architecture, and video application demonstrations.

NOOK Color

NOOk Color from Barnes & Noble is one of the hot devices on the market – the content, distribution, Android OS, and demographics all make this device special. Well, if you live here in Europe not so much :D. At MAX you can learn more about this ecosystem:

• The App Opportunity with Barnes & Noble – Bring your rich content to the leading monetization platform for Android — NOOK Apps by Barnes & Noble. This session will focus on the business opportunity, market demographics, and advantages of publishing Adobe Flash and AIR based apps for NOOK Color. Make sure to stop by the NOOK developer booth to attend one of our 50-minute workshops on development of NOOK apps and for a chance to win a NOOK Color.

Motorola

If you ever developed a mobile application you know that building the app is just one of a long list of the check points you have to complete. And arguably it is the easiest to check too (thanks to Adobe AIR, Flex, and Flash Builder I’d say). One question I heard at many mobile events is related to application discoverability. At MAX you can learn about making your app more visible in Android Market and on Motorola smartphones and tablets:

• Get Your App Discovered: Android Market and Beyond – Join Randy Ksar, Motorola Mobility Community Manager for MOTODEV, on best practices to get your app discovered in the marketplace. Randy will cover how to optimize your Android Market listing, utilize social media as a marketing and customer feedback tool, leverage testing to improve your customer ratings, and introduce new marketing opportunities to get your app featured on Motorola Mobility smartphones and tablets.

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:

1. Gyroscope (iOS/Android)
2. NetworkInfo (iOS) – retrieves information about the network interfaces on an iOS device
3. Vibration (iOS/Android) – make the device vibrate
4. iBattery (iOS) – gets the battery status (unknown, unplugged, charging, or full) of an iOS device
5. .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.

Today Adobe announced that the next version of our runtimes, Flash Player 11 and AIR 3, will be released in early October. This is great news for all developers who rely on the Flash Platform for building desktop and mobile applications.

Just a reminder about some of the coolest new features coming with these releases:

• Stage 3D – a new architecture for hardware accelerated graphics rendering that delivers 1000x faster rendering performance over Flash Player 10. This will enable developers to create immersive experiences whether is about a first person 3D game or some 3D or 2D scenes.
• Full native 64-bit support for Flash Player on Linux, Windows, and Mac OS.
• Captive runtime for AIR. Developers will be able to package their AIR applications together with a specific version of the AIR runtime. This means that users won’t have to install the AIR runtime when installing your AIR application or you can protect “freeze” your application to a specific version of the runtime so you don’t have to worry about testing your app when a new runtime is out.
• Native extensions for AIR on Android, iOS, and desktop. This feature enables developers to take advantage of existing native code libraries as well as deep native hardware and OS capabilities. Using this feature you can create extensions that give access to notifications or the contact address book for example.

Gaming

If you’ve ever played games like Machinarium or Tanki Online you know that Flash Player is one of the best options out there for developers and companies who want to build online games. To help you getting the most out of the Flash Platform we created a gaming center: Adobe Gaming Solutions.

We are also announcing the Starling framework: a lightweight framework for 2D graphics and animation that combines the simplicity of Flash with the power of the Stage 3D API. It is an open source ActionScript library. Watch this particle effect with Starling and Flash Player 11:

Adobe will also soon make a 3D framework technology preview called Proscenium. This will allow developers using Flash Builder to rapidly prototype apps focused on simple content interaction and display, whether for simple games, visualization, or high-quality rendering of small object collections.

Mobile Apps Support

The Native Extensions feature is aimed at mobile developers. I believe that this feature was the “missing link” that stopped some people who otherwise would have chosen the Flash Platform.

Indeed being able to write native code to expose native hardware and OS features and APIs means that you can basically extend the AIR runtime from now on. So, instead of asking Adobe for support for notifications or the contact list API you can create or buy/reuse a native extension that does this.

I know many people are already working on a number of native extensions many of them taking care of some of the most popular developer requests. I hope we will have some kind of a market so people who want to build native extensions and those who want to consume them will be able to meet.

Finally, the Stage 3D API will come to mobile devices too. So this means it will be possible run even more incredible content on these devices.

What about Flex and Flash Builder

With the new version of the runtimes almost out it is only natural to ask this question: what about Flex and Flash Builder? Well, don’t worry because Flex 4.6 and Flash Builder 4.6 are coming this year too (and if you are a Flash Builder 4.5 customer you’ll get this version for free).

Flex 4.6 extends the mobile support introduced by Flex 4.5 by adding new components and better performance. Here are some of them:

SplitViewNavigator

CallOutButton

SpinnerList

DateSpinner

Toggle Switch

The other big news is the improved support for text input across devices. Flex will be using the native text input control on every platform. What does this mean for developers? It means you can customize the keyboard (having access to all supported keyboards; e.g. numeric keyboard or email keboard) and you have access to features like spell checking or cut/copy/paste.

In terms of performance, simply repackaging with Flash Builder and Flex 4.6 can boost your application performance up to 50%.

These releases will provide support for the latest operating systems like iOS 5 and the upcoming Android OS.

Also Flash Builder 4.6 will have support for monitoring network traffic and unit testing for mobile projects.

Download

You can download the release candidates from Adobe Labs.

If you do the math, you’ll see that it has been almost three months from the previous updates of the runtimes, Flex, and Flash Builder. This is not much time, and yet the teams were able to add lots of new features. So I think they deserve a big round of applause! Well done guys!

Adobe MAX 2011 is just around the corner. Every year I feel the same: how fast the last year has passed! I guess I have a better feeling of how the time is passing by counting the MAXs :D

Anyway let’s get back to the event itself. There are many reasons for wanting to attend Adobe MAX (learning new products and technologies, staying in touch with the latest and greatest, and networking just to name few) but if you plan to start mobile development or to learn new tricks then here is a list I put together.

Beginner

• Getting Started with ActionScript 3.0 (Lab on Monday, October 3, 2:45 p.m. – 4:15 p.m.). If you are new to Flash Platform mobile development then this lab will help you learn ActionScript 3.0 the language used for creating Flash applications including those running on mobile and tablets.
• Introduction to Flex (Lab on Monday, October 3, 2:45 p.m. – 4:15 p.m. and Tuesday, October 4, 8:00 a.m. – 9:30 a.m.). If you are new to the Flash Platform, then understanding how the open source Flex framework works will help you a lot.
• Flex Mobile Boot Camp (Lab on Monday, October 3, 2:45 p.m. – 6:45 p.m. and Tuesday, October 4, 12:30 p.m. – 4:30 p.m.). This boot camp will teach you the basics of Flex and Flash Builder mobile features.
• Developing High-Performance 2D Mobile Games with Adobe AIR (Lab on Monday, October 3, 12:45 p.m. – 2:15 p.m. and Tuesday, October 4, 3:00 p.m. – 4:30 p.m.). If gaming is your poison and you are new to our platform then this lab is for you.

Intermediate / Advanced

• Flash Professional CS5.5 for Mobile – Android and iOS (Lab on Monday, October 3, 2:45 p.m. – 4:15 p.m.).
• Building a Flex Application for Tablets (Lab on Monday, October 3, 2:45 p.m. – 4:15 p.m., Wednesday, October 5, 8:30 a.m. – 10:00 a.m., and Wednesday, October 5, 11:00 a.m. – 12:30 p.m.). In this hands-on session you will build a complete Flex app for tablets starting from scratch.
• Advanced Mobile Application Development (Lab on Monday, October 3, 5:00 p.m. – 6:30 p.m. and Wednesday, October 5, 1:30 p.m. – 3:00 p.m.). This lab is presented by the guys behind Conqu – one of the best task management apps for iOS, Android, and PlayBook built with AIR, Flex, and Flash Builder. So you will get a chance to learn from the best.
• Developing an iOS Application with Flex and Adobe AIR (Lab on Tuesday, October 4, 12:30 p.m. – 2:00 p.m., Wednesday, October 5, 1:30 p.m. – 3:00 p.m., and Wednesday, October 5, 4:00 p.m. – 5:30 p.m.).This 90-minute lab will cover how to create and simulate an iPad application in Flash Builder, and will walk you through the steps of creating and deploying IPAs onto your personal devices.”
• Deep dive into Molehill (Stage 3D) (Session on Monday, October 3, 5:00 p.m. – 6:00 p.m.). Although this feature is not yet available for mobile it will be soon. If you plan to do advanced 3D stuff then you shouldn’t miss this one.
• Flash gaming deep dive (Lab on Sunday, October 2, 9:00 a.m. – 5:00 p.m.). You will learn the ins and outs of creating games using popular game frameworks like Flixel and PushButton Engine. You’ll also discover how to use Molehill to create stunning 3D for games, and we’ll show you how to use advanced techniques such as blitting to help with performance.
• Programming a 3D First-Person Shooter Game in Flash (Session on Tuesday, October 4, 8:30 a.m. – 9:30 a.m.). Learn more about how to build the next generation of action games with the new Flash Stage 3D API. This session will cover the key steps required to create advanced first-person shooter gameplay, such as creating a scene and adding a person, movement, shooting, camera following, animations, and more, all in the context of 3D.
• Mobile Apps from 0 to 90: Powered by ColdFusion (Lab on Tuesday, October 4, 8:00 a.m. – 9:30 a.m.). This intermediate hands-on is all about building mobile apps that consume ColdFusion data.
• Unit Testing ActionScript and Flex (Lab on Monday, October 3, 12:45 p.m. – 2:15 p.m., Tuesday, October 4, 8:00 a.m. – 9:30 a.m., Tuesday, October 4, 12:30 p.m. – 2:00 p.m., and Wednesday, October 5, 4:00 p.m. – 5:30 p.m.). No matter how ninja you are (or you think you are) bugs are to be found everywhere. Join this lab to learn about unit testing for ActionScript and Flex.

I want to call out these sessions:

• Design to Release: Building a multiscreen mobile application (Session on Tuesday, October 4, 8:30 a.m. – 9:30 a.m.) presented by Renaun Erickson.
• Adobe AIR App Demo Showcase for Sony Tablet Devices (Session on Tuesday, October 4, 1:00 p.m. – 2:00 p.m.) presented by Ryan Stewart and Taichi Takayanagi. Watch live demos of innovative applications built by your peers that take advantage of the unique capabilities of the new Android Sony Tablet devices.
• Deploying Flash Professional Content Across Screens (Session on Wednesday, October 5, 1:30 p.m. – 2:30 p.m.) presented by Paul Trani. Discover specific workflow enhancements available in Adobe Flash Professional CS5.5. This session steps through the process of deploying Flash Professional content on mobile platforms, including Android, BlackBerry, and iOS.

My team has been working lately on a number of mobile applications so we have lots of experience earned first-hand. I encourage you to attend Renaun’s, Ryan’s, and Paul’s sessions.

See you there and don’t forget you’ll be able to watch the keynotes online if you don’t plan to attend the event in person. Let’s rock the house once again!

The Flash Platform as a compelling mobile solution across devices is enjoying an excellent momentum. I’m getting and seeing more and more Flash powered mobile apps. While this is interesting and cool this not what I want to focus on in this post.

Most people think about the Flash Platform for mobile as something that enables developers to build mobile apps for Android, iOS, and BlackBerry Tablet OS. What it is not so evident is it’s versatility: you can build almost whatever you want. And when I say this I mean it. You can build sophisticated games (and soon you will be able to build cool 3D games thanks to Stage3D), you can build beautiful apps for enterprise or consumer brands, you can build high performance apps for consumers, and the list can go on and on.

The last big thing that was a show stopper for some projects is about to be removed by the Native Extensions feature. This feature (it will be available in the soon-to-be-released next version of Adobe AIR) will enable developers to extend the runtime and achieve deeper integration with the device by accessing device/OS capabilities or other applications.

Let me give you just one example. Three applications that are quite different in what needs they solve while working and looking just great.

Cassandra Stand is a companion application for Android, iOS, and PlayBook devices. It picks  your location automatically and displays time/date, temperature, and news. While this app is a simple one it works and looks great. Congratulations to Leonardo Risuleo and the team.

Web Reader is probably one of the best PlayBook apps for those who use RSS readers. It is fast and intuitive and it works great with Google Reader. I’d love to see these guys writing an article about how they built their app. As with the previous two apps I installed the app on my tablet and played with it. My RSS list is pretty big and I was curious about how they will display all the categories and how easy would be to navigate between the various items. All I can say is that they did a good job :)

Hungry Cho-Cho is a funny little game for iOS. Tomer Reiss of KWAZI shown me this app during my visit to Israel earlier this year. It worked just great on my iPod Touch (at that time they were using AIR 2.5; I’m curious how it would feel with AIR 2.7 as this release brought more speed and performance especially for iOS devices). They released their application and he wrote a blog post about some of the things he learned while developing the game.

If you created some cool mobile apps using the Flash Platform, you know how you can get in touch with me. I’m out!

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.

Here are some screen shots of their game – called Chemistry Brothers:

During the presentation (and after while we enjoyed some beer and food) I learned more about this project and the company. And I think this project and the way they approached it is a good example of how you can get into mobile development if you are a web or desktop developer.

These were Stefan’s challenges before deciding to start the project:

• no expertise in mobile development
• no expertise in Flash and AIR mobile development
• no expertise in selling an application on Apple’s app store

Though these challenges were quite big he had something to rely on:

• tons of creativity
• great expertise in desktop and web development including Flash and Adobe AIR
• a plan

The plan he had was as important as the skills of his team. First of all, he decided to spend a week for building the game, from nothing to the polished “thing” you can find in app store. It was an all-or-nothing kind of bet. And to increase the chances of success he took his team out of the town to a remote town with nothing to distract them. They did a sort of software bootcamp.

Second, from the beginning he didn’t want to have anything less than great performances. To ensure this they used a first generation iPad for testing the code and they targeted 30 frames per second for their game. Anything less was not accepted.

Third, they struck a fine balance between the “features” of this game. They spent a lot of time on the graphics and game story but they didn’t spend much time on building lots of levels. It would have been impossible to do all those things with such restrictions (three people and one week).

And finally, they did a kind of agile development not for the code but for the product (game). Remember that I said they didn’t have any prior experience in building and selling mobile applications. So their plan was to build the game in one week and then ship it. If it had success then they would continue to develop as they already had the game story and lots of ideas. Guess what? They are happy with how the game is selling so far. Stefan told me that they will continue this project.

If you are one of the people who couldn’t find time for trying mobile development so far you are not alone. And more importantly, it is not so difficult to make your first move. Just think of an application that you’d like to build and make sure you allocate time for this. It could be a series of weekends during a month or three days of your vacation. It really doesn’t matter. What matters is to be focused and work on this fully committed. Chances are that you’d be surprised by yourself and what you can do.

In the end I just want to share some pictures from their office. Some say that having a creative environment stimulates creativity. After talking to Stefan and seeing his company’s work I’m not sure about this anymore. It looks like creative people change ordinary things into something to remember.

A wall built out of books

Playing around with Darth Vader's helmet

Another inspirational wall closely guarded by a she-clone

Rest room guardian!

Taking a break or having a meeting in a cozy space

If you have similar stories or just want to talk back, don’t hesitate to use the comments :). All I can say is: Bravo Stefan & Company!

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.

Here are two screen shots of the Facebook application running on Android and iOS that illustrates this idea:

Using the ActionBar component

Using the ActionBar component is quite easy. First, you’ll need to create a Flex mobile project that uses either ViewNavigatorApplication or TabbedViewNavigatorApplication. Then, you can define the components you want to add to the ActionBar either globally (for all the Views) or individually (for each View).

If you want to add them inside of a View here is how you do it:

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
      xmlns:s="library://ns.adobe.com/flex/spark">

 <s:navigationContent>
     <s:Button label="Back"/>
 </s:navigationContent>
 <s:titleContent>
     <s:TextInput prompt="type to search" width="100%"/>
 </s:titleContent>
 <s:actionContent>
     <s:Button label="+"/>
 </s:actionContent>

</s:View>

This code produces the following ActionBar:

If you want to set it globally then the method differe slightly depending on what Application root tag you chose when creating the project (ViewNavigatorApplication or TabbedViewNavigatorApplication). For ViewNavigatorApplication you’d do something like this:

<?xml version="1.0" encoding="utf-8"?>
<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
       xmlns:s="library://ns.adobe.com/flex/spark"
       firstView="views.ActionBarHomeView">

 <s:navigationContent>
      <s:Button label="Back"/>
 </s:navigationContent>
 <s:titleContent>
      <s:TextInput prompt="type to search" width="100%"/>
 </s:titleContent>
 <s:actionContent>
      <s:Button label="+"/>
 </s:actionContent>

</s:ViewNavigatorApplication>

And for TabbedViewNavigatorApplication you’d add one for each tab you have in your application. For example:

<?xml version="1.0" encoding="utf-8"?>
<s:TabbedViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
       xmlns:s="library://ns.adobe.com/flex/spark">

 <s:ViewNavigator label="Tab 1" width="100%" height="100%" firstView="views.Tab1View">
      <s:navigationContent>
           <s:Button label="Back"/>
      </s:navigationContent>
      <s:titleContent>
           <s:TextInput prompt="type to search" width="100%"/>
      </s:titleContent>
      <s:actionContent>
           <s:Button label="+"/>
      </s:actionContent>
 </s:ViewNavigator>
 <s:ViewNavigator label="Tab 2" width="100%" height="100%" firstView="views.Tab2View">

 </s:ViewNavigator>

</s:TabbedViewNavigatorApplication>

And here is how this code looks like at runtime:

If you set the ActionBar globally and you want to override a section or all sections in a particular View all you have to do is to set that section/sections in the View.

You should also know that you can control the ActionBar visibility and rendering mode. For example in any View in which you want to hide the ActionBar you can set actionBarVisible = false. By default the ActionBar is rendered so it takes up some of the available space for the rest of your application. If you want to have the bar hovering on top of the rest of your application you can set the overlayControls to true in your View.

Understanding how the ActionBar component works

Let’s see how everything is put together. Each part of the ActionBar (navigation, title, and action content) is actually a Spark Group object. If you open the ActionBar class file you’ll find three properties named: actionGroup, navigationGroup, and titleGroup. These Groups are populated by calling the setter methods: actionContent(), titleContent(), and navigationContent(). These methods are called by the View class to push the components you set for each section and the argument is an Array (you can set a Button or a number of UI components for each section).

How about the layout used by these three groups? Well you can set a different layout than the default by calling the actionLayout, navigationLayout, and titleLayout setters.

The ActionBar component is a Spark component and this means that the task for laying out the various UI components that you can add to each section is actually implemented by a skin class. And of course the look and feel is implemented by the same skin class. The default skin is spark.skins.mobile.ActionBarSkin. This class extends the MobileSkin class, which in turns extends the UIComponent.

The interesting parts in the skin class are these three methods: createChildren(), measure(), and layoutContents().

If you take a look at the createChildren() method you will see that here is where the three groups (navigationGroup, actionGroup, and titleGroup) used for each section are actually created and the default layout is set. Also you can see that the default layout used by each group is HorizontalLayout. Here is a snippet of the code that creates the navigationGroup:

navigationGroup = new Group();
var hLayout:HorizontalLayout = new HorizontalLayout();
hLayout.horizontalAlign = HorizontalAlign.LEFT;
hLayout.verticalAlign = VerticalAlign.MIDDLE;
hLayout.gap = 0;
hLayout.paddingLeft = hLayout.paddingTop = hLayout.paddingRight
        = hLayout.paddingBottom = 0;
navigationGroup.layout = hLayout;
navigationGroup.id = "navigationGroup";

The measure() method is executed executed after the createChildren() method or when the invalidateSize() method is executed. As the name implies, this method measures the width and the height of the ActionBar taking into consideration the padding (left, right, top, and bottom) and each group width and height (navigationGroup, titleGroup, and actionGroup). It is important to note that the height of the ActionBar is determined by the highest element you have, if this height is bigger than the default height. In other words if you add a Button and set the height of the button to 200, then the ActionBar height will be 200 pixels.

And finally the layoutContent() method is responsible for positioning and setting the size of each Group. This method positions each group starting from left to right with the navigationGroup, titleGroup, and actionGroup. If the total width of the navigationGroup and actionGroup is equal to or more than the total available width then the titleGroup is not displayed (visible = false).

Here is a graphical representation of how these different parts are related:

Skinning the ActionBar component

Let’s talk about styling the ActionBar component. Out of the box you can quite easily change the appearance using the CSS properties. For example you can use CSS to transform the default look and feel  of the ActionBar presented in a screen shot at the beginning of this article to something like this with a little bit of CSS:

And the CSS code that does this is this (please note that you have to include the CSS code or file in the main application file and not in the Views):

<fx:Style>
@namespace s "library://ns.adobe.com/flex/spark";

s|ActionBar {
      chromeColor: #484877;
      defaultButtonAppearance: beveled;
}
</fx:Style>

The second CSS property in the code above (defaultButtonAppearance) is responsible for rendering the buttons in iOS style. If you inspect the ActionBar class you will find all the important CSS properties that you can play with.

If you want to go beyond background and font colors, sizes, and so forth you have to go down the road of creating a custom skin. And the easiest way to do this is to extend the ActionBarSkin class.

Here are the important parts of the ActionBarSkin class from a skinning perspective:

• border and borderClass properties. Border represents the first child of the ActionBarSkin (take a look at the createChildren() method).BorderClass is a reference to an FXG file that is set in the class constructor depending on the applicationDPI value. The borderClass is used for creating the borders of the ActionBar and the shadow at the bottom. Here is a screen shot of what this looks like (I placed a pinkish background behind the graphics to provide some contrast for the highlights you can notice on the left/right side):

• drawBackground() method. This method is responsible for drawing the background. In the previous screen shots this is where the black or dark blue color is coming from. If you take a look at this method you will notice that it uses CSS properties (default or set by the programmer) to draw a gradient.

I think that in the most of cases, when you want to skin an ActionBar component you’ll likely modify the drawBackground() method and create a different borderClass FXG file.

Let me show you an example of a custom skinning. There are three steps involved in this.

First, I created a new FXG file to be used for the background. To do this I opened up the FXG file used by default by the ActionBarSkin in Adobe Illustrator (you can find the path for this FXG in the ActionBarSkin constructor). And I added three green rectangles (some with a solid color, others with a transparent gradient). Here is the result in Illustrator:

Then, I exported the FXG file as an FXG. And I opened this file in a text editor to remove some of the tags and attributes introduced by Illustrator. Finally, I add the FXG file to the Flex mobile project.

Second, I created a new ActionScript class that extends the ActionBarkSkin. In the constructor I make sure that the borderClass uses the FXG file I created in the previous step. And I overrode the drawBackground() method because the FXG file does everything I need. Here is the complete listing:

Third, I changed the CSS from the main application file in order to set the new skin class as the ActionBar skin class, and the chromeColor used for the buttons. Here is the code:

Finally, here is how the skinned ActionBar at runtime:

In conclusion, if you couple these techniques with skinning of the other components you plan to use inside the ActionBar then you can really get something that is quite unique.

You can download the Flex project source code used for this example from here.

Andrew Shorten (group product manager for Flex and developer tools at Adobe) just posted an interesting write-up about the future of Flex. If you are a Flex developer I’m sure you’ll find this worth reading. I know I did.

I won’t spoil the surprise but I have to say that I think this is good news!

If you have comments, please leave a message here! I will make sure it reaches Andrew’s inbox!

If you are a ColdFusion guy or maybe just curious to find what’s new in this space then you shouldn’t miss Adobe ColdFusion Developer Week. It is a free series of webinars presented by experts. It starts on September 12 and ends on September 16. Here is the schedule:

1. September 12- Getting Started with Web Application Developement Using ColdFusion ›
2. September 12 – Working with PDFs Made Easy with ColdFusion ›
3. September 12 – Introduction to ColdFusion Components (CFCs) ›
4. September 13 – Improve Your ColdFusion Code Through Unit Testing ›
5. September 13 – Using ColdFusion Frameworks for Application Development ›
6. September 14 – ColdFusion Builder: The Professional IDE to Boost Your Productivity ›
7. September 14 – Expand Functionality with ColdFusion Builder Extensions ›
8. September 15 – Developing Your First Application Using ColdFusion 9 and ORM ›
9. September 15 – ColdFusion and Mobile – Browser-Based Applications Made Easy ›
10. September 16 – Accessing ColdFusion Services From Flex Applications ›
11. September 16 – Make Your Site Searchable with Solr ›

You can register and read more here.

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;

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)

So how can you store data locally in an AIR mobile application (Android, PlayBook, and iOS)? You have almost the same methods as in AIR desktop applications (on the desktop you can use the encrypted local store to save ActionScript objects):

• Use the embedded SQLite database – obviously perfect for data that are a good match for a relational database
• Save ActionScript objects or collections of objects in files – serialize the objects into a file and read back when needed. Or you can use SharedObject to do the same
• Save binary assets directly into files – perfect for saving images or videos locally

I won’t go into details about these three techniques. Almost three years ago I wrote a blogpost that explains each technique (back then it was only AIR for desktops, but remember that apart from the encrypted local store you can use the same approach on mobile or desktop). So click here if you want to learn how to use these techniques.

There is one aspect I do want to highlight, however. When you want to save data locally using files you should always use the application storage folder. This folder is outside of the application installation folder. So you can update the application without worrying about the saved data. Here is a simple example for creating a new file inside the application storage folder:

var file:File = File.applicationStorageDirectory.resolvePath("new-file.png");
var fileStream:FileStream = new FileStream();
fileStrean.open(file, FileMode.WRITE);
fileStream.writeBytes(data, 0, data.length);
fileStream.close()

Flex mobile support for persistence

You probably already know about the persistence support of the Flex mobile framework. If you save your information to the data property of your View pages and set the persistNavigatorState attribute in the main application file to true, then all the information will be automatically saved when the application is closed and restored when the application is re-opened.

So here is a simple example. Suppose that you use this data model in your application:

package {

[Bindable]     
class User {
    public var firstName:String;
    public var lastName:String;   
}
}

Next, you turn on the persistence support in the main application file:

<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    firstView="views.HomeView"
    persistNavigatorState="true"/>

And finally you use the data property to save the current instance of User. Bellow is the first View of the application. It uses bidirectional binding for displaying the User first name and last name properties.

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   title="HomeView"
   viewActivate="onViewActivated()">
<fx:Script>
 <![CDATA[

   private function onViewActivated():void {
      // if it is the first time the application runs t
      // here is no data
      if (!data) {
         // create a new User instance and
         // save it to data property
         data = new User();
      }
   }

 ]]>
</fx:Script>
 <s:layout>
     <s:VerticalLayout/>
 </s:layout>
 <s:Spacer height="10"/>

 <s:Label text="First Name:"/>
 <s:TextInput width="100%" text="@{data.firstName}"/>
 <s:Label text="Last Name:"/>
 <s:TextInput width="100%" text="@{data.lastName}"/>
</s:View>

When you run the application for the first time you won’t see any information in the two text input boxes. However if you type in something and then close the app and re-open it, you will see the information you typed during the previous session.

When is the data property of a View saved to disk? Every time the application is closed or a View is destroyed/replaced by a new View. In terms of events right after the View deactivate event is triggered.

When is the data property of a View recreated if persistence is turned on? Right before the View activated event is thrown.

The data property of each View is saved to disk using flash.net.SharedObject and the object that does this is the ViewNavigator instance accessible in any View class by using the navigator property.

If you want to be sure that the data property is persisted you can call navigator.saveViewData() in your View. Why would you want to trigger the saving process manually? Because in the unlikely event the app is closed by the operating system due to low battery or memory events you cannot be sure that the normal event flow for closing the app will be followed. By calling navigator.saveViewData() manually each time the user updates something you can make sure that nothing will be lost.

RegisterClassAlias

When you serialize ActionScript objects to files or use SharedObject the original data type is lost when you deserialize them. The same applies when using the data property of the View because, under the hood, SharedObject is used for storing the data. If you want to keep the custom data type, all you have to do is to use registerClassAlias() method.

Why? Because the serialization is done using the AMF3 format (Action Message Format) and if you want to preserve the class information for the objects you serialize/deserialize then you have register the class alias of the class object. If you don’t do this, when you decode the objects you’ll get anonymous objects.

In a previous section I used a custom data type User. If I want to make sure that the data type is preserved I can register this class in the main application file (this way I make sure that the class is registered before any decoding is performed):

<?xml version="1.0" encoding="utf-8"?>
<s:ViewNavigatorApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
 xmlns:s="library://ns.adobe.com/flex/spark"
 firstView="views.HomeView" persistNavigatorState="true">

<fx:Script>
<![CDATA[
   import flash.net.registerClassAlias;

   registerClassAlias("User", User);
]]>
</fx:Script>

</s:ViewNavigatorApplication>

Conclusions

On Android you have to remember to set the appropriate permission in the application configuration file if you want to write files to disk (android.permission.WRITE_EXTERNAL_STORAGE). Also take into consideration how much space the data you want to saved will occupy. You should let the user know if you plan to consume GB of space.

I’m really curious to find out what your favorite iOS or Android apps are. If you don’t mind sharing your preferences with me and spending a couple of minutes on writing them down, please drop a comment. You’ll get my eternal gratitude!

PS. You can name as many as you want as long as you consider them killer (or favorite apps).

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.

How do you use the ContentCache class?

You can enable caching for your Spark Image or BitmapImage objects quite easy. All you have to do is to create an instance of ContentCache and set this instance to the contentLoader property of the BitmapImage or Image object. Other than this, it’s business as usual. When you want to load an image you just set the source property of the Image or BitmapImage object and the ContentCache object will take care of the rest.

There is one thing you must be aware of: if an image was changed after it was cached and the source is the same then you have to invalidate the cache yourself in order to see the new image. Otherwise you will see the old version. When you want to remove an image from the cache you use the removeCacheEntry() method and pass the source for the image you want to invalidate in the cache.

You control the number of cached images using maxCacheEntries property (the default value is 100).

Let’s see a simple example:

private var cache:ContentCache = new ContentCache();

private function setImage(source:String):void {
   //if we didn't set the cache
   if ( !img.contentLoader ) {
       img.contentLoader = cache;
   }
   //set the image source
   img.source = source;
}
...
<s:Image id="img"/>

Using ContentCache with Lists

The Flex framework has a built-in list item renderer that supports images: IconItemRenderer. This is perfect for displaying lists that have images and text. By default the IconItemRenderer uses a ContentCache object to cache the images. However the ContentCache instance is not shared across all the item renderers.

What do I mean? A Flex mobile list uses virtualization. This means that if the list displays 10 items at once it will create about 11 item renderer instances and reuse them. So even if the list has 1,000 items to display only 11 item renderers will be created. Next, each item renderer instance will use a ContentCache instance to cache the images. So in total there will be 11 ContentCache instances. This means that it could happen to have an image already displayed by the list but because it was cached by a different ContentCache instance than the one used by the current item it will be loaded again.

The IconItemRenderer class uses a static property to hold an instance of the ContentCache. This means that the same image cache will be used by your list. However, if you have a second list or you use multiple item renderers for the same list, by default, it will be used another instance of ContentCache. The easiest way to fix this is to first create a single ContentCache instance (you can use the Singleton pattern here):

Then you extend the IconItemRenderer and set this Singleton as the contentLoader object:

When you build from scratch a list item renderer that uses images, you can use the same approach.

Obviously this technique can be used for other places as well not only for lists.

Drawbacks

As with any caching or pooling technique there are trade-offs. You have to find a fine balance between not caching any images and caching all the images. By default the ContentLoader is set to cache 100 entries. But this doesn’t mean that it is the best value.  It all depends on how big the images are and how much memory you want to use for caching. So be sure you take this into consideration when caching images.

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:

Here is the code to implement this (as a new MXML component that extends SkinnablePopUpContainer):

<?xml version="1.0" encoding="utf-8"?>
<s:SkinnablePopUpContainer xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    backgroundColor="0x898989">

    <s:layout>
        <s:VerticalLayout horizontalAlign="center"/>
    </s:layout>

   <s:Label text="The contact was saved" width="100%" textAlign="center"/>
   <s:Button label="OK" width="100%" click="this.close()"/>
</s:SkinnablePopUpContainer>

The API for controlling the SkinnablePopUpContainer is pretty simple:

• To open or display the window you create a new instance and then call the open() method of SkinnablePopUpContainer. This method has two arguments. The first argument is the display object container where it will be created. The second argument is a flag that tells Flex if the window will be modal or not.
• To close the window and send data from the window to the application you use the close() method of SkinnablePopUpContainer. This methods also has two arguments. The first argument is a flag. You can set this to true if, for example, the user clicked the OK button, and false otherwise. If you want to send some data back to the application you use the second argument. For example, if you have a TextInput in your dialog and you want to send the text you will use this second argument.
• To listen for the close event and read the data sent from the SkinnablePopUpContainer you have to register an event listener on the SkinnablePopUpContainer. The event type is PopUpEvent. PopUpEvent has two properties that you can use to read the flag and data set when calling the close() method: commit and data.

Here is an example of how to open a SkinnablePopUpContainer component and read the flag/data when it is closed:

//create the component and open it
var alertWindow:SkinnablePopUpContainer = new SkinnablePopUpContainer();
alertWindow.addEventListener(PopUpEvent.CLOSE, onAlertClose, false, 0, true);
alertWindow.width = stage.width;
alertWindow.height = stage.height / 2;
alertWindow.x = 0;
alertWindow.y = 100;
alertWindow.open(this, true);

private function onAlertClose(event:PopUpEvent):void {
    trace(event.commit);
    trace(event.data);
    alertWindow = null;
}

Creating custom dialog windows

Once you understand how to use the SkinnablePopUpContainer it is pretty simple to create any kind of dialog window you might need: confirmation messages, simple alerts, pop up lists, and so on. Here is the code for a confirmation window that has two buttons (Yes and No) and lets you set the message text:

And here is how this component look on my Android phone:

And here is the code for a pop up list that lets you to set the title, the list’s data provider, the list’s label field, the list’s initial selected items, and multiple selections (you can retrieve the selected items by listening for PopupEvent.CLOSE and reading the data attribute).

And here is the component running on my phone:

Skinning

The two custom dialog windows I showed you in the previous section use the default look and feel. What about skinning a SkinnablePopUpContainer? There is a Flex class that provides the default skin for a SkinnablePopUpContainer: SkinnablePopUpContainerSkin. By creating a skin that extends this default skin you can change the background of the component quite easily. If you look at the SkinnablePopUpContainerSkin skin you’ll notice that it has a rect with the id equal to background. This is the starting point to change the default background. You can draw additional stuff on top of this background or replace it alltogether with an FXG or PNG file.

For the rest of the UI components used in a SkinnablePopUpContainer (buttons, text inputs, labels, and so on) you will create additional skins and/or use CSS. Here is a screenshot with the same confirmation window but this time using a custom skin:

Here is the skin class used to customize the confirmation window presented in the previous section:

And this is the FXG used by the skin class to draw the background:

Download

You can download a working Flex project that includes all the code used in this article from here.

We just released AIR 3 Beta 2 for desktop and Flash Player 11 Beta for desktop. You can download them from here and here.

Here is a list of the most important news in these releases.

AIR 3 Beta:

• You can download the AIR 3 SDK and start building mobile and desktop apps. You can also download the AIR 3 runtimes for Windows and Mac OS
• Stage Video Hardware Acceleration for mobile ( previously, this was available only for desktops). This will enable developers to leverage hardware acceleration for decoding and composing the video on the screen. This means reduced memory and CPU usage and smoother video playback.
• Captive Runtime Support (AIR for desktop and Android). You will be able to package your application with a captive runtime. This enables you either to use a specific version of the runtime instead of what the user might have or to push the app together with the runtime so the user doesn’t have to go through the installation process of the runtime. Needless to say that this was one popular request :)
• iOS Background Audio Playback Support. You can write multi-tasking apps that can play audio in background.
• Android Licensing Service Support. You have access to the Android Market Licensing Service so you can enforce licensing policies for paid apps that are published through Android Market.
• Android Front-facing Camera Support. This is another popular request. This was already available on iOS and PlayBook; now you can use it on Android too.
• Encrypted Local Storage for Mobile. Another feature that developers wanted badly. Now you can store encrypted data the same way you would do on AIR desktop apps. Great for storing passwords and other sensitive data.
• H.264/AVC Software Encoding for Cameras for Desktop. You can stream high-quality video from your computer’s camera with better compression and industry-standard support.

You can read more here.

Flash Player 11 desktop Beta:

• Stage3D APIs (AKA Molehill). 3D GPU accelerated graphics.
• Native 64-bit support. For 64-bit operating systems (Linux, Mac OS, and Windows).
• G.711 audio compression for telephony. Real-time voice and telephony capabilities and support for integration with existing phone systems using a G.711 codec.
• Socket Progress Events. This was another feature requested by many developers.
• JPEG-XR support. Support for JPEG-XR compression format so you can use higher quality images with less bandwidth. Plus you can use alpha channel transparency.

You can read more here.

If you are a developer fragmentation is part of your life. Everywhere you look you find it:

• device fragmentation (devices running on different OSes, with different screens and capabilities – smartphones, personal computer, tablets, televisions, and so on),
• browsers fragmentation (you have desktop browsers and mobile browsers, as well as embedded device browsers like those found in televisions or other devices).

Judging fragmentation in terms of good or bad is counter productive. It is what it is, right? In the end it gives us more work which is not that bad :)

There is fragmentation and fragmentation

However, there is another type of fragmentation that is becoming more and more visible. And this version is quite annoying. It is about having all these devices like islands in a big ocean. And all these islands are not aware of each other and they don’t even know they are islands.

What am I talking about? Let’s take a look at a typical household. You’ll find devices like:

• router
• personal computers
• smartphones
• tablets
• console or media center
• television with Internet connectivity (like GoogleTV for example or Samsung SmartTV)
• air conditioning units
• car(s)
• automation devices (video cameras, remote controls for the main door or garage door)

And the simple truth is that all these devices are not aware of each other. Or in other words, if I have a smartphone and I’m home enjoying some TV time on the latest television set I don’t get any extra functionality on either device.

All together now

So what could we do to improve this simple scenario (a smart TV and a smartphone/tablet)? Well think of the “ultimate” remote control”. In a perfect world, when I want to find something interesting to watch at TV, I’d pull out my tablet (or smartphone) and open up the remote control app. This app will connect to television or set-top box and retrieve all the programs that are available.

Then it will present them in a useful way. Today, we think in terms of channels. You have x channels and you zip through them. Instead of this, this Remote Control app would display the available programs sorted on categories: SF movies, nature, cooking, news, fashion, sports, and so on. So with a quick flip through movie sections I could find easily an interesting movie. Or if I love football or tennis I can find what’s available right now.

Next, suppose that I select a tennis match (the US Open is coming by the way). While I’m watching the match I could choose the social section of the Remote Control app and I can check to see if my buddies are online. I could ping them to watch the match together and chat using text messages, VOIP, or video calls directly from the tablet device.

While enjoying the match together with my friends, my wife is on the way home. She has a smartphone as well and because of that I can get a notification on my smartphone or tablet that she is quite close to home. So I can go to the kitchen and start preparing the dinner. She could have left for me instructions for me (using her smartphone or personal computer) and I could check them on my device or using the fridge integrated tablet (did I mention the fridge has an integrated tablet?).

While cooking some delicious dishes somebody rings the doorbell. My tablet pop ups a notification and with one tap I can see who’s outside and decide to open the door or to ask him what he wants.

My wife wants a new couch and I start browsing for options using my laptop. Once I found something that looks great I choose to display the web site on my TV so we can see what it looks like. While the images are displayed on the TV I use my laptop to navigate, rotate, or zoom the images.

The next morning, as we are getting ready to leave the house I could check the car status on my phone: fuel level, service notifications, outside temperature. As I arrive at the office I realize that I forgot to program the air conditioning unit. I just fix this using my mobile phone.

Present or the land of opportunities

Now back to reality. Most of what I have described here is already possible. Of course there is no off- the-shelf solution but a smart developer can create software that makes different devices work together. I’ve been thinking about this a lot lately and also I’ve been talking to others smarter than me (fellow evangelist Mark Doherty has lots of idea about this cross device experience).

And the reason we don’t have off-the-shelf solutions (or solutions that do exist are very expensive) is that we don’t have a standard that is implemented by all the manufacturers who build smart devices. Manufacturers will have to expose some of the core functionality of their devices to third parties as well if we want to build software like my “Remote Control” example. Today it is pretty hard to come in as a third party developer/company and try to build in some interoperability.

How is this post related to what I’m usually talking about on my blog? Well, you can do many things with the Flash Platform since you can use it to build stuff for so many devices (personal computers, embedded devices, mobile devices, Arduino and Phidgets). Maybe we can start building cool prototypes and go after the big consumer electronics manufacturers and show them what is possible to do. This is one way to turn around this issue.

I don’t have enough insight into the consumer industry so what I’m about to say could be horribly wrong. I have the impression that many of the big players (companies who build TVs, cars, broadcasters and content providers) are just missing this. There is no doubt in my mind that one way or another we will end up talking about this type of fragmentation using the past tense. Until then, I wish you an amazing weekend and don’t forget to post a comment if you have something to share!

PS 1. Almost two years ago I wrote a post on a somehow related matter (augmented reality + always connected/synced). Back then I was pretty sure that in about two years we would have something like that available.

PS 2. There are some companies who are working in this direction (use your mobile device with your television, making home automation more accessible) but these examples are far too few.

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.

Today, July 20th, join Adobe & Sony for a webinar on Sony Tablet devices and the Adobe AIR App Challenge. Fellow evangelists, Ryan Stewart and Mark Doherty, will present the two webinars:

• 11:00 AM – 12:00 PM US/Pacific Time – Mark Doherty
• 7:00 PM – 8:00 PM US/Pacific Time – Ryan Stewart

You can register here.