Come sviluppare app per tablet line-of-business come sviluppatore .NET? [chiuso]

La mia azienda ha molta esperienza nello sviluppo di .NET e uno dei nostri prodotti in un sistema ERP. Di recente, un cliente ci ha chiesto se potevamo fornire un'interfaccia tablet per quel sistema, ovvero un software che consente al cliente di visualizzare le informazioni sul prodotto e creare ordini su un tablet.

Naturalmente, non siamo entusiasti dell'idea di investire un sacco di tempo e denaro nell'apprendimento di Objective-C, l'acquisto di workstation di sviluppo Mac, il pagamento di tasse ad Apple, ecc. Solo per questo progetto ( potremmo essere in grado di vendere l'app in seguito ad alcuni clienti aggiuntivi, ma il mercato è molto piccolo, poiché sarebbe utile solo per i clienti esistenti del nostro sistema ERP).

Quindi cosa dovremmo fare? Per quanto posso vedere, abbiamo le seguenti opzioni:

• Scrivi una " semplice vecchia applicazione Windows " (WPF) ed eseguila su un tablet Windows 7, come Samsung Slate o Acer Iconia.

  Svantaggi: dispositivi pesanti e costosi con tempi di esecuzione brevi (rispetto ai tablet "reali").

• Attendi i tablet basati su ARM di Windows 8 e scrivi un'app Metro (WinRT).

  Svantaggi: attendere almeno un anno; non è chiaro se Windows 8 ARM supporterà l'installazione di app B2B personalizzate senza passare attraverso l'app store.

• Usa mono per Android e scrivi un'app .NET per Android.

  Svantaggi: ancora un'altra libreria UI (diversa da WPF e Silverlight); alcuni provider non consentono il sideload delle app.

Finora, le opzioni 1 e 3 sembrano essere le più realistiche. Ho perso alcuni ovvi inconvenienti o vantaggi? C'è un'altra opzione che non ho ancora preso in considerazione? Sei stato in una situazione simile e (con successo) hai scelto un'opzione particolare?

Japery Mobile + Phone Gap Build .

Questo sta sostanzialmente dicendo "usa HTML5 e JavaScript per creare la tua app", come è stato detto prima, ma con una svolta importante.

Il servizio Phone Gap Build di Nitobi (ora di proprietà di Adobe) consente agli sviluppatori di convertire app HTML5 / JavaScript in app "native" (app realmente ibride) che possono essere distribuite localmente su un dispositivo. Capisco che fondamentalmente ciò che sta accadendo sotto il cofano è il confezionamento di un piccolo binario nativo che chiama il browser nativo e carica il tuo sito da un file: // URL.

Non è necessario targetizzare alcun framework JavaScript specifico: lo stesso HTML e JavaScript che funzionerebbe davvero bene in un'app Web mobile funzionerà bene.

Anche il supporto offline non è difficile. Con l'archiviazione del browser locale ben supportata con molti dispositivi mobili, puoi creare app offline davvero potenti in questo modo. È consigliabile impacchettare localmente le dipendenze esterne anziché utilizzare una rete CDN, in modo che l'app funzioni correttamente offline.

Frame come KnockoutJS e BackboneJS sono molto utili per consentirti di creare app JavaScript ben progettate e funzionano perfettamente con il servizio di build di Phone Gap.

Quando il dispositivo è online, puoi facilmente farlo colpire back-end del servizio ASP.NET/MVC, WebAPI o WCF per aggiornare i dati.

Le app risultanti sono davvero abbastanza buone e possono essere distribuite sui mercati Apple e Android. Esistono già molte app in quei mercati costruiti con Phone Gap Build e altri prodotti simili e il 99% delle persone (inclusa la maggior parte degli sviluppatori) non può dire la differenza.

Ovviamente non proverai a costruire Angry Birds in questo modo (anche se, con Canvas, suppongo che potresti provare), funziona meravigliosamente bene con il tipo di app di cui stai parlando.

