Category Archives: software development

Another Windows app store – but this time it is virtual. Embarcadero’s AppWave promises instant installs

Embarcadero has announced the AppWave Store, a forthcoming app store for Windows which uses application virtualization to avoid the hassles and risks of the usual Windows install process.

image

The idea is that purchasing apps for Windows will be as simple as installing an app on a mobile using the Apple app store or Android Market.

The underlying technology was developed to simplify deployment of Embarcadero’s tools. The All-Access subscription includes a tool box application that lets you run tools using “InstantOn”, which means no installation, just click and run. I have used this for a while now and it works well.

image

When you run an InstantOn tool for the first time, you are prompted to download:

image

There is of course a pause while the app downloads. This is not thin client technology where the app actually runs remotely. It is installed on your local machine, but isolated so there are no dependencies or conflicts.

image

Once downloaded, you just launch the application. No other setup, other than software agreement and registration prompt.

image

The download is cached, so you can launch next time without delay, and it works offline too. AppWave is a rebranded version of InstantOn, and is also available for internal deployment of Embarcadero tools.

The AppWave store takes this technology and applies to a store for the general public. Developers will pay $99 per year (though the fee is waived if you sign up now) and get AppWave Studio, which lets you convert software to run under AppWave. The conversion process is called “mastering” and only takes a few hours, according to the FAQ [pdf].

Windows XP, Vista and 7 are supported clients, availability will be worldwide at launch, and Embarcadero takes 30% of your sale price. No launch date has been announced.

I guess the first big issue is whether developers will feel that the 30% fee is good value bearing in mind that there are many other ways to sell and deploy software.

Second, there are other app stores out there or coming, not least Microsoft’s own which is likely to be part of Windows 8. Will AppWave compete effectively?

Third, does Embarcadero have what it takes to market AppWave and make a destination for Windows users looking for apps?

App virtualization is a neat trick though, and could save significant support costs as well as being appealing for customers. Deploying apps using runtimes like Silverlight or Adobe AIR can be equally seamless, but apps have to be written specifically for those runtimes, whereas AppWave works with apps written for the full Windows API.

It is surprising that Embarcadero is not also marketing the AppWave technology for developers for general purpose use. Possibly this is coming; or maybe the company will try to keep it as an exclusive benefit for the AppWave store. There are alternatives, including Microsoft App-V and VMWare ThinApp.

See also Marco Cantu’s post Understanding Embarcadero AppWave, which is what alerted me to the AppWave store.

RIM announces Java and Android runtimes for the Playbook, beta of native SDK

RIM has announced several new options for developing apps for its PlayBook tablet.

RIM will launch two optional “app players” that provide an application run-time environment for BlackBerry Java® apps and Android v2.3 apps. These new app players will allow users to download BlackBerry Java apps and Android apps from BlackBerry App World and run them on their BlackBerry PlayBook.

In addition, RIM will shortly release the native SDK for the BlackBerry PlayBook enabling C/C++ application development on the BlackBerry® Tablet OS. For game-specific developers, RIM is also announcing that it has gained support from two leading game development tooling companies, allowing developers to use the cross-platform game engines from Ideaworks Labs and Unity Technologies to bring their games to the BlackBerry PlayBook.

It sounds as if the Android runtime will not be perfectly compatible with real Android:

Developers currently building for the BlackBerry or Android platforms will be able to quickly and easily port their apps to run on the BlackBerry Tablet OS thanks to a high degree of API compatibility.

Nevertheless, this will be an attractive route for Android developers looking for a quick way to port to the Blackberry.

The native SDK is currently in “limited alpha release” but RIM is promising an open beta for this summer.

The BlackBerry Tablet OS NDK will allow developers to build high-performance, multi-threaded, native C/C++ applications with industry standard GNU toolchains. Developers can create advanced 2D and 3D applications and special effects by leveraging programmable shaders available in hardware-accelerated OpenGL ES 2.0.

The deal with Unity is important too. Unity is an increasingly popular toolkit for game development and adding the Blackberry to the list of supported platforms will boost its appeal. Ideaworks Labs makes the Airplay SDK, a cross-platform toolkit which already supports Apple iOS, Android, Symbian, Samsung Bada, HP webOS and Windows Mobile.

Note that the primary SDK for the Playbook has until now been Adobe AIR; and since the UI itself uses the Flash runtime this likely still makes sense for many applications.

RIM is doing a good job of opening up its platform. It is an interesting contrast to Microsoft’s “Silverlight, XNA or nothing” approach for Windows Phone.

Silverlight in Microsoft products – Silverlight the new Windows runtime, HTML 5 the new Silverlight?

Is Microsoft ditching Silverlight and embracing HTML 5? Or is Silverlight the future of desktop and browser-based development on Microsoft’s platform?

Good question; and I am not sure that Microsoft itself can answer. There is evidence for both cases.

One thing I have noticed though is that Silverlight is turning up in numerous Microsoft products. This is in contrast to the early years of the original .NET Framework, which Microsoft used rather little in its own stuff, though the context is different today because of the growth in web-based development.

