Tag Archives: adobe

Adobe results: 200,000 Creative Cloud subscribers and an impressive transition

Adobe has released its quarterly figures for its third financial quarter 2012. The figures show the success of Creative Cloud, Adobe’s subscription-based model for purchasing the Creative Suite applications, including Photoshop, Illustrator, InDesign, Acrobat and Flash. Total revenue is fractionally up on the same period in 2011, from $1013.2M to $1080.6M.

Adobe reports over 200,000 paid subscribers and 8,000 new subscriptions per week, compared to its projections of only 5,000 per week.

The Creative Cloud model has several advantages for Adobe. First, it gives assurance of a steady continuing income rather than the pain of driving a 2 year upgrade cycle. Second, it forms a platform from which to sell other products and services.

Adobe also says that its publishing platform, the Digital Publishing Suite, now has 1,100 customers distributing on average 125,000 publications daily, mainly to the iPad, with over 40 million delivered to date. This is good business for Adobe since it generally charges a fee per download.

The slight downside for Adobe is that the launch of Creative Suite 6 delivered lower initial revenue than is usual for a new launch, because customers are transitioning to the subscription model. That is not really a downside, but rather a sign that the strategy is working.

What impresses me about Adobe is how well the company has survived the decline of Flash and the relative failure of its efforts in enterprise applications (the digital enterprise segment is now subsumed in the figures into “Digital Marketing”). The segment breakdown for the third quarter looks like this:

$millions

  • Digital Media (Creative Cloud) 769.1 (71%)
  • Digital Marketing (analytics etc) 257.1 (24%)
  • Print and Publishing 54.4 (5%)

Think back a couple of years. Adobe was dependent on sales of shrink-wrap software and had a range of products which pivoted around Flash as the universal runtime and rendering engine. Now it has some claim to being a cloud company – though of course the primary benefit of Creative Cloud is in desktop software applications that you download – and in place of Flash it it betting on HTML5, together with its ability to compile Flash-based content into native applications.

The transition is not so easy for developers who invested in the Flash platform, coding applications in Flex and ActionScript. Adobe has stopped developing Flash for mobile, even on Android and other mobile platforms where it is not blocked. Still, if that has pushed developers into targeting HTML5 earlier than they would otherwise have considered, it may not be a bad thing.

Adobe’s Roy Fielding patches Apache to ignore IE10 Do Not Track privacy request

Adobe’s Roy Fielding, who is also the original author of the W3C’s Tracking Preference Expression draft, has patched Apache, the open source web server, to ignore the Do Not Track header sent by Microsoft’s Internet Explorer 10, the browser in Windows 8:

image

Under the heading “Apache does not tolerate deliberate abuse of open standards,” Fielding’s patch sets Apache to remove the Do Not Track request header if IE10 is the web browser.

Fielding’s argument, one presumes, is that IE10 breaches clause three in the Tracking Preference Expression draft:

Key to that notion of expression is that it must reflect the user’s preference, not the choice of some vendor, institution, or network-imposed mechanism outside the user’s control. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.

However the document goes on to say (highlighting is mine):

We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent’s configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). The user-agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.

Here is what happens in Windows 8 after startup. This is among the first screens you see when installing Windows 8, before you get full access to the operating system:

image

One of the settings specified is “Turn on Do Not Track in Internet Explorer. If you click Learn more about express settings you get this:

image

If you click Customize you get this:

image

Does this respect the user’s preference? It seems to me a reasonable effort. The only objection I can see is if you consider that any user agent that defaults to setting Do Not Track on cannot be respecting the user’s preference. The draft specification does not state what the default should be.

It is also worth noting that clause 3 in the Tracking Preference Expression draft has changed; the wording about “not the choice of some vendor” was inserted in the 7th September draft, after Windows 8 was released to manufacturing. Here it is in the latest (March 2012) W3C Working draft:

Key to that notion of expression is that it must reflect the user’s preference, not the preference of some institutional or network-imposed mechanism…

Even if you agree with Fielding’s views on browser defaults, quietly patching the world’s most used web server to ignore the IE10 setting looks hard to defend, especially on a matter that is far from clear cut. Fielding is personally involved, not only as the author of the Tracking Preference Expression document, but also as an employee of Adobe, which specialises in digital marketing and may be more aligned with the vendors and their brands which may want to track user activity wherever their ads appear, rather than with end users.

