A bit harder part was handling events. Air for Mobile supports touch and multi-touch events but generally you have to choose whether to use multi-touch, gesture or none. If you use gesture mode you can use defined gestures and all other simple events are interpeted like mouse events.  Choosing touch mode will enable you to have more control over events e.g synthetise you own gestures. When you decide not to use touch events, all will be interpreted as mouse events, and is advised to use when app is intended to run on touch and non-touch devices. My choice was to use touch and I was able to enable horizontal swipes between app screen as well as scrolling and taping for selected items. Of course mouse over events do not work on mobile devices.
After spending couple of days I was converted from Android ignorant to Android developer, and here are big thanks to Adobe. Being able to use the same, well known and adapted technology is a great thing which brings down entry-barrier into Android development world. Every Air/Flex developer will be able to create mobile versions of application using technology that is well known to him, using the same controls, effects and back-end communication. Only thing that changes is visual – but it is something you cannot avoid, and events, but it is nothing much different from ordinary mouse events.

Release date is said to be second half of 2010 so I expect to have final version of Air this autumn, but already there are plenty of apps in web. The only problem for me was unable to test it on real device – I don’t have Nexus One.

Now it’s piling up for Flash again: Steve Jobs is crusading against Flash accompanied by the entire HTML5 consortium. Atop of this all major video-service providers, mobile phone makers, and a whole lot of others are now leaving Flash behind in the dust.

Once so close to web domination with virtually cross OS and cross browser support, Flash has bailed me out of many a worry of making things work in all browsers (remember IE6 anyone). Flash’s biggest blow may have been when they couldn’t make their player a web standard and include it in the DOM (as a seemless part of every browser).

Here we are stepping right in the core of the problems; Flash is run in a plugin… A “browser” inside a browser, so to speak. A semi-propritary technology is not wise to include in any standards. So that leaves us all to download a plugin in order to run the Flash content. We don’t really like this, but most of us are willing to forgive this if the content is worth it, and it suprisingly often is (IMHO).

Part of Flash’s problem is how easy things are to create. Everybody can make something in Flash, there are grandmothers making things in Flash! However when it comes down to dynamic applications using webservices, remoting and object orientated code libraries many fall off the wagon and start improvising. Uh-oh. This is where you shouldn’t improvise at all, and all over the web your bombarded with error-messages and applications stopping working.

Would you let your local baker do brainsurgery on yourself, or leave your car at the hot-dog-cart for a full haul-over. Not likely. But it’s OK for your web-shop to be designed by a developer and developed by a designer? Lets face it, it’s the perfect combination: A developer needs only two hours to “design” any solution, and the designer needs only a day “to make it work”. So good times then, or shouldn’t someone start raising the red flag here?
This scenario is unfortunately a not uncommon in the world of Flash as “everybody” can do “everything”. However, there’s more and more Flash-projects being done more correctly now adays as Adobe has created a more intuitive work-flow.

Flash is pinpointed for the web. The web have never had any unified organisation going through all webpages and flashs approving them for the web, like Apple does for their platforms. This means that a lot of crap-application and banners etc are loaded on overy page out there. No wonder people are eager to kill Flash.

Of course there’s also a lot of technical issues with flash making people dislike it. Like it doesn’t support touch-screens, it lacks abilities for SEO and WAI (Search engines and accessibility), it’s CPU-heavy, device-problems and a lot of other things.
All of these technicalities I believe Adobe must pay attention to in order to keep the Flash platform alive. It really shouldn’t be that difficult. Adobe should do one more thing, maybe more important than the technical issues, they need to rethink the philosophy behind Flash and where to go with it. Maybe not so easy to foresee the iPhone, but now that iPhone has been around for a long time, Adobe has not really adopted to it, but rather started a defensive verbal argument.

So will Flash die a slow painful death now? Of course it’s a time for everything. One day Flash will be history, as will the iPhone and most of the things we see and use, but it’s not the time for Flash quite yet.

Why not let Flash do what Flash does best, be the icing on the cake or the heavy-lifter of data-structures. It’s still perfect for animations, components, games and applications (hey, wasn’t that what it was supposed to do?). When HTML and other thechnologies don’t work or takes too long time to make, Flash is still a good alternative, but we developers need to look out for backups on devices that doesn’t run Flash, or don’t support mouse-devices.

