Осталось буквально четыре дня до момента, когда мы закончим принимать заявки на участие во второй «Мобилизации» Яндекса. Она вновь объединит четыре летние школы для начинающих специалистов: Школу менеджмента, Школу мобильного дизайна, Школу разработки интерфейсов и Школу мобильной разработки под Android.
Своим опытом и знаниями с участниками будут делиться не только сотрудники Яндекса, которые делают приложения для миллионов пользователей, но и приглашенные специалисты. Мы не обойдемся только теорией. Будет много практики и командной работы над настоящими продуктами. Как всегда, обучение бесплатное, а всем иногородним студентам Яндекс оплатит проезд и проживание. Если вы еще не отправили заявку, есть немного времени это сделать. Занятия стартуют 3 июля и закончатся 23 сентября — в день двадцатилетия Яндекса.
В мобильной разработке одни из самых горячих споров ведутся вокруг нативной и гибридной разработки. Мы решили дать трём преподавателям «Мобилизации» порассуждать на эту тему. Получилось небольшое интервью, которое может быть интересно как новичкам в разработке, так и тем, кто уже определился со своим выбором.
Юрий Подорожный. Руководитель службы разработки мобильных геоинформационных сервисов Яндекса. Работает над Яндекс.Картами и Яндекс.Метро. Занимается мобильной разработкой более восьми лет. Основатель студии Any Void, которая в 2014 году стала частью Яндекса.
Сергей veged Бережной. Руководитель отдела разработки поисковых интерфейсов, в Яндексе с 2005 года. Успел поработать над Поиском, Почтой, Поиском по блогам, Я.ру, Картинками, Видео. Помимо этого, активно занимается развитием внутренних инструментов для создания сайтов.
Лола Кристаллинская. Руководитель департамента дизайна, работает в Яндексе с 2008 года, отвечает за найм, управление и развитие дизайнеров, коммуникации и образовательные программы департамента и всю экосистему дизайна в компании. С Лолы начался коллектив дизайнеров и исследователей дизайна Яндекса. До прихода в компанию руководила отделом создания сайтов Студии Артемия Лебедева.
Лола Кристаллинская:
Давайте для начала дадим определение, что вообще такое нативная и гибридная разработка и в чем между ними разница?
Юрий Подорожный:
В 2007 году появился iPhone, в 2008-м Apple дала возможность под него делать приложения, что и стало отправной точкой нативной разработки. Это компилируемый язык программирования со средой разработки, ограниченной какой-то одной мобильной платформой. Objective-C и Swift для iOS, Java — для Android. Приложения создаются на одном из этих «родных» языков по законам определенной платформы.
Лола:
В части программирования это было что-то революционно новое?
Юрий:
Конечно, нет. Сам термин «нативная» возник просто на контрасте с гибридным подходом.
Сергей Бережной:
Под гибридной разработкой мы подразумеваем способ писать приложения, когда оно полностью или частично рендерится и работает с помощью веб-технологий. То есть внутри используется что-то, реализованное с помощью HTML, CSS, JavaScript.
Юрий:
На самом деле чистое веб-приложение сейчас не сделать. Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C. Значит, все равно будет какой-то процент нативного кода. Чистые веб-приложений были, наверное, только первый год существования iPhone, когда еще нельзя было создавать их со стороны. И Apple тогда продвигала тему, чтобы разработчики делали веб-приложения. Кстати, эта функция есть до сих пор. Заходишь в Safari, нажимаешь на экран «домой», на рабочий стол добавляется иконка, по сути, это и есть чистое веб-приложение. Только его, конечно, не распространишь через Store.
Сергей:
Сейчас есть целый ряд фреймворков, платформ типа PhoneGap/Cordova, в которых, условно говоря, уже написан этот фрагмент кода. Ты просто берешь их за основу и разрабатываешь на них, сочетая с веб-элементами на свое усмотрение.
Юрий:
Гибридный подход возник, наверное, из естественного желания сэкономить время и ресурсы, когда мобильная разработка начала набирать обороты. Например, есть некая молодая ОС, есть целый спектр технологий, которые пришли из веба, и у многих возникает соблазн, почему бы их не использовать. Но, честно говоря, не знаю зачем. На мой взгляд, ни одно нормальное приложение с помощью веб-технологий не сделать.
Гибрид для простых задач, натив — для сложных
Лола:
В таком случае актуальна ли вообще проблема выбора? Например, я менеджер, у меня есть продукт и мне нужно сделать мобильную версию. Как принимать решение, что для меня лучше — гибридная разработка или нативная?
Сергей:
Нужно исходить из задачи, необходимых выразительных средств для ее реализации и имеющихся ресурсов. Если в жизни просят сыграть музыку, а у вас есть только краски, то будет тяжело. Если нужно в реальном времени обрабатывать видео с камеры, сделать 3D-анимацию и подобные сложные вещи, то без ядерных технологий нативной платформы не обойтись. И, наоборот, если вашему приложению в качестве выразительных средств достаточно простого черно-белого карандаша, то веб-технологии могут сэкономить время и деньги.
Юрий:
Согласен, все зависит от задачи. Но, на мой взгляд, веб уместен лишь в нескольких случаях. Например, если это совершенно новый продукт и пока не понятно, воспримет ли его рынок, нужен ли он кому-то или нет, то есть задача — протестировать некую гипотезу. Или если это просто отображение контента в небольшом количестве и не предполагается активного взаимодействия с интерфейсом, переходов между экранами и разделами. Например, приложение Meduza. Заходим на экран новости, это как раз веб-вью. У них простая верстка, точно такая же, как для веба, им даже контент готовить не надо, в мобильной версии все сразу отображается.
Сергей:
По задаче сайты могут быть совершенно разными. Помните, в свое время был выбор между тем, делать флэш-сайты или HTML-сайты. И все говорили, если хотите, текст, нарисованный по кругу, видео внутри и чтобы все было красиво, то нужно делать только флэш. Так и здесь.
Юрий:
Есть, конечно, удачные примеры гибридных приложений. Например, интересная модель у Basecamp: часть навигации реализована нативно, для того, чтобы переходы осуществлялись быстро и плавно, а отображение контента в списке задач сделано на HTML, благодаря чему у них одинаковые шаблоны для тачовой и мобильной версий. Но у нас в Яндекс.Картах всегда был нативный подход, потому что сделать приложение с картами, которое будет производительным и удобным, с помощью веб-технологий просто невозможно. Единственное место, где мы используем веб, это вывод лицензионного соглашения.
Скованные гайдлайнами
Лола:
В идеале все, конечно, должно идти от смысла, от того, что и зачем тебе нужно, какой продукт и что для него важно. Но мы живем в реальном мире, где не у всех и не всегда в принципе есть выбор. У кого-то не хватает денег, чтобы нанять целую команду разработчиков, поэтому приходится быть изобретательным. Какие еще факторы играют роль при выборе технологии?
Сергей:
Если бы у меня было бесконечное количество денег, я бы нанял трех разработчиков, которые сделали бы хорошие нативные версии под все платформы. Но я слишком жадный, чтобы позволять себе такое расточительство. Гибридный подход позволяет сэкономить: сделать один вариант и использовать его везде. Но если в дальнейшем задача усложнится, и появится необходимость, например, сделать наложение картинок на видео в реальном времени, то все равно придется потратиться на трех разработчиков.
Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.
Лола:
Если приложение сделано не по гайдам, то проверку в Store не пройти?
Юрий:
Можно, конечно. Далеко не все приложения, прошедние проверку в Apple, соответствуют дизайнерским гайдлайнам. Никто особо не следит за соблюдением этих правил.
Сергей:
Но мы же говорим о приложениях A+ и AAA-класса, о высшей лиге. Если такие делать, то вопрос о нативном дизайне для каждой платформы обязательно встанет.
Лола:
А общий дизайн невозможен в нативной разработке: если просто свои кнопки и контролы?
Сергей:
Смотря к какому лагерю вы относитесь. Некоторые считают, что приложение должно быть внутри платформы. Альтернативная точка зрения – каждый бренд должен выглядеть на всех платформах одинаково. Если посмотреть на Instagram или Facebook, то это как раз примеры борьбы бренда за самоидентификацию по отношению к платформам. Они специально дизайнят свои приложения так, чтобы те выглядели по-особенному и везде одинаково.
Как делают приложения в Яндексе
Лола:
Для многих тот факт, что Facebook разочаровались в веб-технологиях и перешли на нативную разработку, стал доказательством превосходства последней. Насколько это обосновано?
Сергей:
Это как раз история про то, что хорошо быть Facebook, когда можно нанять сколько угодно программистов, чтобы сделать продукт отдельно для всех платформ. Кстати, в ответ на такой шаг некие ребята, чтобы попиарить свою студию, сверстали фейсбучное приложение на веб-технологиях без всех тех недостатков, из-за которых Facebook сменили подход. То есть здесь всё не так однозначно. Может быть, ваше веб-приложение тормозит не потому что веб-технологии плохие, а потому что у вас программист не сделал всё что мог.
Юрий:
У Facebook в первой версии было полностью нативное приложение, потом они перешли на HTML, пару лет пожили с двумя звездочками в Store, потому что продукт реально тормозил, все их ругали, в итоге вернулись к нативу. Вот живая иллюстрация того, как из благих намерений хочешь сделать хороший интерфейс на веб-технологиях, но в итоге все равно упираешься в низкую производительность или недостаток средств для развития.
Лола:
Но поисковое приложение Яндекса, например, сделано гибридно. Почему, если столько недостатков у веб-технологий?
Сергей:
Наши сервисы в основном решают информационные задачи, поэтому и интерфейсы могут быть проще, чем в случае с развлекательными игровыми продуктами. Так что мы не сильно упираемся в производительность. А выразительные средства веб-технологий при умелом использовании не такие уж и скудные. Кроме того, гибкость гибридного подхода позволяет не переписывать полностью какие-то наработки, сделанные ранее в вебе, которых у нас довольно много, и их переделка потребовала бы больших трудозатрат. А так мы экономим время и деньги.
Но сложно приходится нашим дизайнерам — им нужно создавать интерфейсы, которые будут восприниматься пользователями как «общий интерфейс Яндекса» независимо от платформы.
Юрий:
Помимо UI, есть еще вопрос удобства пользователя. И у каждой платформы свой UX. Пользователи ожидают, что хорошее приложение будет удобным и будет следовать их привычкам.
Лола:
Как вы в своих продуктах решаете проблему баланса между удобством пользователей и единством бренда?
Юрий:
Два года назад эта проблема в Яндексе была более явной. Все приложения сильно отличались между собой по стилистике. В итоге мы разработали свои общие для всех интерфейсные гайды, выбирая наиболее удачные паттерны из всех мобильных гайдлайнов, а иногда и придумывая свои, лучшие. Но процесс внедрения новых правил очень длительный, с огромным количеством подводных камней и пока не завершен окончательно.
Сергей:
Основные движущие факторы наших экспериментов с технологиями — это оптимизация трудозатрат на разработку и желание предоставить пользователям качественный продукт. Изначально мы делали наше поисковое приложение нативно, но столкнулись, например, еще с такой проблемой, как синхронизация команд и релизов. Даже если изначально вы решили потратиться на разных разработчиков под три разные платформы, то в дальнейшем рискуете столкнуться с проблемой управления. Как сделать так, чтобы новый UI, новые фичи на этих платформах везде обновлялись в одно время, и чтобы у них было действительно синхронное понимание этого интерфейса?
Как показывает практика, в крупных компаниях все это превращается в разные кланы разработчиков: одни делают мобильную версию приложения, другие — тач-версию сайта, третьи — десктопную версию, кто-то создает приложение для Android, а кто-то — для Windows Phone. И нужен менеджер 80-го уровня, чтобы синхронизировать все эти пять команд между собой. А подход единого кода, следовательно, единой команды, помогает избавиться от подобной путаницы.
Юрий:
На мой взгляд, это не проблема, а условие задачи. Например, когда мы в Яндекс.Картах делаем какую-то новую штуковину, то сначала отрабатываем ее на одной платформе, а потом уже, собрав все грабли, добавляем на все остальные.
Что нужно знать разработчику, чтобы начать делать приложения
Лола:
Насколько разнится порог вхождения у нативной и гибридной технологий? Вообще, какая база должна быть у программиста, чтобы уйти в мобильную разработку?
Юрий:
Разработчик нативных приложений должен знать Objective-C, или SWIFT, или Java, или C++. Но, на мой взгляд, на каком языке писать, дело наживное, ключевое здесь — базовые знания программирования. Все, с кем я в своей жизни делал приложения, были студенты без мобильного опыта, но с хорошим бэкграундом. Все остальное постигается на практике. Попадешь в хорошую команду профессионалов, вырастешь на порядок быстрее.
Сергей:
Если у человека есть опыт разработки интерфейсов с помощью HTML, CSS или JavaScript, то придется глубже погрузиться в специфику именно мобильных браузеров. Если мы говорим об интерфейсах, то это паттерны взаимодействия — больше пальцами, меньше с клавиатурой. Своя специфика внутри Runtime JavaScript и CSS для мобильных браузеров, но отличий в последнее время все меньше. Как правило, разработка под мобильные проще, чем под широкий спектр десктопных браузеров, потому что у них, как относительно новой технологии, более современная реализация именно веб-стандартов. Но сейчас по мере того, как мобильные платформы стареют, начинают возникать те же проблемы, что на десктопе, когда есть клиенты со старыми браузерами, которые какие-то вещи не поддерживают.
Лола:
А есть у программистов деление на мобильных и не мобильных? Например, на рынке дизайна сейчас это уже обязательный дополнительный скилл. Может быть, ты действительно каждый день не имеешь дела с мобильными интерфейсами, но без базовых знаний мобильного дизайна уже почти невозможно пройти собеседование и отбор.
Юрий:
Программирование имеет такое огромное поле применения, что человек, который занимается разработкой на C++ каких-то серверных компонентов, может вообще ничего не знать про мобильную разработку, писать, к примеру, какой-нибудь банковский софт и комфортно себя чувствовать.
Сергей:
Согласен, разрабатывать микроконтроллеры или пользовательские интерфейсы — вещи действительно очень разные, и перепрыгнуть из одной лодки в другую не так-то просто. Но если говорить о мобильной разработке, то в Яндекс мы берем людей, которые верстают наши сайты сразу под декстопные и мобильные версии. То есть они должны понимать, как наша верстка, наш HTML, CSS и JavaScript будут работать в десктопных браузерах, а как в мобильных, какие есть особенности и нюансы. Получается, как с дизайнерами, дополнительный скилл фронтенд-разработчика.
Лола:
А внутри мобильной сферы насколько жесткое деление специалистов в зависимости от платформы?
Юрий:
Android и iOS — две совершенно разные истории. При желании, конечно, можно научиться делать и то, и другое. Но среди тех, с кем я работал, не было ни одного, кто менял бы платформы.
Сергей:
Каждая платформа — это достаточно глубокая экосистема, и для работы нужен хороший практический опыт. Но думаю, стажера со знанием андроидных технологий и желающего изучить эппловские, в команду, которая занимается iOS-приложениями, мы легко возьмем. Разница все же не такая большая, как между программированием микроконтроллеров.
Адаптивная верстка — не панацея
Лола:
Я слышала, что для бедных, но хитрых, есть еще такая вещь, как адаптивная верстка, которая сразу и для веба, и для мобильных.
Сергей:
Есть технологическая возможность сделать интерфейс на веб-технологиях так, чтобы он вел себя по-разному на десктопе и на мобильных, и чтобы мог адаптироваться под них. Но, к сожалению, резиновость некоторых изделий не бесконечна, и та вариативность, в пределах которой может быть эта адаптивность, весьма ограничена. Главное преимущество такой резиновой верстки в том, что вы один код сверстали и везде его используете.
В Яндексе мы делаем немного по-другому: есть общие куски, которые мы используем везде, а есть те, которые должны быть разными, под разные размеры, их мы пишем отдельно. Таким образом мы пытаемся усидеть на двух стульях: взять и реиспользование кода, которое есть в концепции адаптивности, и привнести более тонкую адаптивность конкретными переопределениями для тачовых и для десктопных платформ.
Лола:
Давайте резюмируем, как менеджеру, дизайнеру и разработчику учитывать все эти нюансы?
Сергей:
Я рекомендую не быть упоротыми фанатиками и каждый раз осознанно делать выбор, имея в голове как можно более широкий контекст и принимая во внимание все факторы. Не мыслить типа «Раз Facebook перешел с гибридного подхода на нативный, значит, и нам нужно» или «Раз Яндекс верстает свою выдачу в приложении на веб-технологиях, значит, и нам надо делать так». Нужно погрузиться в тему.
Юрий:
А для этого нужно как минимум понимать и в том, и в другом. Понимать, как устроен мир, как это работает, потому что единственно правильного подхода нет. Вполне можно делать нативное приложение, в котором какие-то интерфейсы и разделы будут сделаны на вебе, и тем самым местами упрощать себе жизнь. Нужно разбирать каждую задачу индивидуально, и только потом принимать решение. Волшебной таблетки здесь не существует.
Автор: Яндекс