Of course Apache is an open source project and Fielding’s patch has attracted the attention of the Apache community and may not survive.

It is also possible that a future draft of the Tracking Preference Expression document will state that Do Not Track must be off by default; but even if it does, patching the web server to ignore the browser’s header strikes me as a contentious solution.

Finally, it is worth noting that sending the Do Not Track header has little effect on whether or not your activity is tracked, since its meaning is unclear and respecting its value is a a choice made by third-parties, so this is a debate with little practical impact for the time being.

Adobe Brackets: a different type of HTML and JavaScript code editor. Interview with Adobe’s Adam Lehman.

On Adobe’s Tools and Services page there is an intriguing remark about the company’s plans for a code editor. “We think there’s a need for a different type of code editor – we’re working on something and will have more to share soon.”

image

That something is Brackets, a code editor written in HTML and JavaScript (which means, as with all the best tools, that you can code Brackets in itself).

Advertisement

Although Brackets is written in HTML and JavaScript, it is not yet a web application. Instead, it runs on the desktop using Google’s Chromium Embedded Framework (CEF), which lets you embed the Chrome (strictly, the Chromium) browser engine in a desktop application. In the case of Brackets, the wrapper is lightweight, the intention being that in future Brackets may be fully browser-hosted. The consequence though is that currently you need Google Chrome installed and it only runs on Windows and Mac.

The project is open source under the MIT license; anyone can grab the code from Github. Brackets also depends on another open source project, CodeMirror, which is a JavaScript editor component for browsers. I installed it on Windows and soon had it up and running. Note that you should pull brackets_app if you want to run it, as this brings down the Brackets code as well.

image

I spoke to Brackets Product Manager Adam Lehman. “This might be the first project we started with the intent of being open source from day one,” he said.

“Our general intent is that we wanted to provide an editor that web developers felt that they could own. In the past we might have built something in Eclipse, and there would have been this giant gap between the person who knew HTML, JavaScript and CSS, and then having to write a Java-based Eclipse plug-in to extend the editor.

“When we start talking to developers, they’re going back to just text editors, things that don’t do much more than edit and manage a document, and as complex as HTML and JavaScript apps are getting these days, it seemed crazy that our tools weren’t keeping up with us. So the idea was to start this project, add a little bit of our own ideas, and have the community supply their own ideas.”

But how does Adobe intend to use Brackets in its own products, and what is the business model?

“We believe there are two spaces for the editor market. There is the larger IDE, but there’s also these lightweight text editors. We’re finding that the traditional JavaScript and HTML developer, CSS developer, was heading towards the lightweight text editor and not towards the larger IDE. We don’t see Dreamweaver and Brackets as direct competitors because they service two different tastes. It wasn’t a matter of could we add a feature here or there that was going to get people to use Dreamweaver. It was that difference between our larger tool and a much lighter weight tool. That’s where Brackets come in.”

How then will Brackets tie in with other Adobe products?

“That’s the key for Brackets. We wanted to see if we could innovate in the space and we also wanted to have a common language that we could start targeting. When you say, I want to open up an editor from Adobe Edge and start coding, we needed to define what that editor would be, so Brackets would come into that.

“We’re also saying we need to do better tooling around PhoneGap. A lot of people are fine with the command line, but we want to take a step beyond that and so Brackets is the obvious place where we’ll start to build an extension where we can tie into PhoneGap Build, or extensions around the PhoneGap APIs.

“We’ve got a lot of ideas around using Brackets to bring a lot of our HTML efforts together, not only our core HTML products but also a lot of the W3C and WebKit work that we’re doing. Brackets is a great place to put tooling, that isn’t quite ready for mass consumption yet, but we could actually build extensions for something like Shaders where those people who are interested in it can get in and start playing around with it.

“The beauty of building on the web platform is that we can go wherever the web platform goes.”

Initial prototypes of Brackets ran entirely in the browser, which would be interesting for future versions of Adobe’s Creative Cloud as well as other scenarios, but Lehman said this got mixed reactions.

