Danny-T.co.uk

Mike Downey’s Apollo preso @ DEMO

Mike Downey (Apollo Sr. Product Manager) gave an excellent short and precise demonstration of Apollo at DEMO. He demonstrates some of the functionality from the much discussed San Dimas project which is looking awesome and really shows off the power of Apollo.

Another cool showcase that has caught my attention is by the guys at Cynergy who are truely ahead of the game for Flex development, check out cynergysystems.tv. Not sure how into the Apollo thing these guys are but no doubt they’ll come up with some good stuff if they are.

[excuse for lack of recent posts: More thoughts on Apollo shortly, i'm totally snowed under at the moment moving house.]

Flex 2.0.1 new release

Ryan Stewart has an overview of some of the new features and fixes for the release of Flex 2.0.1, there are some interesting extras for the SDK and Flex Builder 2. There is also support for some Apollo functionality although we don’t know too much about this. My guess is Adobe are getting the libraries out there so everyone is tool’d up ready for the Apollo beta launch sometime soon. Ted has a countdown running on his blog with some other clues as to what’s included.

Who are the Apollo Developers?

Just re-reading a post I made a short while back on Apollo, where I mentioned a split between desktop application developers and web applications developers and thought I’d go into a little more depth here.

I am of the understanding that the target audience for Apollo is web developers, this is quite an obvious one really as one of the major benefits of Apollo is the re-use of existing web-based skill sets (flash, flex, html, ajax etc). This is also reflected in the positioning of Apollo from a marketing perspective (flash conferences and web dev conferences/user groups).

This will undoubtedly lead to an influx of “Rich Internet Desktop Application Developers” (can I be the first to publish the acronyms RIDA and RIDADs? ). However what perhaps isn’t so planned for that I can foresee is the number of traditional “desktop application developers” coming out of the desktop woodwork to show these web devs the ins and outs of desktop application development. We went through a massive learning curve when we educated ourselves on developing applications for web. So much so that perhaps a certain amount of this education will need to be undone now we are venturing back to the desktop.

This is of course assuming there is any form of distinction between a desktop app developer and an internet application developer? Personally I would say I started out as a web developer, became a desktop application developer and now sit somewhere in between desktop and web application developer (when I have a developer hat on of any sort). I would certainly not be surprised if a number of web developers have never developed traditional desktop applications nor intended to that are now considering the shift to application development with the advent of Apollo.

My queries that we will see answered throughout 2007 and beyond are:

Might Apollo also lead to more traditional desktop application developers delving into web technologies to get their hands dirty with Apollo?
Will there be a clash of web app developers vs desktop app developers arguing over how things should be done on the desktop?
Will there be a new breed of application that is exploited through the leveraging of desktop and web apps on a single platform?

Apollo platform ubiquity

One of the challenges Adobe face with Apollo will be how wide an audience they can reach in a short amount of time. The golden target would be of course, to reach similar levels of adoption as the Flash Player. However this is a mamouth task and will certainly not happen over night.

The other query that springs to mind is whether Apollo needs that kind of distribution? Are the benefits Apollo offers going to be capitalised by the open public market (E.g. YouTube apps, eBay apps, Amazon apps etc.) that become household names and can be found in every home, web cafe and office workers desktop. Or will the big benefits by drawn by closed audience Intranet and Extranet applications?

Apollo deployment figures will be an interesting one to watch and will be very much influenced by the creation of popular applications. Another consideration for RIA enthusiasts is whether to create a solely online application or create a version for web browser access, a beefed up version for local installation and even mobile specific implementations. The flexibility of the platform should allow for the catering of these different platforms without the need for complete re-development each time. Approaches like this should greatly benefit the adoption rate of Apollo by offering extra sugar for users that try the online versions of applications.

Non web apps with Apollo

After reading a comment recently about the number of windows application developers who will jump on the RIA bandwagon with the introduction of WPF, I got to wondering if the argument stands the other way round. The initial comment was along the lines of “Windows application devs don’t understand that web apps are different…” which, is a pretty weak argument really but that isn’t the point of this post.

My query is whether or not with the introduction of Apollo, will this promote the creation of many non-web applications built using web technologies? The web developer audience who are familiar with flash/flex and/or HTML & AJAX is vast to say the least. Will the opportunity to leverage these skills on the desktop see a rise in non-web specific applications being developed using web technolgoies.

It just so happens that an absolutely ideal case in point example arose on the blogosphere today: fauxto.com is a photoshop like graphics tool created entirely in Flex, currently this is an online tool, but I’m sure I’m not the only person who saw how well suited to Apollo this would be. Ryan Stewart has also made callings of a similar nature (this guy seems to be on my wavelength with every Apollo thought I have – which is hopefully a good thing considering his profile in the dev community).

During Mike Chambers’ presentation at FOTB his exact words (or very similar) were “Apollo isn’t for creating the next version of photoshop… I’m sure someone will, but that’s not where we’re aiming”. Well it appears someone has done that already and I wonder what other non-web related apps will come about despite that not being Adobe’s focus with Apollo.

I’ll save the argument on desktop app developers vs internet app developers for another post .

Presenting Apollo at LFPUG

Have just confirmed with Tink that in Feburary I’ll be doing a presntation on Apollo at the London Flash Platform User Group.

More info when I have prepared a little more.

Apollo : Local Resources

Ryan Stewart has a blog post containing an interview with Alan Lewis of with EffectiveUI who are the developers of an Apollo app in development for eBay known as the San Dimas project. I saw a demo of this app at FOTB and it looks very impressive.

One particular part grabbed my interest:

“Alan also mentioned that one of the big advantages of the desktop model is improved caching. For instance there is a web service call to go out and grab the entire tree structure of eBay’s categories. In XML format, this is about a 20 meg download. With Apollo, the team can call this once and cache it on the local machine so that the application never has to make the calls to get subcategories. This means fewer calls to the server and better performance.”

The use of caching and local storage is a key area of Apollo that is perhaps the most alien to web application developers. Short of browser cache and cookies we’ve had no form of local storage available. The above quote highlights the performance opportunities available through caching (something I’d not previously considered). Caching information about the site that never (or infrequently) changes could help greatly improve performance and reduce bandwidth.

Also the ability to make use of local file storage is what will really aid disconnected applications. In the instance of San Dimas you might be able to create and manage your eBay items for sale whilst not online then, once you have a web connection, commit them all to eBay. A couple of other examples I can think of off the top of my head:

• Football manager game – manage your team offline (on the bus, plane, train etc). then, once connected commit team for online matches and results downloading.
• Business Applications – managers and staff who are not office based can have access to their business information whilst travelling or making site visits, then download the latest data when web access available.
• Web content writing – Authors of content managed websites, news sites, blogs etc could have the facility to write content in a native application at any time, allowing them to submit their content when connected. Would save having to use word or other text editor to write and save the their content then copy, paste, reformat before posting.

Being able to continue to use a web application when offline should greatly reduce frustration for users. Have you ever spent ages filling in an online form of some sort or spending forever writing a page of content only to find that when you’ve submitted it you’ve lost your web connection and all your hard work gets lost?

Apollo : Breaking out of the Browser

I made a rather long post about Apollo in general, I intend to explore in a little more depth some of the opportunities that will arise as Apollo emerges onto the scene.

One of my first thoughts is on the implications of being able to create rich internet (desktop integrated) apps without any of the imposing restrictions of the browser. I think this is a neccessary step for RIAs and will go towards further defining the distinction between web applications and websites.

People have said for years now one of the downfalls of Flash is that you can’t use the browsers “Back” button. Well, it’s common knowledge that you can code around this issue and cater for Back buttoners, but should you have to?

As I eluded to, a web application is not a web site. The back button is merely a built in function of the [current] means to access a web application and it is here where the perception of web apps has been cloudy in the past. A web application is an application developed to perform a specific task that is enabled through web technologies. Until now we have been used to, and only used a web browser to access such an application as that is all we have had available. On reflection, the browser is perhaps not the right tool with which to access web applications, web apps were certainly not what browsers were originally designed for.

Apollo seems to be a platform that is lending itself to this purpose, if your application doesn’t need to offer Back, Forward, Refresh, Bookmark functionality… then don’t offer it.

Big Apollo Overview after FOTB

This post is written from some notes I took at Mike Chambers’ Presentation @ FOTB – Apollo. This is very much as at time of writing and it is very likely that some of this will quickly become out of date information. If anyone spots any glaring mistakes please post a comment and I will rectify it.

“Apollo” is the codename of a new technology from Adobe that has currently reached an internal release. Mike Chambers, Senior Product Manager for Developer Relations at Adobe gave an excellent overview of how Apollo is shaping out. Here is a summary of my notes from his presentation he gave at Flash On The Beach earlier this week.

Apollo is a desktop runtime that enables desktop RIAs built in Flash, Flex, HTML and/or AJAX and any combination there in. One of the key advantages of having a local machine runtime for what have been traditionally web applications, is the ability to make use of local resources such as file I/O (e.g accessing mp3s, saving local images, saving configurations or data for offline working etc.).

Apollo applications will be developed essentially to work locally as per traditional software, however with an inherent access to online technologies, services and APIs. This is essentially freeing online application developers from the restrictions of the browser. No worrying about inappropriate use of the back button, if you need a back button, you implement a back button.

One of the huge advantages and key elements of Apollo is that it is going to be truely cross platform. You can develop for Apollo, deploy to windows, mac, linux. This is huge deal, no cross browser issues OR cross platform issues. One platform = one implementation with no need for dirty hacks and no restrictions on your audience.

Apollo application development caters for two primary development platforms: Flash & HTML. I think it is worth stressing that Apollo is “NOT JUST ABOUT FLASH”. You will not have to develop Apollo apps in Flash or Flex. you will be able to create a fully featured Apollo application using just HTML and Javascript (think Googlemaps with local file access for saving of locations and map images).

When developing an Apollo application, HTML content can contain Flash AND Flash content can contain HTML. This was demonstrated at Mike’s presentation and is something I have been wanting to appear in Flash for a long time. Basically you can add a rendered HTML page to a displaylist in Flash just the same way as you can add any other image. Imagine loading in a HTML document into a movieclip in your Flash movie, being able to apply rotation, scaling, filters etc but still being able to use it as a fully featured HTML page. In the presentation Mike loaded the Adobe homepage, rotated it 45 degrees, scaled it down, applied a blur and then was still able to navigate the site.

The chosen HTML Engine for Apollo is WebKit, this was chosen for the following reasons:
- Open Project
- Proven Technology
- Minimum file size
- Proven ability to run on mobile devices

Another feature of Apollo is that both Flash and HTML can integrate PDF, this wasn’t demonstrated and is still in development. I queried Mike on how downloads would work and he said that plugins will be required as needed. So rather than packaging the huge Acrobat reader to the Apollo runtime installer you can prompt for this if and when needed.

APIS
Apollo provides access to several desktop apis
Offiline / Occasionally connected to determine the current connectivity state and whether to poll an online service for the latest information/update personal settings or to use localised resources until a connection is available.
Complete Network support – http, xml/soap Binary and xml sockets
File I/O – synchronous AND asynchronous (sync for small files e.g settings, async for larger files e.g. playlist or photo album)
Local storage / Settings
Desktop Integration
Drag & Drop files to/from Apollo
Application shortcuts
System event notifications

These apis leads to potential Apollo apps that can run in the background I.e no need for any sort of UI until if and when needed. Apollo allows custom chrome, this means you have complete control over how your application looks. Shape and Alpha of application on desktop. Mike demonstrated there are currently two modes for chrome, system chrome or transparent chrome. System chrome will present your app in the default chrome for your operating system (I.e. right hand maximise, close minimse buttons in windows or ‘traffic light’ buttons on left in mac)

Installing an Apollo Application
There are currently planned, three methods to install Apollo apps:
.air extension – is a .zip packaged application.xml and swf. These installers are for if the user has Apollo on their machine they can simply double click the .air file et voila.
Native installer – creates windows/mac installer, includes checking for Apollo, if not present will install Apollo then your app
Web Install – “Express install”, install direct from web with a check for the Apollo runtime

My View
As you may be able to tell from the write-up I think Apollo is going to be big. It certainly looks to solve a lot of peoples problems and wishes. I would say the biggest thing of the moment is going to be ideas for implementation. We’re all used to either developing web applications or developing software applications. To my mind we’ve never had a platform that so smoothly destroys the boundary between online and offline software development and this new way of thinking will take some getting used to. I’m sure we’ll start off with a nice steady flow of photo galleries, aggregators etc but give it time and there’ll be some application concepts far beyond current considerations.

Other Notes
The following are some notes I made from the presentation that I intend to do some further research on and will post in due course:

• Small runtime footprint – currently 5meg (includes HTML and Flash)
• Currently HTML only runs through Flash
• HTML is rendered via the Flash displayList
• HTML can be manipulated as per bitmaps in Flash – whilst maintaining HTML functionality
• HTML events can be captured in Javascript AND Flash
• Other plugin integration: Some will be supported – Flash, PDF not quicktime/windows media for 1.0

Scripting
Low level interaction between HTML/JS and Flash
Flash can manipulate HTML DOM
Javascript could manipulate Flash’s drawing API

1.0 will launch for Win and Mac, Linux will be later
Command line tools – adt and adl to assist build of Apollo apps
HTML Flex control

Demo – Google Maps App
Accesses all local contacts, allows click of contact to find where on map they are
Demo – Picture this
Photo from webcam, converts to png, saves to filesystem – could have compressed to jpg with jpg library.
Demo – ScreenPlay
Allows drawing over desktop
Demo – Assassin
Allows monitoring of items on amazon, get desktop alerts for changes in availability, price, comments etc.

Application
At minimum will have 2 files, 1 swf/html/js and 1 xml
Xml – application properties, name, author etc, root application file, specify mac and windows icon or png which will dynamically generate icons

Timeline: beta on labs early 2007
1.0 mid-late 2007

More info:
www.adobe.com/go/apollo
weblogs.macromedia.com/mesh
mxna smart category

not aimed at kiosk/cd rom apps

security – undetermined as yet, multiple sandboxes – unknown author = web sandbox (restrict file access etc), digitally signed – full desktop privileges.

Flash player and acrobat reader will be prompted for as required.
Update mechanism for releasing application updates.