Results tagged “flash” from ITJOBLOG

I've been reading a new survey of mobile developers from VisionMobile. Around 400 developers were surveyed, and the platforms covered were iPhone, Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash, and the mobile Web.

The topic is significant. Companies everywhere are crying out for mobile apps, especially for Apple iPhone but increasingly for Google Android as well. The device+cloud computing model is today's big trend, and support for mobile devices in some form or other is becoming necessary for a wide range of applications and web sites.

The first notable fact is the extent to which iPhone and Android dominate. This chart on page 10 tells the story: there is little relationship between the device installed base and the number of available apps. Windows Phone, for example, has 75 million devices out there but only 13,500 apps; iPhone has 60 million devices and 225,000 apps.

blog-fig-1.png
 
The reason is that Apple has created a viable ecosystem for development, as well as a superb mobile platform. Much as I dislike the locked-down nature of that platform, and its Apple tax, I acknowledge and admire what has been achieved.

Android has just 20 million devices but 72,000 apps. I'd guess that the quality of those apps is not as high on average, but it's still clear that iPhone now has competition.

If this paper is to be believed, Android will even pass iPhone. Android is identified as the most popular among developers, with around 60% using it versus 50% on iPhone. Why?

We believe that Android's lead in developer mindshare ahead of Apple's iOS is down to two factors: first the $99 fee developers have to pay in order to deploy their applications, an entry barrier which reduces the innovation from developing countries. Secondly, the very effective use of open source licensing as a marketing technique to attract developers to Google's Android.

Another factor is that Android apparently offers the best developer experience. In an appendix, the survey tests iOS, Android, Symbian and Java ME for coding, debugging, device emulation and support resources. Novices could create a simple app more quickly on Android. The coding effort was less; building 9 simple apps took nearly 3000 lines of code on Symbian, versus just under 1500 lines on iPhone and a little over 1000 lines on Android. Debugging is faster on Android. The survey comes up with the following claim:

Using the above data, we can say that when developing common applications, each hour of work for a given Android developer, irrespective of level of experience, equals 1 hour and 10 minutes for a Symbian developer, 1 hour and 20 minutes for a Java ME developer and approximately 1 hour and 30 minutes for an iPhone developer.

Contentious, no doubt, and a lot will depend on what sort of app is being developed. Still, a good result for Android.

Both iPhone and Android seem safe bets, but what about other platforms? Adobe Flash is an interesting one:

Our research further indicates that Flash developer mindshare seems to be in decline, despite Flash's installed handset base of more than 1.3B devices. Adobe's string of execution failures has meant that the installed base for Flash Lite is extremely fragmented, breaking the write-once-show-anywhere story for media brands who are Adobe's key customers. At the same time, Flash, the much-touted replacement for Flash Lite, was more than 18 months late, while Flash Lite shipments have stagnated, dropping from 43 percent to 15 percent of handsets sold from 1H09 to 2H09. This leaves Adobe with a rapidly shrinking window of opportunity, primarily on Android handsets, while having been banned from Apple's growing empire, and slowly seeing the adoption of HTML5, yet another replacement threat for Flash.

That's overly negative in my view. In favour of Flash is that it runs on the Web and desktop as well as on mobile, and will run across a number of mobile platforms. Even so, the research shows the pressure on Adobe to deliver mobile Flash, which will not be in the hands of the public until Android 1.2 "froyo" is availble on devices; and the Apple problem will not go away.

Symbian is in trouble too; in fact, since Nokia is now moving to MeeGo for smartphones, it now has little interest for developers. Some observers think Nokia should go to Android instead.

Java ME? Windows?

The vast majority of Java ME respondents have lost faith in the write-once-runanywhere vision. Moreover, anecdotal developer testimonials suggest that half of Windows Phone MVP developers (valued for their commitment to the platform) carry an iPhone, and would think twice before re-investing in Windows Phone.

That strikes me as accurate. Predicting the future is hard though. Google Android came from nowhere; it is possible that a couple of years from now different patterns will have emerged.

For now though, it's iPhone and Android all the way.

The iPad has just launched in the UK, queues are long, stock is short, and it is yet another successful new product from Apple. The iPad has frustrations, like no Adobe Flash support for web browsing, no Java, no printing, and the general sense that you do things the Apple way or not at all. Still, users love it and are willing to pay for it, and in the end that is what matters.