“While we believe that the future of development is heading towards the cloud, and the general consensus from developers is the same, we also heard that it is not ready yet. We decided to focus on a desktop version first, with the idea that towards the end of this year or beginning of next year we’ll start to supplement with other targets, whether it be in the cloud or  a tablet, or embedded in a tool like Edge,”

says Lehman. He adds that a browser-hosted Brackets could end up integrated with the PhoneGap Build site. PhoneGap Build is a service for compiling cross-platform HTML and JavaScript into mobile apps for a variety of devices.

Since Brackets is built on Google’s Chrome/Chromium platform, what are the implications for cross-browser compatibility?

“There’s two pieces to it. There’s our container that Brackets runs in, and that is running on Chromium.

“The other part is that we have this live preview system which is tied directly to Chrome on the desktop. We happened to just start with Chrome, mostly because there is a remote debugging API that’s pretty fleshed out there.

“With Firefox and Internet Explorer, it’s a little bit different. We talked to Mozilla and they’re just now starting to work on that remote debugging API and trying to get it inline with where Chrome is, so we’re expecting to hear from them in August that they actually might have an API where we can start to build that same functionality, which is our intent.

“We’ve already started engaging with Microsoft about Internet Explorer. Right now their remote debugging API is somewhat private and in the form of a COM object which is not ideal coming from a JavaScript perspective, but we’ve showed them what we’re after, and we’ve started discussion of what a remote API from IE might look like that didn’t require COM. We’re exploring those options. Those are our priorities right now.

“If we build a cloud-based version then it’s going to be a question of what browsers this is going to run in. Our intent is to run in the modern major browsers. We aren’t building anything that’s Chrome-specific, we’re doing our best to stay as browser-agnostic as we can, but we are likely to require a more modern browser. We feel it would be OK to require the latest versions of Firefox, IE or Chrome.”

I asked Lehman whether Brackets might be useful for server-side as as client-side code. He said that Brackets is focused on the client, though a community extension is under way for node.js. He adds that since Brackets is fully extendable, others may do plug-ins for languages such as PHP.

Why is Brackets at Github and not Apache?

“We have a lot of people at Adobe who work for Apache now, and we talked to them before we released Brackets. Our sense is that Apache might be too much of a turn-off for the individual contributor, who just wants to hack and fix a bug and submit it back,”

Lehman told me. Although there are external contributors, all the committers are currently at Adobe, though there are plans for adding external committers by the end of the year. “We don’t want this to be 100% Adobe controlled.”

When will Brackets get to version 1.0?

“We’re being as agile as we can. Every bit we add, it comes closer to being a 1.0 for somebody. The things that I think are missing that you would expect out of a core editor are around code-completion for CSS and JavaScript, and solid and advanced search and replace. In the web world, that’s how we refactor code. We’re hoping to drive those in by November time. But we are on 2.5 week sprints and things change rapidly.”

I also asked about plans for a mobile app version of Brackets. Lehman says that is planned for next year, though the community is working on getting a Linux version working and support for ChromeOS.

Brackets is a fascinating project on several levels. What stands out is how far Adobe has moved from being the Flash company. A few years back Adobe came up with a system for having Flash applications run on the desktop and on mobile devices: Adobe AIR. It also invested in Eclipse and came up with the Flash Builder IDE.

Now here is Adobe with an open source project for a desktop application built from HTML, JavaScript, and a third-party open source browser engine; and in place of mobile AIR it has PhoneGap.

It is a big change, most of which has become publicly known in less than a year, signalled by the repositioning of Flash and AIR versus HTML in September 2011, and the abandonment of Flash for Mobile in November 2011.

As for Brackets itself, it is well worth a look though probably not a tool you want to use for real work just yet. In a few months though, that may well change.

Postscript: Brackets reminds me of another Adobe, or rather Macromedia, HTML code editor. That was HomeSite, an excellent text-based tool that Adobe discontinued in 2009; active development ceased years before that.

Enable Adobe Flash and BBC iPlayer on the Google Nexus 7