Now that CS5 is out with no support for iPhone and really no whole-hearted solution to support the flow of devices thrown at us we need to await Adobes next move…I hope it’s an offensive one

“Moving forward, RIA developers and rich web content producers won’t need to amend existing and future content to make it searchable—they can now be confident that it can be found by users around the globe.”

Two years later we have experienced that some of our Flash solutions does not get many results when googling them. Now why is this? Has Adobe/Google/Yahoo! failed or is it just that we have missed out on the details on how to really make the Flash more search optimized? Adobe stated in 2008 that all existing SWF solutions, across all versions of the SWF file format should be supported. That is without taking any grips to improve existing solutions for SEO. Can this be true? There are a lot of rumors and myths about Flash and CEO around on the web. I’ll try in this article to figure out what the real facts are…

What does it really take to make your Flash site optimized for search engines?

[Fact] The technology that Adobe is cooperating with Google and Yahoo! to achieve is to allow the search engine spider to crawl through a SWF file, navigating as is it was a normal user. The spider would then collect all text and links that occur at any state of the application, which then can be used in search results to the end user.

[Fact] External resources loaded into Flash are also indexed by the search engines. This was not the fact from the beginning but Google announced this in June 2009. This means that if the Flash file loads a XML-file containing the Flash solution’s text, this text will be associated to the Flash file.

[Fact] The search engine crawlers do support JavaScript techniques for embedding Flash (SWFObject & SWFObject2). This was not the case before the summer of 2009.

[Fact] There are ways to improve (and help) the search engine spiders to index your Flash content. Deep-linking is one way. Using one of the many solutions for deep-linking SWF content may improve how links can drive relevance to specific parts of an application and reflect a specific state of the SWF content. I have successfully used SWFAddress for this purpose in more than one occasion.

For complex sites you can also use techniques such as a site map XML file to highlight specific URLs to the search spider. Create multiple HTML files that provide different variables to the SWF and start the application from the correct subsection. This way you can get the benefits of a site that is indexed as a suite of pages. Read more about sitemaps for Flash here.

[Fact] Avoid using too much Flash. If you can, avoid creating the entire site in pure Flash. Though it is possible to make it optimized for search engines, it is usually discouraged. One reason for this is that you can’t weigh the different elements in Flash to tell the search engine how important they are. This is possible in HTML by placing information in header tags and so on. Though you are able to use CSS and HTML coding in your Flash text fields, it probably won’t weigh the same way as in HTML.

To make the best out of it build HTML into the Flash text fields (using .htmlText of the TextField class) and make sure you build the HTML-code to enhance the importance of the text elements as if you build the site in HTML. Use links, headings and other HTML tags.

HTML fallback

It is always good to provide users with a HTML fallback. This helps in many ways. Users without the proper Flash Player installed or maybe running without JavaScript will fail to see your conent when opening your site. A pure HTML fallback solution with provide them with the information they need but without the user experience that the Flash solution is there for. Another big advantage is that the HTML fallback will provide info for the search engine crawlers and index the content on your site.

Does it work?

How good do the search engine crawlers really index Flash content? To be honest I’m not sure and I am not completely convinced that they do their job good enough. But there is really not much more to do with it. Let’s hope Adobe and Google/Yahoo! take this seriously enough to continuously improve their crawlers to index the SWF content out there.

Sources:

http://www.hochmanconsultants.com/articles/seo-friendly-flash.shtml
http://www.adobe.com/devnet/seo/
http://www.adobe.com/devnet/flash/articles/ora_seo_flash.html
http://www.adobe.com/devnet/flashplayer/articles/swf_searchability.html

Most web developers agree that the ability to play video on webpages is a must, however the jury is out on how these videos should be played. I’m of course referring to the HTML 5 video format controversy. Throw FlashPlayer into the mix and you’ll end up with a humongous fight leading fast to nowhere. Based on this, focusing on finding a solution, I tried to piece together a player using both HTML 5 video, and FlashPlayer for less capable browsers like Internet Explorer. You can find a demo alpha version of the player here: http://makingria.com/demo/html5/videoplayer/

