Гибридные, Нативные и Мобильные Web приложения: взгляд изнутри. Гибридные и нативные приложения
Примерно 2 года назад я захотел приобрести микрофон. Как обычно, перед покупкой я посмотрел несколько обзоров наиболее популярных моделей, узнал о тех характеристиках, которые отличают микрофоны, и зашел на сайт магазина, где собирался приобрести аппарат. Мой выбор пал на модель М1 (дабы исключить обвинения в рекламе и продакт-плейсменте заменим название микрофона). Эта модель была в двух комплектациях: обычный микрофон и вариант с USB-подключением, который стоил дороже. Кроме этого, эти две вариации ничем не отличались. Хорошо, берем деньги и идем в магазин. В магазине на витрине лежали обе модели. Я выловил девушку-консультанта и попросил показать понравившийся мне микрофон. «А не хотите взять эту модель?», — спросила девушка, показывая на более дорогой вариант с USB. «Разве она чем-то лучше? Именно в плане звука?» Девушка подумала немного: «Да, конечно лучше!». Мой совет: не верьте продавцам!
Но кому же верить? Когда мы хотим купить товар или услугу, мы общаемся именно с продавцами, которые, к сожалению, не являются экспертами в данном вопросе. На мой взгляд, выход в этой ситуации один. Взять все в свои руки и самому, хотя бы поверхностно, разобраться в интересующем Вас вопросе или найти профессионала в в данной области и узнать его мнение. Давайте так и сделаем. Вопрос, в котором мы будем разбираться звучит так: «Что лучше — нативные или гибридные приложения для мобильных платформ?».
Гибриды против натураловЧтобы с чего-то начать, давайте прибегнем к проверенному и надежному способу - загуглим интересующую нас проблему. Гугл выдает десятки статей, написанных словно под копирку. Различного рода блогеры, программисты, менеджеры, рекламщики, мамы рекламщиков, бабушки менеджеров и прочие люди, которые «отлично» разбираются в этом вопросе, пытаются интересно, индивидуально и с юмором донести до нас следующие вещи:
Да и разработчиков нужно меньше. Просто найдем пару крепких парней, которые знают HTML и JavaScript. Они нам все и напишут. А то ищи всяких Java, С#, С++, Objective-C разработчиков и потом еще всей этой ораве деньги плати.
Казалось бы, теперь мы знаем, чем отличаются гибридные и нативные приложения. На этом можно спокойно закончить статью и заняться делом — идти писать код. Но нет! Мы же помним: «Не верьте продавцам!». А большая часть людей, которые писали все эти пункты - именно продавцы, в той или иной форме. Так что, разбираемся дальше.
Веб-приложенияСама идея сайта, который выглядит как приложение, — это, конечно, интересно. У этого подхода есть как минусы, так и определенные плюсы. Но есть один большой вопрос: «Зачем?». Представьте, что вы пользователь, не обремененный особыми познаниями в IT-технологиях. Открываете вы какой-то сайт и … О, Боже! У меня открылось приложение! Демоны! Это, наверное, вирус какой-то! Хотя стоп, а почему строка браузера видна? Это сайт что-ли такой? Или все-таки приложение? Хм, в списке установленных его нет. Работает он ужасно медленно. Установлю-ка я лучше нормальное приложение, а не это не пойми что.
В общем, не совсем понятен смысл всей этой мимикрии. Зачем вводить пользователя в заблуждение? Ведь кто-то может поверить, что это — приложение, и ожидать поведения, соответствующего обычному приложению. Хочется привести следующее сравнение: найдем здоровый камень круглой формы и покрасим его так, чтобы он выглядел как футбольный мяч. А потом спросим первого же горе-футболиста со сломанной ногой про его впечатления от нашего оригинального дизайнерского хода.
ГибридыТак как опыта работы с PhoneGap и с другими фреймворками подобного рода у меня не особо много, то я решил обсудить этот вопрос с нашим JS/HTML разработчиком, который писал программу при помощи фреймворка PhoneGap. Оказывается, на данный момент большая часть описанных проблем решена. На этой страничке переодетый Черный Властелин обещает нам, что теперь реакция на клики будет проходить быстро и безболезненно. Существует вагон и маленькая тележка различных плагинов , которые позволяют получить доступ к различным системам целевого устройства. А если чего и нету, то можно свой плагин написать. И кажется, что вот оно — отличное решение для кросс-платформенной разработки мобильных апп! Но давайте задумаемся поглубже над этой проблемой.
Что это за волшебные пилюли — плагины, которые решают все проблемы? Может, это какая-то магия? К сожалению, магии в нашем мире нет. По крайней мере, в IT. Плагины — это JavaScript обертки над нативным кодом Android или iOS. То есть, по сути, PhoneGap — это GUI, который на самом деле является веб-приложением, выполняемым в WebView. Логическая часть программы, выполняющаяся при помощи плагинов, которые на самом деле являются вызовами нативного кода через JavaScript, взаимодействует с устройством. Теперь, зная составляющие фонгап приложения, мы можем порассуждать о том, как все это будет работать.
В общем, что я хочу сказать? Кроссплатформенность в данном случае мнимая, и приложения будут выглядеть странно. Я думаю, гибридные приложения стоит использовать в качестве прототипов, на которых можно оценить реакцию пользователей на вашу идею и получить некоторый фидбек. Для продакшн-версии лучше все-таки использовать нативные приложения. Эти рассуждения актуальны для всех гибридов, работающих на связке HTML/JS.
НативныеПро нативные ничего особо писать не буду. Тут и так все понятно. Быстро работают, хорошо выглядят, широкие возможности кастомизации. И стоят они соответствующе. Хотя первые три пункта актуальны, только если вы не наняли команду крепких профессионалов с семилетним опытом работы из Нью-Дели.
Тру кроссплатформенностьНа мой взгляд, едиственный фреймворк, который может действительно позволить вам написать кроссплатформенное мобильное приложение в данный момент — это С++ Qt. Этот фреймворк генерит нативный Android код с использованием Android NDK. Поэтому производительность должна быть на уровне кода, написанного программистом при помощи Android SDK, а для фрагментов, использующих тяжелые расчеты еще и выше — за счет NDK. Qt — это качественная, протестированная библиотека. Это означает, что вы не будете в процессе ловить какие-то левые баги. В случае какой-либо проблемы, вы можете взглянуть на исходники Qt. Это, действительно, очень нужная возможность для разработчиков. В некоторых случаях это единственный способ побороть баг. Для того, чтобы получить программу для целевой платформы (Android или iOS), вам нужно просто перекомпилировать исходники. Хотя, насколько я знаю, иногда все-таки придется писать нативный код для платформы, т. к. не все возможности доступны через библотеки Qt. Надеюсь, это вскоре будет исправлено.
Но есть и минусы. Для продакшн-разработки вам придетcя приобрести лицензию Qt — что, соответственно, стоит денег. Для начинающих разработчиков это серьезная проблема. К тому же, на данный момент, Qt для мобильной разработки все еще сыроват. Ждем следующих релизов.
ВыводНа данный момент не существует средства, которое можно было бы с чистой совестью назвать настоящей кросплатформенной средой для разработки мобильных приложений . Возможно, в будущем, это место займет Qt, но на данный момент оно вакантно. Для проверки своей идеи посредством разработки прототипа, вы вполне можете использовать различные JS/HTML фреймворки, но я бы не советовал их применять для разработки сложных продакшн-приложений. В этой сфере разработки альтернативы нативным приложениям в данный момент нет.
Во второй части тяжкого выбора первого языка программирования мы затронем тему разработки мобильных приложений. Данное направление ещё не достигло пика своего популярности, да и вообразить тот момент, когда все мы станем менее зависимы от подручных гаджетов, пока представить невозможно.
Поэтому давайте сразу перейдем к делу и кратко ответим на самый простой вопрос по теме: «Какие бывают виды мобильных приложений?»:
Веб-приложения. Иначе говоря, мобильные версии сайтов, запускаемые напрямую через браузер вашего устройства. Здесь царят те же законы, часто ограничен функционал, часто трудятся те же самые разработчики, что и над полноценными версиями.
Нативные приложения. Здесь речь идет о приложениях, разработанных под «родную» платформу, то есть Android, iOS или Windows. Они загружаются напрямую из местного магазина, оптимизированы с точки зрения взаимодействия с системой, расхода батареи и полноценного использования возможностей устройства.
Гибридные приложения. В данном пункте есть некоторое расхождение во мнениях: кто-то считает гибридные приложения веб-сайтами, разрабатываемыми по универсальной схеме для десктопов и мобильных устройств. Яркими примерами являются страницы Google или Amazon . Но в данном тексте будем придерживаться несколько другой версии, при этом не исключающей первую: гибридные приложения - это некий компромисс между веб-приложениями и нативными, то есть загружаемые из магазина, имеющие оболочку, написанную на платформенном языке, но имеющие в той или иной степени веб-функционал.
Приложения-эксперименты. Это когда разработчик просто хотел реализовать свою задумку, плевав на правила и целевую аудиторию. Популярностью такие приложения по понятным причинам не пользуются, потому в стандартные классификации обычно не включаются.
Приняв это деление за основу, перейдём непосредственно к языкам.
Веб-приложенияОткровенно говоря, если вы только начинаете свой путь в мобильную разработку, то веб-приложения - прекрасный выбор. Во-первых, с точки зрения языков, вам здесь вполне хватит «больших» HTML5 и JavaScript. Выучить их придётся на хорошем уровне, чтобы пробелы в образовании не приводили к серьёзным багам. Но в остальном даже с точки зрения литературы вполне хватит прочтения двух книг: «Основы разработки веб-приложений » или «HTML5. Разработка приложений для мобильных устройств ».
Во-вторых, вам не надо придерживаться никаких норм по платформам и устройствам. Всё что от вас требуется - запихнуть большой сайт в маленькую красивую оболочку. Полученных знаний о языках и более-менее здравого представления о работе подобных приложений на мобильных устройствах хватит для плодотворной работы.
Правда минус такой специализации очевиден - приготовьтесь к тому, что большие деньги на веб-приложениях вы заработаете только имея большое количество заказов от проверенных клиентов и, как следствие, мало свободного времени. И конечно запросы от этих самых клиентов будут самые невероятные.
Нативные приложенияКогда речь заходит о разработки мобильных приложений, все в первую очередь думают именно об их нативном виде. Сразу вспоминается приверженность платформ своим языкам, требования к оформлению и внешнему виду приложения, чтобы оно было загружено в официальный магазин, и примеры того, как делать не надо, хотя формально всем требованиям такое приложение соответствует. С точки зрения погружения в профессию и требований к исполнителю это уже продвинутый уровень.
Базовые языки для iOS - ObjectiveC и Swift. Если вы никогда не сталкивались с первым, то я просто не вижу доводов для его изучения в качестве первого языка. Всё дело в том, что Swift создавался с целью закрыть все недостатки ObjectiveC и не отвергнуть уже состоявшихся разработчиков. В итоге, на сегодняшний день это один из самых прогрессирующих языков, как с точки зрения популярности, так и качественного развития. Для изучения предмета с нуля прекрасно подойдёт книга «Swift. Основы разработки приложений под iOS » или интенсив « ».
В Android-е вам придётся поработать с Java. Сколько бы там не прошло судов , призывающих Android признать нелегальное использование этого языка, сколько бы не было угроз о принципиальной смене курса, стоит признать, что сотрудничество с Java не утратило своей актуальности. В качестве литературы советую «Android 4. Программирование приложений для планшетных компьютеров и смартфонов ». Книга не самая свежая, но новичку больше информации и не надо. Про бесплатный курс « » от GeekBrains тоже не забывайте.
Ну а платформа Windows проповедует язык С#. С точки зрения разработки именно нативных приложений для WP, ценность изучения C# сомнительна, так как рынок необычайно мал. Но во-первых, C#, как любой популярный язык, всё же помогает создавать достойные кроссплатформенные приложения, например на Xamarin , а во-вторых перспективы роста от мобильных устройств к десктопным - тоже неплохая мотивация. Для вводного начала хватит курса « ».
Кстати, о кроссплатформенности. Большинство по-настоящему крутых нативных приложений не создаётся с использованием только одного языка программирования. В простейшем случае имеет место быть компилирование исходного кода в требуемый, а уже на месте «допиливаются» возможности родной платформы. Но в этом есть определённые сложности, связанные с избыточностью выходного кода и появлением плавающих ошибок, да и с точки зрения вхождения в профессию такого рода рассуждения пользы не принесут.
Уровень знания языков напрямую зависит от сложности желаемого приложения. Помимо указанных в тексте курсов GeekBrains по некоторым языкам, вы можете посетить и другие, например, по созданию . А дальше, если подобное направление завлечёт, уже сами подберёте удобный только для вас путь развития.
Гибридные приложения
Несмотря на все кажущиеся преимущества данного вида приложений, подводных камней здесь тоже немало. Но касательно сегодняшней темы расскажем о приятном. Языки вы можете использовать любые, в зависимости от того, что у вас за приложение. В простейшем случае, для создания интерфейсной части вы используете нативную часть (Swift, Java, C# и т. д.), а внутренности создаются на HTML5, JS, да и вообще на чем угодно. То есть для того, чтобы перейти на другую платформу, вам придётся потратить куда меньше времени, чем при создании стандартного нативного приложения. В помощь вам специальные фреймворки. вроде PhoneGap или Eclipse . Опять-таки компиляция из любого другого места, в случае чего, поможет.
С точки зрения адаптации под требования платформ тоже никаких проблем. Сделаете кнопку «назад» для iOS, будет она и на Android, пусть даже там она никому не нужна. Просто стандарты здесь совсем другие. Создание гибридного приложения делает акцент именно на идее, остальное - вторично.
Минусы же очевидны - сниженное по сравнению с нативными приложениями быстродействие, меньше возможностей для взаимодействия с устройствами, больше вероятность появления ошибок.
Впрочем, к выбору языка это не имеет никакого отношения, а кажется именно за этим мы здесь собрались.
Сегодня статья о гибридных Android-приложениях для малышей. Во всех смыслах этих слов. Мы поговорим о написании простейшего гибридного (Java+HTML+Javascript) Android приложения для опросов учеников начальных классов об их рюкзаках. Предполагается минимальное знание основ Java, HTML и JavaScript. Если Вы Android-разработчик, хоть с минимальным опытом – Вам эта статья вряд ли будет интересна, можно не открывать. Всех остальных, кто еще только начинает или думает начать разработку под Android, и кому интересны основы разработки под Android, прошу под кат.
Вводная. Дочке (2 класс) было поручено сделать исследовательскую работу на тему «Влияние веса рюкзака на здоровье ребенка». Естественно, в силу возраста, основная работа пришлась на родителей. Решили провести опрос в классе на предмет того, у кого сколько весит рюкзак, кто сам сколько весит (для вычисления нормы веса рюкзака, который не должен превышать 10% от массы ребенка), кто носит рюкзак в школу и так далее. Для того, чтобы разнообразить школьные будни, решил сделать приложение под телефон на Android, который есть у дочки, приложение для опроса. Изначально планировалось включить в опросник вес рюкзака и детеныша, но не успел, и по итогу эти параметры записали на листик, по старинке. Остались только те вопросы, на которые детеныши могли ответить самостоятельно.
Суть задачи: разработать приложение для опроса младшеклассников для создания презентации дочке о том, насколько вредно носить тяжелые рюкзаки. На картинке выше можно увидеть то, что у нас по итогу получится.
Сразу оговорюсь, обычно я разрабатываю нативные приложения для Android, HTML чисто для Web-приложений, но в этот раз было решено разработать гибридное приложение так как во-первых, быстрее для данной задачи, а сроки были предельно сжатые, во-вторых, это было удобней с точки зрения функционала приложения, в третьих, это был первый проект разрабатываемый в Android Studio, хотелось минимизировать возможные проблемы при использовании нового инструмента, чтобы закончить вовремя.
Итак, приступим. Для начала, разумеется, Java-код (пояснения в комментариях), естественно не забываем добавить WebView в нашу Activity, присваиваем ему id webView:
Package com.probosoft.survey;
import android.os.Build;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.Window;
import android.webkit.WebSettings;
import android.webkit.WebView;
public class MainActivity extends AppCompatActivity {
// Перегружаем метод onCreate, в нем создаем необходимый нам WebView и устанавливаем ему возможность масштабирования
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main); // Показываем нашему приложению, кто тут главный
WebView wv = (WebView) findViewById(R.id.webView); // Создаем WebView – мини-браузер в приложении
WebSettings settings = wv.getSettings(); // Получаем класс настроек нашего мини-браузера
settings.setDisplayZoomControls(true); // Разрешаем показать настройки масштабирования для мини-браузера
wv.loadUrl("file://android_asset/html/index.html"); // Загружаем страницу нашего приложения в мини-браузер
}
}
Помещаем тестовый index.html в папку assets/html. Пробуем запустить. Ничего не получается. Выясняем важный момент, что при обращении к внутренним ресурсам слешей после протокола должно быть не два, а три. Меняем:
Wv.loadUrl("file://android_asset/html/index.html");
на:
Wv.loadUrl("file:///android_asset/html/index.html");
Ура! Все загрузилось. Начинаем писать HTML и JS код.
Survey
#menu {
width: 100%;
}
Спасибо за ответы!
var respondents;
var adminMode = true; //
function clearAll () {
try {
if(typeof(Storage) !== "undefined") {
this.storage = localStorage;
}
} catch (e) {
alert ("Local storage error: "+e);
}
this.storage.clear ();
}
function init () {
$("#mainPane").show ();
$("#resultsPane").hide ();
if (adminMode) $("#showResults").show ();
$("#title").html ("Выберите ученика");
var res = dataRespondents;
res.forEach (function (element, i, arr) {
element.id = i+1;
});
respondents = new Respondents (res);
respondents.renderRespondents ($("#menu"));
$("#storeForm redirectURL").val (document.location.href);
}
init ();
Сначала я пробовал использовать AJAX для загрузки данных, но довольно быстро убедился, что внутри WebView, и на локальных ресурсах он попросту не работает. Поэтому, для загрузки контента пришлось использовать довольно противоречивый метод – сохранить все данные о респондентах в глобальный массив.
Пробуем запускать. Опять не работает. В чем же дело? Для нашего WebView мы не разрешили выполнение JavaScript. Исправим. Добавим к Java коду:
settings.setJavaScriptEnabled(true);
Теперь работает. Ура! Нам нужно было разрешить исполнение JavaScript в нашем WebView. Пишем классы функционала. Код приводить не буду. С ним можно познакомиться на GitHub проекта (в конце статьи). Здесь же описываю основные проблемы, с которыми может столкнуться начинающий разработчик гибридных приложений.
/**
* Represents survey for particular respondent
* @param integer id Id of respondent
*/
var Survey = function (in_respondentId, in_respondent)
{
var respondentId; // Id опрашиваемого ученика
var respondent = null; // Объект, представляющий опрашиваемого ученика
var questions = null; // Массив вопросов
var parent = this; // Грязный хак, позволяющий получить контекст объекта внутри вложенных контекстов
var storage = null; // Переменная содержжащая LocalStorage на случай если его придется повторно использовать
this.answers = ; // Массив ответов на вопросы опросника
/**
* Begins survey for chosen respondent
*/
this.start = function ()
{
var res = dataQuestions; // Инициализируем переменную с вопросами
parent.questions = new Questions (res, parent.respondent); // Создаем первый вопрос
parent.questions.start (); // Приступаем к опросу
}
/**
* Stores all answers in storage
*/
this.collectAnswersAndStore = function ()
{
this.storage.setItem (window.UNIQUE_STORAGE_ID+this.respondentId, JSON.stringify (this.answers)); // Сохраняем результат опроса
window.init (); // Возвращаемся на главный экран
}
this.surveyOption = function (val)
{
this.answers.push (val); // Запоминаем ответ ученика
//alert (this.answers);
if (!this.questions.advanceQuestion ()) // Проверяем, есть ли еще вопросы
{
this.collectAnswersAndStore (); // Если нет больше вопросов, сохраняем ответы
}
}
// Инициализация переменных
this.respondentId = in_respondentId;
this.respondent = in_respondent;
// Пытаемся получить доступ к хранилищу
try {
if(typeof(Storage) !== "undefined") {
this.storage = localStorage;
}
} catch (e) {
alert ("Local storage error: "+e);
}
}
Все вроде как и работает, но ничего не сохраняется. Попутно узнаем забавную подробность – в последних версиях Android alert в WebView делает… ничего. Совсем ничего. Ни ошибки, ни какого-то сообщения в консоли. Просто как-будто его и нет. Выясняем, что для использования LocalStorage в WebView нам нужна установка дополнительных флагов для WebView. Сделаем это:
Settings.setDomStorageEnabled(true);
settings.setDatabaseEnabled(true);
Ура! LocalStorage заработал. Долго ли коротко ли, за выходные что-то пригодное для использования было написано. Ребенок был отправлен в гимназию с телефоном, на котором было установлено данное поделие. Ребята (уж с помощью учительницы, или самостоятельно – это осталось за кадром) добросовестно прошли анкетирование, и не было данных только по четырем ученикам, которые по тем или иным причинам отсутствовали на занятиях.
Теперь передо мной встала проблема: нужно как-то извлечь данные (да-да, об этом нужно было думать изначально, но не забываем, что приложение разрабатывалось в жутком цейтноте, и предполагалось, что эта задача не из сложных и не из неотложных и ее вполне можно решить потом).
Основная проблема оказалась в том, что у дочки довольно старый и слабый телефон (выбирался с учетом фактора «чтобы не жалко было чуть что»). Пробовал вытащить данные через Bluetooth, отправкой AJAX-запроса на сервер, создавалась форма для отправки и т.д. – без вариантов. Текст в DIV’е не выбирается, по итогу DIV был переделан в TextArea (что можно наблюдать в финальном коде на GitHub). Оттуда удалось выделить и скопировать текст с результатами опроса и переслать его на мой E-mail. По итогу это оказался единственный рабочий вариант.
Пишем скрипт, чтобы данные оказались в Excel таблице. На данном этапе выявилась еще одна проблема изначальной архитектуры – те ученики, которые не проходили анкетирование помечались простой строкой «Анкета не заполнена». Естественно, regexp’ы, которые были рассчитаны на нормальные данные на этих строках «спотыкались». Благо таких строк было всего четыре. Вручную они были удалены из итоговых результатов и мы получили вполне адекватную выборку (реальные имена заменены на плейсхолдеры):
Ученик 1, имя: Когда как,Никогда,Мне все нравится в моем рюкзаке 2. Ученик 2, имя: Когда как,Иногда попадаются,Слишком тяжелый 4. Ученик 3, имя: Взрослые,Иногда попадаются,Просто неудобно, но объяснить не могу 5. Ученик 5, имя: Я,Никогда,Мне все нравится в моем рюкзаке 6. Ученик 6, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 7. Ученик 7, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 8. Ученик 8, имя: Я,Никогда,Мне все нравится в моем рюкзаке 9. Ученик 9, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 10. Ученик 10, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 11. Ученик 11, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 12. Ученик 12, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 14. Ученик 14, имя: Когда как,Никогда,Мне все нравится в моем рюкзаке 16. Ученик 16, имя: Я,Всегда что-нибудь есть,Мне все нравится в моем рюкзаке 17. Ученик 17, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 18. Ученик 18, имя: Я,Всегда что-нибудь есть,Мне все нравится в моем рюкзаке 19. Ученик 19, имя: Я,Иногда попадаются,Просто неудобно, но объяснить не могу 21. Ученик 21, имя: Когда как,Всегда что-нибудь есть,Мне все нравится в моем рюкзаке 22. Ученик 22, имя: Я,Никогда,Слишком тяжелый 23. Ученик 23, имя: Я,Иногда попадаются,Мне все нравится в моем рюкзаке 24. Ученик 24, имя: Я,Иногда попадаются,Слишком тяжелый
Можно было, конечно, преобразовать все это на телефоне, но так показалось проще. Это уже легко разбирается простым регулярным выражением. Пишем PHP-скрипт: