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.

jQuery UI is a powerful extension to jQuery with themeable widgets as well as functionality to bring rich user interaction to the web. The library is widely used, and has a big developer community behind it. On the other hand, wicked tongues has started muttering that jQuery UI has gotten too extensive and therefore bloated, which has given room for other players on the field of rich websites.

jQuery Tools is a collection of the most popular user-interface components for today’s web. While jQuery Tools doesn’t have all the features of jQuery UI, their approach is making the library as lightweight as possible with a limited set of components and functionality customization. The built-in components are Tabs, Tooltip, Scrollable, Overlay and Form tools. jQuery Tools also provides its own Flashembed, History, Expose and Mousewheel through its toolbox. As they say on their home page: «Let’s face it: do you really need drag-and-drop, resizable windows or sortable lists in your web applications?»

The release of jQuery Tools spurred a bit of a controversy, as some feel that it’s wrong to go solo instead of contribute their ideas to the jQuery UI project.

While I disagree with the statement that we don’t need drag-and-drop or sortable lists on the web (we have used it with success ourself), competition is always welcome. This drives the competitors to make even better products and it makes it possible for us, the developers, to evaluate the options and choose the alternative that suits the task best. We’re in the process of using jQuery Tools in one of our own projects, and will hopefully return with a better evaluation later.

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

• 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.

Since the release of the iPhone Adobe have tried to get Apple to release a Flash player version for the iPhone, but without any luck. The situation has not changed when it comes to the iPad. The big difference here is that one of the major things to use iPad to is surfing the web. We have been used to limitations when surfing the web on mobile devices. But I must admit that I don’t expect any of these limitations when it comes to a “mini-computer” like the iPad.

Connecting to millions of sites out there, some major like Disney, ESPN, Farmville, YouTube, through the iPad will not give a very good experience. All the sites that use Flash to enhance the user experience, all the games and videos and much more will be stopped by the iPad. Fallback solutions will be presented and damages the ultimate user experience for many sites. For me this is a big deal and a reason alone to not buy the iPad. Not because I’m a Flash developer. I’m still in love with my iPhone and I love gadgets, but there is a limit for what limitations I am willing to accept. The Flash limitations are demonstrated on the theFlashBlog

Just a couple of days after the iPad news were released MSI showed a prototype of a similar tablet-pc that is based on the Android platform. The fuzz wasn’t as big as around the iPad, but I still think this is exciting news. One thing is sure and that is that Apple needs competition. Android is challenging the iPhone on mobile devices and maybe we will see the same war on the tablet-pc area.

Anyway, whatever the iPad will turn out to be, I would like to thank Apple for what they do when it comes to developing user-friendly innovating technology. Somebody needs to show the way and as long as the crowd follows we will continue to have progress. I do look forward to sit with an iPad in my hands and try it out. I’m a bit skeptic but it’s always possible to convince me.

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

Silverlight 4 will enhance the building media applications and make the building of business applications a lot easier with the SharePoint integration posibilities and enhanced data binding capabilities. Printing is being flaunted as one of the major new features, often mentioned in the punch-line. I honestly have never noticed printing being absent, however it’s really on time to have this functionality in a version 4 . A bit cooler is perhaps that Silverlight 4 can take advantage of your webcam and microphone, and a brand new (or more correct: reinvented) Rich Text Area Control whitch promises the use of true Rich Text Format with bididrectional support for Arabic and Hebrew, functional hyperlinks and embedded images and improved styling. I think we are looking an a massive component here!

Both input from the keyboard and mouse has been improved, now allowing Asian key-sets and mouse wheel and right button (finally!). PNGs is now supported, as is MP4 .h264 video and AAC-LC audio with DRM. Silverlight 4 can also be used for multicasts streaming.

Finally a full support of Google Chrome, with promised 200% better start-up performance, is promised. It seems most of the problems addressed with Opera and Firefox already is fixed in version 3. There is no road-map for further fixing other browsers than Chrome. However, the Silverlight team is promising that all problems with browsers af any kind will be taken seriously.

New “Out-of-browser-experiences” includes resizing and repositioning the window. The concept of “Trusted Application” will allow Silverlight applications to install on a local computer, much like Adobe AIR. This will need the user concent on install, but will allow for access of file-system and cross-domain networking.

When it comes to tools Silverlight 4 promises 100% support in Visual studio 2010, WCF services (a kind of webservices), integration kits for improved data binding, especialy interesting for MakingWaves is the SharePoint integration. MEF architecture is introduced which support a more modularized development and intrestingly allows dynamically adding functionality after deployment, even when application is running!

This is a first look on this new version, which still is in Beta. However, there will probably be more features and tools to look forward to when the release date is coming up.

This causes problems when using DHTML menus and the like. The solution for this is to set the wmode parameter to “opague” which makes the Flash Player render its content directly onto the browser’s window.

Setting the wmode to anything other than “window” (opague or transparent) solves the DHTML menu issue and other issues, but at the same time it creates a bunch of other problems to be aware of!

First of all it makes the Flash totally invisible for any screen readers, making the Flash pretty inaccessible.

Another issue is that it makes a mess concerning textfields and keyboard mappings in different browser like Firefox. For example I experienced that a small form I had created in a Flash banner was suddenly not able to create the ‘@’ character. Using AltGr+2 did not produce anything other than a ‘2’. Shift+2 on the other hand created the ‘@’ but I guess we can’t expect the users to figure that out. Luckily I got in contact with someone who had experienced this before and guided me to the right path of making sure that wmode should be set to “window”. After informing the responsible host for the Flashfile about the issue everything worked out fine and the users where again able to use the keyboard mappings as they were used to.

I’m sure there is more people out there than me that have experienced trouble when changing the wmode parameter. Would be good to have all the issues gathered together on one location to avoid going into another wmode trap in the future!