Tag Archives: adobe

Adobe AIR 2.6, MonoMac 1.0, cross-platform is not dead yet

It is a busy time for cross-platform toolkits. Adobe has released AIR 2.6, and reading the list of what’s new you would think it was mainly for mobile, since the notes focus on new features for Apple iOS, though AIR is also a runtime for Windows, Linux and desktop Mac. New features for iOS include GPU rendering – a form of hardware accelerated graphics – access to the camera, microphone, and camera roll, and embedded Webkit for apps that use web content. On Google Android, you can now debug on devices connected via USB.

There is also a new feature called “owned native windows” which lets you have a group of windows that remain together in the Z order – this lets you have things like floating toolbars without odd results where toolbars get hidden underneath other applications.

Asynchronous decoding of bitmaps is another new feature, allowing images to be processed in the background. This seems like a stopgap solution to overcome the lack of mullti-threading in AIR, but useful nonetheless.

Since the Flash runtime does not run on iOS, Adobe has a packager that compiles an AIR application into a native app. This is now called the AIR Developer Tool or ADT. You can use the ADT to target Windows, Linux or Android as well; however platforms other than iOS still need the AIR runtime installed.

Adobe is dropping support for the original iPhone and the iPhone 3G. iPhone 3GS or higher is needed.

If you want to build a cross-platform app but prefer .NET to Adobe’s Flash and ActionScript, the Mono folk have what you need. I’d guess that the Mono team has a small fraction of the resources of Adobe; but nevertheless it has delivered MonoTouch for iOS and is working on MonoDroid for Android. Just completed in its 1.0 version is MonoMac, for building Cocoa applications on Apple OSX. Mono is not fully cross-platform, since the GUI framework is different on the various platforms, but you do get to use C# throughout.

I am happy to agree that true native code is usually a better solution for any one platform; but at a time when the number of viable platforms is increasing the attraction of cross-platform has never been greater.

Adobe Document Center shutting down, protected documents to become unreadable

The what? Well, few people used it which is why it is shutting down; but the Adobe Document Center is a service for protecting documents, somewhat similar to Microsoft’s Rights Management Services except that it is provided as a hosted subscription service; though I am not sure that it ever made it out of beta and actually started charging. You can use it with a PDF or Microsoft Office document to restrict who can access it and set an expiry date.

At least, you could. I have received an email (because I must have tried the beta back in 2006) informing me that the service is shutting down on April 2nd 2011:

Important: This means that after the Service shuts down you, or anyone you have distributed documents protected via the Service, will no longer be able to open/access these documents. We strongly encourage you to use Adobe Acrobat to un-protect these documents before the Service is shut down.

Time to make a mental note: protected documents are high-maintenance and there is always a risk of losing your data.

Adobe targets Apple iPhone and iPad browsers with tool to convert Flash projects

Adobe has released an “experimental technology” codenamed Wallaby on its Adobe Labs site. Not all Adobe Labs projects become fully released products, but it is an indication of serious interest. The experiment was first previewed at the Adobe Max conference last year.

Wallaby is an Adobe AIR application for Windows and Mac. The tool is simplicity itself: just select a .FLA file and convert it.

image

.FLA is the format of Flash projects, not Flash output. gauges

According to Adobe’s John Nack Wallaby has limited goals, focused on “converting typical banner ads to HTML5.” It is aimed at WebKit-based browsers, the implication being that Adobe’s main intent is to enable Flash ads to work on Apple’s iPhone and iPad, though it also works on Google Chrome and Apple Safari on the desktop. There is no ActionScript conversion, though you can edit the exported project after conversion and add your own scripting.

ActionScript is based on JavaScript so a conversion tool should not be too hard.

Other Flash features not supported include video, sound, 3D transforms, Filters, Inverse Kinematics, and gradient strokes

The fascinating aspect of Wallaby is in its potential. Users do not care whether a web site or application uses Flash or HTML5; they just want it to work. Adobe’s primary strength is in its design tools. One possible scenario is that Adobe might gradually extend its HTML5 support so that the tools are applicable for both platforms; Flash could become a workaround technology for legacy browsers.

No doubt Adobe would rather see the Flash runtime used everywhere but at least the company has a plan B. If, for example, Apple comes to dominate personal and mobile computing and continues to block Flash wherever it can, then that is important. Adobe already has a Flash to iOS packager for apps; now it has the beginnings of a solution for in-browser Flash on iOS as well.

Update: revised post with more detail about what is not supported.

Computer book stats show resilience of Java as Android booms

