How to develop line-of-business tablet apps as a .NET developer?

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?

Answer 1

view product information and create orders

Sounds like stuff well within the capability of HTML 5 (and the related technologies usually mentioned in the same breath). Write a rich Web application, and you immediately support any device with a browser.

Answer 2

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.

Answer 3

I'd recommend developing it as a MVC web app. This would allow you to run it on most any device from a desktop to a smartphone provided you design it well. HTML5 might work but it will depend on the types of devices/browsers you'll need to support. It would be nice if you can get away with using it. Make sure that you architect it where you could adapt portions of it to be a WCF backend to a Metro app in the future.

Answer 4

If you want to leverage the existing .NET knowledge, you should go for a SOA approach, and put as much functionality as possible into a web service (SOAP or REST, pick whichever suits you better). That way you only need a small client app on the device, which would only call the web service functionality and display the results. This should be much easier to develop than a full blown client which implements business logic, no matter which client you choose.

It also allows for adding support for different devices later on, all you need is a small client app for the new device.

In order to pick a device, I see two criteria:

1. Pick the one your current customer favours (if they ask for a tablet app, they will have given some thought to it)
2. Pick the one that is most likely to be accepted by other customers as well. This could very well be the iPad, or perhaps the Kindle Fire, because people have already seen those.

In any case, don't wait for devices that are not on the market yet. That would rule out your option 2 (Windows 8 on ARM tablets).

Answer 5

Any Windows application will mean that you are tied to MS. Also, Silverlight and iOS/IE 10 don't go together well. Go for HTML 5 and JavaScript with Web Services and/or JQuery. Third party tools such as Telerik-Kendo UI should make your GUI cool enough for LOB App. Dot Net could only be of value on the server side.

Answer 6

That last comment says it all really: 'Dot Net could only be of value on the server side' - perhaps Microsoft should have called it .Not? Or .WindowsOnly?

You can't even write Windows RT client-side apps in .Net.

It is true that in order to play in the cross platform game, your business logic and data services written in .Net, have to live on a windows server and expose a Web friendly API. The latest ASP.Net Web API is almost industrial strength in April 2013. This will allow you to expose your .Net objects as JSON so that JQuery/JS client-side apps can integrate easily.

On the client side, you cannot use .Net. You have to write all your UI code in HTML/CSS/JQuery and your logic using JS with perhaps Knockout for data oriented binding.

For us .Net developers, simply drawing our user interface WITHOUT HAVING TO WRITE MARKUP is the Nirvana of developing LOB apps. Whoever comes up with a client side .Net framework which works as well as VS/.Net/WinForms/C#/VB.Net will rule the world - and NO - in my opinion Mono is nowhere (no support from 3rd party component vendors) near VS/.Net/WinForms.