Category Archives: software development

Adobe LiveCycle and the Apple problem

Earlier this week I attended Adobe’s partner conference in Amsterdam, or at least part of it. The sessions were closed, but I was among the judges for the second day, where partners presented solutions they had created; the ones we judged best will likely be presented at the Max conference in October.

Seeing the showcased solutions gave insight into how and why LiveCycle is being used. LiveCycle is actually a suite of products – the official site lists 14 modules – which are essentially a bunch of server applications to process and generate PDF forms and documents, combined with data services that optimise data delivery and synchronisation with Flash clients, typically built with Flex and running either in-browser or on the desktop using AIR. These two strands got twisted together when Adobe took over Macromedia.

LiveCycle applications are Java applications, and run on top of Java Enterprise Edition application servers such as Oracle’s WebLogic or IBM’s WebSphere. This does mean that support for Microsoft’s .NET platform is weak; Adobe argues that that Microsoft’s platform has its own self-contained stack and development tool (Visual Studio) which makes it not worth supporting, though of course there are ways to integrate using web services and we saw examples of this. Many of the partners whispered to me that they also build SharePoint solutions for their Microsoft platform customers, and that SharePoint 2010 is a big improvement on earlier versions for what they do. Still, Java is the more important platform in this particular area.

Why would you want to base an Enterprise application on PDF? The answer is that many business processes involve forms and workflows, and for these LiveCycle is a strong solution. PDF is widely accepted as a suitable format for publishing and archiving. One thing that cropped up in many of the solutions is digital signatures: the ability to verify that a document was produced at a certain time and date and has not been tampered with plays well with many organisations.

Here’s a quick flavour of some of the solutions we saw. Ajila AG showed an application which handles planning permission in parts of Switzerland; everything is handled using PDF form submissions and email, and apparently a process which used to take 45 days is now accomplished in 3 days. Another Ajila AG solution handles the electronic paperwork for complex financial instruments at the Swiss stock exchange. Ensemble Systems showed an e-invoicing system which includes a portal where both a company and its suppliers can log in to view and track the progress of an invoice. Impuls Systems GmbH used PDF forms combined with Adobe Connect Pro conferencing to create online consultation rooms and guided form completion for clients purchasing health insurance. Aktive Reply built a system to replace printed letterheads for an insurance company with 10,000 agents; not only does the system save paper, but it also synchronises any address changes with a central database. Another Aktive Reply application lets lawyers assemble contracts from a database of fragments, enforcing rules that reduce the chance of errors; we were told that this one replaced a complex and error-prone Word macro.

OK, so why would you not want to use LiveCycle for your forms or document-based workflow or business process management application? Well, these solutions tend to be costly so smaller organisations need not apply; and I did worry on occasion about over-complexity. More important, the whole platform depends on PDF, often making use of smart features like Adobe Reader Extensions and scripting. After all, this is why Adobe added all these abilities to PDF, despite security concerns and the desire some of us have for simple, fast rendering of PDF documents rather than yet another application platform.

PDF is well supported of course, but once you move away from Windows and Mac desktops, it is often not the official Adobe Reader that you use, but some other utility that does not support all these extra features. In many cases it is not just PDF, but Flash/Flex applications which form part of these LiveCycle solutions. Adobe understands the importance of mobile devices and I was told that more effort will be put into Adobe Reader for mobile devices, to broaden its support and extend its features. Reader for Android is also available, as an app in the Android Market.

That’s fair enough, but what about Apple? Curiously (or not) PDF is not well supported on the iPad, though you can read PDF in Safari and in mail attachments. This is not Adobe Reader though; and given that PDF now supports Flash as well as scripting there seems little chance of Adobe getting it onto the App Store. Flash itself is completely absent of course.

Lack of compatibility with Apple devices did not seem to be a big concern among the partners I spoke to at the conference. Many of the solutions are internal or work within controlled environments where client compatibility can be enforced. Nevertheless, I can see this becoming an increasing problem if Apple’s success with iPhone and iPad continues, especially in cases where applications are public-facing. My suggestion to Adobe is that it now needs to work on making LiveCycle work better with plain HTML clients, in order to future-proof its platform to some extent.

