Планирование битвы мобильного приложения «родной против html5»

Я разработчик iOS (родной) и с тех пор, как появился App Store. С тех пор я узнал немного Windows-Phone и Android. Я заметил неизбежную тенденцию к созданию веб-приложений HTML5 над родными, и, похоже, он растет быстрее, чем я ожидал. Это разочаровывает меня как родного разработчика, так как в большинстве случаев существует много аргументов для перехода на родной язык, и только несколько для перехода на HTML5 (т. Е. Это кросс-платформенный!), Но эти несколько последних аргументов, похоже, превосходят прежние И больше в эти дни, иногда по причинам, которые недействительны.

Я не покупаю идею о том, что «будущее» мобильных приложений находится в HTML5 и с такими инструментами, как PhoneGap, которые позволяют массовое распространение по платформам. Опыт работы с веб-приложениями всегда будет подпадать по сравнению с родным приложением, и, кроме того, многие мифы, как правило, плавают вокруг него. Например, «Клиенты не будут платить за разработку на нескольких платформах, это слишком дорого!» Это миф, если многие клиенты действительно знают разницу в качестве приложений, которые они получают, они будут платить за это. Это время от времени доказывают лидеры отрасли, которые по большей части не создают веб-приложения для клиентов. Я даже знаю о близком судебном процессе, который имел место, когда генеральный директор получал приложение, которое они передавали на аутсорсинг, и это приложение PhoneGap / HTML5. Он (по праву) был в ярости в компании, которая обещала «приложение» и хотела знать, почему она не чувствовала или не реагировала как другие его приложения, что приводило к беспорядку.

Другие мифы включают в себя то, что переход на HTML5-маршрут экономит столько кода и времени, но это не обязательно так. Тестирование, связанное с устройствами / платформами, не говоря уже о количестве CSS и javascript, участвующих в создании функции приложения на этих платформах, как правило, приводит к беспорядку кода и многому количеству отработанных отладочных проблем. Обычный пользовательский разработчик мог вытащить простые навигационные / подробные представления на основе списков в течение нескольких часов на нескольких платформах, когда он, скорее всего, займет примерно одно и то же время, чтобы создать HTML5 для «имитации» и подделать ту же самую точную функциональность и посмотреть / почувствовать , Кроме того, как насчет того, что переход по маршруту PhoneGap / HTML5 будет ВСЕГДА гарантировать, что вы позади, а не на переднем крае платформ и технологий?

Мое самое большое разочарование заключается в том, что сейчас кажется, что некоторые магазины разработки иногда даже рекомендуют подход PhoneGap / HTML5 к клиентам с любовью к тому, что он является кросс-платформенным и т. Д., Даже не объясняя клиенту (кто иногда может быть невежественным) о том, что Это влечет за собой разницу в производительности и внешнем виде.

Я определенно хочу идти в ногу со временем и готовиться к худшему, поэтому я разветвляюсь, чтобы изучить эти инструменты, но мне просто интересно, как вы, ребята (другие разработчики), справляетесь с подобными вещами? Разве я один в своем размышлении об этом? Любые советы о том, как рационально объяснить людям, как сделать этот процесс принятия решений?

Прежде чем я получу ответы об этом, обратите внимание, что я полностью понимаю, что есть моменты, когда маршрут веб-приложения – это правильный путь, и я полностью понимаю, что есть некоторые клиенты, которые просто не будут платить за родной, так что это хорошо. Я также понимаю, что прогнозы показывают, что процент приложений HTML5 будет продолжать расти с годами. Однако я просто не согласен с растущим мышлением, что «все приложения должны быть HTML5, и мы просто используем родные части, когда Возникает потребность (например, камера и т. Д.) ». Мое личное мнение заключается в том, что все должно быть наоборот: «Все приложения должны быть родными, если только отдельные элементы пользовательского интерфейса и функциональные возможности не будут легче / быстрее работать в HTML5». Компании могут найти собственных разработчиков, которые быстро кода и имеют доступ к библиотекам кода, чтобы сделать собственную разработку так же быстро, если не намного быстрее, чем делать это через веб-приложение.

Мысли? Я заранее извиняюсь, если это неправильный форум для такого рода вещей, но я очень хочу получить мнения и советы. Благодаря! -Vincent

Вот простой пример для Native vs. HTML5. С технической точки зрения, нет ничего, что помешало бы решению на основе браузера стать таким же мощным, как и родное решение, но его НИКОГДА не произойдет, и вот почему: Продвинутые продавцы: у Apple, Google и Microsoft нет стимула для этого. Думаю об этом. Если бы они полностью стандартизировали его, то было бы мало или вообще не было бы преимуществ для их платформ. Давайте возьмем сообщение в качестве примера. Могли бы вы получить лучшие службы обмена сообщениями Apple или Android, поставляемые через HTML5? Конечно, вы могли бы, но почему разработчик платформы возьмет этот маршрут? Почему они девальвируют SDK iOS или Android SDK? Так что это действительно похоже на то, что войны в браузере разыгрываются только в мобильном пространстве. Когда начались войны с браузером, все подумали, что uber-браузер появится, но он так и не появился, и на этот раз он не будет по той же причине. Так что это не просто технический вопрос, как описано, открытый и закрытый. Это тот факт, что вендеры не будут предоставлять свои последние и самые лучшие в открытом виде. Это одна из причин, по которой большинство решений для перекрестных платформ являются шагом вперед по сравнению с выпусками поставщиков.

