Продвижение битвы мобильного приложения "родной против 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

Ответ 1

Вот простой пример для 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, я думаю, что его решение о том, чтобы лица, принимающие решения, признали, что его не только родные разработчики, такие как родные, но и поставщики платформ, такие как родные решения, а это означает, что лучше, более качественные приложения сделанные в синхронизации с улучшениями ОС. В свою очередь это означает, что пользователи счастливых приложений имеют лучший мобильный опыт.

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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