Annoyed that BBC iPlayer does not work on Google’s Nexus 7? There is a fix; though note that Adobe Flash is not supported on Android 4.1 “Jelly Bean” and the official advice is to put up with the lack of Flash, and wait for the BBC to provide a non-Flash option for Nexus 7 and other recent Android devices. The steps below may stop working as the Nexus 7 update itself, who knows?

If you are impatient though, here is what you have to do.

1. Download the Flash APK, for example from XDA Developers here.

2. Rename it from .zip to .apk if necessary, and tap it on your Nexus 7 device. It will tell you that it cannot be installed, but prompt to access settings where you can tick to allow installation from unknown sources:

image

3. Now retry installation and it will work.

4. Install Firefox Beta from the Play Store. Flash does not work with Chrome on the Nexus.

5. Tap the 3 dots in Firefox, go to Plugins, and tap Enabled.

6. Power off your Nexus 7 and restart (it did not work for me until I did that).

7. Go to watch an iPlayer video. You get a message informing you that your phone is not supported. Tap the three dots again and then Request Desktop Site.

image

8. Enjoy iPlayer. Full screen works; though I have to admit, Firefox crashed when I switched to another app and I had to Force Stop. Nevertheless, the video played sweetly enough while I was watching.

image

PhoneGap 2.0 released with WebView, Windows Phone support

Adobe has released PhoneGap 2.0, its framework for creating cross-platform mobile apps using HTML and JavaScript. Using PhoneGap, you can wrap a web application as a native app, taking advantage of the browser control available in all the major mobile platforms.

New features in PhoneGap 2.0 include Windows Phone support, WebView which lets you embed a PhoneGap fragment into a larger native application, improved tooling and a unified JavaScript API across all platforms called Cordova-JS.

The Mac tooling has been improved and no longer depends on Xcode templates. Instead, you create a new project at the command line. However, you do need Lion or Mountain Lion to use PhoneGap.

The associated Apache Cordova project is “nearing graduation from incubation”, according to Adobe’s release.

image

Adobe Flash in Windows 8 Metro, but not technically a plug-in

Today’s Windows 8 rumour is that Adobe Flash will be baked into Internet Explorer 10 in Windows 8, not only in the desktop edition but also in Metro.

Until this is confirmed by Microsoft, it is only a rumour. However, it seems likely to me. The way this rumour mill works is:

  • Some journalists and book authors working closely with Microsoft already have information on Windows 8 that is under non-disclosure.
  • Some enthusiast sites obtain leaked builds of Windows 8 and poke around in them. Unlike new Mac OS X releases, Windows builds are near-impossible to keep secure because Microsoft needs to share them with hardware partners, and mysteriously copies turn up on on the Internet.
  • When an interesting fact is leaked, this allows those journalists and book authors who already have the information to write about it, since most non-disclosure agreements allow reporting on what is already known from other sources.

That is my understanding, anyway. So when you read on WinUnleaked.tk that Flash is in IE10 you may be sceptical; but when Paul Thurrott and Rafael Rivera report the same story in more detail, you can probably believe it.

Back to the main story: presuming this is accurate, Microsoft has received Flash source code from Adobe and integrated it into IE10, in a similar manner to what Google has done with Flash in Chrome. This means that Flash in IE10 is not quite a plug-in. However, on the Metro side the inclusion of Flash is apparently a compatibility feature:

So, Microsoft has extended the Internet Explorer Compatibility View list to include rules for popular Flash-based web sites that are known to meet certain criteria. That is, Flash is supported for only those popular but legacy web sites that need it. This feature is not broadly available for all sites.

say Thurrott and Rivera, though I presume this only applies to the Metro IE10 rather than the desktop version.

Does this make sense? Not altogether. Oddly, while I have heard plenty of criticism of Windows 8 Consumer Preview, I have not heard many objections to the lack of Flash in Metro IE. Since Apple does not support Flash on iOS, many sites already provide Flash-free content for tablet users. Further, on the x86 version of Windows 8 there is an easy route to Flash compatibility: just open the site in the desktop browser.

That said, there is still plenty of Flash content out there and being able to view it in Windows 8 is welcome, especially if you can make your own edits to the compatibility list to get Flash content on less well-known sites. My guess is that Microsoft wants to support Flash for the same reason Android devices embraced it: a tick-box feature versus Apple iOS.