Does this shiny gadget have any relevance to the more humdrum world of business IT? I think it does, especially when taken together with other factors. Here's a remark from Apple CEO Steve Jobs from an informal email conversation with Ryan Tate:

The times they are a changin', and some traditional PC folks feel like their world is slipping away. It is.

Yes, it's a Bob Dylan reference; read the entire thread to see why. Jobs is marketing his company's stuff, of course, but a few days later the stock market put some solid evidence behind his claim. Apple's market capitalisation surpassed that of Microsoft for the first time since 1989. Microsoft remains more profitable; but the figures reflect the market's judgment that Apple has better prospects for growth.

Another sign of change comes from one of Microsoft's most important partners, HP. At the end of April it acquired Palm, and with it the WebOS operating system for mobile devices. Whether HP can make a success of WebOS is uncertain; it will not be easy going up against Apple and Google Android. What is more significant is the implication that HP has finally lost faith in Microsoft's ability to get it right in mobile.

Despite some positive buzz around Windows Phone 7, Microsoft did not help its case when it announced a major reshuffle in its Entertainment and Devices division on May 25th. This follows the bewildering launch of the Kin phone - bewildering because it seems right out on its own in terms of strategy - complete with typical Microsoft flaws according to this thoughtful review:

But the obtuseness of this user experience doesn't stop with the Spot -- it permeates the entire interface as though decisions about how things should work were made almost arbitrarily, without anyone stopping to test them in the real world. The Twitter implementation is a great example of that. You can add your Twitter account to the phone and see updates from people you follow, and you can update your status from the top of the Loop... but that's all you can do. You can't retweet something, you can't send a direct message, you can't go to single person's feed to see all their updates, and you can't even open a link in a Twitter message from the Loop!

Windows Phone 7 will have to be much, much better if Microsoft is to claw back any ground in mobile.

I digress. All that matters is that the world is changing, and looking less Microsoft-shaped with each passing day.

In saying that, I don't mean to diminish the excellent work which I see coming out of some parts of Microsoft - Visual Studio 2010, for example - or to ignore the continuing dominance of the company in many areas of business IT. Many companies still standardise on Windows, and Microsoft Office remains the only productivity suite I come across in work.

All true, but the two great IT trends of today are not centred on Windows and Office. One is mobile, the other is cloud computing; and of course there is synergy between them. Apple's iPad is a further advance for mobile, and will drive increasing mobile data usage and increasing demand both for iPad/iPhone applications and for web applications that work well on those devices.

 

 

 

Mobile devices are today's development battleground. Timing is everything: I recall Borland's 2003 conference when it introduced an extensive mobile development strategy based on the ill-fated C++ BuilderX, with SDKs from Nokia and Symbian. The sessions drew sparse attendance and Borland later abandoned the product, returning to the Windows-oriented C++ Builder.

So what changed? In part, devices have become more powerful and mobile internet access faster and more pervasive, making the platform more attractive. A bigger factor though is Apple's iPhone. In hindsight, the mobile vendors and operators made mobile development too difficult, with fragmented platforms and locked-down devices. Microsoft has had some success extending Windows to mobile devices, for enterprise development in either C++ or .NET, but its market share is too small, the devices insufficiently well liked, and the deployment obstacles too great. Java had some success too, but write-once, run anywhere never really worked for mobile.

Enter iPhone, with a single platform and easy deployment through the App Store. The "easy deployment" part has to be qualified, since developers have been confronted with limited access to the device, restrictions on what they can develop, and an opaque approval process; but it has worked, and the potential of the mobile platform - about which we have known for years - is now being unlocked.

Other vendors are belatedly rising to the challenge. I'm just back from Nokia's Qt Developer Days, and saw the energy the company is putting into creating a cross-platform, open source mobile development framework. Windows Mobile, Maemo and Symbian are on the immediate roadmap. On the deployment side, Nokia has the Ovi store. I've also been at Adobe's MAX in Los Angeles, where broad mobile support for the Flash runtime was the big story. The Flash runtime is not coming to iPhone yet, but Adobe has a native compiler for Flash applications which targets iPhone. Adobe also has app store plans. Google Android is another platform where all the pieces are in place, and Palm Web OS a new hopeful on the scene.

