Category Archives: flash

adobe, flash

Render SWF in JavaScript – a solution for Flash on iPhone/iPad?

1 Comment

Looking at the blazing-fast JavaScript in IE9 Preview 4 made me wonder if anyone had tried to write a SWF renderer in JavaScript. SWF is the Adobe Flash file format and a published specification.

Of course someone has. Tobias Schneider has been working on Gordon and built his first full release in June.

image

Gordon is a little behind in terms of version support:

In this build, Gordon can read and parse all valid SWF’s, even if they are compressed with ZLIB, but plays only SWF1 files completely, as well as the most of the SWF2 features.

The Adobe SWF specification is now up to version 10.

It is still an interesting exercise. Consider Google Web Toolkit, which compiles Java to JavaScript. What if Adobe did something similar for Flash? In fact, if you look at the Smart Paste “sneak peak” from Adobe Max 09 something like this was demonstrated.

The Flash player includes some proprietary codecs that could not easily be replicated in JavaScript. Still, given such limitations, “Export to HTML 5” would be a nice option to find on some future version of Flash Professional, and would help Adobe’s tools business even if it also dented its ambitions for Flash as the universal runtime.

adobe, flash, professional, software development, Web

SOA, REST and Flash/Flex – why Flash does not PUT

Adobe’s Duane Nickull has an illuminating post on how the Flash player handles REST. Nickull is responding to a post by Malcolm Box in which he complains how hard it is to use Flash with a REST web service. Box observes that Flash cannot send POST, PUT and DELETE requests when running in the browser, and does not send cookies.

Nickull defends the Flash behaviour:

Flash’s HTTP libraries currently support GET and POST. My architectural view of this is that the HTTP libraries only should really support these and not worry about the others.

He also notes that cookies are a poor way to manage state:

Cookies are for the browser and belong in the browser. Having Flash Player able to access cookies would be a mistake in my own opinion. Any logic that is facilitated by a browser should probably be dealt with at the browser layer before Flash Player is used.

Now, I think the comments on REST are important to read if you are engaged in designing a web service, as many of us in these days of cloud+device. There is a kind-of “word on the street” approach to web services which says that REST is good, SOA/SOAP is bad; but in reality it is not so simple, and these distinctions are muddled. REST is arguably a form of SOA, you can do SOAP with REST, and so on.

One factor is that reading data in a web client is far more common than writing data. It is easy to be an advocate of the simplicity of REST if all you are doing is GET.

The question Nickull asks is whether the transport protocol has any business dictating how the data it transports should be processed, for example whether it is an operation to retrieve or to write data:

In an SOA world, the transport functionality (usually implemented using SOAP) should focus on just delivering the message and it’s associated payload(s) to the destination(s), optionally enforcing rules of reliability and security rather than declaring to the application layer processing instructions to the service endpoint.

Read the post for more of the rationale behind this. Maybe, even if you are doing REST, restricting your web service to GET and POST is not such a bad idea after all.

That said, whatever you think about the architectural principles, you may find yourself having to write a browser-hosted Flash client for a service that requires an HTTP verb other than GET or POST. There are ways round it: see this discussion of Amazon S3 (which uses PUT) and Flash for an example.

adobe, flash, internet, microsoft, professional, software development, web authoring

Big browser and RIA news: Canvas comes to Internet Explorer 9

2 Comments

I’ve just installed the third Internet Explorer Platform Preview (on a virtual machine just in case) and run through a few of the demos. One of the most impressive is Canvas Pad, which demonstrates the HTML 5 Canvas element.

image

Canvas is particularly interesting, since it provides a surface to which you can draw anything you like. Canvas support was not announced at Mix earlier this year, when IE9 was unveiled, and some of us speculated that Microsoft would omit it in order to preserve the value of its Silverlight plugin – though in doing so it would also help Adobe Flash. Well, apparently the IE9 team decided to risk it. Not only is canvas supported; it is also hardware-accelerated:

Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. Hardware accelerated canvas support in IE9 illustrates the power of native HTML5 in a browser.

