Comment développer des applications de tablette métier en tant que développeur .NET? [fermé]

Mon entreprise a beaucoup d'expérience dans le développement .NET et l'un de nos produits dans un système ERP. Récemment, un client nous a demandé si nous pouvions fournir une interface tablette à ce système, c'est-à-dire un logiciel qui permet au client de visualiser les informations produit et de créer des commandes sur une tablette.

Bien sûr, nous ne sommes pas ravis de l'idée d'investir beaucoup de temps et d'argent dans l'apprentissage d'Objective-C, l'achat de postes de travail de développement Mac, le paiement de frais à Apple, etc. juste pour ce seul projet (nous pourrions peut- être vendre l'application à quelques clients supplémentaires par la suite, mais le marché est très petit, car il ne serait utile que pour les clients existants de notre système ERP).

Alors, que devrions-nous faire? Pour autant que je puisse voir, nous avons les options suivantes:

• Écrivez une " ancienne application Windows " (WPF) et exécutez-la sur une tablette Windows 7, telle que Samsung Slate ou Acer Iconia.

  Inconvénients: appareils lourds et coûteux avec un temps de fonctionnement court (par rapport aux "vraies" tablettes).

• Attendez les tablettes Windows 8 ARM et écrivez une application Metro (WinRT).

  Inconvénients: Attendez au moins un an; il n'est pas clair si Windows 8 ARM prendra en charge l'installation d'applications B2B personnalisées sans passer par l'App Store.

• Utilisez mono pour Android et écrivez une application .NET pour Android.

  Inconvénients: Encore une autre bibliothèque d'interface utilisateur (différente de WPF et Silverlight); certains fournisseurs interdisent le chargement latéral des applications.

Jusqu'à présent, les options 1 et 3 semblent être les plus réalistes. Ai-je raté des inconvénients ou des avantages évidents? Y a-t-il une autre option que je n'ai pas encore envisagée? Avez-vous été dans une situation similaire et avez-vous (avec succès) choisi une option particulière?

JQuery Mobile + Phone Gap Build .

Cela revient à dire "utilisez HTML5 et JavaScript pour créer votre application", comme cela a été dit précédemment, mais avec une touche importante.

Le service Phone Gap Build de Nitobi (qui appartient maintenant à Adobe) permet aux développeurs de convertir des applications HTML5 / JavaScript en applications "natives" (applications vraiment hybrides) qui peuvent être déployées localement sur un appareil. Je crois comprendre que ce qui se passe sous le capot consiste à empaqueter un petit binaire natif qui appelle le navigateur natif et charge votre site à partir d'un fichier: // URL.

Vous n'avez pas besoin de cibler un cadre JavaScript spécifique - le même code HTML et JavaScript qui fonctionnerait très bien dans une application Web mobile fonctionnera bien.

Le support hors ligne n'est pas difficile non plus. Le stockage sur navigateur local étant bien pris en charge par de nombreux appareils mobiles, vous pouvez ainsi créer des applications hors ligne vraiment puissantes. Il est préférable de regrouper vos dépendances externes localement plutôt que d'utiliser un CDN, afin que votre application fonctionne bien hors ligne.

Des cadres comme KnockoutJS et BackboneJS sont très utiles pour vous permettre de créer des applications JavaScript bien conçues, et ils fonctionnent très bien avec le service de construction de Phone Gap.

Lorsque l'appareil est en ligne, vous pouvez facilement le faire accéder aux services principaux ASP.NET/MVC, WebAPI ou WCF pour actualiser les données.

Les applications résultantes sont vraiment très bonnes et peuvent être distribuées sur les marchés Apple et Android. Il existe déjà de nombreuses applications sur ces marchés construits avec Phone Gap Build et d'autres produits similaires, et 99% des personnes (y compris la plupart des développeurs) ne peuvent pas faire la différence.

Évidemment, vous n'allez pas essayer de construire Angry Birds de cette façon (cependant, avec Canvas, je suppose que vous pourriez essayer), cela fonctionne à merveille avec les types d'applications dont vous parlez.

Ne me croyez pas sur parole. PhoneGap a fait le tour du circuit PodCast, ayant récemment été sur Hanselminutes , DotNetRocks et le Tablet Show . J'ai également écrit à ce sujet dans un récent article de blog .

afficher les informations sur les produits et créer des commandes

Cela ressemble à des trucs bien dans les capacités de HTML 5 (et les technologies connexes généralement mentionnées dans le même souffle). Écrivez une application Web riche et vous supportez immédiatement n'importe quel appareil avec un navigateur .

Je recommanderais de le développer en tant qu'application Web MVC. Cela vous permettrait de l'exécuter sur la plupart des appareils, du bureau au smartphone, à condition de bien le concevoir. HTML5 pourrait fonctionner, mais cela dépendra des types d'appareils / navigateurs que vous devrez prendre en charge. Ce serait bien si vous pouviez vous en passer. Assurez-vous que vous l'architectez à un endroit où vous pourriez en adapter des parties pour en faire un backend WCF à une application Metro à l'avenir.

Si vous souhaitez tirer parti des connaissances .NET existantes, vous devriez opter pour une approche SOA et mettre autant de fonctionnalités que possible dans un service Web (SOAP ou REST, choisissez celle qui vous convient le mieux). De cette façon, vous n'avez besoin que d'une petite application cliente sur l'appareil, qui n'appellerait que la fonctionnalité de service Web et afficherait les résultats. Cela devrait être beaucoup plus facile à développer qu'un client complet qui implémente la logique métier, quel que soit le client que vous choisissez.

Il permet également d'ajouter la prise en charge de différents appareils plus tard, tout ce dont vous avez besoin est une petite application cliente pour le nouvel appareil.

Pour choisir un appareil, je vois deux critères:

1. Choisissez celle que vos clients actuels préfèrent (s'ils demandent une application pour tablette, ils y auront réfléchi)
2. Choisissez également celui qui est le plus susceptible d'être accepté par les autres clients. Cela pourrait très bien être l'iPad, ou peut-être le Kindle Fire, car les gens l'ont déjà vu.

Dans tous les cas, n'attendez pas des appareils qui ne sont pas encore sur le marché. Cela exclurait votre option 2 (Windows 8 sur les tablettes ARM).

Toute application Windows signifie que vous êtes lié à MS. De plus, Silverlight et iOS / IE 10 ne vont pas bien ensemble. Optez pour HTML 5 et JavaScript avec les services Web et / ou JQuery. Des outils tiers tels que l' interface utilisateur Telerik-Kendo devraient rendre votre interface graphique suffisamment cool pour l'application LOB. Dot Net ne pouvait être utile que côté serveur.

Ce dernier commentaire dit tout: "Dot Net ne peut avoir de valeur que du côté serveur" - peut-être que Microsoft aurait dû l'appeler .Non? Ou .WindowsOnly?

Vous ne pouvez même pas écrire des applications côté client Windows RT dans .Net.

Il est vrai que pour jouer dans le jeu multiplateforme, votre logique métier et vos services de données écrits en .Net, doivent vivre sur un serveur Windows et exposer une API Web conviviale. La dernière API Web ASP.Net est presque une force industrielle en avril 2013. Cela vous permettra d'exposer vos objets .Net en tant que JSON afin que les applications côté client JQuery / JS puissent s'intégrer facilement.

Côté client, vous ne pouvez pas utiliser .Net. Vous devez écrire tout votre code d'interface utilisateur en HTML / CSS / JQuery et votre logique en utilisant JS avec peut-être Knockout pour la liaison orientée données.

Pour nous développeurs .Net, dessiner simplement notre interface utilisateur SANS AVOIR À ÉCRIRE LE MARQUAGE est le Nirvana du développement d'applications LOB. Quiconque propose un framework .Net côté client qui fonctionne aussi bien que VS / .Net / WinForms / C # / VB.Net gouvernera le monde - et NON - à mon avis, Mono n'est nulle part (pas de support des fournisseurs de composants tiers) près de VS / .Net / WinForms.