Tag Archives: air

Flash developers fret as Adobe doubles down on PhoneGap

 

Adobe has announced Experience Manager Apps for Marketers and Developers. This comes in two flavours: Experience Manager Apps is for marketers, and PhoneGap Enterprise is for developers. The announcements are unfortunately sketchy when it comes to details, though Andre Charland’s post has a little more:

  • Better collaboration – With our new PhoneGap Enterprise app, developer team members and business colleagues can view the latest version of apps in production, development and staging

  • App editing capabilities – Non-developer colleagues can edit and improve the app experience using a simple drag-and-drop interface from the new Adobe Experience Manager apps; this way developers can focus on building new features, not on making updates.

  • Analytics & optimization – Teams can immediately start measuring app performance with Adobe Analytics; we’re also planning to incorporate functionality so teams can start A/B testing their way to higher app engagement and monetization using Adobe Target.

  • Push notifications – Engage your customers on-the-go with push notifications from Adobe Campaign

  • Support and training – PhoneGap Enterprise comes with SLA and support so customers can be rest assured that Adobe PhoneGap has their back.

Head over to the PhoneGap Enterprise site and you get nothing more than a “Get in touch” button.

image

Announcement-ware then. Still, enough to rile Flash and AIR (Adobe Integrated Runtime) developers who feel that Adobe is abandoning a better technology for app development. Despite the absence of the Flash runtime on Apple iOS, you can still build mobile apps by compiling the code with a native wrapper.

Adobe… this whole thread should make you realize what an awesome platform and die hard fans you have in AIR. Even after all that crap you pulled with screwing over Flex developers, mitigating Flash to just games, retreating it from the web, killing AS4 and god knows what else you’ve done to try to kill the community’s spirit. WE STILL WANT AIR!

says one frustrated developer.

Gary Paluk has also posted on the subject:

I have invested 13 years of my own development career in Adobe products and evangelized the technology over that time. Your users can see that there is a perfectly good technology that does more than the new HTML5 offerings and they are evidently frustrated that you are not supporting developers that do not understand why they are being forced to retrain to use inferior technologies.

Has Adobe in fact abandoned Flash and AIR? Not quite; but as this detailed roadmap shows, plans for a next-generation Flash player have been abandoned and Adobe is now focused on “web-based virtual machines,” meaning I guess JavaScript and other browser technologies:

Adobe will focus its future Flash Player development on top of the existing Flash Player architecture and virtual machine, and not on a completely new virtual machine and architecture (Flash Player "Next") as was previously planned. At the same time, Adobe plans to continue its next-generation virtual machine and language work as part of the larger web community doing such work on web-based virtual machines.

From my perspective, Adobe seemed to mostly lose interest in the developer community after its November 2011 shift to digital marketing, other than in an “apps for marketing” context. Its design tools on the other hand go from strength to strength, and the transition to subscription in the form of Creative Cloud has been brilliantly executed.

Adobe AIR for Metro promised for first half of 2013

Adobe Game Developer Evangelist Lee Brimelow has stated on Twitter that AIR for Metro is coming next year.

we’re working on Air for Metro. It should be available first half of next year.

AIR is a way of compiling Flash applications to run outside the browser.

[Microsoft no longer uses the term Metro. We are meant to say Windows Store Apps; but that is even more confusing.]

On BlackBerry 10, Cascades UI and Adobe AIR

I spoke to Jeff Lejeune, RIM’s Advanced User Interface Director, here at BlackBerry DevCon Europe in Amsterdam.

He is part of the team responsible for the Cascades UI, a native code UI framework for the forthcoming BlackBerry 10 OS. One of the things he told me is that the Cascades name is actually being used for parts of the API beyond the user interface. It is a major part of the new operating system.

I had not appreciated until today the extent of the likely difference between BlackBerry 10 and the current Tablet OS 1.0 or Playbook OS 2.0. Since the PlayBook OS is already based on QNX, I had assumed that BlackBerry 10 would be an incremental update rather than a radical new direction.