I guess we cannot really count Visual Studio LightSwitch, which is a tool that builds Silverlight applications, though it is interesting insofar as the target market is not expert developers, but smart general users who want to build database applications.

Lync Server 2010 is a better example. Silverlight is used for the control panel.

image

Windows Azure, a strategic product for Microsoft, uses Silverlight for its control panel

image

Windows Intune, for maintaining networks online

image

System Center for managing Microsoft servers. I’m not actually sure how much Silverlight is used in System Center, but I understand the newly announced “Concero”, a new feature for managing public and private clouds, uses a Silverlight control panel and I suspect it is used elsewhere as well.

image

These are a few that I am aware of; I would be interested in other examples.

Now, you can make sense of this to some extent by distinguishing “Windows platform” from “broad reach” applications. It is curious, but Silverlight which started out as a broad reach plugin is gradually moving towards a Windows platform runtime, though it still runs on a Mac with some limitations, mainly lack of COM interop. There has been speculation that Silverlight could merge with the desktop Windows Presentation Foundation and become a commonly used application runtime for desktop Windows as well as web apps, and of course Windows Phone.

When Microsoft wants broad reach, it uses HTML, an example being Office Web Apps which make hardly any use of Silverlight.

Nevertheless, using Silverlight for products like Windows Intune could be annoying for administrators who might otherwise use an Apple iPad when out and about; but I guess Microsoft figures that if you are deep enough into Windows to use Intune, you probably will not be using an iPad.

Let me add that Silverlight seems to me to be working well in the examples above, to the extent that I have tried it. Could they be done equally well in HTML and JavaScript? Probably, if users have IE9, but probably not if it is IE8 or earlier.

Silverlight the new Windows, HTML 5 the new Silverlight?

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.

Fast JavaScript engine in Apple iOS 4.3 is in standalone Safari only, but why?

Now that Apple iOS 4.3 is generally available for iPhone and iPad, users have noticed something that seems curious. The fast new “Nitro” JavaScript engine only works in the standalone Safari browser, not when a web app is pinned to the home screen, or when a web view is embedded into an app.

This link at mobilexweb.com shows the evidence. Here is the SunSpider test standalone, showing a time of 4098ms, and pinned to the home screen as an app, where it shows 10391.9ms:

image image

The consequence: apps created using WebKit as a runtime, for example using PhoneGap, will not get the benefit of Nitro.

It would be easy to conclude that Apple is deliberately hobbling these apps in order to protect native apps, which can only be installed via Apple’s App Store and are subject to its 30% cut. However that might not be the case. It could be a bug – according to Hacker News it has been reported as such:

To add another note to this, its a bug that Apple seems to know about. I can’t link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.

or it could be a security feature. Using a just-in-time compiler exposes the operating system more than just interpreting the code; perhaps Safari has more protection when running standalone.

Either way, with the increasing interest in WebKit as a de facto cross-platform application runtime for mobile, this particular limitation is unfortunate.

Update: There are also reports of the HTML 5 offline cache not working other than in full Safari:

I’ve tested this by switching apple-mobile-web-app-capable from ‘yes’ to ‘no’ and offline cache works as expected. But whenever it’s switched back to ‘yes’, it’s not working anymore. This occurs when the app is standalone at home screen. As a website, viewed with Safari cache is working as expected.

Guardian.co.uk enthuses about MongoDB, plans to ditch Oracle

The Guardian’s Mat Wall has spoken here at Qcon London about why it is migrating its web site away from Oracle and towards MongoDB.

He also said there are moves towards cloud hosting, I think on Amazon’s hosted infrastructure, and that its own data centre can be used as a backup in case of cloud failure – an idea which makes some sense to me.

So what’s wrong with Oracle? The problem is the tight relationship between updates to the code that runs the site, and the Oracle database schema. Significant code updates tend to require schema updates too, which means pausing content updates while this takes place. Journalists on a major news site hate these pauses.

MongoDB by contrast is not a relational database. Rather, it stores documents in JSON (JavaScript Object Notation) format. This means that documents with new attributes can be added to the database at runtime.

Although this was the main motivation for change, the Guardian discovered other benefits. Developer productivity is significantly better with MongoDB and they are enjoying its API.

Currently both MongoDB and Oracle are in use. The Guardian has written its own API layer to wrap database access and handle the complexity of having two radically different data stores.

I enjoyed this talk, partly thanks to Wall’s clear presentation, and partly because I was glad to hear solid pragmatic reasons for moving to a NoSQL data store.

QCon London kicks off with call to rediscover Agile, use open source

I’m at the QCon developer conference in London – one of my favourite developer conferences of the year because of its breadth and energy.

The opening keynote was from Craig Larman who spoke on doing lean and agile development – in particular, the Scrum methodology – with large multi-site teams. He means sizeable product groups of 500-1500 persons, though he also remarked that development on this scale is really a bad idea and that a team of 10 smart folk is much better.