This means developers now have numerous choices for mobile development, as well as more pressure to create or extend applications to embrace mobile clients. It is not an easy choice. An AJAX application will work on the iPhone and elsewhere, but there is no offline support or access to device features, and the capabilities of mobile browsers vary greatly - though Webkit is becoming a standard on non-Windows devices. Native iPhone works great on Apple's device, but nowhere else. Flash is becoming interesting, but devices with 10.1 will not be around until next year and it is an unproven platform in a mobile context. Windows Mobile will trudge on, though Microsoft's mobile story seems particularly incoherent at present and I expect declining market share. Java on mobile has not gone away either; and Google Android is pretty much a Java platform. C++ will always be attractive for lean, fast applications.

It is fun to pick winners and losers, but impossible to tell how all this will shake out. Here's two safe bets. The first is that mobile, internet-connected applications are in many ways the future of the client. The second is that focusing on a strong web services API (of whatever flavour) is the right place to start. What's your mobile strategy?

Recently I have been working with Microsoft Silverlight, looking at how to put together a simple database application. I am no designer; my interest in Silverlight is to do with cross-platform deployment, a consistent runtime, and an alternative to HTML and Javascript. It seems I am not alone in this respect; the Silverlight forums are dominated by programming rather than design queries. Here are the message counts at the time of writing:

  • Programming with .NET: 61,022
  • Designing with Silverlight: 4,912

The Silverlight 3 wish list is also illuminating. You soon get a feel for what developers are most frustrated about, such as: no printing support, no easy way to save documents to the user's hard drive, ugly fonts, no clipboard support, no access to devices like web cams and microphones, and no support for WSHttpBinding which adds transactions and reliable messaging to web services.

Only a few of these things are fixed in the Silverlight 3.0 beta. There is a file save dialog, and text rendering is improved though Microsoft is a long way behind Adobe Flash in this respect.

That said, Silverlight 3 does offer substantial improvements for business applications. For example, in Silverlight 2.0 you have to handle client-side validation manually, whereas Silverlight 3.0 adds validation support similar to what is in ASP.NET. There is also a new server-side piece called .NET RIA Services, which wraps key areas like authentication and transactions. Although Silverlight cannot do real transactions, .NET RIA Services introduces changesets, which let you bundle a set of database updates into a single web service call. You can also include arbitrary custom operations, such as approving a purchase order. On the server side, where you do have transaction support, this is processed and can succeed or fail as an entire unit.

Despite the snags, there is a lot to like in Silverlight. As a GUI framework it works really well, and it is good to know that special effects and transitions are available are available if you need them. Microsoft appears to have executed well on the challenge of creating a smaller, cross-platform build of the .NET Framework, which is really Silverlight's key advantage.

Another plus is the ability to work in Visual Studio with the server and client projects side by side, integrated for debugging. You can set a breakpoint in the Silverlight client, and another in the ASP.NET web service implementation, and it just works.

Presuming that Microsoft's continues its rapid pace of Silverlight development, my guess it that it will evolve into an excellent client for .NET applications, since this is what the community is demanding. As yet though, Silverlight has made little impact on the wider world of web design, which remains dominated by Flash, and it is hard to see that changing.

silverlight-app-small.jpg

I'm at Microsoft's Mix09 conference in Las Vegas, where the big news (aside from small matters like the final release of Internet Explorer 8) is the beta release of Silverlight 3.0, Microsoft's browser plug-in that competes with Flash as a platform for rich internet applications.

