9

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?

Heinzi
  • 9,646
  • 3
  • 46
  • 59
  • 2
    @Downvoter: Feedback to improve the question is appreciated... – Heinzi Mar 07 '12 at 13:49
  • 11
    You forgot two other options: 1.) learning Java and writing an Android app or 2.) Saying no – Jetti Mar 07 '12 at 13:57
  • For some advice on mobile development for .NET developers, listen to this podcast: http://hanselminutes.com/305/monotouch-and-mono-for-android-with-trainer-john-sonmez. – Treb Mar 07 '12 at 15:00
  • There is a plugin for Visual Studio that allows you to write Android and Apple applications in .Net – ediblecode Mar 07 '12 at 15:38
  • @danRhul: Do you have a link to that? – FrustratedWithFormsDesigner Mar 07 '12 at 15:58
  • 1
    @FrustratedWithFormsDesigner See my answer – ediblecode Mar 07 '12 at 16:09
  • Why are you *not thrilled* to develop a skill that you may later exploit? Is the money not good? You may want to tell the client that. I urge you to think of it in terms of opportunity cost of *letting go* learning Objective-C vs learning it and exploiting the skills for your company in the future! You ARE getting an option to enter a potential new space!! I suggest you crunch some numbers to ascertain whether it's worth it *before* seeking advice, IMHO :) – PhD Mar 08 '12 at 03:27
  • @Nupul: Personally, I love learning new languages and doing new and exciting stuff. However, we *have* done the math and, simply put, as a company, investing into professional Objective-C development is not worth the expected revenue for us (compared to the other options we have). – Heinzi Mar 08 '12 at 10:50
  • @Heinzi - then you have an answer! That too an economically backed one! Have you told this too your client?? – PhD Mar 08 '12 at 17:58
  • 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 08 '12 at 20:48
  • @Jetti: It might interest you that, for performance reasons, your option 1.) was the one successfully used in the end (after trying a HTML-based solution). – Heinzi Jul 25 '13 at 08:34
  • @Heinzi good to know. I'm a big advocate for the right tool for the job, even if it is inconvenient. – Jetti Jul 28 '13 at 00:38

6 Answers6

13

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.

AakashM
  • 2,107
  • 16
  • 20
  • 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 07 '12 at 15:02
  • 3
    @Treb - Jakob Nielsen has some interesting thoughts on this topic: http://www.useit.com/alertbox/mobile-sites-apps.html – jfrankcarr Mar 07 '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 07 '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 07 '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 07 '12 at 17:58
  • It's notable that when they're done writing it this way, and Windows 8 comes along... it supports html+js for metro applications. – Steven Evers Mar 08 '12 at 02:23
10

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.

Kyle
  • 2,773
  • 17
  • 24
4

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.

jfrankcarr
  • 5,082
  • 2
  • 19
  • 25
3

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

Treb
  • 1,638
  • 15
  • 15
0

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.

NoChance
  • 12,412
  • 1
  • 22
  • 39
-1

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.

TriSys
  • 1
  • 1
  • 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 02 '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 '14 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 '14 at 15:43