Certainly there is less difference between PlayBook OS 2.0 and BlackBerry 10 then there is between BlackBerry 7.0 and the PlayBook OS, so my assumption was not completely wrong. That said, the introduction of the Cascades UI acquired with The Astonishing Tribe is a major change. Lejune told me that Cascades UI will be in effect the native UI of BlackBerry 10, and the built-in apps will use it.

The first version of the PlayBook uses both native code and Adobe AIR for its built-in apps.

RIM has given full backing to Adobe AIR at this event, presenting it as one of the supported development platforms and saying that it will support AIR for as long as Adobe does and maybe even longer. Even so, it would be fair to say that RIM is moving away from AIR and towards native code and Cascades UI in BlackBerry 10.

Further, Adobe itself has changed direction since the launch of the PlayBook last year. Adobe has made it clear that while Flash, Flex and AIR are still important, its strategic direction is HTML 5 when it comes to development platforms. Some aspects of Flex, the code-based approach to AIR authoring, are being wound down, including the visual designer in Flash Builder.

My sense therefore is that AIR is not the best choice if you are considering how to develop for BlackBerry 10 – and BlackBerry 10 is the future of RIM’s platform. The primary choice should be between Cascades UI, for best performance and integration, or WebWorks (PhoneGap), for development in HTML and JavaScript and cross-platform code.

What next for Adobe Flash? Think runtime not plugin

Adobe is stating that mobile Flash will no longer be developed:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook. We will of course continue to provide critical bug fixes and security updates for existing device configurations. We will also allow our source code licensees to continue working on and release their own implementations.

Although this seems like a major shift in strategy, Adobe has been moving in this direction for some time. At the MAX conference last month the company was clear that most web developers can be expected to use HTML 5 rather than Flash most of the time, reserving use of the plug-in for video, games and certain kinds of application. As for mobile, all the talk was about AIR and the captive runtime, an approach similar to the iOS packager which bundles the Flash runtime into your application so that no plug-in or additional download is required.

This approach is now explicit, and I reckon we can further conclude that if the Flash plugin for mobile is being abandoned, then the Flash plugin for the desktop is also less important than before. Mobile browsing is huge, and likely to grow, so developing web pages for Flash is unattractive other than in cases where there is an easy way to direct mobile browsers to a non-Flash alternative. Flash as a browser plugin will now decline forever, which is a good thing for web standards even if it is not necessarily a good thing for web developers, who must face the challenge of cross-browser development.

So what is Flash now? It is still Adobe’s runtime, and the client for its media services, and in that role it remains significant. Thanks to Adobe’s packaging work, you can take your Flash or Flex application and deploy it to most desktop and recent mobile platforms, though not to Windows Phone or older Android devices. Could you not use HTML 5, JavaScript and PhoneGap instead? Maybe in some cases; but Flash is a richer, faster and more consistent platform, as well as benefiting from Adobe’s design and development tools.

See also my piece for the Register: Down but not out: Flash in an HTML5 world.

Update: Added official Adobe link for statement on mobile Flash.

Developers keen to get apps on Barnes & Noble Nook

I took a quick look round the exhibition here at Adobe MAX in Los Angeles, and was intrigued to see crowds round the Barnes & Noble Nook stand, a newcomer to Max.

image

Barnes & Noble has its own app store for Color Nook, the AIR runtime is on the device, and in fact is used for some of the built-in apps. It is not the most powerful of tablets, and it only has wi-fi for internet connectivity, but nevertheless is proving a worthwhile market for apps. The store is curated to maintain quality, and one of the points made to me on the stand is that owners expect to pay for their content, making it easier to sell paid-for apps.

image

Unfortunately this device is not available globally, and of course everyone is waiting to see what impact Amazon’s Kindle Fire will have on Nook’s sales. Even so, for developers who have a suitable app this is a significant market.