Browser support

The player supports the following browsers:

• Internet Explorer 7 (FlashPlayer, H:264 video)
• Firefox 3.6 (Native playback, OGG Theora video)
• Google Chrome and Apple Safari (Native Playback, H.264 video)
• iPad and iPhone (Native Playback)
• Opera 10.5 (Native playback, OGG Theora video)

How to build it

My approach to building the player was based on my not so patented “falling down the stairs” method. In plain English this means that playback methods are ranked in a list, falling down the list as support for the wanted playback method is not found.  To accomplish this we utilize the HTML5 video tags ability to hold a list of different source videos. If no support for html5 video is found the video tag will be replaced by swfObject using the Modernizer JS framework.

The list looks as follows:

1. HTML5 video using the H.264 codec – high-res (WebKit browsers and iPad)
2. HTML5 video using the H.264 codec – med-res (iPhone)
3. HTML5 video using the OGG Theora codec (Firefox/Opera)
4. FlashPlayer video using the H.264 codec (Internet Explorer)
5. Error message (Others)

I wanted the player to support play/pause controls, zoom control and outputting the current time and the duration of the video no matter what video playback method being used. I accomplished this by using JavaScript to control all of these aspects of the video, even when using FlashPlayer as the video playback method. If you want to see how this was done in practice, go take a peek at the JavaScript. The code for the FlashPlayer based player can be found here.

Performance

CPU usage is a challenge when playing high resolution video. On my computer, a ThinkPad Intel Core 2 Duo 2.66 GHz with 4 GB RAM (Windows 7 64 Bit) I found that the combination of HTML 5 video playback in WebKit based browsers using the H.264 codec gave the best results when playing a 720p HD video. Also notice the smooth scaling when testing the video in WebKit based browsers.

When using the Gecko renderer in Firefox 3.6, the CPU usage almost doubled compared to the H.264 playback in the WebKit browsers. And it needs to be noted that this was a huge improvement from Firefox 3.5 where native video playback was pretty close to unusable due to a 60-80% CPU usage. This spike in CPU usage is probably caused by the OGG Theora decoder in Firefox and Opera.

In Internet Explorer you’ll end up watching a FlashPlayer rendered video as Microsoft has yet to release a browser supporting the HTML 5 video tag. What’s interesting is the fact that the FlashPlayer renders video content far more efficient (CPU vise) that the native video rendering in Firefox and Opera. WebKit’s native video implementation is slightly more efficient that the one of FlashPlayer, but not by much. It should also be noted that this test was done in FlashPlayer 10.0. Not the mythical speedmonster (rumored) which is FlashPlayer 10.1.

• new set of skinnable Spark components and skinning architecture which leads to better separation between data and view
• introducing FXG declarative syntax for defining graphics
• two way data binding

But if you want to explore full list of changes and improvements to framework, there is a “Flex 4 features and migration guide”, which could give you more information about it.

New set of Spark component architecture defines entirely new way of building application view. Now view and data are separated, and each of functional component can be skinned to look completly different than “default” one. For example you can skin radiobutton to look like button, but still have radiobutton functionality – single select or grouping. This feature is extremely useful, and makes life of developer much easier.

Spark components also adds some new features e.g better handling of text by RichText and RichEditableText controls which enables developer to handle text more efficiently and easily. My personal foe – Repeater could be replaced by Spark DataGroup component which behaves far more intuitive  and of course is suited to new skining architecture

Flex 4 introduces also FXG declarative syntax, it is similar to Degrafa, and in simple words enable programmer to create vector graphics by writing piece of MXML code. This alone is not a big deal, but please remember that there is a data binding mechanism – and having those two together implementing a custom bar progress indicator or some fancy buttons is much, much easier.

Finally we have databinding that works both ways, so when connected to e.g. RichEditableText you will got property synchronized with it’s text. The only thing to remember is to have property that need to be bound declared as public.

Flex 4 is a big step ahead, it resolves a lot of problems that was a pain in Flex 3. I will encourage everyone to use it since it is far better than Flex 3, in my opinion, and could save some development  time especially in skinning of application. Together with Catalyst and Flash Builder it will create a powerful platform for building RIA applications.