Still, I guess large teams are an inevitability, and Larman has written books on the subject. I am not going to summarise the talk exactly, interesting though it was, but I am going to pick out a couple of asides which interested me.

Agile methodology is really about promoting communication; and one of Larman’s themes is that if you do what seems obvious, that is to break down a project into components and give one to each small team, then you end up with numerous teams that do not communicate well with each other. Agile becomes something you do in name only.

Larman spent a bit of time on which collaboration tools to use. One of his points was not to use any commercial tool that describes itself as being for agile project management or similar. I can think of several. He says these tools are just the commercial tool vendors repackaging their old non-agile tools. Whiteboards, spreadsheets on Google docs, wikis and other simple tools are his recommendation. For source code management he suggests Subversion, Git or other open source solutions. Never use Rational Clearcase, he added, it always causes problems.

In fact, he went on to say that any commercial tools cause problems when mutli-site development extends beyond to teams in developing countries. They cannot afford the licences, he says, so avoid them.

It seems to me that the common theme here is how easily agile development intentions become non-agile in practice, especially in these large project groups.

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.

Mono project: no plans for cross-platform WPF

Miguel de Icaza’s report from the Game Developer Conference is upbeat, rightly so in my view as usage of Mono is continuing to build, not only in game development with Unity, a development tool that uses Mono as its scripting engine, but also for mobile development for Apple’s iOS with Monotouch and for Android with Monodroid. These mobile toolkits also give Mono a stronger business model; many sites use Mono for serving ASP.NET applications on Linux, but without paying or contributing back to the project.

Mono is an open source implementation of C# and Microsoft’s .NET Framework.

That said, it is interesting that Mono is still struggling with an issue that has been a problem since its first days: how to implement Microsoft’s GUI (Graphical User Interface) framework on other platforms. Mono does have Gtk# for Windows, Mac and Linux, but this does not meet the goal of letting developers easily port their Visual Studio client projects to Mono. There is also an implementation of Windows.Forms, but de Icaza mentions that “our Windows.Forms is not actively developed.”

Apparently many tools vendors asked the Mono team at GDC when Windows Presentation Foundation (WPF) would be implemented for Mono. WPF is the current presentation framework for Microsoft.NET, though there is some uncertainty about where Microsoft intends to take it. I remember asking de Icaza about this back in 2003, when the WPF framework was first announced (then called Avalon); he said it was too complex and that he did not plan to implement it.

This is still the case:

We have no plans on building WPF. We just do not have the man power to build an implementation in any reasonable time-frame.

That said, Mono has implemented Silverlight, which is based on WPF, and there are some signs that Microsoft might merge WPF and Silverlight. What would the Mono team do then?

Miguel de Icaza says:

Silverlight runs on a sandbox, so you can not really P/Invoke into native libraries, or host DirectX/Win32 content inside of it.
There are other things missing, like menubar integration and things like that.

Of course, this is no longer true on Windows: Platform Invoke is coming in Silverlight 5.

Perhaps the Mono team will knuckle down and implement Silverlight with desktop integration, which would be good for cross-platform Silverlight and compatibility with Microsoft .NET.

Then again, it seems to me that Mono is increasingly divergent from Microsoft .NET, focusing on implementing C# in places that Microsoft does not touch, such as the mobile platforms from Apple and Google.

That is actually a sign of health; and you can understand why the Mono team may be reluctant to shadow Microsoft’s every move with Silverlight and WPF.

DevExpress developers ask for more Windows Forms, say Silverlight and WPF not ready

DevExpress, which creates add-on components and tools for Windows and Delphi, has posted its 2011 roadmap. This shows more convergence between components for Silverlight and WPF:

In essence, by the end of the year, the functionality of DXGrid, DXEditors, DXDocking, and DXRibbon will be the same across both platforms.

As for Windows Forms, or winforms, the roadmap says:

With regard to the Windows Forms controls, it is most likely that there will be a large number of smaller enhancements and new features rather than any large complex new control. The reason for this is simple: we believe that our offerings for this platform are very mature and robust.

Customers posting comments to CTO Julian Bucknall’s blog are not happy:

It is sad to see Winforms pushed back so much. WPF is still too slow on most computers for major apps and SL is not mature enough for a complete ERP app.

says Sigurd Decroos, while Heiko Mueller is more blunt:

Sorry guys, but with this roadmap I will not extend my subscription. I use only WinForms and ASP.NET and I’m not interested in WPF/Silverlight – WPF at this time for me is not suitable for my kind of applications (larger business Apps). Silverlight in my eyes is a dead technology – HTML5 is the future for rich internet applications.

Porting is also an issue says Ioannis Mpourkelis:

I believe that you should put more resources on the WinForms controls for 2011. Winforms is here to stay for many years, especially for the companies who want to support existing Winfroms applications. Currently it is impossible to port WinForms applicaitons to Silverlight and very difficult to port WinForms applications to WPF.

Check the full comments for more.

More evidence for the uncertainty around where Microsoft is going with its rich client API.

Update: Bucknall comments on this specific issue here.