Is there still value in Silverlight and Flash? There is, for several reasons. A plug-in presents a predictable runtime, insulating the application from browser variations. A plugin will work on browsers that do not yet support Canvas. Further, Silverlight includes the .NET Framework with its rich library, and supports the .NET languages, whereas for HTML5 you have to use JavaScript – though don’t forget Google Web Toolkit, which compiles Java to JavaScript, and other similar projects.

Even so, once you have hardware-accelerated Canvas there will be few occasions when you absolutely have to use Flash, Silverlight or Java.

Microsoft is doing the right thing. Crippling IE for the sake of Silverlight would only push users to other browsers, so it would not achieve its goal.

A full list of what is new in IE9 is here. It is shaping up to be the most interesting new IE since version 4.0 back in 1997.

adobe, apple, flash, professional, software development

Adobe financials: strong Creative Suite 5 and Flash, claims company undervalued

Adobe has released its financial results for its second quarter, reporting $227.3 million net income (GAAP) compared to $161.4 million in the same quarter last year; and revenue of $943 million which it says is 34% year on year growth.

Much of this is thanks to a successful launch for Creative Suite 5, which accounts for 56% of Adobe’s revenue. However, Adobe has also reported 12% year-on-year growth for LiveCycle, its enterprise server products about which I learned last week in Amsterdam. The “platform” segment, which includes the Flex development tools, Cold Fusion, and Flash media services, is also growing, from $36.8 million in Q2 2009 to $45.4 million in Q2 2010.

CEO Shantanu Narayen is upbeat, saying “we believe Adobe is significantly undervalued today” and backing his judgement with a share buyback program.

I was particularly interested in the focus on Flash in Adobe’s statements and conference call:

Approximately 3.5 million Flash designers and developers are working with Flash-based solutions today, and their ranks grew by 59 percent in 2009

said Narayen; while Executive VP Mark Garrett noted:

CS5 products containing Flash authoring and output as a product component achieved revenue growth of 22% version-over-version to date

making the point that this exceeded the growth of CS5 overall.

Any clouds on the horizon? Two that I can think of. One is that Apple wants to kill Flash. CEO Steve Jobs says:

Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

The other issue is that Adobe is dependent on Creative Suite, desktop software that arguably will be a business hard to sustain in the cloud and device era.

Still, these are good figures, the best we have seen from Adobe for a while, and despite the efforts of Steve Jobs both Adobe and Flash are prospering right now. A side-effect of Apple’s Flash downer is that competitors have hastened to support it, with Google building Flash support deeply into its Chrome browser.

Detailed figures from Adobe are here.

adobe, flash, mobile

Flash and AIR for Windows Phone 7 by mid 2011?

I’m at an Adobe partner conference in Amsterdam – not for the partner sessions, but to be one of the judges for tomorrow’s application showcase. However, I’ve been chatting to Michael Chaize, a Flash Platform evangelist based in Paris, and picked up a few updates on the progress of Flash and AIR on mobile devices. AIR is a runtime which uses the Flash player for applications that are not hosted in the browser.

It’s well known that AIR for Android is ready to preview, though it is not quite public yet. Which platforms will come next? According to Chaize, AIR for Palm webOS is well advanced, though a little disrupted by the coming HP takeover, and Blackberry is also progressing fast. He added that Windows Phone 7 will not be long delayed, which intrigued me since that platform itself is not yet done. Although Microsoft and Adobe have said that Flash will not be in the initial release, Chaize says that it will come “within months” afterwards, where “months” implies less than a year – maybe six months or so.

We also talked about the constraints of a mobile platform and how that affects development. Currently developers will need to use the standard Flex components, but Chaize said that a forthcoming Flash Mobile Framework will be optimized for devices. Of course, the more you tailor your app for mobile, the less code you can share with your desktop version.

The Apple question also came up, as you would expect. Chaize pointed out that Adobe’s enterprise customers may still use the abandoned Flash Packager, which compiles Flash code to a native iPhone app, since internal apps do not need App Store approval. That said, I suspect that even internal developers have to agree the iPhone Developer Program License Agreement, with its notorious clause 3.3.1 that forbids use of an “intermediary translation or compatibility layer or tool”. Even if that is the case, I doubt that Apple would pursue the developers of private, custom applications.

