Таргетинг / разработка для нескольких мобильных платформ с одним языком программирования (C #)? Затрат и выгод? - PullRequest
24 голосов
/ 17 марта 2011

Сегодня можно использовать программирование на C # для нескольких мобильных платформ, таких как:

(не стесняйтесь редактировать, если я что-то пропустил) Конечно, это все еще программирование для пользовательского интерфейса, но основные библиотеки приложения могут быть общими.

Мы все можем поблагодарить команду, собравшуюся вокруг Mono project и superhero Miguel de Icaza , чьи усилия бесценны.

Что меня беспокоит, каковы преимущества этих опций? Является ли стоимость обслуживания одного приложения на нескольких мобильных платформах менее трудоемкой, чем необходимость кодировать каждую библиотеку отдельно для повышения производительности. Кривая обучения каждого языка? Быть мастером на все руки против .NET Ninja

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

ОБНОВЛЕНИЕ : Очевидно, есть еще одна вещь, которую следует учитывать, и это поддержка. Поскольку Novell куплена Attachmate Group, вся команда Mono уволена. Однако основной член команды, возглавляемой Мигелем Де Икаса , основал новую компанию Xamarin , которая с нуля будет заново изобретать инструменты разработки Mono Mobile.

Ответы [ 8 ]

19 голосов
/ 23 марта 2011

По моему мнению, большим преимуществом использования единой среды (например, C # /. NET) является переносимость кода. И такие классные вещи, как LINQ, без которых вы не сможете жить. Тем не менее, несколько мобильных ОС (iOS, Android, WP7) довольно сильно отличаются от интерфейса пользователя.

И, если я не ошибаюсь в отношении вашего приложения, оно получает значительную долю взаимодействий пользовательского интерфейса, если оно запускается на мобильном устройстве. Большинство мобильных приложений имеют код 80% пользовательского интерфейса.

Таким образом, вы все равно будете писать отдельный набор кода пользовательского интерфейса для каждой платформы - например, вы будете писать в Silverlight WP7 (и во всем доброте WPF), вы будете писать совершенно разные Набор кода для iOS в Какао (IB, Views, контроллеры и прочее), вы будете писать еще совершенно другой набор кода для Android.

Мой опыт всегда заключался в том, что для написания хорошего кода пользовательского интерфейса на любой платформе требуется большой опыт, например изучение WPF / SL - это уже кошмар, бросить в Cocoa Touch и весь беспорядок в Android. Конечно, вы можете написать три набора пользовательского интерфейса, которые выглядят и чувствуют себя достаточно схожими, но есть вероятность, что вы будете изо всех сил пытаться повторно использовать код и иметь общие структуры данных, что ваш пользовательский интерфейс окажется на уровне ниже по сравнению с выделенными приложениями - - и в этом современном мире мобильных приложений современный пользовательский интерфейс не супер (не говоря уже о подпункте) означает смерть для вашего приложения.

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

Максимум, что вы собираетесь использовать - это внутренние модули. Механизмы принятия решений, процедуры поиска, управление данными и т. Д. И даже это будет проблематично, поскольку вам придется идти на компромиссы в своих структурах данных, чтобы обеспечить простую интеграцию с тремя различными наборами кода пользовательского интерфейса, работающими над тремя различными парадигмами пользовательского интерфейса. , Например, используете ли вы DependencyObjects для использования для привязки к представлениям Silverlight в модели MVVM? Если вы это сделаете, это не будет работать с моделью Какао MVC, и вам придется кодировать эти привязки отдельно.

И поскольку не все мобильные среды позволяют использовать полный набор функций - например, MonoTouch для iOS не имеет общих конструкций, которые невозможно определить во время компиляции. По сути, вы используете очень маленькое подмножество .NET (и должны постоянно напоминать себе, какую функциональность можно использовать где), чтобы вы могли запускать их все на трех разных платформах без существенных изменений.

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

По-моему, боль и компромиссы не стоят того. В итоге вы получите три приложения, которые не понравятся людям ни на одной из платформ.

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

2 голосов
/ 20 августа 2012

С тех пор, как принятый ответ был написан в 2011 году, появилась пара различных сред, которые переносят шаблоны MVC и MVVM в Mono для Android и MonoTouch, что очень помогает при разработке приложений для этих цели.

Для MVC проверьте проект под названием MonoCross

Для MVVM проверить Stuart Lodge * MvvmCross

Последний содержит много кода для открытия изображений на трех платформах, составления электронных писем, открытия веб-браузеров, воспроизведения звуков и многого другого. Это также обрабатывает навигацию между ViewModels.

2 голосов
/ 24 марта 2011

Самым большим преимуществом для меня является возможность многократного использования бизнес-логики и кода связи между мобильными платформами. Да, я должен писать интерфейс снова и снова, и нужно время, чтобы разобраться с этим, но по крайней мере мою базовую платформу можно использовать повторно.

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

0 голосов
/ 07 марта 2014

Кроссплатформенное решение работает только в том случае, если ваше приложение простое и понятное. Если вам требуются сложные функции, такие как локальное хранилище данных со сложными графами объектов, переходите на родную систему или ожидайте, что потратите месяцы на устранение неполадок

0 голосов
/ 19 апреля 2011

Еще один способ взглянуть на это - вы можете перенести существующее приложение .NET / C # на различные мобильные клиенты (как нативные, так и нативные), относительно легко используя сервер интеграции WebORB .На стороне клиента вам придется кодировать на родном языке, или вы можете создать приложение Adobe AIR, которое достаточно переносимо для различных мобильных ОС, таких как iOS, Android и BlackBerry PlayBook.

0 голосов
/ 20 марта 2011

Преимущества:

  • Кодируйте все на одном языке и (в основном) можно использовать на каждой платформе
  • Сокращенное время разработки
  • Дешевле

Недостатки:

  • Включение необходимых библиотек значительно увеличивает минимальный размер приложения - если ваше приложение будет большим, тогда разница не столь значительна
  • Снижение производительности

Если у вас есть деньги и люди, всегда лучше, чтобы некоторые люди сосредоточились на iPhone и Objective-C, некоторых Android и Java и т. Д. Таким образом, ваши программисты будут иметь глубокие знания платформы, на которую вы нацелены, и будут быть в состоянии убедиться, что ваше приложение в полной мере использует возможности платформы - приложение не должно быть одинаковым (за исключением, возможно, игр) на всех платформах, вам нужно играть на их сильных и слабых сторонах: приложение для iPhone должно выглядеть и функционировать как приложение для iPhone и т. д.

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

0 голосов
/ 17 марта 2011

Существуют определенные недостатки для библиотек Monotouch / Droid.Небольшое снижение скорости (около 5%, поэтому в большинстве случаев пренебрежимо мало).

По моему опыту, размер не сильно отличается.Большая часть размера находится в ресурсах (ресурсы данных, упакованные изображения и т. Д., А не в использовании процессора), и большинство приложений не несут с собой столько ресурсов (из-за времени загрузки и доступности большого количествастандартные элементы управления на мобильных платформах).

Однако я не думаю, что вы должны использовать фреймворки в играх.У меня нет большого опыта в разработке мобильных игр, но довольно разные фреймворки, которые вы используете в разработке игр (XNA, Android NDK ...) и потребность в системных ресурсах (загрузка процессора, память и т. Д.) Делают их довольно бесполезнымиIMHO.

0 голосов
/ 17 марта 2011

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

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

...