My company has a lot of experience in .NET development, and one of our products

Question

My company has a lot of experience in .NET development, and one of our products in an ERP system. Recently, a customer asked us if we could provide a tablet interface to that system, i.e., a software that allows the customer to view product information and create orders on a tablet.

Of course, we are not thrilled about the idea of investing a lot of time and money into learning Objective-C, purchasing Mac development workstations, paying fees to Apple, etc. just for this one project (we might be able to sell the app to a few additional customers afterwards, but the market is very small, since it would only be useful for existing customers of our ERP system).

So, what should we do? As far as I can see, we have the following options:

Write a "plain old Windows application" (WPF) and run it on a Windows 7 tablet, such as the Samsung Slate or Acer Iconia.

Drawbacks: Heavy, expensive devices with short running time (as compared to "real" tablets).

Wait for Windows 8 ARM-based tablets and write a Metro (WinRT) app.

Drawbacks: Wait for at least one year; it's unclear whether Windows 8 ARM will support installation of custom B2B apps without going through the app store.

Use mono for Android and write a .NET app for Android.

Drawbacks: Yet another UI library (different from WPF and Silverlight); some providers disallow sideloading of apps.

So far, options 1 and 3 seem to be the most realistic. Did I miss any obvious drawbacks or advantages? Is there another option that I haven't considered yet? Have you been in a similar situation and (successfully) chosen one particular option?

Explanation / Answer

JQuery Mobile + Phone Gap Build.

This is basically saying "use HTML5 and JavaScript to build your app", as has been said before, but with an important twist.

Nitobi's Phone Gap Build service (now owned by Adobe) allows developers to convert HTML5/JavaScript apps to "native" apps (really hybrid apps) that can be deployed locally to a device. It's my understanding that basically what's happening under the hood is packaging a small native binary that calls the native browser and loads up your site from a file:// URL.

You don't need to target any specific JavaScript framework - the same HTML & JavaScript that would work really well in a mobile web app will work fine.

Offline support isn't hard, either. With local browser storage well supported with many mobile devices you can build truly powerful offline apps this way. Its best practice to package your external dependencies locally as opposed to using a CDN, so that your app works well offline.

Frameworks like KnockoutJS and BackboneJS are very helpful at allowing you to build well engineered JavaScript apps, and they work just fine with Phone Gap's build service.

When the device is online, you can easily have it hit ASP.NET/MVC, WebAPI or WCF service back ends to refresh data.

The resulting apps are really quite good, and can be distributed in the Apple and Android markets. There are already lots of apps in those marketplaces built with Phone Gap Build and other similar products, and 99% of people (including most devs) can't tell the difference.

Obviously you aren't going to try to build Angry Birds this way (though, with Canvas I suppose you might try), it works wonderfully well with the kinds of apps you are talking about.

Don't take my word for it. PhoneGap has been doing the rounds on the PodCast circuit, having recently been on Hanselminutes, DotNetRocks, and the Tablet Show. Also, I wrote about it in a recent blog post.

Related Questions

Navigate

• Browse (All)
• Browse M
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.