adobe, apple, flash, google, java

Google advances its platform – or should that be advances the Web?

Yesterday Google presented its latest platform innovations at the Google I/O conference in San Francisco. Its strategy is relatively clear: to improve web applications so that you can do everything you need in the browser. The client pieces are HTML 5 – though bear in mind that this is not yet a fixed standard – and especially the Chrome browser, whether installed on a traditional operating system or delivered on a Chrome OS device.

Chrome has always had lightning-fast JavaScript. We’re now seeing other pieces in the Chrome-as-application-platform story, including:

Integrated Adobe Flash

The  Native Client for secure native code, typically coded in C/C++, running in the browser

Announced yesterday, the WebM video and audio format. This includes VP8, acquired with On2 Technologies and now open source, as well as Vorbis audio and the Matroska multimedia container.

The Chrome Web Store, also announced yesterday, which will be an App Store equivalent for web applications.

image

Web Store apps are “installable” which may mean little more than a shortcut in the browser, similar to a bookmark or favourite link. However, there will be a payment infrastructure as well as ratings and user reviews.

Serverless apps. This is another aspect to the Web Store. A Web Store app can be designed to run offline, with all the necessary HTML and JavaScript bundled into the .crx format used by the store. Google calls these Serverless apps, and in many ways the concept is similar to that in Palm’s WebOS – HTML and JavaScript applications that run locally. This is interesting for Chrome OS as it makes it easy to create applications that work offline.

The Google Font API and Directory. This is big news. Most of us stick to the same old web fonts, or use images, or a plug-in like Flash or PDF, for going beyond the standard browser fonts. Using Google’s API, it is easy to include any font in the new directory, with nothing more than a specially crafted CSS link.

The Google Font API hides a lot of complexity behind the scenes. Google’s serving infrastructure takes care of converting the font into a format compatible with any modern browser (including Internet Explorer 6 and up), sends just the styles and weights you select, and the font files and CSS are tuned and optimized for web serving.

On the server side, there is Google App Engine for Business. Google is cooperating with VMware so that you can host Spring applications on its web application platform, App Engine. Spring Roo, a rapid application development tool for Spring, has been integrated with Google Web Toolkit (GWT) to make it easy to build browser-hosted clients for Spring applications. GWT lets you code in Java, but run in JavaScript. Using Spring gives you a choice of where to host your application: on-premise, on App Engine, on the Salesforce.com platform with VMforce, or on another platform such as Amazon EC2.

Spring’s Rod Johnson explains the goals here:

Until the announcement of VMforce and today’s announcement, Java developers lacked a PaaS destination to which they could easily deploy their applications. This was an important gap that threatened to become a danger to the long-term future of Java. I’m delighted that VMware/SpringSource is leading the charge to fill this gap.

Another feature worth highlighting is SQL for App Engine:

SQL database support on App Engine gives enterprise developers access to the full capabilities of a dedicated relational database, without the headache of managing it.

though Google adds that this is a “premium service” which may come at extra cost. According to the roadmap, this is coming in Q3 2010.

While there is a lot to take in, there is a consistent theme: making the web and browser platform more capable, and making desktop applications and on-premise servers less necessary.

Whereas Apple aims to lock us into its devices and App Store, Google’s approach is more open. It is happy to give away stuff like the WebM multimedia project and the Font API in order to improve the Web overall; though of course every time we use the Font API Google can record the traffic on our site and mine that data if it chooses to do so. It is in line with the strategy unveiled at the Mobile World Congress in February: a little bit of everything you do. Google will take its cut of any Web Store sales. What is Web and what is Google is deliberately blurred.

I still think that the forthcoming Chrome OS is an amazing experiment, and the new offline application support announced yesterday makes sense as an alternative to traditional local applications.

