Adobe show how not to do auto-updaters

I haven’t done any Flash development for a while. As a result, I no longer need a debug version of the Flash player installed on my PC. So I installed the non-debug version and enabled the auto-update feature. Then recently, a new version of the Flash player was released and this updater kicked into action. The result is, not to beat about the bush, a complete farce. The following is a set of screen shots of this “automatic” process in action. Enjoy… Continue reading “Adobe show how not to do auto-updaters”

Is it “game over” for Flash?

gameoverIn recent months, Adobe have abandoned Flex and abandoned supporting Flash themselves on Linux and browsers for mobile operating systems. They instead are introducing new premium (ie costs-you-money) features and are marketing Flash as a game development solution. They will be supporting games on (non-Linux) desktops using AIR and browser plugins, and on mobile, using AIR and native compilation. Continue reading “Is it “game over” for Flash?”

“Flash is dead” or how to create a PR disaster

Just under two years ago, I wrote an article questioning the wisdom of demands for Flash on mobile devices. At the time, everyone seemed to want Flash everywhere and were demanding it for the iPhone. Also at the time, HTML5 was languishing in unpopular backwaters of the internet. When the news broke today that Adobe were scrapping future development of Flash on mobile devices, I immediately thought of that article and felt happy that Adobe had finally seen sense on the subject. That happiness has ebbed during the day though, to be replaced by a degree of concern. Continue reading ““Flash is dead” or how to create a PR disaster”

HTML5 must not become the future of the web

HTML 5 LogoIn the beginning there there was simple HTML, which sought to define documents in an abstract way, leaving the browser free to render it as it saw fit. Whilst a great idea in theory, it didn’t work in practice as designers of web sites wanted their sites to look the same on every browser, rather than be at the mercy of the browser’s rendering engine.

Fast forward twenty years and things are very different. These days the humble HTML page has been pummelled into submission and supplies the designer with pixel-perfect rendering via CSS, JavaScript and a range of ACID-tests that encourage all browsers to behave the same. Yet beneath all this, the HTML at the heart of the page remains largely unchanged. Even the near-mythical HTML5 – which will likely take twelve years to become fully adopted – seeks to add just a few tags to the HTML specification. Continue reading “HTML5 must not become the future of the web”

“Doc?” – a great Flash/ Flex developer tool (and its free)

Doc? logoDoc? is  AIR-based API reading tool. It can be used to build up an indexed set of ASDoc-generated API documents that are held locally on your computer, rather than having to be accessed online. To create a library, one points it at the index.html of all the online (or offline) API sources you use and then you leave it to trawl the sites, generating a local copy of each for you.

As a free application, this ability to create a library of offline API documents would be enough to make me recommend Doc? to every Flex/ Flash developer. However, it has another feature up its sleeve that just makes it an awesome product: it has plugins for Flex/Flash Builder and Flash CS3/CS4. These plugins allow you to rapidly access the API documentation for a class you are trying to use. Continue reading ““Doc?” — a great Flash/ Flex developer tool (and its free)”

Your choice: whine about Flash crashing, or help make it better

In recent months, there has been a lot of criticism of the reliability of the Flash runtime. One of the keys to reliable software is testing. To that end, Adobe is asking folk to help it make the upcoming flash runtimes (Flash Player 10.1 and AIR 2.0) as reliable as possible. So if you are a Flash developer or designer, or are simply someone that enjoys flash-based games, BBC iPlayer, TweetDeck etc, why not help combat those criticisms by trying out the beta versions of Flash and AIR?

Download the Flash Player 10.1 beta 2 here and AIR 2.0 beta 2 here.

Install them and try your favourite content out with the betas.

If you find a bug, be sure to let Adobe know.

Finally, why not help spread the word by passing on details of this beta test drive via your own blog or twitter?

UPDATE
I want to add some more here in response to the comments so far. I thought long and hard over whether to get involved in this beta bug request as only this morning I was looking at a bug – ClassReference in nested CSS file compiled to SWF causes error – that was closed as “deferred” two years ago. Stefan Richter had highlighted it as an example of how Adobe mess up with bugs at times. The problem remains unfixed and Adobe’s communications were crap with this bug as they didn’t explain why they chose to ignore it. However, in the end I decided it would be wrong to focus on such negatives at the expense of the great stride Adobe have made toward openness.