Flash Builder (which is a succesor to Flex Builder) is currently avialable in beta 2 version for some time now. Since Adobe is still postponing release date of final versions I decide not to wait any longer and try to grasp it’s new features in some application more complicated than samples provided in tutorials that could be found around the webAfter dowloading and installing application we get 60 days of evaluation period, but it can be prolonged using valid Flex 3 license number.

Flash Builder looks much the same as it’s older brother, but even on the first glance there are small changes that could make developer’s life easier – “Flex Naviagtor” which showed file structure of project in Flex Builder is now changed to “Package Explorer” which basically serves the same purpose but it doesn’t stop on the file level – you could expand each as or mxml file to see its attributes. properties and methods. Of course click on method take you dirrectly to it’s implementation – in fact from file level it looks and acts exactly the same as “Outline” view (which is still there).

When looking into code one could notice slighltly different ways of colouring code. Also Code assits works much better and more up to date with current standards when it comes to development environments. For example you could filter to only show events of certain component without need to scroll through numerous entities on hint list. The feature I found very useful durring some day-to-day work is connecting Code assits with Adobe livedocs with could save a lot of time when looking for explanation of some rarely used feature. Finally the code generation got feature of generating getters and setters with makes any excuses for not creating them futile. One of the most irritating feature of FlexBuilder 3 is also gone: when importing project into environment there is only one path to set. It was such a annoyance to have to copy path to second input each time because otherwise my project got copied to some “workdir” under “My documents”.

My general immpression is very good, Flash Builder is stable (at least with comparison to Flex Builder), there are some very nice features that was absent in Flex Builder 3 , and for those who don’t want to use Flex 4 SDK  (which is still beta) you can use  3.4 SDK as well. If you are got used to Flex Builder switching into new environment will be no problem because after all the core is still Eclipse.

Get the plugin from SourceForge or read Grant Skinner’s installation guide to install it from within Flex Builder.

The desktop version is created in Flex with an AIR application as outcome, while the mobile version was based on Flash Lite 2.0 and developed using Flash. Both applications are based on the same design and both applications use Shared Objects to save the users favorite public transport lines. Part from that there are two very different solutions. Both solutions were developed within a timeframe of 70 hours!

Read more at http://mjl.makingwaves.no/

The main challenge when developing Flash content for mobile is to develop on a version that most available phones support. We decided to develop for Flash Lite 2.0 even though we lose a lot of today’s phones. But even phones with Flash Lite support have different specifications and it’s a jungle to find out which phone that supports which commands and so forth… but it is possible J

But the biggest issue with this application was loading XML. Flash Lite 2.x solutions are not very friendly to xml loading. It fills up the phones memory in no time. So the biggest lesson learned is to find workarounds if the first thinkable solution is to load xml data into the mobile phone. Part from that, developing applications for mobile phones is no walk in the park, but it’s really cool and not to hard either

With that in mind I have created a little showcase of a small AIR application. The application collects weather info from yr.no and is limited to showing the weather in Norway (for now). You are able to search for locations in Norway and get the weather forecast for that location. Using SharedObjects you can also save your favorite locations and set your startup location. The forecast is updated every hour so you always can keep up to date to how the weather will be on your location

Try it out by installing from http://www.svenway.com/applications/weather/

The application is created in Flex based on a simple Cairngorm architecture.

Features include support for all known and unknown media formats (videos, images and audio), a brand new 3D engine with physics subsets, Lingo is “gone” and replaced with JavaScript as main scripting language, text-renderer, a brand new interface and of course a vast selection of new Xtras (plugins).

Director 11 is not a competitor to Flash due to the lower penetration of the ShockWave plugin (4,5 MB). However, it sails ut as a competitor to AIR, and a serious one as many of the new Xtras are certified with Vista and OSX. Many of the new Xtras have capabilities far beyond the AIR environment.

Adobe is pinpointing the game-industry as well as the traditional video and e-learning markets with this new release. Personally I see it as an actor on the application-market for specialized task-applications as well.

Check it out here.