Другим примером этого будет поддержка WebGL. Поддержка WebGL заняла гораздо больше времени, чем нужно. Когда-то что-то лучше, чем WebGl, оно будет предлагаться сначала в native, а затем WebGL, наконец, будет полностью поддерживаться во всех браузерах, на каждом крупном устройстве. Но поддержка всегда будет отставать от родного. Дело в основе браузеров всегда будет на один шаг ниже, потому что это так, как это делают вендоры.

Также обратите внимание, что многие клиенты приложений считают, что переход на HTML5 значительно больше совместим с Интернетом / Интернетом, поскольку на самом деле собственные приложения используют HTTP так же, как и приложения HTML5. Это распространенное заблуждение, поскольку большинство собственных приложений используют доступ к услугам через HTTP, как и приложение HTML5. Единственное различие заключается в том, что вы обрабатываете запросы и ответы в javascript по сравнению с обычным способом.

Безопасность – еще одна важная проблема для рассмотрения, сколько безопасных приложений использует HTML5? Бьюсь об заклад, большинство приложений, которые делают безопасные транзакции, являются родными и не без оснований.

Было бы полезно, если бы люди могли предоставить примеры функций, которые недавно были выпущены в Android или iOS, и уровень поддержки тех функций, которые предоставляет PhoneGap, и что является дорожной картой PhoneGAP в поддержке этих функций sdk. Другими словами, когда вышла новая версия SDK, PhoneGAP не находится на этапе блокировки, и ни один из них не является титаном. Однако PhoneGap – это, на мой взгляд, основное соревнование с родным решением, и поэтому его сравнение с родным будет наиболее значимым. Я думаю, что сравнение родного с проприетарным SDK, который является кросс-платформенным, – пустая трата времени. Это никогда не будет достаточно привлекательным, чтобы предоставить либо PhoneGAP, либо Native для заработка.

Предупреждение для тех, кто взволнован с помощью PhoneGap. Встроенные плагины могут существовать на всех платформах, которые вам нужны, но что, если вам нужно написать свой собственный плагин для PhoneGap? (Вы собираетесь узнать реальную историю за GAP в PhoneGAP) Либо потому, что вы хотите сделать что-то совершенно иное, чем существующий плагин, или потому, что хотите настроить существующий плагин. Это не сценарий, который разворачивается повсеместно. Вам нужно написать собственный плагин для каждой платформы, на которой вы хотите включить эту функцию. Другими словами, вы снова вернулись на родину. Поэтому вам лучше потратить время на тщательную оценку плагинов (на всех платформах, на которых вы собираетесь запускать приложение HTML5), и убедитесь, что они теперь и в будущем, что вам нужно. С другой стороны, HTML5 без PhoneGAP довольно неустойчив и ограничен, и вы вскоре сможете самостоятельно переписать PhoneGAP.

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

Когда вы запускаете приложение HTML5, вы, в основном, запускаете свое приложение в другом приложении, а именно в браузере. Приложение для браузера настолько же мощно, насколько это позволяет платформенный агент. И если история – это какое-то руководство, она будет развиваться, и больше функций будет добавлено, но никогда не будет оптимально, никогда не синхронизироваться со всеми другими вендорами и никогда не будет в том же темпе, что и базовая ОС и SDK, как по техническим, так и по бизнес-причинам.

Пользователи хотят получить лучший опыт, и следует отметить, что, хотя у вас много людей, которые владеют андроидами, и у многих, кто владеет iPhones и iPads, относительно мало кто владеет обоими одновременно. Другими словами, пользователь Android позаботился о iOS-версии вашего приложения, и пользователь iOS мог бы не беспокоиться о вашем приложении для Android. Но пользователь действительно заботится о том, как приложение работает на своей платформе выбора. Они не хотят, чтобы на обеих платформах работало наполовину, потому что они никогда не видели его на обеих платформах. Пользователь практически всегда использует приложение на одной платформе за раз.

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

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

По моему опыту многие мобильные кросс-платформенные решения, такие как Phonegap, Appcelerator или Adobe Air, выходят из строя, если вы хотите создать несколько серьезных приложений. Возможно, в будущем эти решения улучшатся.

На данный момент я рекомендую для разработки мобильных приложений следующее:

  • Очень простые приложения (всего несколько просмотров), ничего особенного: Идите за Phonegap. Простые приложения отлично работают с телефонной связью, и у вас есть «кросс-платформенное» решение.
  • Все, что немного сложнее (много серверной связи, синхронизации и т. Д.): Идите для Native. В этом случае инструменты API / производительности / отладки собственных приложений часто являются более значительными, чем «кросс-платформенный аргумент».

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

Это аналогично вопросу о том, «какой один язык программирования будет побеждать в будущем?» Или (sotto voce) vi vs emacs. Существует несколько способов сделать приложение. У Native есть свои преимущества, а также HTML5, в зависимости от проблемы и набора навыков разработчика. Я рекомендую вам ознакомиться с обоими рабочими процессами, которые будут лучше квалифицировать вас, чтобы сделать рекомендацию в будущем, а также принять чье-то мнение по возможности.

Несколько важных вопросов. Будет ли когда-нибудь большой способ метапрограммирования? Как Титан или первоначальная идея Java. Кроме того, есть вещи, которые лучше реализованы изначально, такие как карты. Кроме того, увеличение CPU, память делает некоторые аргументы в пользу родного менее релевантным.