One further thought: this is a sad moment for Silverlight, if Microsoft is supporting Flash but not Silverlight on the Metro side of Windows 8.

Adobe Dreamweaver CS6, PhoneGap Build, and HTML5 app tooling

I am looking forward to trying out Adobe’s new Creative Suite 6 but have not yet got my hands on it. However one thing I am watching with interest is the work Adobe is doing to integrate PhoneGap developing into the suite, in particular in Dreamweaver.

PhoneGap lets you build native mobile apps for several mobile platforms using HTML and JavaScript, by embedding the browser engine on the device.

There was PhoneGap support in Dreamweaver CS 5.5, but it was curiously broken. It always makes a debug build for Android, for example, and it does not offer enough control of the build settings to be useful. Dreamweaver CS 5.5 is useful for designing a PhoneGap app, but you need to use the command line or Eclipse-based tools to finish it off.

The big new is that Adobe has integrated Dreamweaver CS 6 with PhoneGap Build, a cloud service where you upload your source files and download the resulting build. There are details of the new integration here. You can build for iOS, Android, BlackBerry, webOS and Symbian. A nice touch is that you can use a QR code to download the app to a connected mobile device.

There are a few puzzles though.

1. The Help says:

You cannot use PhoneGap Build and Dreamweaver without a PhoneGap Build service account. Accounts are free and easy to set up.

They are free to set up, but not to use:

image

Do Creative Cloud subscribers get some use of the service included? I am finding out and will report.

2. Build is a great service and lets you support platforms without having to install the SDK; but compiling locally has advantages too. It seems that local builds are no longer supported. Here is the relevant part of the Dreamweaver CS 5.5 Site menu:

image

and here it is in Dreamweaver CS 6 (from a video):

image

This is confirmed by David Powers, who has an excellent overview of what is new in Dreamweaver CS6 and writes:

The way that Dreamweaver CS6 supports building native apps for iOS, Android, and other mobile operating systems using HTML, CSS, JavaScript, and the PhoneGap framework has changed completely. It no longer installs the Android software development kit (SDK) and emulator. Nor can the Mac version hook directly into Xcode and the iOS simulator. Instead, there’s a new panel that uploads your files to PhoneGap Build, an online service that automatically packages applications for iOS, Android, webOS, Symbian, and BlackBerry. Using PhoneGap Build is much easier than working with a simulator, because the Dreamweaver panel displays a QR code that lets you load the app directly onto your testing device. However, you need to build the configuration file manually in XML, and there’s no longer any code hinting in Dreamweaver for PhoneGap plugins. So, although the integration of PhoneGap Build is a definite improvement, it feels as though the engineering team didn’t have time to polish some important details.

3. PhoneGap Build in Dreamweaver CS 6 supports 5 mobile platforms:

image

but the PhoneGap team has also announced support for Windows Phone 7

I would expect that Windows Phone 7 support will be added to Dreamweaver CS6.

4. Adobe had a change of heart with respect to supporting Build in Dreamweaver CS 5.5. This was released as an extension at the end March, then pulled a few days later:

Adobe regrets to inform the Dreamweaver Community that the PhoneGap Build extension for Dreamweaver CS5.5 (released last week) is no longer available for download. For a number of reasons, we have had to pull the extension from public availability.

The functionality of the extension, which integrates PhoneGap Build with Dreamweaver, will be available in the upcoming version of Dreamweaver CS6.

A shame, since PhoneGap support in Dreamweaver CS 5.5 does not work properly and fixing this for existing users would have been nice.

5. Finally, while PhoneGap support in Dreamweaver is welcome, Dreamweaver is primarily a web design tool and not ideal for app development. It seems Adobe shares this view:

Code

We think there’s a need for a different type of code editor – we’re working on something and will have more to share soon.

Adobe has the resources to come up with something great for HTML5 and JavaScript developers – here is hoping that it does.

What’s in Adobe’s Creative Cloud, and should you go cloud or purchase outright?

Adobe has launched though not quite released its Creative Cloud. The name is slightly misleading since Adobe’s main business is in desktop applications and the “Creative Cloud” is as much or more a subscription model for desktop applications as it is a set of cloud services. In its discussions with financial analysts at the end of last year, Adobe said that moving customers to a subscription model is one of its goals since, quite simply, it makes more money that way.

