Archive for category Mobile Content
BlocketPC – DeviceDays at Mobile World Congress 2010
Posted by Mark Doherty in Conference, Flash Player, Industry News, Mobile Content, Mobile World Congress on January 20, 2010

The Mobile World Congress is a massive event with some 50,000 attendees from around the world. Each year there are around 50 Adobe employees from across the organization in attendance, including all the key members of the platform team at Adobe.
This year we’ve managed to delay a few flights and tweak some schedules to create a fantastic line up for the Spanish Mobile and Devices User Group event “DeviceDays”. Raul, Marcos and myself will be joined by Richard Galvan, Product Manager for Flash Professional, Enrique Duvos who leads Evangelism in EMEA.
I’m also really excited to tell you that some of our Open Screen Project partners, and advertising aggregation providers GreyStripe will attend as guests. You’ll get a chance to speak with them directly, and additionally GreyStripe will present on ad-funded applications.. really exciting!
This day long event will be ~70% in Spanish, so a great improvement from last year
Timing/location:
- Torre Mapfre – Avinguda Litoral, 08005 Barcelona, Spain
- 09.30am – 5.00pm 19th February
- Space for 100 attendees
Note: Passing security takes time, arrive 15-30 mins early.
Schedule:
- 09.30am Welcome intro from Marcos and Raul
- 10.00am Overview of Adobe’s announcements at Mobile World Congress
- 10.30am BREAK
- 11.30am Open Screen Project new and Fund update, demos of funded applications
- 12.30am Contextual Applications – best practices, optimizations and inspirational demos
- 14.00pm LUNCH
- 15.00pm Testing Flash based applications with Device Central 3
- 15.30pm Creating iPhone applications with Flash Professional Next
- 16.00pm BREAK
- 16.15pm Creating ad-supported iPhone Applications with GreyStripe
- 16.45pm Closing remarks from Marcos and Raul
The event website is here, so start registering.
Adobe @ Mobile World Congress 2010: Free Tickets ;-)
Posted by Mark Doherty in Flash Player, Industry News, Mobile Content, Mobile World Congress on January 14, 2010
“Any Device” , that’s our tag line for this years Mobile World Congress in Barcelona. Given the huge investments with our Open Screen Project partners in 2009/2010, you can imagine that this will be our most important event in the mobile calendar.
The Mobile World Congress is a chance for OEMs, Chipset Vendors, Carriers, Content Providers and Developers to meet up and decide the future of our ecosystem. For the past two years that I’ve attended we have gone from 400million devices with Flash, to over 1.2Billion, and this year will see a massive step change in our strategy with the launch of Flash Player 10.1.
Adobe CEO Shantanu Narayan will be on site to talk with our industry partners, and to discuss key challenges in the mobile and devices ecosystem, and in particular, how we’re working to solve these issues with our Open Screen Project partnerships.
We’ll be showing Flash Player 10.1 experiences optimized for various devices platforms like Android, Palm and Windows Mobile. Our booth will be packed with demos of multi-screen contextual experiences, including Flash applications running on the iPhone, games running across platforms, the Digital Home and we’ll be showing off Device Central CS5 too.
With this being such a big event for us, we thought it would be nice for Flash developers to share this experience with us. So if you want to come along on us, and see the whole event for free then send us an email with your name, company, email address.
For more information and updates then check out our micro-site for the event.
Adobe’s Mobile Strategy: Responses to Aral Balkan
Posted by Mark Doherty in Flash Player, Mobile Content on December 30, 2009
Aral, a well respected member of the Flash community recently posted an interesting article to discuss our mobile and devices strategy. It’s really great to see community members thinking about our approach, and yes, even criticism is welcome. So here I’ll try and address Aral’s points and demonstrate why we have the right approach in the immediate term.
Hopefully we can put a few minds at rest
Adobe’s current mobile strategy is very similar today to what it always was: get the Flash Player on as many handsets as possible. Let’s qualify that statement, however, with some all-important details, starting with differentiating the two types of Flash support that Adobe wants to implement on devices:
- In-browser Flash support (plugin)
- Standalone Flash application support
Markd: It is absolutely true that our intention, working with our Open Screen Project partners, is to enable the Flash Platform to extend from the desktop and web to devices. This includes everything from desktop PCs, netbooks/Mids, smartphones and ultimately to the Digital Home. We believe that by ensuring the availability of a highly optimized and consistent platform that we can enable the creation, and continuation of innovation across all screens.
Some time ago we agreed with our partners that the browser and standalone use-cases were key in this strategy. Our partners see demand for these, in part because of competition from the iPhone OS and of course to help with their applications strategy. The Flash community is one of the largest, and obviously most creative group of professionals creating rich user experiences.
For those reasons, among others, we believe that this will result in an uplift for the community and ultimately more business for all of us (we sell tools and services remember).
In-browser Flash support is good*
Getting in-browser Flash support on devices is a logical and understandable goal and Adobe is right to devote as much effort as possible into making that happen. In-browser Flash support on mobile devices means that your mobile phone can render today’s web (which, like it or not, contains heaps of Flash content) faithfully and thus provide a similar experience to what is possible on the desktop.
* That said, given that Flash content is notorious for its high CPU (and thus power) usage, and given that a lot of Flash content on the web today is undesirable from the perspective of the end user (ads, intros, etc.), it would make sense for such in-browser implementations of Flash to voluntarily default to a Flash Block behavior (i.e., have Flash disabled by default with the option to activate Flash content if and when the user wants to.)
Markd: We definitely see a huge value in ensuring that web experiences are made available on devices. With Flash Lite we spent a huge amount of time and effort in optimization, battery performance and developer workflow (Device Central). By integrating our engineering teams we added all of that experience to the new Flash Player 10.1 and then some, the proof will land early next year. That said, you will still have to understand how the Flash renderer works and create experiences that are suitable for devices. That is true of all development platforms without exception.
I don’t think that blocking Flash as a default option is very important for the vast majority of users. Many simply want a complete web experience, and while in theory browsing could slow down we have invested alot of energy into startup/shutdown/instance management performance. Feel free to pass judgement when you’ve actually seen it in action.
The remainder of this post will deal with Adobe’s attempts to get Standalone Flash application support in mobile devices.
Flash Lite: stillborn
Adobe’s initial mobile strategy, dating back to 2005, revolved around getting a cut-down version of the Flash player called Flash Lite on as many handsets as possible.
According to Adobe the number of Flash Lite devices shipped should have reached 1 billion in 2009. While that seems like a huge number, it’s rather irrelevant. For one thing, there is more than one version of Flash Lite so that 1 billion number includes outdated players. Also, that number hides further segmentation in that it includes both devices that support only in-browser Flash content as well as those that support standalone Flash applications. Finally, and most importantly, Adobe failed at making it possible for developers to monetize Flash content and failed to provide compelling reasons for developers to create Flash content for Flash Lite.
Why did Flash Lite fail? Because it went for a lowest-common-denominator approach, trying to support as many devices as possible, instead of focussing on creating a great user experience on one device and expanding from there. In other words, it failed because the focus was on features (in this case: wide-range of device support) instead of user experience.
Markd: Today we have shipped over 1.2Bn devices with optimized Flash Players, but do not ignore that ~700m of these were shipped in the last year. To call them outdated negates the fact that regional segmentation, and in some cases carrier control, has enabled highly consistent distribution in key markets.
In some cases platform restrictions have limited the availability of standalone or browser plugin support. This opinion is quite real, sometimes unfortunate, but ultimately based on an out-dated principle that content must run on every device at all costs. At times I’ve heard this same error crop up from those building iPhone applications, who mistakenly believe that everyone has an iPhone (even when there are 3 devices and 5 OS versions).
I have to disagree completely with the principle that it is Adobe’s role to create an entire ecosystem. It is not the role of a tools vendor to build businesses to buy their tools, that is of course completely impossible. In the two years that I have been working on this ecosystem we have seen applications distributed to millions of users, millions of dollars have been made during my time.
One simple game made $2m USD last year alone in one country, and it took 2 weeks to create. Services have been created in Europe (eg Playyoo) with various successes in the US also, some developers reaching over the $1m USD mark in under a year. Is that successful? In fact “sometimes” it is, in reality it depends on your expectations.
The problem is not that we failed to provide monetization, that we don’t have an AppStore or that we reached too many devices. Flash Lite provided an incredible foothold and allowed us to build a new opportunity in a highly complex ecosystem. That ecosystem is global and while we didn’t see many signs of “success” here in Europe, in other parts of the world like USA and Japan we did.
I’m unsure how wide and global device support could have affected user experiences, although I’m sure that companies like LG, Samsung and Sony Ericsson would disagree entirely having sold hundreds of millions of devices using Flash as the user interface engine.
Open Screen Project: same old, same old
You would think that Adobe would learn from its failure with Flash Lite that getting your technology on a huge number of devices isn’t worth the effort if no one wants to use it. Unfortunately, their strategy hasn’t changed with the introduction of the Open Screen Project.
The Open Screen Project aims to remove the fragmentation created by Flash Lite and ultimately aims to have a single Flash Player (the latest one) run on every device on the planet (cue: hysterical world-domination laughter). It seems that Adobe has learned nothing from the recent failures plaguing another company with a similar strategy for its operating system: Microsoft.
Where Microsoft struggles to provide at least a mediocre user experience across the countless hardware combinations that it must support, Apple runs circles around it: Having limited itself to a handful of hardware configurations – all, furthermore, within its control – Apple can provide its users with an exemplary user experience. Apple can do this because it wisely chose to control both the hardware and the software, limit segmentation, and focus on the user experience instead of expanding effort in a fruitless quest to run on any given hardware configuration on the planet.
Adobe’s Open Screen Project is a Microsoft-style, Age of Features strategy that aims to get Flash running on every mobile handset on the planet, user experience be damned. The question is: who cares if you can run the same crappy experience on every handset?
Markd: If Aral had come to see my session at Flash on the Beach then he would have heard my talk on “Relevant Reach”. The principle is quite simple, the world of devices is complex, but largely follows an 80/20 rule for distribution. In the EMEA5 countries 80% of users can be reached targeting only 20% (285) of mobile devices. So in reality the wide reach is to ensure that as a developer, or content provider, you can reach the mass audience for a given market.
The Open Screen Project is an initiative that includes the worlds leading OEMs, even the ones that you’ve never heard of. The achievements made this year are simply unheard of in the ecosystem, and there are more announcements coming of course. It is however a slow-burner when you look at it from the outside, but if you look at what’s changing, the consistency, updated runtimes, hardware optimizations, chipset alterations. All of these things are indicative of a massive effort to realise the full potential of Flash on devices, they are not a fruitless effort to scale, but a global strategy from the key players in the devices industry.
The argument “same crappy experience” is a pretty bold opinion and one that assumes alot about the expectations (and capabilities) of many in the Flash community. We could all argue the value in targeting a single platform, and internally we considered this of course. Ultimately however, the world is bigger than the device in “your” pocket (whatever that may be), and while Adobe is US company we must consider a global audience and customer base, something that many forget.
Flawed to the core
Adobe’s Open Screen Project and its mobile efforts will fail for one simple reason: they are not competitive when it comes to user experience. A Flash application running on a device will never have the same performance or the range of hardware support as a native application. It will never be able to compete with a native app in terms of user experience. Whereas Adobe’s plugin strategy worked on the web, it has and will continue fail on mobile devices.
(See this post for a more detailed discussion of Write Once, Run Anywhere and how it differs from Write Once, Compile Anywhere.)
Markd: This argument is totally subjective and based in principle on an understanding that Flash should be perfect at everything. Flash Player 10.1 includes a new JIT technology to speed up the execution of Flash on devices, we use the power of new GPUs and hardware decoders for video and audio. It is true, at times native code or feature access will be required, that has always been true on any platform.
Our goal is not to run desktop applications on mobile devices, and nor should it be yours. The Flash Platform is designed to enable content production that *can* be optimized for any device or screen. If you create an iPhone app then the same piece of content compiled with Flash Professional CS5 will also run on Android, Blackberry and Symbian. That said, you will still need to invest time and effort to make the user experience compliant with the users expectations.
The user experience is reliant on the capabilities of the developer, the device, and the amount of money spent to achieve relevant reach. Nothing in this business model is new, not even for the desktop developer.
So what should Adobe be doing instead?
In its scuffles with Apple to get Flash on the iPhone, Adobe has already stumbled onto the strategy that it should be following for mobile devices: focus on tooling and Just-In-Time (JIT) compilation to native applications.
In the upcoming CS5 Suite, you will be able to use Flash CS5 to create native iPhone applications. In other words, Flash developers will be able to reuse their existing skills to build native applications for the iPhone. Native applications that will be optimized for the iPhone and, hopefully, indistinguishable in terms of device-specific support and performance from native applications compiled using Apple’s own tools.
This should have been an a-ha moment for Adobe. And I did hope that it would usher in a new era of focus on Adobe’s core business (tooling). Unfortunately, that doesn’t seem to be case, if this short Twitter conversation with Ted is any indication:
I respect Ted greatly but what he (and Adobe) are missing here is that FPS (the frame rate an application can achieve) is just one tiny variable that affects the user experience of applications on mobile devices. How well are native features like location, multi-touch, local storage, etc., supported? A virtual machine is always going to be a couple of steps behind native applications in terms of device-specific support. It’s a losing game. The focus is wrong.
The majority of Adobe’s revenue comes from sales of its Creative Suite products. As such, it should be keeping its eye on the ball and adding value to the CS products as much as it can by making them the premiere toolset for creating mobile content. Getting Flash application support on handsets is not a requirement for this. Instead, Adobe should drop the huge amount of time, effort, and money that it is currently expanding on this and instead focus on enabling Flash developers to make native applications for the top mobile handsets.
Adobe’s next move should be to support native application creation on Android phones like the HTC Hero and Motorola Droid and maybe even adding support to Dreamweaver for building native Palm WebOS applications.
Markd: Aral’s point here is correct, FPS is not a deciding factor on the success of any platform. When you put Ted’s comments back in context he is merely addressing a concern that iPhone applications packaged with Flash Pro CS5 will be slower than native applications. This is absolutely true, even with huge efforts it will always be possible to create faster applications using native code. Again, this is true of all platforms and you have to weigh up your skills and requirements. Is it going to be easier to port your Obj-C game to Android than a highly optimized Flash game? NO.
The core of Adobe’s business is indeed to sell tools, but those tools are successful because of the consistent and expressive platform that they support. Creating a multitude of wildly varying toolchains and workflows for multiple platforms is not only expensive, but a red carpet for fragmentation.
We will not see another cross-compiler/Packager for other platforms, it simply isn’t required where Flash Player 10.1 and it’s nano-JIT are available.
As with most platforms the mobile space is changing all the time, for this reason we build frameworks and today that’s called FLEX. In the future you can expect to see a more rational development workflow for mobile and devices, that not only uses Flex, but shapes it into a more optimized and expressive product in time.
Aral is right to ask questions, and frankly one of a small few who have fully considered the pitfalls. In my role it’s a little alarming that everyone has been so quiet about all of these changes! So in many ways I’m glad to finally discuss some of the concerns and wishes for the future.
We are of course in a transition period and as you’d expect mistakes will be made, courses will be corrected and we’ll all learn together. There should be no doubt however that we are on the right track to make this a success together. Even with our Open Screen Project partners, and with the best tools in the business we do need you all to play your part.
In the next couple of years we’ll all be created new experiences for mobile devices, televisions, set-top boxes and netbooks. Our request is that you get to grips with these new platforms, and the new customer base now so that we’re collectively ready for the future of the platform.
Next year is going to be very very interesting, it’s time to get started.
What can you build with Flash on Mobile Devices?
Posted by Mark Doherty in Devices, Flash Lite, Mobile Content on October 1, 2009
Dale has done a stunning job of rounding up the possibilities for Flash applications and content on devices. In summary he covers the Standalone, Browser and Personalization use cases providing examples of various applications. Rather embarrassingly I think I’ve only seen about 30% of these, so hopefully you’ll be able to get inspired by some of this great work..
Here are some samples.. and note the ridiculous hassle to build a video like this. You can see the video series here.