Mike Hendrickson at O’Reilly has posted four articles analysing the state of the computer book market in more detail than most of us care about.  The overall picture is not too good – sales are down – and there are some interesting trends.

Here is a good one for anyone who thinks Java is dying. The programming languages post shows that unit sales of books on Java increased by 17.2% in 2010 vs 2009, whereas the next most popular language, C#, declined by 1.7%. Objective C, in third place, also declined slightly. JavaScript unit sales were up by 14.5%.

Why is Java booming? There is a clue in one of the two bestselling Java titles mentioned by Hendrickson: Professional Android 2 Application Development

Another trend that caught my eye is in the first post. Some of the Down categories surprised me:

Adobe Flash –84.43%

Mac OS –32.12%

Web Design Tools –53.2%

Adobe’s Creative Suite 5 has sold well as far as I’m aware so although books on Flash and Dreamweaver have not been selling well, it is dangerous to draw obvious conclusions.

The influence of Android is unmistakeable though. Something for Oracle to consider as it pursues Google for breach of intellectual property.

Adobe AIR is user-hostile compared to native apps says BankSimple CTO

Alex Payne, CTO at BankSimple, has written an analysis of Adobe AIR from the user’s perspective. The scenario: his team was looking for a an alternative to Campfire for group chat, and selected HipChat. They liked the features of HipChat, but not the desktop app, which is built using Adobe AIR:

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

Payne investigated further and came to the conclusion that users prefer native apps; and that cross-platform toolkits are for the benefit of software companies not users. Echoes of Steve Jobs’ Thoughts on Flash:

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps.

And lest you think this is bad for AIR but good for Java, note that Payne adds:

For anyone who used a computer in the 1990s, AIR probably brings back scarring memories of Java apps: slow, ugly, inconsistent, awkward.

I was also reminded of Evernote’s experience with .NET versus native code, which I blogged here.

Payne is not all wrong, neither is Jobs. That said, the distinction between what is good for users and what is good for developers is not absolute. Maintaining a single cross-platform code-base, for example, is good for both users and developers, because it reduces bugs and assists feature-compatibility across platforms. It is also good for users of minority platforms who might otherwise have nothing.

Another question: how many of the issues Payne identifies are inherent to using AIR (or another cross-platform runtime), and how many are implementation issues? It is impossible to know without drilling into the details; but I don’t believe that all AIR (or Java, or .NET) apps have “lousy performance”.

It is true that ActionScript code is slower than Java or .NET code, and much slower than compiled C/C++, but speed of script execution is not always the performance bottleneck that users will notice most.

This is seemingly one of those never-ending computing debates; but a post like Payne’s is a reminder that neither Adobe AIR, nor any cross-platform runtime, is a perfect solution to the challenge of multiple client platforms.

Google, Adobe Flash, and H.264 video

On signing into Google Docs today I saw the following:

image

I clicked Learn more and was directed to this article. The files you can upload and play:

  • WebM files (Vp8 video codec and Vorbis Audio codec)
  • .MPEG4, 3GPP and MOV files – (h264 and mpeg4 video codecs and AAC audio codec)
  • .AVI (many cameras use this format – typically the video codec is MJPEG and audio is PCM)
  • .MPEGPS (MPEG2 video codec and MP2 audio)
  • .WMV
  • .FLV (Adobe – FLV1 video codec, MP3 audio)

And how do you play a video?

Simply click a video file that you’ve uploaded to your Documents List and the video opens in a new page that includes a video player. You will need to have Flash installed for the video player to work.

At the same time, Google says it is removing H.264 support from its Chrome browser:

Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

How do we make sense of this? The implication is that Google is not in fact bothered about H.264, but rather wants to promote Flash for video instead of the HTML 5 <video> element. That is a problem for Apple iOS users who cannot run Flash, and puzzling insofar as you would expect Google to be promoting rather than discouraging HTML 5 adoption.

Possibly the real target is Apple. Flash has become a key selling point for non-Apple mobile devices. By making more use of Flash, Google can make the web more annoying for iOS users and thereby promote Android.

As John Gruber observes, Google has some questions to answer.

Update: Google’s Mike Jazayeri has posted some more background on the decision here.

Google flexes its Chrome browser muscles, removes support for H.264 video – but what about Adobe Flash?

Google has announced that it will remove support for the H.264 video codec in its Chrome browser:

…we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

The reason given is that Google wishes to support open standards. That sounds good for open standards, but not so good for users who simply want a video to play.

Google’s position contrasts that of Microsoft with IE9:

In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows

Still, at least IE9 will play VP8 if the codec is installed, so that makes VP8 look a better option for content providers – which is the outcome Google is hoping for.

