Jak tworzyć aplikacje na tablety dla firm jako programista .NET? [Zamknięte]

Moja firma ma duże doświadczenie w programowaniu .NET i jeden z naszych produktów w systemie ERP. Ostatnio klient zapytał nas, czy możemy udostępnić interfejs tabletu do tego systemu, tj. Oprogramowanie, które pozwala klientowi przeglądać informacje o produkcie i tworzyć zamówienia na tablecie.

Oczywiście nie jesteśmy podekscytowani pomysłem zainwestowania dużo czasu i pieniędzy w naukę Objective-C, zakup stacji roboczych Mac, płacenie opłat Apple, itp. Tylko za ten jeden projekt ( być może będziemy w stanie sprzedać aplikację do kilku kolejnych klientów, ale rynek jest bardzo mały, ponieważ byłby użyteczny tylko dla obecnych klientów naszego systemu ERP).

Więc co powinniśmy zrobić? O ile widzę, mamy następujące opcje:

• Napisz „ zwykłą starą aplikację Windows ” (WPF) i uruchom ją na tablecie Windows 7, takim jak Samsung Slate lub Acer Iconia.

  Wady: Ciężkie, drogie urządzenia o krótkim czasie działania (w porównaniu do „prawdziwych” tabletów).

• Poczekaj na tablety z systemem Windows 8 ARM i napisz aplikację Metro (WinRT).

  Wady: Poczekaj co najmniej rok; nie jest jasne, czy ARM systemu Windows 8 będzie obsługiwał instalację niestandardowych aplikacji B2B bez przechodzenia przez sklep z aplikacjami.

• Użyj mono na Androida i napisz aplikację .NET na Androida.

  Wady: Kolejna biblioteka interfejsu użytkownika (inna niż WPF i Silverlight); niektórzy dostawcy nie zezwalają na boczne ładowanie aplikacji.

Jak dotąd opcje 1 i 3 wydają się najbardziej realistyczne. Czy przegapiłem jakieś oczywiste wady lub zalety? Czy jest jeszcze inna opcja, której jeszcze nie rozważałem? Czy byłeś w podobnej sytuacji i (z powodzeniem) wybrałeś jedną konkretną opcję?

JQuery Mobile + Phone Gap Build .

To w zasadzie mówi „użyj HTML5 i JavaScript, aby zbudować swoją aplikację”, jak już powiedziano wcześniej, ale z istotną zmianą.

Usługa Nitobi Phone Gap Build (obecnie należąca do Adobe) pozwala programistom konwertować aplikacje HTML5 / JavaScript na aplikacje „natywne” (naprawdę aplikacje hybrydowe), które można wdrażać lokalnie na urządzeniu. Rozumiem, że w zasadzie to, co dzieje się pod maską, to pakowanie małego natywnego pliku binarnego, który wywołuje natywną przeglądarkę i ładuje witrynę z pliku: // URL.

Nie musisz celować w żadną konkretną strukturę JavaScript - ten sam HTML i JavaScript, który działałby naprawdę dobrze w mobilnej aplikacji internetowej, działałby dobrze.

Wsparcie offline też nie jest trudne. Dzięki dobrze obsługiwanej pamięci lokalnej przeglądarki na wielu urządzeniach mobilnych możesz w ten sposób tworzyć naprawdę potężne aplikacje offline. Najlepszą praktyką jest lokalne pakowanie zewnętrznych zależności w przeciwieństwie do korzystania z sieci CDN, dzięki czemu aplikacja działa dobrze w trybie offline.

Struktury takie jak KnockoutJS i BackboneJS są bardzo pomocne w tworzeniu dobrze zaprojektowanych aplikacji JavaScript i działają dobrze z usługą kompilacji Phone Gap.

Gdy urządzenie jest w trybie online, możesz łatwo trafić w zaplecze usługi ASP.NET/MVC, WebAPI lub WCF, aby odświeżyć dane.

Powstałe aplikacje są naprawdę całkiem dobre i mogą być dystrybuowane na rynkach Apple i Android. Na tych platformach handlowych jest już wiele aplikacji zbudowanych przy użyciu Phone Gap Build i innych podobnych produktów, a 99% ludzi (w tym większość programistów) nie jest w stanie powiedzieć różnicy.

Oczywiście nie będziesz próbował budować Angry Birds w ten sposób (choć przypuszczam, że w przypadku Canvas możesz spróbować), działa on doskonale z rodzajami aplikacji, o których mówisz.

