Мобильные технологии продолжают свой головокружительный взлёт, проникая в нашу жизнь плотнее и глубже. Если раньше многое сводилось к простому серфингу из браузера, то сейчас мы стремимся предоставить пользователям полноценные, удобные и красивые приложения использование которых приносит удовольствие и радость. Однако не всё так просто. Большое количество всевозможных устройств с разной производительностью, платформами и разрешениями экранов вынуждают нас искать наиболее адекватные решения при создании продуктов. Приходится учитывать множество факторов: от архитектуры и процессов разработки до вариантов монетизации и способов продвижения. Так или иначе, в необходимости создания мобильных версий или адаптирования существующих приложений уже никто не сомневается, и сегодня мы поговорим о тех задачах которые возникают в связи с этим, а также о способах их решений. В качестве конктретного примера я буду говорить о разработке веб-браузерной игры «Коррупция». В общем случае можно выделить 3 класса задач: дизайн, производительность, кодовая база. Остановимся на каждой из них подробней.
Ясно, что просто так разместить на относительно небольшом экране мобильного устройства настольное приложение не получится. Например, интерфейс «Коррупции» изначально ориентировался на 716px в ширину. Если отобразить их даже на iPAD с Retina, это всё равно будет выглядеть не юзабельно. Поэтому дизайн пришлось переделывать полностью. Большинство элементов управления распределились между классическим слайд-меню слева и кнопками в футере. Было принято решение зафиксировать портретную ориентацию экрана, что позволило разместить элементы контента в одну колонку и добиться унифицированного интерфейса как для планшетов, так и для смартфонов. Информация о дополнительных действиях стала отображаться в отдельных окошках, занимающих всю колонку при появлении. Таким образом, удалось добиться относительно вменяемого разделения интерфейса на несколько активных зон: игровое пространство, элементы управления и окошки с дополнительной информацией. Иными словами, игровой интерфейс перестал быть представлен на странице полностью, вместо этого разбился на отдельные блоки, доступ и видимость которых контролирует сам пользователь.
Какие элементы интерфейса показывать в мобильной версии, какие нет — зависит от конкретного приложения. Много важнее как этого добиться. Вероятно, наиболее простым и эффективным способом являются CSS3 Media Queries. Основная идея в определении различных стилей для разных разрешений экранов, например, с помощью директив. Мы делаем резиновую ширину для экранов с разрешением < 960px. Точно также можно добиться различного расположения и видимости элементов контента.
Следующий шаг — шрифты. Если задать их в пикселях, на больших экранах будет слишком мелко. Но и просто так относительную величину задать не получится, потому что нужна исходная метрика — размер шрифта, от которого будут считаться все остальные относительные значения. Поступаем точно также: высчитываем размер базового шрифта в процентах, а затем при загрузке приложения переводим его в абсолютную величину и задаём для body элемента. Таким образом, все дальнейшие размеры шрифта мы можем брать относительно размера базового шрифта.
Теперь о производительности. CSS3 transition позволяет добиться поистине восхитительных эффектов, но мы отказались от них в мобильной версии по причине сильных задержек. На данный момент их рендеринг слишком тяжёлый и медленный. Мы также отказались от классической реализации элементов в DOM-дереве. Если раньше почти всё что нам не нужно было отображать в текущий момент имело свойство display: none; то с мобильными приложениями этот вариант не проходит. Вернее проходит, но тоже с очень большими тормозами, т.к. все невидимые элементы всё равно располагаются в DOM-дереве и создают нагрузку на компонент рендеринга. Решение нашлось в выносе разметки в JavaScript переменные и затем их вставку/удаление из DOM по мере необходимости. То что касается серверной части, здесь всё вполне очевидно. Обмен данными происходит через AJAX, что позволяет значительно снизить количество передаваемых данных. По сути, серверная часть обрастает собственным API, которое можно использовать и для трансформирования десктоп приложения в Single Page Application, если этого по какой-то причине ещё не сделано.
Кодовая база. Все о чём мы тут говорили касается, безусловно, HTML/CSS/JavaScript приложений. Но что если хочется использовать ту же самую кодовую базу, но доставлять продукт через AppStore и GooglePlay? На помощь приходят всевозможные фреймворки, будь то Xamarin или Cordova/PhoneGap. Мы остановились на последнем в силу того, что он использует привычную связку HTML/CSS/JavaScript.
Следующая, пожалуй, самая неприятная проблема — различное поведение. Несмотря на корни идеологии, HTML/CSS/JavaScript все равно местами ведёт себя по-разному на различных платформах. Что-то из этого конфигурируется в самом PhoneGap, но по большей части, единственный способ узнать как поведёт себя приложение — запустить на конечном устройстве. Мы, например, столкнулись с тем, что на iOS, если у блока задано свойство position: fixed, после скрытия клавиатуры, блок не восстанавливал свою высоту. При position: absolute ситуация нормальная. С другой стороны, если постоянно контролировать процесс разработки, регулярно тестируя билды на конечных устройствах, различия в поведении поддаются вменяемой корректировке.
Из приятных моментов — наличие плагинов. Каждый из них обычно написан на языке целевой платформы, предоставляя JavaScript интерфейс. Например, это очень удобно для платежей. Для iOS и Android можно использовать плагины, и хотя интерфейс у них всё же разный, при использовании отдельного объекта адаптера эти различия вполне укладываются в общую картину.
Подводя итог выше сказанному, можно отметить следующее. Разработка под платформы достаточно затратна, но при адекватных процессах управления вполне осуществима. Хорошей практикой будет обратить внимание на производительность, адаптивный дизайн и фреймворк, позволяющий использовать единую кодовую базу для разных платформ. И конечно опыт. С каждым новым участком функционала его всё больше, а значит и результат становится лучше.
Автор: robotcheloveche
