#мобильная разработка

10 постов
пост №2003

Помните, мы перезапустили Синхронизацию за 3 месяца вместо года?

Так вот: после этого, мы ещё за месяц работы, силами одного программиста (!) запустили им мобильное приложение!

Есть такой фреймворк Capacitor.js. Он позволяет переиспользовать код сайтов в мобильных приложениях. Это довольно рискованный прием и хочется поделиться тем, как красиво получилось в этот раз, несмотря на 9 кругов ада внутри.

Разработчик приложения и автор статьи — Эдуард Аксамитов.

Иллюстрация: «Круги Ада» Боттичелли, Библиотека Ватикана

пост №1861

Только что опубликовали новое мобильное приложение в AppStore. Сделали его наши веб-разработчики на кросс-платформенной технологии CapacitorJS, так что не потребовалась отдельная команда мобильной разработки, сэкономили месяцы и миллионы рублей.

Два месяца переписывались с Apple по поводу in-app purchases и прочих коммерческих моментов. В результате всё решилось одним коротким звонком с Купертино. По телефону нам на хорошем русском объяснили, что «правила AppStore — это направляющие принципы, каждую ситуацию не распишешь формально, конкретно вам нужно сделать 1, 2, 3». Не стесняйтесь пользоваться опцией заказа звонка!

Интересно, что ни единого вопроса про Capacitor у Apple не было, хотя некоторые люди нас очень пугали, что любые веб-технологии — это сразу бан. Правда, наши фронтендеры собрали полноценное мобильное приложение — с оффлайном, входом через Apple ID и прочим, чего у сайтов обычно нет.

Раньше я был скептически настроен к кросс-платформенной мобильной разработке, но для не супер сложных приложений веб, кажется, победил.

Такой кайф, когда единая команда отвечает за продукт на всех платформах! Нет этого: «веб уже запрогал, андроид сделал не совсем как нужно, но сойдёт, а iOS-команда пока занята, ждём...»

Ура!

Если вы думаете о выпуске мобильного приложения — рекомендую присмотреться к Capacitor — классная технология. Подробный технический рассказ — примерно через месяц: клиент хочет сделать анонс, когда приложение немного обкатается.

пост №1836

Тормозит приложение.

На днях написала топ-менеджер одной ритейл-сети. Тормозит мобильное приложение. Медленно работает поиск, добавление в корзину, оформление заказа. Нажимаешь на кнопку и ждешь…

В ритейле каждая доля секунды задержки — это люди, которые не купили товары, прямые потери. Мобильные разработчики не исправляют ситуацию. Переводят стрелки на бэкендеров, мол это бэкенд тормозит. Как разобраться, на чьей стороне сломалось и починить проблему?

Хорошие разработчики собирают аналитику по производительности своих приложений — какое время занимают ключевые действия типа «открытие главной», «поиск», «добавление в корзину», «оплата». Это называется Real User Monitoring.

Дальше мы кладем эту информацию на график: на оси Х — время, которое занимает действие, на оси Y — количество пользователей. Столбики слева — хорошо. Длинный хвост справа — это несчастные, у них, например, экран оплаты грузится минуту! Эти люди поменяют приложение, если у них будет выбор!

Но это средние значения. Что, если приложение хорошо работает 23 часа в сутки, а по вечерам, в час-пик, в самое важное время, начинает тормозить?

Тут поможет другой классический график: на оси Х — время (вчера, сегодня в течении дня, завтра), на оси Y — время ответа (задержка, latency). Три черты — среднее время, медиана и 95 персентиль. То есть за сколько миллисекунд происходит оплата в среднем, у медианы и за какое время происходит оплата у 95% быстрых пользователей? Он помогает отследить, нет ли тормозов в определенное время суток или в день недели.

Составляем эти два графика для ключевых функций и видим, тормозит наше приложение или нет. По числам оцениваем, стало оно быстрее или медленнее.

Итак, шаг первый — замерить экраны и действия.