I have mixed feelings about this approach, because while it is good for open standards it is bad for compatibility. I am also not sure that it is consistent. Google announced in June that it is integrating Adobe Flash support into the browser; yet Flash is not an open standard.

That also suggests that H.264 video will still play in Chrome, provided it is in a Flash wrapper.

Maybe Google is learning from Apple how to deprecate technologies by removing support. Apple refuses to allow Java or Flash on iOS, and has stopped doing its own build of Java for OS X. Apple has also stated that these “optional” components may not be used in apps that are deployed in the Mac App Store, thus making a disincentive for developers considering those runtimes.

Apple has not squashed Flash though; and Google may find it equally hard to squash H.264, which is widely supported throughout the industry, has the best tools, and for which hardware is optimised. Apple supports H.264 but is unlikely to support WebM or Theora any time soon. Here’s what Apple CEO Steve Jobs said in April 2010:

To achieve long battery life when playing video, mobile devices must decode the video in hardware; decoding it in software uses too much power. Many of the chips used in modern mobile devices contain a decoder called H.264 – an industry standard that is used in every Blu-ray DVD player and has been adopted by Apple, Google (YouTube), Vimeo, Netflix and many other companies.

Although Flash has recently added support for H.264, the video on almost all Flash websites currently requires an older generation decoder that is not implemented in mobile chips and must be run in software. The difference is striking: on an iPhone, for example, H.264 videos play for up to 10 hours, while videos decoded in software play for less than 5 hours before the battery is fully drained.

When websites re-encode their videos using H.264, they can offer them without using Flash at all. They play perfectly in browsers like Apple’s Safari and Google’s Chrome without any plugins whatsoever, and look great on iPhones, iPods and iPads.

It seems Jobs spoke too soon when he said H.264 would play perfectly in Chrome.

Post updated to add Apple quote

What next for application help and documentation? First thoughts on Adobe’s Technical Communication Suite 3

Adobe has launched Technical Communication Suite 3, which bundles FrameMaker 10, RoboHelp 9, Captivate 5, Photoshop CS5 and Acrobat X. FrameMaker and RoboHelp are Windows-only, so the suite is the same.

I had a brief briefing on the product today, which by coincidence came after my bad experience with SharePoint Designer and its help system. Please note: I do not hold Adobe responsible for the shortcomings of Microsoft’s online help, but it helped me to put the subject into context. I was trying to figure out how to get SharePoint to display file extensions in document lists. The supplied help looks pretty:

image

but I found it disappointing. I wanted to know, for example, what are the implications of converting a web part to XSLT, which is on one of the designer context menus:

image

Same story when I wanted to know what the @LinkFileName formula was meant to return. And when I looked for a SharePoint formula reference I got one useless result, an article on creating a workflow initiation form.

What we all do in these situations is to hit Google. The snag: whereas the little online help (which is also meant to search Office online) had high authority but no results, Google has the opposite problem: many results but little authority. I did eventually find the formula reference I wanted but finding correct information on the web as a whole is a matter of luck and judgment.

I found it interesting therefore to talk to Adobe about its Technical Communication Suite. How is online help changing? Do we even need it, when people hit Google rather than F1? Maybe it is better just to make sure your help articles and reference are easy to find on the web, rather than packaging them up and calling it a help document? In which case, we should be thinking in terms of a content management system, rather than online help as such.

The answer I guess is “all of these”. The key concept in Adobe Technical Communication Suite is “single-source authoring”, and you can use the same content for web pages as well as for print and traditional packaged online help.

It is still a bit old-school for my taste. For example, you can now include External content search in RoboHelp documents; but this only lets you add external URLS to the document along with search keywords. It does not let you search external content, but restricted to specified web sites, which would be a nice feature.

That said, if you use RoboHelp Server 9 – not included with the suite itself – in conjunction with an Adobe AIR help client, you can get user topic rating and commenting, so there is some concession to user-generated content.

There are also plenty of scenarios where you do still need a blow-by-blow documentation and reference for an application. In fact, if the SharePoint help mentioned above had provided this, I would have been happy.

This is not a review of the Technical Communication Suite, though I hope to get a look at the actual product shortly. In the meantime, a few points of interest. FrameMaker has considerable feature overlap with InDesign; but Adobe says there is still a place for a desktop publishing tool aimed at long technical documents with strong support for structured documents, cross-references and indexes. RoboHelp now supports collobaration workflows using Acrobat.com and PDF review. There is also new support for ePub, the eBook format for everything but Amazon Kindle, in FrameMaker and Kindle. I asked about Kindle support; the Adobe spokesperson was sniffy about Amazon’s proprietary MOBI format but said it might be added eventually if Amazon do not add ePub compatibility to the Kindle.

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?