Native code interop in Adobe AIR vs Microsoft Silverlight

The latest versions of Adobe AIR and Microsoft Silverlight both allow access to native code, but with limitations. The two platforms take a different approach though – here is a quick comparison.

Native code access in AIR

The new version 2.0 of Adobe AIR is just about done. The runtime is available now (as is Flash Player 10.1), but we have to wait until June 15 for the final version of the SDK.

AIR lets you create cross-platform desktop applications that use the Flash runtime. Supported operating systems include Mac, Windows and Linux, and coming soon, Android. Sadly, supported operating systems do not include Apple’s iPhone or iPad.

One of the big new features in AIR 2.0 is access to native code. Of course this breaks cross-platform, unless you create identical native code extensions for all the platforms that AIR supports. Still, the ability to extend AIR without limit using native code is significant. So how do you use it, can you call a DLL or a dynamic shared library? What about COM on Windows, for automating Microsoft Office?

The answer is that you can do all these things, but not easily. There are actually three obvious ways to communicate with native applications in AIR 2.0:

1. Open a document using the default file handler. This is done using the new openWithDefaultApplication function. This is a handy way to open a PDF or Microsoft Office document, but you as the developer have little control over what happens. You do not know which application will open, and cannot control it once it does open.

2. Socket support. Your AIR application can send and receive data over a TCP socket. If you write a native code socket server and install it, you can get access to the local operating system APIs that way.

3. Native process support. This one looks promising. The new NativeProcess class lets you launch a native application and communicate with it via STDIN and STDOUT. Your native application could do anything, of course, such as calling a DLL or using COM, but it must use STDIN and STDOUT to communicate with AIR.

Another limitation is that AIR applications which use this function must be installed with a native installer, rather than by downloading an .AIR file. A further limitation is that auto-update does not work for these applications. You will have to write your own code to check for updates and download an updated installer if necessary.

Native code access in Silverlight

Microsoft Silverlight 4.0 also has the ability to run on the desktop and to call native code – but the native code part only works on Windows, and is restricted to applications that are “Trusted”, which means the user has approved the installation. A trusted Silverlight 4.0 desktop application can call COM via AutomationFactory.CreateObject. Presuming it is successful, your application can call methods on the returned object. If what you really want is to call a DLL, for example, you would have to write a COM DLL (or an application with a COM API) that calls the native DLL.

In addition, Silverlight 4.0 trusted applications have socket support, so that would be another possible approach. However, unlike Adobe AIR 2.0, you cannot simply open a document using the default file handler for its type. That said, it would be trivial to do so using COM and the WScript object, for example. You can also use the browser to do this – see here for an interesting case study from Beat Kiener, who does this with remote documents.

The main limitation of native code access in Silverlight is that it only works on Windows. Even if it does go cross-platform at some point, you would not use COM on Mac or Linux, so some other mechanism will be necessary.

Comparing the two

First, let’s acknowledge that native code interop is not something to use lightly in a cross-platform runtime. If you have to use native code, maybe AIR or Silverlight is not the right choice.

Opening files using the default file handler is a different case, as you can do this without any platform-specific code.

Still, if you can do almost everything in AIR or Silverlight, but need to call a native API for just one or two important features, it may be a reasonable approach.

My immediate observation is that native code interop is easier in Silverlight, though wrecked by being restricted to Windows only. The packaging and updating limitations in AIR, plus being restricted to STDIN and STDOUT, is more arduous than using COM in Silverlight.

Further, it is a shame that neither platform lets you simply call a dynamic library. It would then be relatively easy to write some conditional code to load the appropriate library on different platforms, and many tasks could be accomplished without needing to build and deploy your own native code executable for each platform.

Will you be using native code interop in either AIR or Silverlight? I’d be interested in hearing of examples, and how well it is working for you.

Steve Ballmer and Ray Ozzie at All things Digital – a poor performance

Microsoft CEO Steve Ballmer and Chief Software Architect Ray Ozzie put on a poor performance when quizzed by Walt Mossberg at the All Things Digital conference, judging by Ina Fried’s live blog.