Flash Development with Android SDK 1.5 Part 2
Posted by Mark Doherty in Android, Devices, Flash Lite, Flash Player, Mobile Content on August 12, 2009
As we already know by now the HTC Hero supports Flash in the browser, and by double tapping on Flash content it will be played in full screen mode. In fact I believe that’s also the reason why we cannot use the Flash Player directly with Intents.

Those of you familiar with Nokia’s WebRuntime or the iPhone UIWebView will recognize WebView, because it’s the same thing. Really it’s an implementation of the browser framework made available as a UI component. Some of these implementations come with hooks into the platform code through JScript, and enable the use of device APIs like Location.
So what can we do with the Android browser? Let’s look at the pieces provided by Android:
- WebView – Used to load and display web pages using the built-in device browser and chrome, embedded into your application.
- WebViewClient – Enables the handling of various browser actions like page loading and error handling. Overrides the Activity in the built in browser.
- WebChromeClient – Enables the replacement of the browser chrome for events like progress, alerts and for window controls. Can override the default Chrome.
Step 1: Launch the built-in browser using WebView
The code to do this couldn’t be simpler, but there are a few extra changes to make with the layout declarative XML and with the AndroidManifest.xml. Android supports the ability to lay out the application using standard components, much like Flex.
To add a WebView to our layout we must add the WebView node to the main.xml (in project/assets/layout). You can see the id property of the node looking rather special, and that’s because it’s indicating a binding.. again, just like Flex. We can use this resource, and any others later in our code using the builtin R class.
Now we’ve done that we have to add a new permission to the Android Manifest.xml. You’ll notice that the XML includes a number of nodes pertaining to my application, most of it is easy to understand. Note also that my application has it’s own Intent and an Activity called StubApp.
With that we only need to add a tiny piece of code to use the webview component, check it out.
As before we overload the onCreate method, call the parent for good measure and then get to business. We call setContentView to build the WebView using our layout XML file above and then get a reference to this view, set JScript to enabled and load a URL. It really couldn’t be simpler and as before this runs on the device, however there are issues.
Clicking links in WebView above causes the loss of client control over the page. The result is that Flash works, but we cannot control the user experience.
The next step was to attempt to bring the control over loading new pages within the webview instance. To do this we need to extend the WebViewClient class and override the shouldOverrideUrlLoading method, this gives us the opportunity to load the page ourselves; before the browser gets to it.
It looks like this and note that return true after view.loadUrl(url) means don’t bubble this event to other web views:
The result of this is work is that we can simply replace the currently loaded page without launching a new activity, but it comes with a penalty. As when I implemented the custom WebViewClient it became clear that the Flash plugin was not being loaded. Worse still, there’s no way to load it (despite APIs to the contrary) and that’s by design at this time.
So there you have it, the investigation into creating a Flash Application that lives in the browser can only succeed when using the native browser. The Android Platform allows for the creation of custom browser clients and chrome, but the penalty for this is that you loose access to plugins.
Hopefully this has been an informative post, and maybe inspired you to have a look at Android with Flash Player support. Maybe you can extend my examples, or by all means provide some secret code that can help us start up the plugins


Recent Comments