Silverlight 3.0 is stuffed with new features, one of which is the ability to run outside the browser. Right-click an applet, choose Install onto this computer, and suddenly you have a desktop application complete with a shortcut in the Start menu, or on the Mac desktop. This has triggered a debate over how SLOOB (that's Silverlight Out Of Browser) compares to Adobe's existing AIR (Adobe Integrated Runtime), which supports Flash applications running on the desktop.

Understandably, Adobe folk like Ryan Stewart are emphasising the differences:

"I think AIR and the Silverlight OOB (Out of Browser) are two very different technologies for two very different scenarios...AIR is about letting you take your web application skills to build desktop applications and Silverlight OOB is more about letting you take your Silverlight applications to the desktop. The different models will be different for everyone, but right now AIR gives you a lot more flexibility and more API hooks into the operating system."

The big issue is how much these desktop/web hybrids interact with the local machine. Microsoft makes a point of how SLOOBs run in the same sandbox as they would in the browser, which means the user can install without a security prompt, but also that the application has very access to the user's desktop. The only access to the file system is to a protected area called isolated storage, or via a file dialog that the user controls. Microsoft says there might (or might not) be a way of displaying notifications but that is about it.

AIR applications by contrast run with the same permissions as the user. Installation involves the user consenting to a dialog which usually threatens unrestricted access to the system. Your AIR app can read and write any files that the user can read or write. There is also a notification API, and support for drag-and-drop.

That said, AIR applications are also restricted by design. They cannot be extended with native code, or execute other applications. Adobe has always presented AIR as a way of delivering web applications on the desktop, rather than as an alternative to C++ or .NET for traditional desktop applications. So is it really so different from SLOOB?

Well, some of the AIR features do give it an edge. One is the ability to fire notifications (annoying though this can be). It's something that Microsoft definitely intends to add to SLOOBs, though I get a different answer every time I ask about it; it might not come until Silverlight 4.0. Another difference is that AIR can host HTML as well as Flash content, which is an advantage for applications that depend on both. AIR also includes an embedded relational database engine, SQLite, whereas SLOOB developers will have to roll their own or use XML, though I doubt this is really a big deal. One other thing: Silverlight knows nothing about printing, which is unfortunate when running outside the browser.

Nice features; but I still feel that AIR and SLOOB are close competitors. Both take a cross-platform, rich internet application runtime and make it available from a desktop shortcut and with offline support. That makes a huge difference to users, even if the technical differences between running in or outside the browser are not so great. SLOOBs are going to be attractive to .NET developers because they include the .NET runtime and can be developed in the familiar Visual Studio IDE.

Personally I'd like to see an option to run AIR applications sandboxed, as full file access is more than most of them need. I'd also like an option to run SLOOBs with greater local system access when needed. Why not have the best of both worlds?

In the meantime, I'm expecting both to succeed. For applications that will work as a SLOOB, it makes a great user-friendly, cross-platform alternative to Windows Forms; and we've already seen effective user of AIR for cloud-centric utilities like Twitter clients. Both platforms are also highly effective for visualizing data. Who knows, this approach could become the norm for a wide range of business applications.

Last week Sun launched JavaFX, its Java-based platform for Rich Internet Applications. Sun picked up the high level of interest in Adobe's Flash as an application runtime, and perhaps Microsoft's Silverlight as well, and hurriedly developed its own equivalent. JavaFX is a new scripting language that runs on the JVM (Java Virtual Machine) and is optimized for graphical effects and multimedia. It brings to Java animation features like timelines and motion paths, support for a variety of audio and video codecs, and a way of coding a graphical user interface without the supposed complexities of Swing with its Model/View/Controller (MVC) design. JavaFX applets can run within or outside the browser. One innovation is that you can drag an applet out of a web page and onto your desktop. If you close the browser, the applet keeps running, thanks to support for out-of-process plugins in Internet Explorer 7 and Firefox.

So far JavaFX has received a mixed reception, and it is easy to see why. The launch was rushed, and some early visitors to the site had a bad experience, with videos that would not play or samples that did not run. Videos running in JavaFX flash unpleasantly if you resize the browser. The install experience is not as smooth as for Flash or Silverlight in my experience, because you need to install the Java Runtime Environment (JRE) as well as the JavaFX plugin. The download size is larger, although this is disguised by Sun's slimmed-down initial install. The idea is that you get up and running quickly, while the rest of the JRE installs in the background. The SDK does not yet run on Linux or Solaris, although the applets themselves should run because they only require the standard JRE plus a runtime jar (add-on library) and can be executed using Java Web Start. The latest NetBeans has JavaFX support, but another downer is the lack of any dedicated visual design tools. Sun only offers an export add-on for Adobe's Photoshop and Illustrator, or a converter for SVG (Scalable Vector Graphics). There is no 3D API yet, though it is promised.

It is easy to be negative; but some of these problems will disappear as JavaFX matures. A visual design tool is in the works, as is a mobile version that will be shown at the Mobile World conference in February next year. JavaFX will have a place for Java developers who are envious of what Flash and Silverlight can do. While it may not match Flash in terms of broad runtime deployment, I'm guessing that Sun will outpace Microsoft in this respect. JavaFX also has a couple of advantages over Flash, including more sophisticated client-side security and better code performance in some scenarios. The Java VM is mature and well optimized. Adobe's ActionScript virtual machine does have a just-in-time compiler, but seems slower than either Silverlight or Java for code execution. Speed of graphical effects is another matter, and while I have not seen any comparisons yet, I suspect Adobe's long multimedia experience may come into play here.

JavaFX will be welcomed then by Java developers who need more expressive graphics in their applications, and will be an interesting option for those developing games for mobile devices. Try as I might though, I'm finding it hard to believe that this is a huge section of the market, or that Sun will have much success persuading designers to target JavaFX rather than Flash, or that JavaFX will win much market share from Adobe for web-hosted video. Swing works well these days, its MVC architecture has merit, and it is well-suited to the kinds of Enterprise applications which commonly have Java clients. JavaFX is a useful addition to Java, but I doubt that Adobe is losing sleep over its likely impact. That said, I'm keen to hear from developers with plans for JavaFX applications, so don't hesitate to let me know.

Adobe's MAX conference in San Francisco this week was focused on what it calls the "Flash Platform", a technology stack oriented round the Flash multimedia runtime. The "platform" word highlights the fact that you can code for Flash and have your application run everywhere that Flash runs, including Windows, Mac, Linux, and some mobile devices as long as they are not from Apple. It is not a complete platform, being essentially an Internet client, though there are some server-side pieces such as LiveCycle Data Services, to simplify and optimize communication between Flash clients and Java middleware. You can also blur the distinction between browser and desktop with AIR, which runs Flash outside the browser and adds a local database engine.

So what's new? There was the usual set of announcements. The key ones are as follows:

AIR 1.5: an update to the desktop runtime which adds support for Flash Player 10 features such as Pixel Bender, for runtime graphical effects, and an option to encrypt local databases. There is also the SquirrelFish JavaScript interpreter - though this only comes into play if you are running JavaScript within HTML, rendered by WebKit, rather than ActionScript without the Flash runtime, which has its own just-in-time compiler. AIR 1.5 is available now.

A new version of Flex and the Eclipse-based Flex Builder IDE, code-named Gumbo. This has a new skinning and component architecture, more advanced text rendering, easier two-way data binding and a new Client Data Management (CDM) feature which from early descriptions looks reminiscent of a .NET dataset. You work with data on the client, storing updates locally, then zap the updates back across the wire in a single update operation. One thing that is not yet clear to me is the extent to which CDM requires LiveCycle on the server; I'll be sure to clarify this in a couple of weeks at MAX Europe (I was not present at the US event). The database aspect is significant, because so many enterprise applications boil down to CRUD (Create, Retrieve, Update, Delete) in one form or another.

Catalyst, formerly code-named Thermo, was previewed. This is a fascinating product which converts Photoshop artwork into Flex code; it also allows designers to create and preview a degree of interaction in their designs. Catalyst shares the same project format as Flex Builder. Again, I will be taking a closer look at MAX Europe. Here's a preview screen grab:

 

catalyst.jpgCocomo (yet another codename) is a cloud effort from Adobe, focused on conferencing. Adobe hosts the services and provides Flex components to enable file sharing, text and VOIP (Voice over IP) chat, whiteboards, and data messaging; there is also user management built in.

Alchemy is a tool that converts C/C++ code to ActionScript, for execution within the Flash player. It's intended for re-use of existing libraries, not for general development.

Third-party announcements that caught my eye included Ensemble's Flex add-in for Visual Studio (though I was underwhelmed by the preview), and Zend's addition of AMF (Action Message Format) into its PHP Framework. AMF is a binary format that optimizes data transfer between servers and Flash clients.

Although none of these announcements is spectacular in itself, taken together they show the momentum behind Flash as a client for applications as well as video and multimedia, as I have mentioned here before. A good thing? Designers love Flash because of the freedom it gives them, along with the excellence of Adobe's design tools - Creative Suite 4 really is spectacular. Nevertheless, I have a nagging concern that if we adopt Flash rather than AJAX - interactivity in HTML and Javascript - for our next-generation clients, we are giving away the openness of the Web, because Flash is proprietary technology. I recommend this thoughtful post from Google's Brad Neuberg, which recommends not only open-sourcing the Flash runtime, but also integrating it more deeply with the browser and embracing web standards. There's little chance of Adobe adopting Neuberg's proposals, but he does a good job of spelling out the issues. Flash is compelling, as is Microsoft's Silverlight, but each is controlled by a single vendor. Do you think that matters? I'd be interested to hear your opinions.

 

Current Vacancies from CWJobs

(* Required field)










Preferred format