What was wrong with it? They allowed the conversation to be focused mainly on competing products: Apple iPad, Google Android, Google Apps, Google search. Since these products have exposed weaknesses in Microsoft’s own offerings, it was unlikely to work out well.

Mossberg asks about the transition to the cloud. “You guys are putting, for instance, a version of Office in the cloud.”

That was a gift. You would expect the two men to enthuse about how Microsoft’s dominance with desktop Office was now including the cloud as well, how the Office Web Apps enable new opportunities for collaboration, how Microsoft’s investment in XML for Office was now enabling the same document to live both on the desktop and in the cloud.

Nope. Ozzie waffles about people being more connected. Ballmer “disputes the notion that everything is moving to the cloud”.

So what about Steve Jobs prediction, of a transition from PCs to tablets and mobile devices? Ballmer says “not everyone can afford five devices,” lending support to the notion that Windows is for those who cannot afford something better.

Mossberg asks about tablets. Although Mossberg did not say so explicitly, tablets have been a tragi-comedy at Microsoft. Bill Gates evangelised the tablet concept years ago, pre-echoing Jobs’ claim that they would largely replace laptops. Microsoft tried again and again, with XP Tablet Edition, Vista on tablets, then “Origami”, or Ultra-mobile PC. Going back even further there were was the stylus-driven Palm-size PC (I have one in the loft). Tablet PC was not a complete failure, but remained an expensive niche. Origami sank without trace.

Ballmer replied that the “race is on”. Meaning? I guess, now that Apple has demonstrated how to make a successful Tablet, Microsoft will copy it? Or what?

I am not sure how you defend such a poor track record; but the starting point would be to explain that Microsoft has learned from past mistakes. In some ways it has; Windows 7 learns from mistakes in Vista, and Windows Phone 7 learns from mistakes in Windows Mobile.

None of that from Ballmer, who says vaguely that he expects Windows to run on a variety of devices. He makes matters worse later, by defending the stylus. “A lot of people are going to want a stylus,” he says. Some do, perhaps, but Apple has pretty much proved that most people prefer not to have one. I’d like to see effort go into designing away the need for a stylus, rather than implying that Microsoft is just going to repeat its part mistakes.

Someone in the audience asks, “Will we see Silverlight on Android or iPhone?” “My guess is  if it did, it would be blocked”, says Ballmer, ignoring the Android part of the question.

He’s ignoring the force of the question. Why bother developing for Silverlight, if it is locked into a Microsoft-only future, especially considering the company’s poor position in mobile currently? Ballmer could have mentioned the Nokia Symbian port. He could have said how Microsoft would get it on iPhone just as soon as Apple would allow it. He could have said that Microsoft is working with Google on an Android port – I don’t know if it is, but certainly it should be. He could have said that Silverlight plus Visual Studio plus Microsoft’s server applications is a great platform that extends beyond Windows-only clients.

Microsoft does have problems; but it also has strong assets. However it is doing an exceptionally poor job of communicating its strengths.

Update: There is a fuller transcript at Engadget, in which Ballmer and Ozzie come over better, though they still fail to impress. On mobile though, I like this comment:

We have new talent, we had to do some cleanup, we did it for Windows, and we’re doing it for mobile. And excellence in execution is also part of the equation.

I’d be interested in hearing from anyone present at the event.

My first Google Chrome Web Application

Update: this post is based on obsolete beta code. Please go to the updated version here.

When I read Patrick Aljord’s blog on how to create Chrome Apps I thought, “that looks easy”. So I installed the dev channel version of Chrome as advised here, though on a VM just to be safe, and set about creating my own.

Well, WordPress is a web application; so my example is this blog. I created a manifest in Notepad.

image

Next, using my artistic skills, I made two icons of the required size: 24×24 and 128×128.

I ran the dev. build of Chrome using the –enable-apps switch. On the Extensions tab there are tools for building a .crx, which is the container for a Chrome Web App. I built the app, then installed it.

image

You get a generic warning about the extension. I was surprised not to see a stronger complaint about my app having no authenticated signature – it could be from anywhere. I guess this may be changed for the final release.