Теперь можно переходить к поиску первопричины. Приложение может тормозить само по себе или из-за медленного бэкенда.

Тут мы опираемся на те же два графика, но уже смотрим скорость ответа бэкенда.

Качественно настроить сбор данных и дэшборды — это дополнительная работа, но она с лихвой окупается при расследовании проблем.

Хотите заказать классную разработку или аудит? Обращайтесь! @samatg https://fansdev.ru

пост №1628

Яндекс Практикум ищет опытных Android и iOS-разработчиков для соавторства на курсах по мобильной разработке.

Работа командная, уже есть несколько крутых авторов, но нужны еще. Работа удаленная, 8-10 часов в неделю. Денег не много, зато кайф от обучения начинающих и полезные знакомства. Писать @paperbrain.

пост №1326

Вдохновляющая статья Coinbase о том, как они переписали свои приложения для iOS и Android на React Native и переформатировали команды под это. Перескажу основные тезисы.

Крупнейшая криптобиржа на свете, 56 миллионов пользователей в 100 странах, полтора миллиарда долларов прибыли в квартал.

200+ экранов, 30 мобильных разработчиков. Кросс-функциональные команды, которые поддерживали фичи, были такие: 8 человек, 2 бэкендера и 6 фронтов, по 2 на каждую платформу — 2 веб, 2 iOS, 2 Android. Цель перехода: из команд по 8 инженеров, сделать команды по 5, 2 бэкендера и 3 React Native.

Как сделали?

1. Не пытались переписать большое приложение по-частям (очень сложно интегрировать react native с нативой), а сделали отдельное приложение с самой сложной частью функциональности для небольшой части Pro-пользователей, чтобы проверить, возможно это вообще или нет — заняло 6 месяцев, всем понравилось.

2. На втором этапе, решили-таки попробовать впилить небольшой кусочек react native в старое приложение — добавили в основное старое приложение новый онбординг на react native из приложения Pro. Разработчикам было больно (вспомните статьи Airbnb), но за 6 месяцев справились.

3. Учитывая опыт из двух предыдущих шагов, переписали основное приложение на React Native за 6 месяцев, не пытались дружить нативу с react native.

4. Profit. Красивые числа о технических и бизнес-метриках смотрите в картинке ниже.

Пишут, что теперь и старые разработчики мобильных приложений и веб-разработчики сайта пишут код мобильных приложений на React Native — всего больше 100 комиттеров в репу.

Дальше собираются выделить общий уровень данных из веб-сайта на react и мобильных приложений на react native в общие библиотеки.

Их бы устами да мед пить! 🚀

пост №1098

Ура, классный эпизод получился!

Саша руководит мобильными разработчиками Сбербанк Онлайн, а Ярик - дизайнерами. Это сотни специалистов.

Я боялся, что гости окажутся энтерпрайз менеджерами с процессом головного мозга, с которыми не о чем будет говорить, только палкой тыкать. На деле получилась одна из самых бодрых записей. Был магический момент, когда ребята впервые рассказали публично, как через адский факап, они пришли к распределённой системе разработки с десятками кросфункциональных команд. Кайф. Теперь хочется позвать тинькова для дисса ;)

Слушайте и подписывайтесь на всех платформах: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.

Хотите послушать у нас кого-то конкретного или про какую-то тему? Пишите в личку, на почту [email protected] или просто комментарием в любом удобном месте.

P.S. Торжественно обещаю не перебивать гостей так часто и смеяться потише.

пост №692

Airbnb — одна из немногих крупных компаний (больше 100 мобильных разработчиков!), которая сделала ставку на React Native в мобильной разработке два года назад.

Их библиотека Native Navigation — одна из самых популярных.

За два года Airbnb написали на RN 80 тысяч строк кода, 220 экранов и 40 тысяч строк js-инфраструктуры (натива при этом 800 экранов и 320 тысяч строк кода).

Так вот, Airbnb отказывается от RN. Они описывают технические и организационные трудности в серии постов.

