Как разрабатывать бизнес-приложения для планшетов в качестве разработчика .NET? [закрыто]

Моя компания имеет большой опыт разработки .NET и один из наших продуктов в системе ERP. Недавно клиент спросил нас, можем ли мы предоставить планшетный интерфейс для этой системы, то есть программное обеспечение, которое позволяет клиенту просматривать информацию о продукте и создавать заказы на планшете.

Конечно, мы не в восторге от идеи инвестировать много времени и денег в изучение Objective-C, покупку рабочих станций для Mac, оплату Apple и т. Д. Только для этого одного проекта ( возможно, мы сможем продать приложение впоследствии нескольким дополнительным клиентам, но рынок очень маленький, так как это будет полезно только для существующих клиентов нашей ERP-системы).

Так что нам делать? Насколько я вижу, у нас есть следующие варианты:

• Напишите « простое старое приложение Windows » (WPF) и запустите его на планшете с Windows 7, например, Samsung Slate или Acer Iconia.

  Недостатки: тяжелые, дорогие устройства с коротким временем работы (по сравнению с «настоящими» планшетами).

• Дождитесь появления планшетов на базе Windows 8 ARM и напишите приложение Metro (WinRT).

  Недостатки: подождите не менее года; неясно, будет ли Windows 8 ARM поддерживать установку пользовательских приложений B2B без прохождения через магазин приложений.

• Используйте моно для Android и напишите приложение .NET для Android.

  Недостатки: еще одна библиотека пользовательского интерфейса (отличается от WPF и Silverlight); некоторые провайдеры запрещают загрузку приложений.

Пока что варианты 1 и 3 кажутся наиболее реалистичными. Я упустил какие-либо очевидные недостатки или преимущества? Есть ли другой вариант, который я еще не рассмотрел? Вы были в подобной ситуации и (успешно) выбрали один конкретный вариант?

JQuery Mobile + Phone Gap Build .

По сути, это говорит о том, что «используйте HTML5 и JavaScript для создания своего приложения», как было сказано ранее, но с одной важной особенностью.

Служба Phone Gap Build от Nitobi (в настоящее время принадлежит Adobe) позволяет разработчикам преобразовывать приложения HTML5 / JavaScript в «родные» приложения (действительно гибридные приложения), которые можно развернуть локально на устройстве. Насколько я понимаю, в основном то, что происходит под капотом, - это упаковка небольшого собственного двоичного файла, который вызывает собственный браузер и загружает ваш сайт из файла: // URL.

Вам не нужно ориентироваться на какую-либо конкретную среду JavaScript - те же HTML и JavaScript, которые действительно хорошо работают в мобильном веб-приложении, будут работать нормально.

Оффлайн поддержка тоже не сложная. Благодаря локальному хранилищу браузера, который поддерживается многими мобильными устройствами, вы можете создавать действительно мощные автономные приложения таким образом. Рекомендуется локально упаковать внешние зависимости, а не использовать CDN, чтобы ваше приложение работало в автономном режиме.

Такие фреймворки, как KnockoutJS и BackboneJS , очень помогают вам создавать хорошо спроектированные приложения JavaScript, и они прекрасно работают со службой сборки Phone Gap.

Когда устройство подключено к сети, вы можете легко подключить его к серверам ASP.NET/MVC, WebAPI или WCF, чтобы обновить данные.

Получающиеся приложения действительно весьма хороши и могут распространяться на рынках Apple и Android. На этих торговых площадках уже есть множество приложений, созданных с помощью Phone Gap Build и других подобных продуктов, и 99% людей (включая большинство разработчиков) не могут заметить разницу.

Очевидно, что вы не будете пытаться создавать Angry Birds таким образом (хотя, я полагаю, вы можете попробовать и с Canvas), он прекрасно работает с типами приложений, о которых вы говорите.

Не верь мне на слово. PhoneGap проводил обходы на схеме PodCast , недавно был на Hanselminutes , DotNetRocks и Tablet Show . Кроме того, я написал об этом в недавнем сообщении в блоге .

просматривать информацию о продукте и создавать заказы

Звучит как вещи в рамках возможностей HTML 5 (и связанные с ними технологии обычно упоминаются на одном дыхании). Напишите богатое веб-приложение, и вы сразу же поддержите любое устройство с браузером .

Я бы рекомендовал разработать его как веб-приложение MVC. Это позволит вам запускать его практически на любом устройстве, от настольного компьютера до смартфона, при условии, что вы хорошо его спроектируете. HTML5 может работать, но это будет зависеть от типов устройств / браузеров, которые вам необходимо поддерживать. Было бы неплохо, если бы вы могли обойтись без него. Убедитесь, что вы спроектировали его так, чтобы в будущем его части можно было использовать в качестве бэкенда WCF для приложения Metro.

Если вы хотите использовать имеющиеся знания .NET, вы должны использовать подход SOA и использовать как можно больше функциональных возможностей в веб-сервисе (SOAP или REST, выберите тот, который вам больше подходит). Таким образом, вам нужно только небольшое клиентское приложение на устройстве, которое будет вызывать только функциональность веб-службы и отображать результаты. Это должно быть намного легче разработать, чем полноценный клиент, который реализует бизнес-логику, независимо от того, какой клиент вы выберете.

Это также позволяет добавить поддержку различных устройств позже, все, что вам нужно, это небольшое клиентское приложение для нового устройства.

Чтобы выбрать устройство, я вижу два критерия:

1. Выберите тот, который предпочитает ваш нынешний клиент (если они попросят приложение для планшета, они об этом подумают)
2. Выберите тот, который, скорее всего, будет принят другими клиентами. Это может быть iPad или Kindle Fire, потому что люди уже видели это.

В любом случае, не ждите устройств, которых еще нет на рынке. Это исключило бы ваш вариант 2 (Windows 8 на планшетах ARM).

Любое приложение Windows будет означать, что вы привязаны к MS. Кроме того, Silverlight и iOS / IE 10 плохо сочетаются друг с другом. Перейти на HTML 5 и JavaScript с веб-службами и / или JQuery. Сторонние инструменты, такие как Telerik-Kendo UI, должны сделать ваш графический интерфейс достаточно крутым для приложения LOB. Dot Net может иметь значение только на стороне сервера.

В последнем комментарии действительно все сказано: «Dot Net может быть полезен только на стороне сервера» - возможно, Microsoft следовало бы назвать это. Не так ли? Или .WindowsOnly?

Вы даже не можете писать клиентские приложения Windows RT в .Net.

Это правда, что для того, чтобы играть в кроссплатформенную игру, ваша бизнес-логика и службы данных, написанные на .Net, должны жить на сервере Windows и предоставлять дружественный для Web API. Последний веб-API ASP.Net стал практически промышленным в апреле 2013 года. Это позволит вам представить ваши объекты .Net в виде JSON, чтобы легко интегрировать клиентские приложения JQuery / JS.

На стороне клиента вы не можете использовать .Net. Вы должны написать весь свой код пользовательского интерфейса в HTML / CSS / JQuery и свою логику, используя JS с, возможно, Knockout для привязки к данным.

Для нас, разработчиков .Net, просто рисование нашего пользовательского интерфейса БЕЗ НАПИСАНИЯ МАРКУПА - это Нирвана разработки LOB-приложений. Кто бы ни придумал клиентскую платформу .Net, которая работает так же, как VS / .Net / WinForms / C # / VB.Net, будет править миром - и НЕТ - на мой взгляд, Mono нигде нет (никакой поддержки от сторонних поставщиков компонентов) возле VS / .Net / WinForms.