Есть ли какое-то преимущество в программировании для мобильной разработки? - PullRequest
12 голосов
/ 19 ноября 2011

Мне нужно разработать приложения для компании на некоторых основных мобильных ОС, в частности, на iOS, Android и WP7.

Сначала я планировал написать три отдельных приложения для трех разных ОС, каждое из которых использовало собственный SDK.

Однако, есть ли какое-то преимущество в этом? Существует множество кроссплатформенных инструментов - Sencha, Phonegap, Rhodes и т. Д. Насколько «родными» приложения, созданные ими, чувствуются на разных устройствах? Какую аппаратную интеграцию они имеют (камера, GPS, локальное хранилище и т. Д.)?

У меня нет ограничений по времени, и у меня нет абсолютно никаких проблем при разработке трех собственных приложений, если есть какое-либо преимущество.

РЕДАКТИРОВАТЬ: В случае, если это имеет значение, приложения будут иметь как онлайн, так и в автономном режиме, функции.

Ответы [ 4 ]

18 голосов
/ 19 ноября 2011

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

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

Я собираюсь предположить, что вы говорите о кроссплатформенных решениях на основе HTML (таких как PhoneGap , Sencha и Rhodes ), а не кроссплатформенные игровые платформы, такие как Corona SDK или Moai , а также не всегда интересные Mono через MonoTouch и Mono для Android . Я также исключаю Titanium , который не поддерживает Windows Phone.

Ниже приведены некоторые пробелы между нативными и этими кроссплатформенными решениями HTML:

  • Пользовательский интерфейс
  • Производительность (особенно пользовательский интерфейс)
  • Совместимость
  • Debugging
  • API платформ

Пользовательский интерфейс

Пользователи каждой платформы создают определенные ожидания относительно того, как все работает. Приложения в iOS часто имеют определенные парадигмы пользовательского интерфейса (эта строка вверху с кнопкой «Назад» слева, эти округленные пользовательские интерфейсы таблиц / списков и т. Д.), Приложения в Android могут иметь другую (например, ActionBar, которая похожа, но не совсем). так же, как панель iOS, или долго нажимаемые элементы для контекстных меню), пользователи Windows Phone еще один (плитки и панорамы). Если вы создадите тот же HTML-интерфейс, вы, вероятно, не сможете воспользоваться этим. Эти знакомые шаблоны пользовательского интерфейса делают приложение более интуитивным и удобным для пользователя, который обычно не тратит свое время на изучение нескольких платформ.

Performance

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

Совместимость

Еще одним недостатком использования кроссплатформенного инструмента HTML является то, что разные телефоны по-разному работают с HTML / CSS / JavaScript. Это смешно, потому что это немного обоюдоострый меч. С одной стороны, замечательно, что HTML по своей природе является кроссплатформенным, с другой - у вас все еще возникают проблемы, зависящие от устройства. Это особенно актуально для Android, где у вас так много разных устройств, и где производители почему-то любят возиться с реализацией WebView s. Вы получаете небольшие ошибки, когда определенные устройства делают странные вещи. Если вы работаете полностью нативно, у вас, как правило, лучшая совместимость (конечно же, за счет увеличения объема работы). Также не хватает поддержки более старых версий Android.

Debugging

Отладка JavaScript - не самый замечательный опыт на мобильной платформе. Вы заканчиваете тем, что сделали много регистрации к консоли. Это выполнимо, но, конечно, не так приятно, как построчно входить в ваш код. Похоже, что в этом направлении есть некоторый прогресс (см., Например, этот инструмент, называемый weinre ), но я не могу комментировать, насколько он хорош, поскольку я не удосужился в него разобраться.

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

API платформы

В целом, крупные игроки, о которых вы упомянули, имеют довольно приличную аппаратную поддержку. Функции, которые вы упомянули, такие как камера, GPS и локальное хранилище, занимают важное место в списке функций, важных для разработчиков приложений, поэтому они включают их. Для получения полного списка функций вы, вероятно, захотите перейти на веб-сайт каждой из них (например, диаграмма поддержки функций PhoneGap высокого уровня по платформам ), но, как правило, это большие "телефонные функции", которые Вы думаете о том, что есть. Несмотря на это, есть куча более сложных вещей, которые, насколько я знаю, эти платформы не делают или не делают так же хорошо, особенно вещи, которые имеют меньшее отношение к функциям телефона и больше связаны с платформой. Threading является одним из примеров.

4 голосов
/ 19 ноября 2011

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

  • производительность (издержки интерпретатора, задержка JIT или потеря оптимизации кросс-компиляции),

  • объем памяти и время загрузки приложения,

  • будет ли API-интерфейс промежуточного звена работать с новейшими и лучшими API-интерфейсами устройств и аппаратными функциями достаточно скоро (если они вам нужны),

  • существуют ли специфичные для устройства (не кроссплатформенные) API-интерфейсы, которые посреднический API предоставляет или не предоставляет, и можно ли их добавить,

  • независимо от того, предоставляет ли промежуточный уровень или позволяет ли вы переопределить его возможности представления UX / UI, чтобы приложение выглядело так, чтобы оно работало и выглядело "должным" в каждом целевом сообществе устройств или магазине приложений,

  • однократная запись, повсеместная отладка (плюс многоплатформенное регрессионное тестирование исправления для любой одной платформы) и т. Д.

Обратите внимание, что неэффективность работы может проявляться в более быстрой разрядке батареи в дополнение или вместо видимой задержки интерфейса пользователя.

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

2 голосов
/ 03 апреля 2012

Я лично использую PhoneGap.Я держу свою пользовательскую библиотеку как минимум, возможно, использую только Jquery Mobile.И пока код javascript хорошо написан, возможно, используйте фреймворк mvc, я действительно не замечаю какой-либо потери производительности.

Иногда я использую удаленный php-сервер для базы данных, и ajax-вызовы выполняются гладко, иногда я использую html5-хранилище, которое также работает гладко.

Так что, если вы не хотите учитьсяJava или цель-c ...:)

1 голос
/ 19 ноября 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...