Adobe to ship Flash 11 and AIR 3, repositions Flash vs HTML 5

Adobe has announced that Flash 11 and AIR 3 will ship in early October.

There are significant changes in this release.

  • Flash gets Stage 3D (previously codenamed Molehill), a set of low-level 3D APIs, GPU accelerated where hardware allows, which will make console-like 3D graphics and games possible in Flash. Stage 3D wraps DirectX on Windows and OpenGL on desktop and mobile platforms.
  • 64-bit Flash is here at last, supporting 64-bit Internet Explorer and other browses on Windows, Mac and Linux.
  • AIR, which uses Flash as a runtime for desktop and mobile applications, now supports native extensions for better device support, operating system integration, and the ability to speed performance-critical code or use open source libraries.
  • In addition, the AIR packager for iOS, which lets you wrap your application as a native executable, is now a feature called Captive Runtime which is available for Windows, Mac and Android as well as iOS. Users who install a packaged application will not know it uses AIR, and will not need to install or update the AIR runtime as it is packaged with the application, though it is not actually a single file (on Windows at least).

These new options make the Flash and AIR combination an interesting comparison with other cross-platform development tools, such as Embarcadero’s new Delphi XE2, which targets Windows, Mac and iOS with a new framework called FireMonkey; or Appcelerator’s Titanium tool for cross-platform desktop and mobile development. Note though that Adobe is not promising any performance improvement. This is just another way to package the same runtime.

Adobe’s advantage is its high quality design and development tools and the maturity of the Flash runtime. For application size and performance, it will likely fall short of true native development tools. The ActionScript language could do with updating, and I would not be surprised if Adobe addresses this in the next major Flash release.

But do we still need Flash? Flash in the browser is in decline, thanks to the influence of Apple and the rise of HTML 5. Adobe’s MAX conference is coming up soon, and I noticed in the schedule [Flash needed] a defensive note in some of the sessions; there is even one called “The Death of Flash” which talks about “the misinformation that’s percolated through the web over the past year”.

That may be so; but even Adobe is re-positioning Flash and recognizing the rise of HTML 5. “Customers see significant advantages for Flash in a few focused areas,” said Adobe’s Danny Winokur, VP and General Manager of Platform , in a press briefing. He identified these areas as gaming, media apps, and “sophisticated data-driven applications” – think data visualisation rather than just forms over data. “For everything else it is very clear that … HTML 5 is a mature enough technology that it is a really good solution.”

Adobe is therefore investing in HTML 5 tools as well as Flash tools, and Winokur mentioned the Edge motion design tool as well as the venerable Dreamweaver.

I asked Winokur, given that HTML 5 is maturing fast, how Adobe sees the picture vs Flash in say two years time. He replied that Adobe is actively working to advance HTML 5, but that “there will continue to be opportunities for innovation in Flash, where we can … enable new possibilities that did not previously exist on the Web.” He makes the case for Flash as a kind of leading edge for HTML, with features that eventually become part of the HTML standard.

It is a fair point, but it is obvious that the niche for Flash is getting smaller rather than larger.

Adobe has never charged for the Flash runtime, and while the Flash vs HTML path is tricky to navigate, Adobe mainly makes its money from design tools, server applications and web analytics, and while Flash plays some client role in many of these products, Adobe can tune them over time to make less use of the runtime. I believe we can see this happening.

More positively, Adobe is benefiting from the demand for rich content across both web and applications, and has just reported decent financial results, showing the company’s resilience.

Finally, everyone is asking what Adobe will do about Microsoft’s WIndows 8 Metro platform for tablets, given that browser plug-ins are not supported. Here is the answer:

… we expect Flash based apps will come to Metro via Adobe AIR, much the way they are on Android, iOS and BlackBerry Tablet OS today

though I hope this will be delivered more quickly than the promised Flash runtime for Windows Phone 7, which is not a subject either Adobe or Microsoft seems willing to talk about.

Update: Adobe has also announced the Flex 4.6 SDK and Flash Builder 4.6, which supports these new capabilities including Captive Runtime and Native Extensions, and has new controls specifically aimed at tablet apps.

Adobe closes AIR Marketplace, InMarket

Adobe is giving up its efforts to support developers deploying to multiple app stores. The idea of InMarket,  announced at the Adobe MAX Conference in October 2010, was to be a one-stop distribution point for developers seeking to target multiple platforms. Adobe handled distribution and billing. The reason given:

After reviewing our efforts and based on feedback from developers, we have decided that we will deliver the most value by helping developers author and publish their apps on multiple platforms. Given this focus, we have decided to discontinue development and support of Adobe InMarket. We are going to continue to provide support for publishing to different app stores through our tooling. The recent Flash Builder 4.5 and Flash Professional CS5.5 provide support for publishing to multiple mobile platforms including Android and Apple iOS devices.

Adobe is not giving developers much time to adjust. The InMarket URL will terminate on August 31. This is causing some consternation:

I don’t understand how you expect publishers will be able to push an update to all the markets they publish to with enough time to get their user base to update before they’re totally screwed. One month? You do realize that even updates pushed to AppUp can take up to 2-weeks for vetting? This is crazy

That said, the low traffic on the InMarket forum is a clue to what Adobe is closing it down.

InMarket only supported Intel AppUp and AIR Marketplace, which rather misses the point of targeting multiple platforms. Had Adobe been able to offer instant deployment to all the key app stores, including Android Market and Apple’s iOS App Store, it would have been more attractive. Given the complexities of the approval process, it is not surprising that this was hard to achieve. A further complication is that Adobe’s AIR runtime is not allowed on iOS. Apps for iOS have to be packaged as native iOS apps.

What about AIR Marketplace?

When we established Adobe AIR Marketplace three years ago, there were few distribution opportunities for AIR developers. There are now several app stores on desktops, mobile devices and tablets that service AIR developers including Apple App Store, Android Market, BlackBerry App World, Intel AppUp center, Samsung Apps, and Toshiba App Place. We encourage you to use these newer popular app stores to distribute your applications.

This of course describes describes exactly the problem that InMarket was meant to address: the challenge of maintaining support for multiple app stores.

AIR Marketplace is still up and running at the time of writing, and seems to have more life than InMarket:

image

That said, why would any potential customer look specifically for AIR applications? It is a runtime and ideally should be invisible to the user. I was interested to see reference to AIR packagers for Windows, Mac and Android in a recent announcement, suggesting to me that Adobe is de-emphasising AIR as a runtime and making it into something more like a cross-platform development tool.

Hands On with Flash Builder 4.5.1 for Apple iOS

Flash 4.5.1 has been released recently, the first with integrated support for Apple iOS as well as Google Android and RIM Blackberry Tablet OS. I was keen to try my calculator app on iOS, having already tested it for Android. You can do most of the development on Windows, but I moved the project to OS X so I could try it in the iOS simulator and then on an actual iPhone 4.

Adding iOS as a target platform was easy: right-click the project, choose Properties, check to add the platform.

image

Then I worked on the UI. The buttons on my design were too small. The answer I guess is to use relative sizes, but I thought for a quick test I would simply set the device to Apple iPhone 4 and resize the layout for that.

image

After a bit of tweaking I got the app working nicely in the iOS simulator, again set to iPhone4. I was also able to set breakpoints and debug the app easily.

image

Then I tried it on the device. I did the Apple provisioning dance. I then compiled a release build, which took a long time and featured a thermometer that stuck on zero the entire time. It worked though, and I got the app into iTunes and synched.

On the device the app did not look too good.

image

Well, I have read up on supporting multiple screen sizes and on setting mobile project preferences and I am still not sure why this did not work, especially as it looked OK in the simulator. I had auto-scaling on, and the docs say:

When you enable automatic scaling, Flex optimizes the way it displays the application for the screen density of each device.

I fixed the the immediate issue though by adding the attribute applicationDPI=”320” to the ViewNavigatorApplication element.

Now it works fine.

image

So how is performance? I have managed to create some rather poorly performing calculator UIs in my various tests of cross-platform mobile tools, and this is one of the better ones, though not as responsive as the Titanium app on iOS. However the Flex app is more consistent across Android and iOS, whereas Titanium was poor on Android. Loading takes a few second, but it is acceptable. The app size is only 6MB which is not bad, considering that the necessary bits of Adobe AIR are compiled into it.

Note that this is little more than a Hello World app. My reasoning is that if this does not work well, then nothing will.

So far I am encouraged. Taking into account the development experience and performance across both Android and iOS, this is one of the best I have tried so far with my simple example.

Cross-platform concerns as Adobe abandons AIR for Linux

Adobe is giving up on AIR for Linux – at least, in a fully supported manner:

To support the variety of Linux-based platforms across PCs and devices, we are prioritizing a Linux porting kit for AIR (including source code), which Open Screen Project (OSP) partners can use to complete implementations of AIR for Linux-based platforms on PCs, mobile devices, TVs and TV-connected devices. We will no longer be releasing our own versions of Adobe AIR and the AIR SDK for desktop Linux, but expect that one or more of our partners will do so. The last Adobe release of AIR for desktop Linux is AIR 2.6.

This is a curious message. OSP partners include ARM, Intel, the BBC, Google, Toshiba and other big names; but which of these might build an AIR SDK and on what sort of terms might it be supplied? Or it is more likely that, say, the BBC will deliver BBC iPlayer for LInux in a bundle that includes the AIR runtime? Or is it just wishful thinking?

Adobe’s open source evangelist Dave McAllister has a go at defending the decision, pointing out that the growing client operating systems are Android and iOS, not desktop Linux, and that AIR for Linux accounts for only a 0.5% download share. However, Linux developers observe that Adobe’s AIR for Linux effort has always been half-hearted and tricky to install, especially on 64-bit installations. AIR itself is still 32-bit, as is the Flash Player on all systems, though there is 64-bit version in preview codenamed “Square”.

Most people run Windows or Mac desktops, and will not miss AIR for Linux. That said, decisions like this do undermine confidence in the Flash platform as a cross-platform proposition. The problem is, Flash technology is not open source and ultimately whether a particular platform is supported is a matter for Adobe, with all the commercial and political factors that implies.

The risk for Adobe is that when it abandons smaller platforms, it make open standard alternatives and in particular the collection of web technologies we call HTML5 more attractive.

No Java or Adobe AIR apps in Apple’s Mac App Store

Apple’s App Store Review Guidelines appear to forbid Java or Adobe AIR applications from being published in the store:

Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.

Since Adobe AIR is not shipped by default with OS X, any applications requiring that runtime will not qualify. Java is forbidden because Apple has deprecated its own build of Java; and while it seems supportive of Oracle’s official OpenJDK project for Mac OS X, apparently that support does not extend to allowing Java apps into the store.

Of course it is not only Java and Adobe AIR that are affected, but any apps that need a runtime.

There are many other provisions, most of which seem sensible in order to protect the user’s experience with the App Store. Some of them have potential for causing controversy:

Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them. Apps that are not very useful or do not provide any lasting entertainment value may be rejected.

What defines duplication in this context? How will Apple test whether an app has “lasting entertainment value” – I presume this refers to games.

The situation on Mac OS X is different than on the iPhone or iPad, since users can easily install apps via other routes. That said, if the App Store catches on then not being included may become a significant disadvantage. Further, it will not surprise me if Apple starts hinting that non-approved apps carry more risk to the user, so that some users might decide to avoid anything without this official stamp of approval.

I wonder if Adobe will do a Flash packager for the Mac similar to that which it offers for iOS, to get round these restrictions?