After installing, the app appears in the Chrome New Tab page.

image

You can try my web app here.

The whole process is very simple, which I like. It is also almost the same thing as a bookmark or favourite link. The main differences that I can see:

  • Apps get pride of place on the default Chrome Home page.
  • Apps can be installed from the forthcoming Chrome Web Store, with user reviews, a payment model, and so on.
  • Apps can have extra permissions.
  • Apps can be locally installed as “serverless” apps – this is huge, especially for the forthcoming Chrome OS which has no other provision for local applications.

Incidentally, if you try installing an app into the current standard build of Chrome, it installs as an extension but does not do anything. I also had to omit the “permissions” section of the manifest, otherwise I got an invalid permissions error when installing. In the developer build all was fine.

I tried dragging my app from Chrome to the desktop to make a shortcut. It worked, but simply created a standard web shortcut, which opens in your default browser, not necessarily in Chrome.

It is all so easy that it will make sense for almost anyone to create a Chrome Web App from their web property. Which also means there will be plenty of junk web apps around.

I’m not clear exactly how the Web Store will work. While I would love to sell URLs for money, they are not inherently of any value, though a serverless app is different. Presumably the normal thing would be to sell some sort of subscription, which implies registration and user authentication. No doubt everything will work smoothly if you use a Google ID as your authentication provider, though I hope Google will also provide for alternative systems.

What is happening with Silverlight on Intel Moblin/Meego?

Last September, Microsoft and Intel announced a port of Silverlight to Moblin Linux. I posted on the subject here, including a quote from Microsoft’s Brian Goldfarb:

Microsoft and Intel announced today that the two companies have agreed to work together to bring support for Silverlight 3 to Intel’s Atom-based Mobile Internet Devices (MID). These Atom-based devices run on Windows and Moblin, an open source, Linux-based operating system targeted at Atom-based devices. In order to help bring Silverlight content to these devices, Microsoft has provided Intel with Silverlight source code and test suites, and Intel will provide Microsoft with an optimized version of Silverlight for Moblin devices that Microsoft can then redistribute to OEMs.

Since then, Moblin has merged with Novell’s Maemo to form MeeGo (though this is still work in progress), and we’ve heard very, very little about Silverlight on either platform. The only snippet of news I have is that it was mentioned at the Intel Developer Forum in Beijing and reported by Char Zvolanek, who said that it came up in the Meego Q&A after regular sessions ended, and Silverlight will be supported in Meego  version 1.1 in October:

In May, the 1.0 version will be released, and with 1.1 coming out in October, there will be support for Silverlight, Java, and Air. Developers can write native or runtime apps that can be Java-based, Web-based, Silverlight-based, or Air-based.

Today, another clue, but not a good one for Silverlight. Intel is holding an application lab on May 26th in San Jose, for developing for the Intel AppUp store, either on Windows or Moblin. On the agenda: C/C++ and Adobe AIR, and the upcoming Adobe AIR SDK for Moblin. No Silverlight.

If anyone is going along, and can discover any news about Silverlight on Moblin, I’d be interested to know.

What next for Embarcadero Delphi? Roadmap with Mac, Linux support published.

Embarcadero has published an updated roadmap for its Delphi development tools: Delphi, C++Builder and the RAD Studio shared IDE. These tools combine the Object Pascal (Delphi) or C++ language with a visual component library and native code compiler for Windows.

Chief Technical Architect Michael Rozlog outlines four products which are being worked on, including “Fulcrum”, “Wheelhouse”, “Commodore” and “Chromium”. He says work is being undertaken on all of these, so the exact release schedule is not specified. Embarcadero has an annual release cycle for these products so you might reasonably project that Fulcrum is set for release later this year, Wheelhouse for 2011, and Commodore for 2012. Delphi 2010 came out in August 2009.

Delphi “Fulcrum” introduces a cross-compiler for Mac OS X, with the emphasis on client applications. The IDE will run only on WIndows. Rozlog also talks about integration with Microsoft Azure so that Embarcadero can tick the Cloud Computing box.