Non crederci sulla parola. PhoneGap ha fatto il giro del circuito PodCast, essendo stato recentemente su Hanselminutes , DotNetRocks e Tablet Show . Inoltre, ne ho scritto in un recente post sul blog .

visualizzare le informazioni sul prodotto e creare ordini

Sembra roba che rientra nelle capacità di HTML 5 (e delle tecnologie correlate di solito menzionate nello stesso respiro). Scrivi un'applicazione Web avanzata e supporti immediatamente qualsiasi dispositivo con un browser .

Consiglierei di svilupparlo come app Web MVC. Ciò ti consentirebbe di eseguirlo su quasi tutti i dispositivi da un desktop a uno smartphone, purché tu lo abbia progettato bene. HTML5 potrebbe funzionare ma dipenderà dai tipi di dispositivi / browser che dovrai supportare. Sarebbe bello se riuscissi a cavartela usando. Assicurati di progettarlo in modo da poter adattare parti di esso per essere un backend WCF a un'app Metro in futuro.

Se si desidera sfruttare la conoscenza di .NET esistente, è necessario adottare un approccio SOA e inserire quante più funzionalità possibile in un servizio Web (SOAP o REST, scegliere quello che si adatta meglio). In questo modo è necessaria solo una piccola app client sul dispositivo, che chiamerebbe solo la funzionalità del servizio Web e visualizzerebbe i risultati. Questo dovrebbe essere molto più semplice da sviluppare rispetto a un client completo che implementa la logica aziendale, indipendentemente dal client scelto.

Consente inoltre di aggiungere supporto per diversi dispositivi in ​​un secondo momento, tutto ciò che serve è una piccola app client per il nuovo dispositivo.

Per scegliere un dispositivo, vedo due criteri:

1. Scegli quello che il tuo attuale cliente preferisce (se chiedono un'app per tablet, ci avranno pensato)
2. Scegli quello che molto probabilmente sarà accettato anche dagli altri clienti. Questo potrebbe benissimo essere l'iPad, o forse il Kindle Fire, perché le persone hanno già visto quelli.

In ogni caso, non aspettare i dispositivi che non sono ancora sul mercato. Ciò escluderebbe l'opzione 2 (Windows 8 su tablet ARM).

Qualsiasi applicazione Windows significherà che sei legato alla SM. Inoltre, Silverlight e iOS / IE 10 non vanno bene insieme. Scegli HTML 5 e JavaScript con servizi Web e / o JQuery. Strumenti di terze parti come l' interfaccia utente di Telerik-Kendo dovrebbero rendere la tua GUI abbastanza interessante per l'app LOB. Dot Net potrebbe essere utile solo sul lato server.

Quell'ultimo commento dice tutto davvero: "Dot Net potrebbe essere utile solo sul lato server", forse Microsoft avrebbe dovuto chiamarlo. No? O .WindowsOnly?

Non puoi nemmeno scrivere app sul lato client di Windows RT in .Net.

È vero che per giocare nel gioco multipiattaforma, la tua logica aziendale e i tuoi servizi di dati scritti in .Net devono vivere su un server Windows ed esporre un'API web friendly. L'API Web ASP.Net più recente è quasi un punto di forza industriale nell'aprile 2013. Ciò ti consentirà di esporre i tuoi oggetti .Net come JSON in modo che le app lato client JQuery / JS possano integrarsi facilmente.

Sul lato client, non è possibile utilizzare .Net. Devi scrivere tutto il tuo codice UI in HTML / CSS / JQuery e la tua logica usando JS con forse Knockout per l'associazione orientata ai dati.

Per noi sviluppatori .Net, disegnare semplicemente la nostra interfaccia utente SENZA DETERMINARE IL MARKUP è il Nirvana dello sviluppo di app LOB. Chiunque proponga un framework .Net lato client che funziona così come VS / .Net / WinForms / C # / VB.Net governerà il mondo - e NO - a mio avviso Mono non è da nessuna parte (nessun supporto da fornitori di componenti di terze parti) vicino VS / .Net / WinForms.