They have a open bug reporting system. A lot of the flash development environment is open (the whole of Flex Framework for example.) Part of opening up to the community involves inviting the community to give back to the project, both in terms of bug reports and bug fixes. Adobe have frequently highlighted the fact that people are welcome and encouraged to not only report bugs, but to help fix them too. So to those that complain bugs remain languishing unfixed for long periods of time, I have a simple question for you: have you tried contributing to the openness of Flash by helping fix that bug?

ClassReference in nested CSS file compiled to SWF causes error

Long may the iPhone remain Flash-free

“When is Flash coming to the iPhone?” seems to be a commonly asked question of Adobe. It’s clear from the likes of Lee Brimelow that it is a question that causes great consternation within that company. They want Flash on the iPhone, of that there is little doubt. Flash is available on Windows, OS X and Linux and – assuming all goes well with the Open Screen Project – it will be available within the browsers of all smart phones bar the iPhone later this year. As a Flex developer and an iPhone user, I guess this should worry me. To be honest though, it really doesn’t. In fact, it fills me with hope for the future. Continue reading “Long may the iPhone remain Flash-free”

Why flex/flash developers should be excited about Flash Builder 4

flashbuilderFlash Builder has a great selection of new features, such as new workflow integration with Flash Catalyst and Professional, improved debugger, refractoring and profiling tools and great data services integration. Beyond these headline features though, there are some nice little enhancements to the developer experience that seem to have been overlooked by most. Continue reading “Why flex/flash developers should be excited about Flash Builder 4”

Adobe pay homage to failed development methodologies with WorkflowLab

waterfall methodThis week’s Adobe MAX event has seen a sizeable number of interesting and potentially exciting announcements and releases. One rotten apple stood out amongst these releases though.

As anyone who has been involved in software development over the last couple of decades will know, everyone once used to slavishly follow the waterfall method of software development. Projects were consistently late, over-budget and of poor quality. An endless succession of solutions to solving these problems were suggested, with little success. Then one day, the penny dropped and it was realised that the the waterfall method itself was to blame. It is a crap way of developing software; this is well recognised today. Instead of the design, implement, test, ship step approach to development, agile methods, such as Scrum, are growing in popularity. The reason is simple: agile methods are far more likely to deliver projects on time, in budget with a high quality value.

Given this, I was excited to see a work flow tool appear on Adobe Labs, called WorkflowLab and eagerly installed it to see what the tool would offer. To say I was disappointed would be a gross understatement. I was actually shocked by what I found.

The first – and relatively minor – problem was the poor user experience it offered me as a Windows 7 user. Rather than use the Windows chrome, the developers have opted to implement their own chrome. As a consequence, it lacks the nice drop shadow that “proper” windows applications have. It doesn’t support the new Windows 7 window resizing controls (ie dragging on the titlebar when maximised didn’t cause it to resume its non-maximised size). And it basically plain looks crap as it sits amid a sea of aero glass-decorated programs. My guess is that the developers use Macs and did no Windows 7 UX tests. As the latter has been freely available via the beta programme for months now, the developers have no excuse for this.

The second – and way more important –  problem can be observed in the screen shot below (click on it to see the full size image). What you see is a supposed “best practice” work flow for “InDesign to Kindle Store”.

WorkflowLab screenshot
WorkflowLab screenshot

The developers seem to seriously believe that completing the layout before previewing the result is “best practice”! And lest you think that this is a one-off, even the “Workflow Behind WorkflowLab” work flow show the classic design, develop, test, release waterfall approach and sells this too as “best practice”.

In case you haven’t worked it out by now, I strongly feel this is a rubbish application, full of bad work flow advice. By itself, this wouldn’t be too bad, but this is an Adobe-endorsed product that is supposed to sell the use of Flash Catalyst in the development work flow.  Catalyst has come in for criticism from some developers as the beta releases of the product only support one-way design -> develop work flows. I had assumed this due to it being a beta and that the final release would support circular, iterative, development. WorkflowLab opens up a worrying possibility though: that Catalyst will only ever support this one way flow, and Adobe are trying to con the world into thinking this is OK by presenting a failed work flow method as “best practice”.