Delphi “Wheelhouse” adds Linux support, on a similar basis where the IDE runs only on Windows. It also adds a focus on server applications for both Linux and Mac OS X, including support for Apache modules.

Delphi “Commodore” is the 64-bit release, with 64-bit and easier multi-core development on all three platforms. Rozlog also tosses in “Social Networking integration” and “Better documentation”.

2012 is a long time to wait for 64-bit, particularly as the Windows server world is now primarily 64-bit. Embarcadero is promising a 64-bit compiler preview for the first half of 2011, though this will be command-line only.

Delphi “Chromium” is a revamp of the Visual Component Library with a new look and feel and “natural input integration” – location, voice, video motion.

In addition, Rozlog talks about updates for Delphi Prism, which is loosely the Delphi language plus a .NET compiler, and integrates into Visual Studio. Prism 2011 will work with Visual Studio 2010, and includes support for Mono. This extends to working “with MonoTouch to create Apple iPhone ready applications.” Rozlog doesn’t state whether this has been cleared with Apple’s Steve Jobs, who is opposed to use of languages other than Objective C for iPhone or iPad development.

Is Embarcadero doing enough to keep Delphi current? I’m not sure. Delphi is a fantastic RAD and native code compiler for Windows; in the past it suffered when Borland tried to extend it beyond that, to Linux and .NET, distracting development effort from its core role. The risk here is that the Mac and Linux effort may be more of the same. Of course this will be nice to have, though running the IDE on Windows and compiling for Mac is a limitation that means it will not appeal to Mac developers, only to Delphi Windows developers hoping to extend their market. But there are other ways to do cross-platform now –  Silverlight, Flash, web applications – and I wonder if the time for this has passed.

A compiler for iPhone and iPad would now be bigger news, especially since Silverlight and Flash are not available on these platforms, but for this Embarcadero would need to overcome Apple’s cross-compiler restrictions as well as solve the technical problems.

Windows 7 has breathed some new life into Windows client development. I hope Embarcadero is not neglecting areas like great RAD support for features like Jump Lists and thumbnail previews, for the sake of the uncertain cross-compiler market.

There is a discussion of the new Roadmap in the Delphi forums here, and Marco Cantu also comments.

Adobe’s Kevin Lynch: we’re focusing on everybody else

I enjoyed this interview with Adobe’s Kevin Lynch from Web 2.0 Expo in San Francisco, where he talks about the Apple problem. Adobe has created a compiler for Flash that creates a native code iPhone application, but Apple’s latest developer agreement prohibits its use.

Lynch presents it as a matter of freedom. Software developers should be allowed to target multiple operating systems with one code base; and developers should be allowed to deploy applications without needing permission from a company.

“We’re focusing on everybody else” he says, talking about forthcoming devices that will support Flash and the Flash-based Open Screen Project. “All the variety and the innovation that happening with all hese other companies is going to dwarf what’s happening from one company,” he says. “We’re at the beginning of the game not the end of the game.”

The snag is that Apple’s devices are the most attractive market for applications, thanks to smooth deployment via the App Store and the higher than average wealth of Apple’s customers. It’s a matter of which is more true: that Flash is marginalising iPhone and iPad, or that iPhone and iPad are marginalising Flash.

I’d also suggest that having Adobe control the platform for the Open Screen Project is not ideal, if we are going to talk about software freedom. If you listen to the interview, notice how Lynch tries to avoid mentioning Flash in the same breath as the Open Screen Project. It’s really the Adobe Flash Screen Project, but you wouldn’t know from what he says.

Nevertheless I agree with both his points. Both the App Store and Apple’s new restrictive developer agreement are bad for competition and I dislike them. That said, I doubt that the existence of a few upset developers will have any noticeable impact on Apple’s success. What will make a difference is if the “variety and innovation” which Lynch talks about produces devices that are better than Apple’s offerings.

Steve Jobs saying Flash is bad does not make it so

I’ve mulled over the statement by Apple CEO Steve Jobs on why he hates Flash. It’s been picked over by many, so there’s little point in analysing it line by line, spotting what’s true, what’s false, what’s twisted. It doesn’t matter. What counts is that Jobs is disallowing Flash and attacking Adobe – he’s decided it should get out of the runtime business and just do tools for HTML5:

Perhaps Adobe should focus more on creating great HTML5 tools for the future

Apple is a powerful enemy; and what I’ve found alarming watching the reaction is the extent to which Jobs saying “Flash is bad” has lowered the reputation of Flash; it’s as if all the great things which it has enabled – web video that works, pushing the boundaries of what is possible in a web browser, an entire industry of casual gaming – has been forgotten because one charismatic and influential individual has called it old stuff that crashes Macs.

The army of enthusiasts which leaps to the defence of all things Apple both amuses and disturbs me. I understand some of the reasons. People warm to Apple because the company has improved their lives, in computing, in music, in mobile phones – especially in contrast to the efforts of Microsoft and its partners who have all too often made computers and mobile devices that are hostile and unpleasant to use. This last factor is not Apple’s fault; and without Apple it might not now be changing. Apple deserves our thanks for that.

That doesn’t make Jobs or his followers right about Flash, which is a magical piece of technology. Yes, it’s been widely abused to make annoying ads and animations; yes, it crashes the browser sometimes; yes, both HTML5 and Microsoft Silverlight are encroaching on Flash territory.

Still, Flash is never going to be allowed on Apple’s new wave of personal computing devices, which by the looks of things it intends to form the core of its business. Nor can we write for Flash and compile for Apple; it’s not allowed.

This is the new model of computing: the web if you want open, or humbly seek permission from the device overlords if you want a local application install, at least on Apple’s platform; and Microsoft is headed in the same direction with Windows Mobile 7. It’s not a model I like; but the trend is unmistakeable.

Apple no longer loves Mac developers

At least, that’s the impression you get from its latest move: dropping Mac applications from its Apple Design Awards, presented during the its Worldwide Developers Conference. In 2009 there was an OSX developer Showcase alongside the iPhone Developer Showcase. This year? Well, iPad is here, and three’s a crowd, one had to go.

While the Apple Design Awards are a tiny insignificant detail in the grand scheme of things, this is still a clear pointer for anyone who had not yet noticed, that Apple is keen to focus on its locked-down devices ahead of its computers. It’s better business, because a mobile device yields multiple revenue streams: money from the device sale, money from the mobile contract, money from app sales via the only permitted route, the App Store. There is also an argument that it is better for the user, since a locked-down device is more secure and less likely to be break, though you have to set that against loss of freedom, and the impact of a single-supplier market on price and competition. It also fits with bigger industry trends, where devices are mobile and data is in the cloud, that are shaping the computing landscape.

HP hedges mobile bets by buying Palm and webOS

I love that this industry is full of surprises. This week has brought a couple. One is HP getting seriously into mobile by buying Palm – I think this is good news since webOS, based on JavaScript and the W3C DOM, is an interesting platform that was otherwise near to death. But surely HP is Microsoft’s trusted partner and might be expected to back Windows Phone 7? That’s the other intriguing aspect. HP has suffered as Windows Mobile has stuttered, and with mobile fast becoming the computing client that matters most, Microsoft’s platform does not look like a safe bet.

HP’s problem though is that webOS does not look like a safe bet either. In the context of HP’s overall business, Windows Mobile, now Windows Phone, makes more sense; and it cannot afford not to do the Windows stuff alongside whatever is planned for webOS. As HP told the Reg:

HP intends to continue selling Windows-based devices. "We believe in choice," Bradley said. But it sees a brighter future in offering Windows phones and tablets alongside systems based on webOS, which debuted earlier this year on the Palm Pre. "With Palm, HP acquires a strong operating system to deliver a unique customer experience," Bradley said.

It’s a mixed message, which means it is hard to articulate, and hard to make it work.

Nor it is the first time HP has wavered over Windows for mobile devices. Remember when HP rebadged the iPod, back in 2004? It was a short-lived experiment, to nobody’s surprise. This deal makes more sense than becoming an Apple OEM, but it will still be hard for HP to pull off.

The other surprise, also mobile related? Apple no longer lovers Mac developers.