Компромиссы между нативными приложениями и кроссплатформенными решениями на Android и iOS (iPhone / iPad) - PullRequest
0 голосов
/ 20 мая 2011

Я собираюсь заняться разработкой приложения для планшетов (Android / iPad).Наши клиенты просят нас сделать его кроссплатформенным, если нет причин придерживаться его.Я просмотрел здесь несколько постов, связанных с кроссплатформенной разработкой для iOS / Android, но я все еще не уверен, стоит ли мне просто разрабатывать нативное приложение на конкретной платформе или я должен попытаться сделать его кроссплатформенным.Я новичок в разработке приложений для мобильных устройств.Если вы можете дать какой-либо совет / опыт, это было бы здорово!

Насколько я знаю, по техническим причинам компромиссы заключаются в следующем:

  • Собственные приложениябыстрее, но нелегко повторно использовать коды на других платформах.
  • Кроссплатформенные решения с использованием веб-приложений (например, PhoneGap) имеют более низкую производительность, ограниченный доступ к ОС и аппаратным API-интерфейсам, веб-интерфейс пользователя.
  • Кроссплатформенные решения, такие как Appcelerator Titaniumскомпилируйте коды в нативные коды, но я не уверен насчет его ограничения (если мне придется изменить его на нативное приложение после разработки в течение трех месяцев, я заплачу!), и это стоит денег.

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

Есть предложения?

Заранее спасибо!:)

Ответы [ 2 ]

1 голос
/ 20 мая 2011

Лично я бы придерживался нативных приложений.Я работаю в компании, которая хочет создавать приложения для нескольких платформ, и они искали альтернативы нативной разработке, такие как Titanium и PhoneGap.Мы выбрали следующий подход:

  • Меня наняли для разработки приложения для iPhone.
  • Некоторые студенты университета, вероятно, будут работать над версией Android, гдеФреймворк / слой данных будет выглядеть и работать примерно так же, как мой код Objective-C, например:

-getFlightInfoWithId:forUserId: станет чем-то вроде (void)getFlightInfo(flightId, userId) в Java.

Вид и уровни контроллера, вероятно, будут сильно отличаться, в основном потому, что устройства Android и iOS имеют разные рекомендации и возможности графического интерфейса (например, размеры экрана Android могут сильно различаться, тогда как в iOS есть только 2 реальных варианта).

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

0 голосов
/ 20 мая 2011

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

Хорошая новость заключается в том, что вы можете делиться активами между ними.

Полагаю, вы могли бы написать большие куски вашей версии для iPad на C, а затем скомпилировать ее для Android через NDK, но есть все, что связано с пользовательским интерфейсом, и поэтому все еще будет две версии.

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