Adobe Max 2009 missed headline: “Windows users can now develop iPhone apps”

Using Windows to develop iPhone appsAt yesterday’s keynote, Adobe announced that just about every mobile phone manufacturer – except stubborn old Apple of course – was working with them to add Flash 10.1 to their devices in future. Then they made their “big announcement” that the next release (CS5) of the Flash authoring tool would support compiling iPhone native applications. Flash is coming to the iPhone, sort of.

Amidst all the excitement of deluded fools thinking now was their chance to make millions selling iPhone apps without having to learn “real” programming, the real big announcement seemed to get missed. Reading through Adobe’s FAQ on the matter, two important things stood out for me:

  1. A version of the Flex/ AIR SDK is to also to be released that will let Flex Builder (and presumably other developer tool) users to compile up iPhone apps.
  2. Those tools will run on Windows.

Until now, the iPhone app developer has been faced with a huge initial cost hurdle of having to buy a Mac. The reason for this is that, until now, only two possible solutions to developing iPhone apps existed: Apple’s own objective C development environment and MonoTouch. The latter is a .NET development tool for compiling C#, IronRuby etc into iPhone native applications. It, like Apple’s own tools, only runs on OS X. Also MonoTouch costs a lot of money, whereas the Flex SDK’s tend to be free. This opens up the possibility that Apple’s “iPhone development kit for Windows” may well be free too.

The FAQ suggests there will be compromises. My reading of it is that one cannot test the apps in Apple’s iPhone simulator, only directly on the phone itself (this applies to Mac users too) and I don’t think the normal set of iPhone APIs are accessible either.

Obviously a lot of this is speculation. A public beta of CS5 is due out by the end of the year though so we will know for sure within the next three months.

FOTB 2009 Day 1

Flash on the Beach 09This year’s Flash on the Beach keynote started on a high with a hilarious act from three faux Mexicans. Having got everyone in the mood, John Davey came on stage to rapturous applause and introduced the folk from Adobe who were to do the main keynote piece. Sadly the keynote then went downhill and left me wondering quite why I’d bothered. As much of the Flash stable (Flash Catalyst, Flex 4 SDK & FlashBuilder) are all currently in beta – and with just 2 weeks until MAX – there was little in the way of new stuff to show us. So we were subjected to yet more AIR applications along with some style-over-substance (or “proof of concept” to be more generous) 3D and sound demos.

Toward the end of the keynote, we were at least treated to some sneak peaks at upcoming features in the next release of the Flash Pro authoring tool, including better integration with FlashBuilder. There was also a hint that there might be news on Flash Player 10  finally appearing on smart phones (though presumably not the iPhone) at MAX.

Next up was a presentation on AIR by Mike Chambers. It was a curious mix of self-promotion of his as3corelib project and some details on features coming in AIR 2.0. The latter is to gain built-in support for detecting removable drives being mounted/ unmounted and a new native application mode. The native mode will be built as a .exe (or the MAC equivalent) and can communicate with other native applications via stdin and stdout pipes. This seems an odd solution when the likes of Mike’s own Command Proxy project offer a much richer solution already. I guess we will have to wait for more details from MAX to understand the solution better.

The only other session of note – in this developer’s view – was a session on Spark by Mike Jones. Sadly Adobe have dumped the great name “gumbo” and replaced it with the far more boring “spark” for their new skinnable component set. The session described the current state of the spark components (subject to change of course as it’s all still in beta). Despite many criticising the namespace in CSS solution Adobe came up with to support both halo and spark in the one application, I personally think it’s a very nice solution. Catalyst remains a odd one. At the moment it just doesn’t work to my mind: it is too product-skin focused and only really goes one way from designer -> developer. I fully agree with Mike’s hope that the final product better support general (and custom) component skinning and that it better support a two way design/ develop workflow.

Tomorrow has far more developer-orientated content than today, so hopefully should prove a more fruitful day for me.