NVIDIA Tegra 2: amazing mobile power that hints at the future of client computing

Smartphone power has made another jump forward with the announcement at CES in Las Vegas of new devices built on NVIDIA’s new Tegra 2 package – a System on a Chip (SoC) that includes dual-core CPU, GPU, and additional support for HD video encoding and decoding, audio, imaging, USB, PCIe and more:

image

The CPU is the ARM Cortex-A9 which has a RISC (Reduced Instruction Set Computer) architecture and a 32-bit instruction set. It also supports the Thumb-2 instruction set which is actually 16-bit. How is 16-bit an upgrade over 32-bit? Well, 16-bit instructions means smaller code, even though it gets translated to 32-bit instructions at runtime:

For performance optimised code Thumb-2 technology uses 31 percent less memory to reduce system cost, while providing up to 38 percent higher performance than existing high density code, which can be used to prolong battery-life or to enrich the product feature set.

The GPU is an “ultra low power” (ULP) 8-core GeForce. In essence, the package aims for high performance with low power consumption, exactly what is wanted for mobile computing.

Power is also saved by sophisticated power management features. The package uses a combination of suspending parts of the system, gating the clock speed, screen management, and dynamically adjusting voltage and frequency, in order to save power. The result is a system which NVIDIA claims is 25-50 times more efficient than a typical PC.

According to NVIDIA, Tegra 2 enables web browsing up to two times faster than competitors such as the Qualcomm Snapdragon 8250 or Texas Instruments OMAP 3630 – though of course these companies also have new SoCs in preparation.

Tegra 2 is optimised for some specific software. One is the OpenGL graphics API. “The job of the GPU is to implement the logical pipeline defined by OpenGL”, I was told at an NVIDIA briefing.

image

I asked whether this meant that Tegra 2 is sub-optimal for Microsoft’s Direct X API; but NVIDIA says it is sufficiently similar that it makes no difference.

Nevertheless, Tegra 2 has been designed with Android in mind, not Windows. There are a couple of reasons for this. The main one is that Android has all the momentum in the market; but apart from that, Microsoft partnered with Qualcomm for Windows Phone 7, which runs on Snapdragon, shutting out NVIDIA at the initial launch. NVIDIA is a long-term Microsoft partner and the shift from Windows Mobile to Android has apparently cost NVIDIA a lot of time. The shift took place around 18 months ago, when NVIDIA saw how the market was moving. That shift “cost us a year to a year and a half of products to market”, I was told – a delay which must include changes at every level from hardware optimisation, to designing the kind of package that suits the devices Android vendors want to build, to building up knowledge of Android in order to market effectively to hardware vendors.

Despite this focus, Microsoft demonstrated Windows 8 running on Tegra during Steve Ballmer’s keynote, so this should not be taken to mean that Windows or Windows CE will not run. I still found it interesting to hear this example of how deeply the industry has moved away from Microsoft’s mobile platform.

Microsoft should worry. NVIDIA foresees that “all of your computing needs are ultimately going to be surfaced through your mobile device”. Tegra 2 is a step along the way, since HDMI support is built-in, enabling high resolution displays. If you want to do desktop computing, you sit down at your desk, pop your mobile into a dock, and get on with your work or play using a large screen and a keyboard. It seems plausible to me.

During the press conference at CES we were shown an example of simultaneous rich graphic gaming on PC, PlayStation 3, and Tegra 2 Smartphone.

image

Alongside Android, Tegra 2 is optimised for Adobe Flash. NVIDIA has been given full access to the source of the Flash player in order to deliver hardware acceleration.

image

image

Actual devices

What about actual devices? Two that were shown at CES are the LG Optimus 2X:

image

and the Motorola Atrix 4G:

image

Both sport impressive specifications; though the Guardian’s Charles Arthur, who attended a briefing on the Atrix 4G, expresses some scepticism about whether HD video (which needs a large display) and the full desktop version of FireFox are really necessary on a phone. Apparently the claimed battery life is only 8 hours; some of us might be willing to sacrifice a degree of that capability for a longer battery life.

Still, while some manufacturers will get the balance between cost, features, size and battery life wrong, history tells that we will find good ways to use these all this new processing and graphics power, especially if we can get to the point where such a device, combined with cloud computing and a desktop dock, becomes the only client most of us need.

NVIDIA says that over 50 Android/Tegra 2 products are set to be released by mid-2011, in tablet as well as Smartphone form factors. I’m guessing that at least some of these will be winners.