Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
@Downvoter: Feedback to improve the question is appreciated... –  Heinzi Mar 7 '12 at 13:49
11  
You forgot two other options: 1.) learning Java and writing an Android app or 2.) Saying no –  Jetti Mar 7 '12 at 13:57
    
For some advice on mobile development for .NET developers, listen to this podcast: hanselminutes.com/305/…. –  Treb Mar 7 '12 at 15:00
1  
@FrustratedWithFormsDesigner See my answer –  danRhul Mar 7 '12 at 16:09
1  
@Nupul: No, I don't have an answer, I have just one option (writing a native iPad app in Objective-C) ruled out. There are still other options, which might be economically feasible, hence my question here. ;-) –  Heinzi Mar 8 '12 at 20:48
show 7 more comments

6 Answers 6

up vote 10 down vote accepted

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.

share|improve this answer
    
+1 I think this is the best compromise to writing a native tablet app. –  Eric King Mar 7 '12 at 17:27
    
I might just try this to get an app or two off the ground... –  DmainEvent Aug 14 '13 at 21:08
add comment

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.

share|improve this answer
2  
From a technical point of view you are right, but in my experience people who are willing to buy tablets expect something more shiny than a web app. –  Treb Mar 7 '12 at 15:02
2  
@Treb - Jakob Nielsen has some interesting thoughts on this topic: useit.com/alertbox/mobile-sites-apps.html –  jfrankcarr Mar 7 '12 at 15:07
2  
Many tablets allow for you to "install" the web app so it appears to act like an application. So I wouldn't count this out because HTML5 doesn't appear app-like. This seems like the best option to me. –  RationalGeek Mar 7 '12 at 15:54
3  
Also... this doesn't rule out having two parts: Web App and Native app. HTML5 is a blanket option... once that's built and operational, you can create an optional Android/Apple/Metro/Blackberry app if the business opts for it. Many sites give you the option of installing an app for their site. –  WernerCD Mar 7 '12 at 17:07
2  
@Treb - It's possible to make a pretty shiny web app. I'd at least look into their shine related requirements. –  psr Mar 7 '12 at 17:58
show 1 more comment

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.

share|improve this answer
add comment

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).

share|improve this answer
    
As of today's announcement, wrt Microsoft Surface, the devices may very soon be in the market. –  Mamta Dalal Jun 19 '12 at 9:59
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I have to downvote this answer because of the false statement "You can't even write Windows RT client-side apps in .Net." –  Ramhound Apr 2 '13 at 13:32
    
Sorry, I completely disagree with your assertion that you can write .Net applications for Windows RT - where is your proof? –  TriSys Apr 30 at 14:51
    
I will bite. What do you mean exactly by "client-side apps" because I took it has something very specific a year ago. Because I promise you I have written .NET 4.5.1 Windows Store/WinRT applications and published them to the store. I used C# if your wondering and the entire application is stored client side. –  Ramhound Apr 30 at 15:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.