Subscriptions are good for vendors in various ways. They offer a regular income, tend to keep going through inertia, and offer an opportunity to upsell additional services.

The applications in Creative Cloud include everything in Creative Suite Master Collection as far as I can tell, including Photoshop, Illustrator, InDesign, Dreamweaver, Flash Professional, Flash Builder, Fireworks, Premiere Pro, After Effects, Audition, Edge (animator for HTML5) and Muse (a no-code visual designer for HTML pages).

You also get a set of iOS/Androd apps: Photoshop Touch, Proto, Ideas, Debut, Collage and Kuler. And Lightroom, which curiously is not in Creative Suite.

Adobe Digital Publishing Suite Single Edition is “coming soon” to the Creative Cloud.

Nevertheless there are cloud services as well as desktop applications in the Creative Cloud. Here is what you get:

Store and Share: automatic cloud storage and file syncing. 2GB for a free membership or 20GB paid for. A desktop app called Creative Cloud Connection, for Windows and OS X, synchs files to a computer, while you can also access files from Touch apps on iOS or Android.

Publish: host up to five websites on Adobe’s hosting service. If you use Adobe Muse, you can design and publish without coding. Features of the web hosting? PHP? Coldfusion? Server-side Java? Database? Ecommerce? These details seem to be absent from Adobe’s current information but I am keen to find out more and will post an update.

Update: apparently this is the Business Catalyst hosting service – see here for details. This is rather limited as you cannot use any sort of server-side programming platform, but only the Business Catalyst services, though this does include a “customer database”. That said, there is an API for “connecting third party services” which might be a workaround in some cases.

Pros and cons

There are real advantages to a subscription versus buying the packaged Creative Suite. You get additional services, additional products, and also, Adobe is hinting, more updates than will be available to shrinkwrap purchasers.

If you have a short-term requirement for Creative Suite, the subscription approach is obviously advantageous.

The disadvantage, as with any subscription, is that you have to keep paying in order to keep using the products, whereas the shrinkwrap (actually a download) is a one-off payment. How much? All prices below exclude VAT.

For UK customers, Creative Cloud is £36.11 per month (£433.32 per annum), though there is a special offer for existing shrinkwrap owners of CS3 or later of £22.89 per month (£274.68) for the first year only.

The full version of Creative Suite 6 Master Collection is £2,223.00 – around five years of Creative Cloud and therefore a poor deal. Most software is almost worthless when five years old.

On the other hand an upgrade from Creative Suite 5.5 Master Collection is £397.00. Even that is barely a better deal, unless you plan to use it for two years and do not need the additional products and services.

image

The prices for UK customers are much higher than for the US, a fact which is causing some consternation. For example, the full CS6 Master Collection is $2599.00, a little over £1600 at today’s exchange rate.

The bottom line: Adobe wants you to subscribe so you can expect the pricing to push you in that direction.

Adobe turns to OpenCL rather than NVIDIA CUDA for Mercury Graphics Engine in Creative Suite 6

Adobe has just announced Creative Suite 6. CS 5.5 used the Mercury Playback Engine in Premiere Pro, which takes advantage of NVIDIA’s CUDA library in order to accelerate processing when an NVIDIA GPU is present. Just to be clear, this is not just graphics acceleration, but programming the GPU to take advantage of its many processor cores for general-purpose computing.

Premiere Pro CS6 also uses the Mercury Playback Engine, and while CUDA is still recommended there is new support for OpenCL:

The Mercury Playback Engine brings performance gains to all the GPUs supported in Adobe Creative Suite 6 software, but the best performance comes with specific NVIDIA® CUDA™ enabled GPUs, including support for mobile GPUs and NVIDIA Maximus™ dual-GPU configurations. New support for the OpenCL-based AMD Radeon HD 6750M and 6770M cards available with certain Apple MacBook Pro computers running OS X Lion (v10.7x), with a minimum of 1GB VRAM, brings GPU-accelerated mobile workflows to Mac users.

