Любое преимущество программирования для мобильной разработки?

Ответ 1

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

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

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

Некоторые пробелы, которые я вижу между родными и этими кросс-платформенными решениями, выглядят следующим образом:

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

Знакомство с пользовательским интерфейсом

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

Производительность

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

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

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

Отладка

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

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

API-интерфейсы платформы

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Итак, если вы не хотите изучать java или objective-c...:)

Ответ 4

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

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