Nie wierz mi na słowo. PhoneGap obchodzi rundę obwodu PodCast, ostatnio w Hanselminutes , DotNetRocks i Tablet Show . Pisałem także o tym w ostatnim poście na blogu .

przeglądaj informacje o produkcie i twórz zamówienia

Brzmi jak rzeczy dobrze mieszczące się w możliwościach HTML 5 (i powiązanych technologii zwykle wspomnianych jednocześnie). Napisz bogatą aplikację internetową, a od razu będziesz obsługiwać dowolne urządzenie z przeglądarką .

Polecam opracowanie go jako aplikacji internetowej MVC. Umożliwiłoby to uruchomienie go na większości dowolnych urządzeń, od komputera do smartfona, pod warunkiem, że dobrze go zaprojektujesz. HTML5 może działać, ale będzie zależeć od typów urządzeń / przeglądarek, które musisz obsługiwać. Byłoby miło, gdybyś mógł z niego korzystać. Upewnij się, że zaprojektowałeś go w taki sposób, aby w przyszłości można go było dostosować jako backend WCF do aplikacji Metro.

Jeśli chcesz wykorzystać istniejącą wiedzę .NET, powinieneś wybrać podejście SOA i umieścić jak najwięcej funkcji w usłudze sieciowej (SOAP lub REST, wybierz to, co bardziej Ci odpowiada). W ten sposób potrzebujesz tylko małej aplikacji klienckiej na urządzeniu, która wywoływałaby tylko funkcjonalność usługi sieciowej i wyświetlała wyniki. Powinno to być znacznie łatwiejsze do opracowania niż w pełni rozwinięty klient, który implementuje logikę biznesową, bez względu na wybranego klienta.

Pozwala także na późniejsze dodawanie obsługi różnych urządzeń, wszystko czego potrzebujesz to niewielka aplikacja kliencka dla nowego urządzenia.

Aby wybrać urządzenie, widzę dwa kryteria:

1. Wybierz ten, który preferuje twój obecny klient (jeśli poprosi o aplikację na tablet, zastanowi się nad tym)
2. Wybierz ten, który najprawdopodobniej zostanie zaakceptowany również przez innych klientów. Może to być iPad, a może Kindle Fire, ponieważ ludzie już je widzieli.

W każdym razie nie czekaj na urządzenia, które nie są jeszcze dostępne na rynku. To wykluczałoby twoją opcję 2 (Windows 8 na tabletach ARM).

Każda aplikacja Windows oznacza, że ​​jesteś związany ze stwardnieniem rozsianym. Ponadto Silverlight i iOS / IE 10 nie idą w parze. Wybierz HTML 5 i JavaScript z usługami sieciowymi i / lub JQuery. Narzędzia innych firm, takie jak Telerik-Kendo UI, powinny sprawić, że GUI będzie wystarczająco fajne dla aplikacji LOB. Dot Net może mieć wartość tylko po stronie serwera.

Ten ostatni komentarz mówi wszystko tak naprawdę: „Dot Net może mieć wartość tylko po stronie serwera” - być może Microsoft powinien to nazwać. Nie? Lub .WindowsOnly?

Nie możesz nawet pisać aplikacji po stronie klienta Windows RT w .Net.

Prawdą jest, że aby grać w grę międzyplatformową, logika biznesowa i usługi danych napisane w .Net muszą żyć na serwerze Windows i udostępniać interfejs API przyjazny dla sieci. Najnowszy interfejs API sieci Web ASP.Net ma niemal przemysłową siłę w kwietniu 2013 r. Pozwoli to na ujawnienie obiektów .Net jako JSON, dzięki czemu aplikacje po stronie klienta JQuery / JS będą mogły zostać łatwo zintegrowane.

Po stronie klienta nie można używać .Net. Musisz napisać cały kod UI w HTML / CSS / JQuery i logikę używając JS z być może Knockout do wiązania danych.

Dla nas, deweloperów .Net, po prostu rysunek naszego interfejsu użytkownika BEZ PISANIA MARKUPU to nirwana tworzenia aplikacji LOB. Ktokolwiek wymyśli platformę .Net po stronie klienta, która działa tak dobrze, jak VS / .Net / WinForms / C # / VB.Net, będzie rządzić światem - i NIE - moim zdaniem Mono nigdzie (brak wsparcia ze strony zewnętrznych dostawców komponentów) w pobliżu VS / .Net / WinForms.