Нативный интерфейс. Гибридные, Нативные и Мобильные Web приложения: взгляд изнутри
Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:
JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.
Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.
Titanium !== HTML
Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.
Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.
Что ты имеешь в виду под «Нативной» разработкой?
В ответ я стал спрашивать:А что делает приложение нативным?
Может быть, то что…
- Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
- Разработчик использует стандартный для платформы язык?
- Приложение использует строительные блоки (API), которые предоставляет платформа?
- Приложение работает так, как ожидает пользователь на этой платформе?
Что такое хороший User Experience?
Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.Выглядит и ведет себя ожидаемо
iOS, Android и Windows имеют различные требования к дизайну (iOS , Android ,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.
Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView .
Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.
Чувствуется ожидаемо
Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView , он может быть на 60% более отзывчивым, чем его предок, TableView .
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».
Как достичь классного UX?
Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!
Гибридная и нативная разработки: сравним?
Гибридные приложения или нативные (от англ. native – родной)? Это один из самых главных вопросов, который возникает у заказчика программного обеспечения, когда ему требуется выпустить новое приложение для пользования потребителем.
Давайте начнем с определения каждого из них. Гибридное приложение, как это и звучит, сочетает в себе элементы как родного (приложение работает без каких - либо внешней поддержки) и Web (приложение работает с помощью браузера и, как правило, написано на HTML5) приложений. Приложение заимствует кросс-совместимые веб - технологии, такие как HTML5, CSS и Javascript и использует часть собственного кода для большей приспособленности к пользовательскому устройству. Гибридные приложения размещаются внутри собственного приложения где находится WebView мобильной платформы (браузер в комплекте внутри мобильного приложения, если можно так выразиться). Проще говоря, гибрид приложение представляет собой веб-сайт, который упакован в оригинальную обертку. Примеры брендов, использующих гибридные приложения: Amazon App Store, Gmail и Yelp.
Нативное приложение разработано для определенной мобильной операционной системы (Objective-C /Swift для iOS или Java для Android) и оптимизировано в полной мере использовать все возможности платформы (камера, список контактов, GPS и т. д.). По существу, нативное приложение реализуется с помощью собственных инструментов платформы. Примеры таких приложений включают Старбак, Home Depot, Facebook (хотя с последним некоторые не согласны).
Рассмотрим некоторые важные соображения, которые помогут вам выбрать между нативным или гибридным приложением.
Стоимость разработки
Гибридные приложения разрабатываются для многих платформ. Идентичный HTML-код может быть применен и повторно использован на более чем одной мобильной операционной системе. Проще говоря, когда вы заказываете разработку гибридного приложения, ваш конечный продукт будет работать сразу на большинстве современных смартфонов и планшетов. Таким образом, ваши затраты на разработку значительно снижаются.
Разработка нативного приложения, с другой стороны, требует написания совершенно разных программ для каждого уникального устройства. В отличие от гибридного программирования, которое заимствует информацию из предыдущего опыта HTML5 в интернете, нативное программирование часто считается более специализированными. Таким образом, увеличивается стоимость, что непрактично для небольших компаний и частных лиц.
Время
Гибридные приложения часто нравятся компаниям, стремящимся поставить что-то на рынок массового потребления как можно скорее. Опять же, так как тот же HTML-код повторно используется для различающихся операционных систем и только часть комплексного машинного кода должна быть переписана, приложение будет готово для работы на нескольких устройствах в самом скором времени, как только возможно.
Если время не является приоритетом, то нативная разработка может подходить для вас. В ином случае гибридная будет предпочтительнее.
Обновления
Гибридная разработка позволяет обновлять контент непосредственно из Интернета. Если нет какого-то резкого изменения функциональности, то обновления получаются практически незаметные. Многие из этих обновлений могут быть установлены не через App Store. Это делает исправление ошибок и добавление обновлений более эффективным, и заставляет пользователя меньше раздражаться. Тем не менее, есть одно предостережение, связанное с веб-обновлениями.
Может возникнуть ситуация, когда приложение ориентировано на особенности мобильной платформы, которая больше не работает, потому что плагин устарел. Когда это происходит, вы сталкиваетесь с дилеммой – необходимо либо удалить функцию приложения или нанять программиста, чтобы написать плагин. Тот же сценарий применяется при выходе новых версий мобильной платформы. Если вы хотите, чтобы ваше приложение могло использовать новые возможности, вы снова даете разработчику задание создать плагин для размещения обновления, или можете подождать, пока сообщество создаст.
При нативной разработке, вы можете обновить приложение, чтобы обрабатывать изменения платформы, и пользоваться новыми возможностями, не рассчитывая на постоянную поддержку сообщества ваших плагинов и, не будучи зависимым от циклов выпуска сообщества. Для гибридной же разработки необходимо проводить всесторонний учет надежности плагинов, чтобы избежать неприятных неожиданностей в ближайшем будущем.
Пользователи
С нативного приложения можно легко использовать широкий функционал мобильного устройства: камеру, микрофон, GPS и многое другое. При этом кривая обучения пользователя невелика.
Родные приложения также обычно разрабатываются для использования, когда нет Wi - Fi или возможности получения данных извне. Гибрид может также работать в автономном режиме, у вас просто будет немного меньше вариантов.
Стоит отметить, что скорость отклика при прочих равных условиях обычно выше у нативных приложений. Это часто ощущается пользователем в игровой среде, которая зависит от графической производительности. Это проявляется даже тогда, когда гибридное приложение использует HTML5 Canvas и WebGL. Разница в скорости составляет доли секунды – вам решать, критично это или нет.
Безопасность
Гибридный критики могут ссылаться на JavaScript инъекции или SSL уязвимости, но если вы обеспечили безопасность вашего сайта, то это вас не касается. Однако, у гибридных приложений имеется больше общедоступной информации знаний, что делает процесс обратного инжиниринга более вероятным. Они также зависят от плагинов, которые составляют дополнительный слой кода, где потенциально может быть найдена уязвимость системы безопасности.
Родные же приложения используют собственные функции безопасности без плагинов. Таким образом, для приложений, где требуется высокий уровень безопасности, нативная разработка может быть более предпочтительной. Для всех других потребностей бизнес - приложений, разработка гибридов предлагает вполне удовлетворительный уровень безопасности.
Кросс-платформенная совместимость
Здесь все просто - В этом гибридные приложения выигрывают: нативное приложение, разработанное для iPhone, не будет работать на Android, и наоборот.
Вывод
Вы ищете однозначный ответ? Единственное, что я могу сказать вам так это то, что лучшая форма разрабатываемого приложения это та, которая соответствует вашим уникальным потребностям. Это будет зависеть от ваших ресурсов и потребностей вашего конечного пользователя. Напомню, что вы всегда можете обратиться за разработкой программы ко мне; я могу создать приложение на Java или C#. Есть также опыт разработки под J2ME и Android.
Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков и ххх-роликов, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул - это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами.
Одни разработчики ждут от кросс-платформенных фреймворков решения всех своих жизненных проблем, другие же воспринимают их в штыки. В обоих «враждующих лагерях» есть свои заблуждения, вызванные непониманием того, как и что работает. Это подливает масла в огонь, так как вместо технических доводов в ход идут эмоции.
Также среди разработчиков, особенно начинающих, существует множество мифов о кросс-платформенных мобильных фреймворках. В нашей статье мы разберем самые популярные из них. Но для начала посмотрим на мобильную разработку глазами бизнеса, дающего деньги на весь айтишный блек-джек.
Зачем нужны кросс-платформенные инструменты?
Исторически на рынке компьютеров всегда была конкуренция, и каждый производитель предоставлял оптимальный набор так называемых нативных (родных) инструментов для разработки приложений под свои операционные системы и устройства.
Нативные инструменты = предоставляются владельцем экосистемы.
Все остальные признаки «нативности» ВТОРИЧНЫ - поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.
К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.
Второй важный момент - наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.
Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:
- максимизировать общую базу кода на едином языке программирования, чтобы продукт было проще разрабатывать и поддерживать;
- использовать существующие компетенции и специалистов для реализации приложений на новых платформах.
Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt .
Теперь можно поговорить и о мифах.
Миф 1. Магия
Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.
Главный принцип, лежащий в основе кросс-платформенных решений, - разделение кода на две части:
- кросс-платформенную , живущую в виртуальном окружении и имеющую ограниченный доступ к возможностям целевой платформы через специальный мост;
- нативную , которая обеспечивает инициализацию приложения, управление жизненным циклом ключевых объектов и имеет полный доступ к системным API.
Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge) , именно он и определяет возможности и ограничения кросс-платформенных фреймворков.
При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.
Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.
Миф 2. Ненативно!
Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.
Все операционные системы: iOS, Android и Windows UWP - предоставляют доступ к следующим подсистемам (наборы системных API):
- WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
- JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
- OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
- UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.
Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:
WebView - приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.
JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.
OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.
Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос - как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.
Если резюмировать - то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.
Миф 3. Костыль на костыле
Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно - взрослые зрелые решения с длительной историей.
Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.
Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.
Приложение на PhoneGap - это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части - просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.
При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок - это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.
Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.
Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) - это надстройка над ними.
Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke . Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.
И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.
Qt - «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.
Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.
Миф 4. Медленно
Важный козырь, которым любят пользоваться в спорах о кросс-платформенных фреймворках, - низкая производительность. Опять же, смотря что с чем сравнивать и в каких попугаях считать.
Напомним, что особенность кросс-платформенных приложений заключается в параллельном существовании двух миров, связанных мостом:
- PhoneGap: HTML/JS и Native Java / Objective-C / C#;
- React Native: JS и Native Java / Objective-C / C#;
- Xamarin: Mono и Native Java / Objective-C;
- Qt: С++ и Native Java / Objective-C.
Таким образом, при сравнении производительности надо учитывать скорость работы:
- кросс-платформенной части;
- нативной части;
- моста.
Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом - кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.
Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.
В переводе с английского native означает «родной». Нативное приложение разрабатывается для мобильных телефонов под конкретную операционную систему. Этим занимаются специалисты, которые обладают определенными знаниями и навыками в этой области. У нативных приложений приятный дизайн, они свободно взаимодействуют с мобильной ОС, могут работать через интернет-соединение или оффлайн.
Что это?
Нативное приложение - это разработка, доступная для одной платформы устройства. Например, существуют мобильные приложения, которые созданы специально для платформы Android или iPhone. С развитием современных технологий, появлением различных приложений (нативных, гибридных, веб) появилась возможности выбора. Загружаются нативные приложения через специальные магазины (App Store, Google Play) и устанавливаются на смартфон.
Особенность в том, что они разрабатываются для конкретной платформы, с использованием «родных» языков программирования при их написании. Если приложение создано под конкретную операционную систему, оно хорошо работает и смотрится органично. К тому же приложение с легкостью использует функции программного обеспечения смартфона, такие как фотокамера, микрофон, плеер, и экономит ресурсы устройства.
Одно из самых известных примеров нативных приложений - Shazam. Оно определяет, какая песня играет на другом устройстве. Shazam устанавливается из магазина, для него требуется доступ в Интернет, а для работы необходим диктофон смартфона. Instagram - популярное нативное приложение, которому для работы необходимо соединение с Сетью.
Предназначение
Мобильное приложение в современном мире - это канал связи, коммуникации между людьми и компаниями. Они необходимы в бизнесе. Через них можно продавать услугу или товар, общаться с клиентами, создавать структуру бизнеса с партнерами. Приложения для телефона помогают оптимизировать внутреннюю коммуникацию в фирме. Сегодня через мобильные приложения можно читать газеты, узнавать последние новости, смотреть телешоу, фильмы. И все это независимо от времени суток и места нахождения. Приложения способы продвигать товар, презентовать услуги. Это отличное маркетинговое средство. Кроме того, через мобильные приложения можно посещать социальные сети, общаться с друзьями и заниматься бизнесом. Особенность в том, что приложение для смартфона разработчики могут сделать на заказ, специально для конкретного проекта.
Разработка нативных приложений для бизнеса проходит три основных этапа. Первый - это адаптация уже имеющегося веб-сайта под смартфон (создание web-приложения). Второй этап - создание гибридных приложений, сочетающих веб-технологии и функции мобильных устройств. Третий шаг - написание нативного приложения для мобильного телефона. Он наиболее ресурсоемкий, но позволяет реализовать возможности операционной системы устройства и добиваться намеченных результатов за счет расширенного функционала смартфона. Популярность нативных приложений зависит от их высокой производительности, отлаженности, стабильности, возможности работать без Интернета. Последующая загрузка в магазин приложений позволяет отслеживать разработчику статистику продаж. Используйте нативные приложения, если необходима обработка огромного количества данных и большая скорость работы.
Виды
Виды мобильных приложений: нативные, веб и гибридные имеют сходства. Нативные пишутся специально для операционных систем, таких как iOS. Android, Win Phone. Загружаются они через магазины приложений и соответствуют их требованиям. Нативные приложения работают быстро и отлажено, благодаря оптимизации под конкретные ОС. У них есть доступ к функциям устройств. Эти приложения могут работать от Интернета или же автономно.
Веб-приложения имеют общие черты с мобильными версиями сайтов, но у них расширенный интерактив. Они создаются для того чтобы можно было пользоваться сайтом через смартфон. Его главное отличие: приложение не нужно устанавливать. Вся работа осуществляется через браузер. Разница между нативным и веб-приложением заключается в возможности свободно управлять информацией.
Гибридные сочетают в себе функции двух предыдущих. Приложение работает с программным обеспечением смартфона, так как является кроссплатформенным. Загружается из магазина приложений, работает через Интернет. Гибридное приложение - самое популярное среди пользователей. Нативное используется, если нужна высокая скорость обработки информации (социальные сети, игры или геолокация). Помните, что нативные приложения Android не подойдут для айфона или смартфонов с другой платформой.
Преимущества
Нативное приложение обладает рядом преимуществ. Высокая производительность, взаимодействие с конкретной операционной системой, малое потребление энергии, памяти телефона, удобство использования. К преимуществам этого приложения можно отнести максимальную функциональность и отличную скорость работы, доступ к программному обеспечению смартфона, в некоторых случаях для использования не требуется интернет-соединение. Скачать и установить приложение можно лишь через специальный магазин.
Недостатки
Нативное приложение имеет недостатки. На его разработку уходит много времени, стоимость такого приложения выше. От разработчика требуются знания определенной среды программирования. Кроме того, нативное работает с единичной операционной системой. Если потребуется что-либо изменить в приложении, необходимо выпускать обновление.
Как установить?
Нативное мобильное приложение устанавливается с учетом операционной системы смартфона. Для того чтобы выбрать необходимое приложение, перейдите в любой магазин, например Google Play, и выберите подходящее. Скачайте его и установите. Как правило, приложение будет работать, если есть соединение с Интернетом. Если не получается установить, проверьте объем памяти смартфона. Его должно быть достаточно для установки.
Нативный код
Что значит "нативное приложение"? Для многих это словосочетание покажется новым, но на самом деле практически все современные пользователи гаджетов сталкиваются с ним ежедневно. Для корректной работы нативного приложения разработчики пишут специальный код. Эта система команд, машинный язык, который будет интерпретироваться смартфоном. Инструкции, заложенные в приложении, позволят пользователю реализовать его возможности на полную мощность. Команды, заложенные разработчиком, могут быть разной длины и диапазона. Нативные приложения работают быстро из-за емкого, но небольшого кода.
Этих приложений - Java. Он дает разработчикам большие возможности. Его универсальность, удобство позволяет создавать в кратчайшие сроки простые корпоративные приложения. Плюс Java-разработки в том, что его инструменты доступны на всех операционных системах ПК, которые включают Linux и MacOS. Если хотите разработать приложения на языке Java, потребуется компьютер под управлением MacOS X. Нативное приложение iOS отличается от Android количеством времени, потраченного на разработку.
Цена
Бесплатный конструктор для нативных мобильных приложений помогает пользователям самостоятельно его создать. В Сети огромное множество конструкторов. Самые популярные и известные - это My-apps, Net2Share, BuildApp, MobiumApps, Appsa4u. Например, конструктор My-apps самостоятельно собирает приложение под операционные системы iOS и Android. Пользователи могут выбрать один из десяти готовых шаблонов, в зависимости от предназначения приложения. Конечный результат можно будет опубликовать в магазине для скачивания.
Полноценная разработка нативного приложения стоит недешево. Перед тем как ее планировать, определитесь с бюджетом. Он должен состоять из средств на продвижение готового продукта и саму разработку. Если приложение готовится для нескольких операционных систем, его стоимость увеличивается вдвое. Речь идет о разработке для юридических лиц, например, торговых компаний. Гибридные приложения стоят на 30% больше нативных, а у веб низкая цена из-за единой кодовой базы, поэтому разрабатывать их выгоднее, чем нативные.
Создание нативных приложений - это всегда огромные траты денежных и Не существует типовых проектов, для каждого заказчика приложения разрабатываются индивидуально. Цена включает в себя дизайн, число операционных систем, использование технологий для написания кода, сложность работы, тестирование, публикация и прочие нюансы. Сложное приложение может стоить несколько миллионов рублей. Причем это только разработка. Публикация, тесты и прочие услуги нуждаются в дополнительном финансировании. Именно поэтому приложения заказывают крупные бизнес-компании, которые готовы позовлить себе такое благо. Приложения в дальнейшем приносят хороший доход и окупаются со временем. Ведение бизнеса, расширение увеличение спроса на продукцию, создание положительного имиджа - плюсы мобильных приложений.
Производительность
От производительности смартфона зависит, как будет работать приложение. У нативных есть прямой доступ к платформе телефона и его функциям, что положительно влияет на их производительность. Гибридные приложения, если они корректно сделаны, могут преобразовывать веб в нативные. Производительность web-приложений зависит от скорости интернет-соединения, поэтому у нескольких пользователей оно может работать по-разному.
Распространение
После разработки нативное приложение Windows, Android, iOS должно добраться до пользователей. Распространение через магазины приложений - самый оптимальный вариант. Существуют особые требования к готовому продукту, которых разработчику следует придерживаться заранее. Они зависят от внутренней политики магазина. Если приложение успешно, его скачивают пользователи, а владелец получает прибыль и повышение рейтинга. Помните, что добавление любого контента (нативных и гибридных разработок) в магазин приложений нуждается в процедуре подтверждения.
В этой статье мы сравним 6 решений для кросс-платформенной разработки, которые были популярны в 2016 году и попытаемся найти лучшее решение.
Кросс-платформенные фреймворки PhoneGap, Xamarin, Unity, Qt и Appcelerator Titanium, Telerik Platform на сегодняшний день занимают 80% рынка кросс-платформенной разработки для мобильных устройств.
В таблице ниже представлены основные характеристики для каждого фреймворка:
| PhoneGap | Xamarin | Unity | Qt | Appcelerator Titanium | Telerik AppBuilder | |
| Языки | JavaScript, HTML5, CSS3 и нативные языки (Java, Objective-C, C#) | C#, Xaml | C#, UnityScript, Boo | C++ QML | JavaScript, Python, Ruby, PHP | .Net, JavaScript, HTML5, Java, PHP |
| Поддерживаемые латформы | Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, Firefox OS. | iOS, Android, Windows Phone and Windows 8/RT, Tizen | Android, iOS, Windows Phone, Tizen, PS 4, Xbox One | Android, iOS, WinRT, Windows, Symbian, Linux, QNX | iOS, Android, BlackBerry, Windows, Tizen, Denso | iOS, Android, BlackBerry, Windows, Windows Phone |
| Цены | Цены PhoneGap Платная версия: от 9.99$ Бесплатная версия: доступна Adobe Creative Cloud Membership: доступно |
Цены Xamarin Xamarin Studio Community: бесплатно Visual Studio Community: бесплатно Visual Studio Professional: доступно Visual Studio Enterprise: доступно |
Цены Unity Personal Edition: бесплатно Professional Edition: от 75 $ в месяц |
Цены Qt Есть бесплатная версия. Платные версии начинаются от 79$. |
Цены Appcelerator Indie: 39$ в месяц Есть бесплатный пробный период Цена от 39$ в месяц |
|
| Open source | + | - | - | + | + | - |
| UI | Web | Native | UI Canvas | Native | Native | Web |
PhoneGap
PhoneGap позволяет создавать мобильные приложения используя стандартные веб технологии (HTML5, JavaScript and CSS3). В результате это привело к быстрому росту популярности фреймворка, с его помощью можно обойтись без разработки на таких языках программирования как:Java for Android, Objective-C for iOS и C#.PhoneGap Build позволяет делать сборки для iOS, Android и Windows Phone одновременно, без необходимости устанавливать какие-либо SDK tools (конечно, в этом есть доля лукавства – при разработке всё равно лучше делать сборку локально, хотя бы на Android, перед отправкой на тестирование). Но что более важно, этот сервис позволяет делать сборки для iOS в облаке без наличия Mac.
Установка PhoneGap требует неимоверных усилий, потому советую освободить пол дня… Шутка. Установка для XCode заняла минуты 3 - заключалась в скачивании архива, распаковке и установке. Вот собственно и все.
PhoneGap представляет возможность использовать нативные функции мобильного устройства по работе с:
- акселерометром,
- камерой,
- компасом,
- контактами,
- файловым хранилищем,
- геолокацией,
- базой данных,
- событиями, уведомлениями,
- медия и др.
Преимущества:
- PhoneGap имеет простое API, что позволит легко начать разработку, для тех кто сталкивался с HTML, CSS и JavaScript.
- Возможность использования любых существующих JavaScript библиотек (JQuery, Prototype, Sencha Touch)
- Поддержка всех мобильных платформ
- Пользовательский интерфейс визуализируется с помощью встроенного браузера. Это создает трудности в получении обратной связи по сравнению с нативным приложением.
- Часто существующие плагины оказываются устаревшими, поэтому иногда придется писать свои.
Xamarin
Xamarin второй в нашем списке кросс-платформенный фреймворк. Xamarin позволяет создавать одну единственную логику приложения с применением C# и.NET. Функционально платформа Xamarin представляет ряд субплатформ. Эти субплатформы играют большую роль - через них приложения могут направлять запросы к прикладным интерфейсам на устройствах. Определяется визуальный интерфейс, привязывается логика на C#, и все это будет работать на Android, iOS и Windows Phone. Видео с разработкой приложения на Xamarin.
Преимущества:
- Большое и развивающееся сообщество.
- Разработчики могут использовать TestCloud для тестирования приложений автоматически.
- Если вы уже знакомы с C# и.NET то вам не нужно будет тратить много времени на изучение нескольких новых фреймворков.
- Можно повторно использовать уже написанный код.
- Приложения под разными системами будут выглядеть очень похоже.
- Динамическая верстка для iOS в бесконечное число раз проще, чем использование constraints вручную.
- За счет CustomRenderer‘ов стандартные контролы легко дополняются произвольными свойствами (например, сделать градиентную заливку кнопок - дело пары минут, хотя «из коробки» это не работает).
Недостатки:
- Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
- Возникают проблемы со стороны платформы mono, monotouch и monodroid. Ваше приложение должно удовлетворять особенным требованиям стабильности.
- Android страницы невозможно расположить как часть уже существующего Activity/Fragment.
- Реализованы не все контролы.
Telerik AppBuilder
Одной из основных причин использовать AppBuilder является полноценная онлайн IDE. Она позволяет создавать, тестировать и даже публиковать гибридные приложения с любого компьютера или мобильного устройства, без необходимости в его загрузке.Возможность создавать iOS приложения работая на Windows или Linux еще одно преимущество.
Преимущества:
- Telerik предоставляет плагины Visual Studio и Sublime Text для AppBuilder.
- AppBuilder предлагает быстрый способ импорта плагинов Cordova.
- Полноценная онлайн IDE.
- Легок в использовании и изучении
Недостатки:
- Небольшое сообщество
Unity
Мультиплатформенный инструмент для разработки 2D и 3D приложений и игр Unity, также один из лучших инструментов для демонстрации 3D контента. Созданные с помощью Unity приложения работают под операционными системами Windows, OS X, Linux, Android, Apple iOS, Windows Phone, BlackBerry, а также на игровых приставках Wii, PlayStation 3 и Xbox 360. Видео с разработкой мобильной игры на Unity. Преимущества:
- Отличный вариант для создания мобильных игр для целого ряда устройств
- 3D-движок дает высококачественные результаты без каких-либо сложных конфигураций
- Есть много хороших бесплатных плагинов
- Unity позволяет разработчику сделать свои собственные шейдеры и изменить путь, которым Unity визуализирует игру.
Недостатки:
- UI и сложность в использовании для новичков
- Исходный код недоступен
- Компиляторы Unity не оптимизированы для ARM процессоров на некоторых мобильных устройствах.
Преимущества:
- Qt имеет множество хороших инструментов которые помогут в разработке, например: IDE QT Creator, Qt Designer и code profiling.
- Он имеет библиотеки, содержащие интуитивно понятные API интерфейсы для элементов, таких как сети, анимации и многое другое.
Недостатки:
- Qt сложен для начинающих
Appcelerator Titanium
Titanium - это полностью открытая платформа для разработки, развертывания, распространения, и, в конечном итоге, для исполнения веб-приложений. Appcelerator Titanium позволяет создавать мобильные приложения на JavaScript, HTML и CSS.Вы можете создавать современные, а главное - нативные приложения, используя любую популярную на сегодняшний день операционную систему: Windows, GNU/Linux или MacOS X.
Приложения созданные с помощью данного SDK будут действительно нативными. Контроллер навигации на Андроиде будет выглядеть привычно и не так как на iOs. Причем не только вид, но и сам код приложения будет тоже нативный. Это кстати не мешает вам создавать и классический WebView и наполнить его желаемым web контентом.
Преимущества:
- JavaScript позволяет легко разрабатывать приложения без использования языков платформы.
- Appcelerator позволяет делать аналитику в режиме реального времени
- Использование native API даст более высокую производительность для приложений, которые не очень велики.
Недостатки:
- Есть задержки при запуске приложения из-за загрузки библиотеки
- Трудно создавать сложные приложения, так как использование JavaScript отрицательно сказывается на производительности приложений.
React Native
Что такое React Native? Это JS-фреймворк, основанный на JS и React - JS-библиотеке для создания UI (View-уровня).Технология очень перспективная, но молодая, поэтому платформа кое-где еще сырая. Версия для Android появилась позже, поэтому для iOS-приложений пока есть больше компонентов. Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику. Можно сказать, что сейчас React Native можно использовать для быстрого прототипирования мобильных версий ваших веб приложений. Причем если веб приложение уже написано на ReactJS, то скорость переноса возрастает в разы. Пример разработки на React Native.
Преимущества:
- Единый воркфлоу и инструменты: неважно, работаете ли вы на Android- или iOS-версией - все равно используете одни инструменты.
- По этой причине - скорость и простота разработки.
- Обвязка унаследованного приложения в JS API и гибридные приложения: допустим, у вас уже есть готовое приложение для iOS, и вы хотите перейти на React Native. Тогда можно обернуть нативные компоненты так, чтобы они были доступны в React Native. Так вы можете постепенно переходить на React, и получается гибридное приложение - половина его нативная, а половина - в React, и несколько унаследованных компонентов - в JS API.
Поиск
Мы можем оповещать вас о новых статьях,