PhotoShop CS6 also uses the GPU to accelerate processing, using the new Mercury Graphics Engine. The Mercury Graphics Engine uses the OpenCL framework, which is not specific to any one GPU vendor, rather than CUDA:

The Mercury Graphics Engine (MGE) represents features that use video card, or GPU, acceleration. In Photoshop CS6, this new engine delivers near-instant results when editing with key tools such as Liquify, Warp, Lighting Effects and the Oil Paint filter. The new MGE delivers unprecedented responsiveness for a fluid feel as you work. MGE is new to Photoshop CS6, and uses both the OpenGL and OpenCL frameworks. It does not use the proprietary CUDA framework from nVidia.

It seems to me that this amounts to a shift by Adobe from CUDA to OpenCL, which is a good thing for users of non-NVIDIA GPUs.

This also suggests to me that NVIDIA will need to ensure excellent OpenCL support in its GPU cards, as well as continuing to evolve CUDA, since Creative Suite is a key product for designers using the workstations which form a substantial part of the market for high-end GPUs.

Appcelerator Titanium gets Mobile Web SDK, cloud services

Appcelerator’s Titanium cross-platform development framework has moved up a gear with the announcement of two new features:

  • A set of cloud services, based on those acquired with Cocoafish in February this year. These are now known as Appcelerator Cloud Services (ACS).
  • Support for mobile web applications as well as native

These features are integrated into the Titanium development environment, an Eclipse-based IDE which has evolved from Aptana, a JavaScript tool acquired in early 2011. Start a new project, and ACS support is included by default.

image

The cloud services are hosted on Amazon and comprise the following:

  • Push Notifications
  • User management
  • Photo manipulation and storage
  • Places (rich location storage)
  • Social integration
  • File Storage
  • Check-ins
  • Status updates
  • Chats
  • Friend connections
  • Ratings and Reviews
  • Discussion forums
  • Event planning
  • Messaging
  • Key-Value data storage

“We have a portfolio of additional services rolling out over the next several quarters,” said Jo Ann Buckner, VP of Product Management. There are code examples here. A limited usage of the services is available free, after which it is pay as you go. It is a REST API that you can use from any platform; use of Titanium is not essential.

The other big feature is the Mobile Web SDK. Why is Appcelerator doing this given that it has been pushing native code apps as the way forward for mobile deployment?

“Two reasons,” says Buckner. “The debate has been going on for a long time, is it native, or web? Our position is that it native and mobile web are complementary. We have customers building native apps with Titanium that also want to have a mobile web presence, even for iOS and Android. Some customers will just interact with a mobile web site and never download the application.

“The second is reach beyond iOS and Android.”

Does that mean Appcelerator will not support other platforms such as Blackberry or Windows Phone with its native approach? “This is not a replacement for those efforts. We are investing in support for additional platforms,” says Buckner.

There are differences of course between what you can do in a native app, and what you can do in a web app, and these differences vary according to the target browser. Titanium allows you to write platform-specific code in order to workaround these problems, or to vary the user interface to suit the device. The illustration below shows the new Titanium IDE with an app which targets both Android and the Mobile Web, and you can see the folders on the left which separate common code and platform-specific code (click the image to enlarge).

image

Titanium installs its own web server for testing. Here is an example running in the Android emulator, served from Titanium.

image

When should you do a native app and when a mobile web app? “You’re going to build more than one application,” says Mike King, Appcelerator’s Principal Mobile Strategist. “If you are doing an augmented reality application the native interaction is going to require that to be a native application. You can do a forms-based application as well, and mobile web is going to be a better fit for that. Different use cases require different architectures.”

But why do your mobile web apps in Titanium, when you could use pure HTML 5 tools instead? “It’s about one platform for all of your development requirements, as opposed to one for native and one for HTML 5,” says King.

Titanium is certainly evolving with impressive speed. The latest 2.0.1 IDE is a rich tool, and pop-up help guides you concerning supported platforms for each keyword.

image

Another strong point is the way you can easily write conditional code for tablet form-factors.

The comparison with Adobe PhoneGap is interesting. PhoneGap takes a different approach, supporting native apps but by means of the embedded browser in each device, rather than by building a native user interface. Titanium’s new mobile web support is different in that it runs as a web app in the browser, not as a native app with an embedded browser.