A good day for Adobe and Flash, or a bad one? Adobe’s Kevin Lynch demonstrated new HTML 5 capabilities in Dreamweaver, via an add-on pack. As expected, Adobe is becoming a little less Flash-focused in its PR. Google’s emerging platform is a tool opportunity for Adobe. Still, that is a lesser role than establishing Flash as the universal client, a possibility which Apple seems to have killed. Google is supporting Flash, of course, by building it into Chrome, but at the same time things like WebM, Font API, HTML5, and Native Client (shown as the natural client platform for browser-hosted games) undermine the need for Flash.

Apple is a problem for Google too. Will native client ever work on iPhone or iPad? WebM? The big question – who will marginalise whom?

.net, adobe, flash, java, microsoft

Java versus C/C++ performance – which is really faster?

9 Comments

Cliff Click of Azul Systems has an excellent post on Java vs C/C++ performance:

Is Java faster than C/C++?  The short answer is: it depends.

He then presents three categories of cases: the first C/C++ beats Java, the second where Java beats C/C++, and the third and longest, where C/C++ proponents claim Java is slower but in reality it is not.

My quick summary: there are few cases where Java (or C#) is so much slower that it matters, save for one big issue which Click mentions early on – start-up time:

Flash games beat Java games mostly because it took 30+sec to load the JVM from disk… and so now the web-game developer community has settled on Flash as the standard (and it still takes 10+sec to load the JVM).

Start-up time makes a big difference to usability, for reasons which I cannot entirely explain. Just for fun, I’ve been running Microsoft Office 95 in a virtual instance of Windows XP recently, and the fact that Word 95 loads in a blink makes it feel much faster than Word 2010, which takes 5-10 seconds on first load, even though the productivity difference must be negligible.

If I had to theorise about this, I’d say it is to do with the way humans learn from experience. We don’t like waiting, and if an application take a while to start then part of our brain tells us to avoid it in future. We override that instinct when it is an app we need to run, but it contributes to a negative impression.

The opposite is also true. If an application starts instantly – I mean to the point where we can use it, not just a splash screen – it contributes to a positive impression and we are more inclined to use it in future.

Incidentally, Click thinks that Java is generally faster than C#, though he adds that he is “not able to give C# a fair treatment” because he does not track it closely.

flash, microsoft, silverlight, web authoring

A business web site implemented entirely in Silverlight

12 Comments

Ever wondered what the web would look like if Silverlight or Flash were used for everything? The other day I came across a business site implemented entirely in Silverlight – well, apart from the forums, which seem to be HTML and JavaScript. ForefrontSecurity.org is a third-party resource site for Microsoft’s firewall and server security products. It is mostly documents and videos.

image

On the plus side, the site looks good, provided you can run Silverlight; and given the target readership that’s not too much of a stretch in this instance. Playing the embedded screencasts is very smooth, and they feel seamlessly integrated with the site, more so than with HTML plus a video plug-in.

That said, I found the site infuriating. Without thinking, I tried to scroll a document using the mouse wheel; nothing happened. The page up and down keys do not work either. Copying text works with Ctrl-C, but if you select and right-click, you just get the Silverlight “about” menu. I also found that the graphic effects – screens typically fade in as they change – made the site seem slow. Some things, like hyperlinks in full-screen mode, did not work as expected.

An interesting experiment; but for a site like this which is mainly about finding and reading documents, its hard to see a good reason not to use HTML.

adobe, apple, flash, google, internet, web authoring

After Apple’s Flash ban, what next for Adobe?

2 Comments

I imagine there must be urgent meetings taking place at Adobe following Apple’s prohibition of Flash content or applications on its iPhone and iPad devices, and last week’s open letter from Apple CEO Steve Jobs which leaves little hope of a change in policy.

The problem is that until now Adobe has put the Flash runtime at the heart of its strategy. The Flash Platform is a suite of tools and technologies including middleware (LiveCycle Data Services), web and desktop runtimes (Flash and AIR), design and developer tools (Creative Suite and Flash Builder). The company has worked to integrate Flash and PDF, using embedded Flash content for multimedia and to blur the boundaries between documents and applications.

If you look at Creative Suite 5, the latest release of Adobe’s flagship tools and from which it derives most of its revenue, there is scarcely a product within it which Flash does not touch.

Adobe’s hosted document and collaboration platform, Acrobat.com, uses Flash for online document viewing and editing, for web conferencing, for online presentations.

Adobe’s abandoned Flash to iPhone compiler was not only something for third-party developers, but also for Adobe itself, and the company has already been using it to enable access from iPhone to some of its Flash-based online services. For example, Adobe Acrobat Connect Pro Mobile for iPhone, which lets you attend Acrobat Connect Pro meetings:

This application was developed using the Flash platform and the Packager for iPhone to publish it as a native iPhone application. We will also be able to use the same code to deliver this application on other mobile devices when AIR for mobile devices becomes available later this year.

Of course Adobe is not solely a Flash company. It’s also a PDF company, and while there is no Adobe Reader for iPhone, it is at least possible to view PDFs on Apple’s devices. Adobe is an HTML company too, and products like Dreamweaver and Fireworks are geared towards HTML content.

Still, Apple has created a big problem for Adobe. The appeal of the Flash Platform starts with the ubiquity of the runtime.

Let’s assume that Apple trundles on, grabbing an increasing share of the Smartphone market and encroaching into what we now think of as the laptop/netbook market with iPad and possibly other appliance-type computing devices. What can Adobe do? Here are a couple of top-level choices that occur to me:

1. Resign itself to being an anything-but-Apple company. There is life beyond iPhone and iPad; and Adobe is making good progress towards establishing Flash elsewhere, from Android mobiles to set-top boxes to games consoles. Unfortunately the Apple-owning community is a wealthy and influential one; the impact of losing that part of the market is greater than its market share implies. Nevertheless, this seems to be Adobe’s immediate reaction to the Jobs bombshell. It is rumoured to be giving Android phones to its employees, for example, and there are signs of an Adobe-Google alliance forming against Apple – note that Google is building Flash by default into its Chrome browser.

2. Pull back on Flash. For example, redesign Buzzword, its Flash-based online document editor, in HTML and JavaScript. Tune its PR message to emphasise how useful its tools are in an non-Flash context, rather than presuming its runtime will be everywhere. I think Adobe will have to do this to some extent.

A mitigating factor is that while Adobe has (until now) done a great job of deploying the Flash runtime, it has done less well at monetising it. If you look at its latest financials, you’ll see that Flash Platform (including AIR) accounted for only 6% of its revenue, compared to 50% for design tools including Creative Suite and Photoshop, 28% for business use of Acrobat, and 10% for the recently acquired Omniture web analytics. Although some of its design market is Flash-dependent, there is plenty more that is not.

adobe, flash

Adobe no longer investing in Flash compiler for iPhone, sings Android praises

4 Comments

Adobe’s Mike Chambers has posted about Apple’s new restriction on how applications are built for the iPhone or iPad. He says Adobe is ceasing development work on this feature:

We will still be shipping the ability to target the iPhone and iPad in Flash CS5. However, we are not currently planning any additional investments in that feature.

Of course he says “currently” so development could be resumed, presumably if the restriction is lifted.

He also suggests that Apple may be specifically targeting Flash despite the general wording of its notorious clause 3.3.1:

While it appears that Apple may selectively enforce the terms, it is our belief that Apple will enforce those terms as they apply to content created with Flash CS5.

Chambers spends much of his post saying how well Flash runs on Android – though Flash Player 10.1 and AIR 2.0 for Android are still in beta – and suggesting that Flash developers target Android instead.

The problem is that developers will go where their customers are. If Apple continues to increase its market share, its platform will continue to attract developers.

This is another instance of something I blogged about two years ago: the risk of building your business on a third-party platform. My post then was about Amazon, eBay and Facebook. Now the focus is on Apple. Other platforms like Salesforce.com and Google have the same inherent problem.

I think this problem will get worse rather than better, as people migrate from general-purpose open platforms to more locked-down appliances.