Аргументы, как всегда: незрелость технологии, плохие инструменты разработки, малое комьюнити и как следствие слабая веб-документация (в сравнении с iOS и Android), необходимость разбираться хорошо в мобайле и в js одновременно, сложность комбинации команд, сложность найма, низкая «воспринимаемая разработчиками» скорость разработки, добавленная сложность тестирования.

Ух.

Интересно, что они продолжают верить в Server-Driven Rendering. Это подход, в котором клиенты (мобильные приложения) умеют рисовать базовые компоненты, а сервер присылает список компонент и данные для экрана. Это дико интересный подход, и его на самом деле можно реализовать без RN (с RN он сам напрашивается). Сложности, которые возникают со старыми клиентами и фолбеками компонент в SDR — по настоящему интересная техническая задача. В ней нужно балансировать «красоту и гибкость в будущем» со сложность разработки «здесь и сейчас», а цена ошибки достаточно высока. Вот бы кто-то поделился своим опытом в этой области.

Часть проблем с RN, описанные Airbnb, специфичны для продуктовых компаний, часть — для крупных продуктовых компаний. В любом случае, «не создай себе кумира», выбирайте технологии не по хайпу, но на основе ваших потребностей и ваших ресурсов.

пост №280

iOS разработчик из восхитительного Basecamp рассказывает, как они делают мобильные приложения.

Для всех страниц есть фоллбек в webview сайта, многие нативные штуки делаются динамически на основе данных из веба. Это позволяет выкатывать новые фичи одновременно на обоих платформах в режиме webview (не теряя при этом приятных нативных деталей), а потом довозить нативную поддержку.

Интересный способ делать "нативные" кросс-платформенные мобильные приложения. Особенно мне понравилось утверждение, что веб/нативное - не бинарное отношение, а целый спектр возможностей.

https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture-afc071589c25

пост №141

Google представил Developer Preview для следующей версии Android — Android O. Список фич такой, что у любого неравнодушного мобильного разработчика слюнки потекут.

https://android-developers.googleblog.com/2017/03/first-preview-of-android-o.html

- Background limits, чтобы экономить батарейку (прямо как в iOS);
- Notification channels (!), чтобы легко отписываться от неинтерсных уведомлений, не блокируя пуши совсем. В айфоне так вообще проще удалить надоедливое приложение, чем понять, как отключить ему уведомления;
- Picture-in-picture, чтобы смотреть видео в маленьком окне (ох, от видео теперь не скрыться вообще нигде);
- Telecom Framework, чтобы скайпы и прочие вайберы работали также, как родное телефонное приложение, со списком звонков и прочим (уже есть в iOS);
- Low latency audio — качественное аудио было отличительной особенностью iOS, из-за этого есть десятки профессиональных программ-микшеров-пультов для iPad и ни одной для Android — that's going to change;
- и ещё многие другие улучшения.

Ложка дёгтя:
1. Покупатели флагманских моделей получат это обновление в лучшем случае через год-полтора, а массовый дешевый рынок вообще непонятно когда;
2. Производители железа испоганят прекрасную систему своими свистелками;

«Родной» телефон от Google Pixel не имеет этих недостатков, но стоит дороже, чем начальные модели iPhone'ов.

Android уверенно движется к званию самой продвинутой операционной системы. Осталось подрихтовать описанные выше шероховатости и как-то мотивировать Android-разработчиков писать более качественный софт. И тогда держись Apple.

пост №114

Apple перестал принимать обновления приложений, использующих rollout.io.

Раньше очередь на проверку обновлений приложений в AppStore была неделю-две и люди придумали целый бизнес на том, чтобы выкатывать хотфиксы без проверки. Сейчас среднее время ревью всего 1-3 дня — Apple прикрывает лавочку. Это всегда было против правил, так что нечего удивляться. Expedited review, к тому же, никто не отменял — нужно только уметь внятно формулировать мысли и говорить с живыми людьми.