Всем привет! Меня зовут Дмитрий Репин, я Flutter-разработчик в Surf.

В этой статье я расскажу, как работать с асинхронностью в Dart: всё о самых важных классах библиотеки dart:async с примерами под катом. Поговорим о том, как в однопоточном языке сходить в сеть или базу данных и при этом не затормозить приложение.

Эта статья написана по материалам моего ролика на YouTube. Посмотрите видео, если больше любите слушать, чем читать.

Dart однопоточный язык программирования, который выполняется в одном процессе. Что это значит по факту: если мы будем в одном потоке выполнять любую операцию, требующую времени, то приложение просто подвиснет. И всё время, пока мы, например, ждём ответа от сервера или выполнения запроса в БД, пользователь будет страдать и смотреть на лагающий интерфейс.

К счастью, Dart хитрый однопоточный язык, который предоставляет механизм Event Loop он даёт возможность откладывать какие-то операции на потом, когда поток будет посвободнее.Такие отложенные операции мы будем называть асинхронными.

Все операции в Dart можно разделить на два типа:

1. Синхронные те, что блокируют другие операции до своего выполнения.

2. Асинхронные, которые позволяют другим операциям выполняться, пока текущая не закончится.

Вместе с операциями, функции тоже можно поделить на синхронные и асинхронные. И синхронные, и асинхронные функции могут содержать синхронные операции. Асинхронной функция начнёт считаться в тот момент, когда в ней появляется хотя бы одна асинхронная операция.

Создание асинхронной функции с помощью класса Future

Чтобы было нагляднее, давайте напишем простую асинхронную функцию. Пусть она будет принимать строку и смотреть на её длину: если она больше 10 символов, функция вернёт число 42, в ином случае ошибку. Представим, что вычисление длины строки достаточно тяжеловесная операция чтобы сделать её асинхронной.

Чтобы сделать код асинхронным, нам понадобится класс Future. В конструктор он принимает функцию, которую необходимо выполнить асинхронно, а также предоставляет два обработчика: then и catchError. Первый обрабатывает успешное выполнение функции, а второй выполнение функции с ошибкой. В итоге у нас должен получиться такой код:

runSimpleFutureExample({    String question = 'В чем смысл жизни и всего такого?',  }) {    print('Start of future example');    Future(() {      print('Вопрос: $question');      if (question.length > 10) {         return 42;      } else {        throw Exception('Вы задали недостаточно сложный вопрос.');      }    }).then((result) {      print('Ответ: $result');    }).catchError((error) {      print('Ошибка. $error');    });    print('Finish of future example');  }

В начале и конце метода выводятся строки о том, что он начал и закончил работу, а между ними создаётся сам future. В конструктор он принимает метод, который вычисляет длину строки, а затем к Future добавляются обработчики then и catchError, которые обрабатывают выполнение Future. Попробуем запустить этот пример и посмотрим, в каком порядке выводится на консоль результат:

Start of future example

Finish of future example

Вопрос: В чем смысл жизни и всего такого?

Ответ: 42

В результате сначала выводятся строки о начале и завершении метода, а потом выполняется код самого Future. Дело в том, что асинхронный код в Dart выполняется исключительно после синхронного. Соответственно, в синхронном коде мы не можем обработать результат асинхронной операции при работе с асинхронщиной стоит держать это в голове.

Работать с Future через обработчики then и catchError не самая хорошая идея, особенно если нужно передать результат одного Future во второй, а второго в третий и т. д., порождая callback hell.

Для таких случаев Dart предоставляет ключевые слова async и await. Словом async помечается функция, исполняющая асинхронные операции через await. Словом await помечаются сами асинхронные операции. К сожалению, при таком подходе мы теряем обработчик catchError, однако никто не мешает нам обрабатывать ошибки через стандартный try/catch. Чтобы понять, как это работает, перепишем наш предыдущий пример с использованием async/await и для удобства вынесем Future в отдельный метод:

 runFutureWithAwaitExample({    String question = 'В чем смысл жизни и всего такого?',  }) async {    print('Start of future example');    try {      final result = await _getAnswerForQuestion(        'В чем смысл жизни и всего такого?',      );      print('Ответ: $result');    } catch (error) {      print('Ошибка. $error');    }    print('Finish of future example');  }   Future<int> _getAnswerForQuestion(String question) => Future(() {        print('Вопрос: $question');        if (question.length > 10) {          return 42;        } else {          throw Exception('Вы задали недостаточно сложный вопрос.');        }      });

Здесь мы объявили метод, возвращающий Future. Вызываем его с использованием слова await, передавая в переменную result, с которой мы можем работать дальше, как будто в синхронном коде. Выведем на консоль результат работы метода:

Start of future example

Вопрос: В чем смысл жизни и всего такого?

Ответ: 42

Finish of future example

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

Обработка последовательности асинхронных событий с помощью Stream

Помимо Future, есть ещё один важный класс для работы с асинхронностью Stream. В отличие от Future, Stream может обрабатывать целый набор асинхронных событий. Давайте сразу разберём на примере:

void runStreamSimpleExample() {    print('Simple stream example started');    final stream = Stream.fromIterable([1, 2, 3, 4, 5]);    stream.listen((number) {      print('listener: $number');    });    print('Simple stream example finished');  }

У стрима много разных конструкторов, посмотрите их в документации. Здесь используем fromIterable. Создаём в массиве пять чисел, подписываемся на стрим через метод listen и выводим на консоль:

Simple stream example started

Simple stream example finished

listener: 1

listener: 2

listener: 3

listener: 4

listener: 5

Как и в случае с Future, сначала выполняется синхронный код: сообщения о старте и завершения примера. Только потом обрабатывается стрим и выводятся на консоль числа. В этом примере подписка на стрим обрабатывается асинхронно через listen, однако есть способ обрабатывать стрим через знакомые нам ключевые слова async и await. Перепишем пример с их использованием:

void runStreamAwaitedSimpleExample() async {    print('Simple stream example with await started');    final stream = Stream.fromIterable([1, 2, 3, 4, 5]);    await for (final number in stream) {      print('Number: $number');    }    print('Simple stream example with await finished');  }

Теперь обработка стрима похожа на обычный цикл. Но не стоит обрабатывать слишком большие стримы таким образом: это может затормозить работу программы. Выведем результат на консоль:

Simple stream example started

listener: 1

listener: 2

listener: 3

listener: 4

listener: 5

Simple stream example finished

Тут всё так же, как и с async/await во future. Сама функция стала асинхронной, поэтому теперь обработка Stream происходит до завершения метода.

Single-subscription и broadcast стримы. Основы StreamController

Представим, что нам нужно подписаться на стрим в двух разных местах программы. Для этого можно сделать какой-нибудь синглтон, который бы предоставлял стрим и который можно было бы дёргать в двух разных частях кода. Чтобы не усложнять, попробуем подписаться на стрим дважды в одном методе, и посмотрим, что получится:

print('Simple stream example started');    final stream = Stream.fromIterable([1, 2, 3, 4, 5]);    stream.listen((number) {      print('listener 1: $number');    });    stream.listen((number) {      print('listener 2: $number');    });    print('Simple stream example finished');

И результат:

The following StateError was thrown while handling a gesture.

Bad state: Stream has already been listened to.

Мы получаем ошибку: на стрим уже произведена подписка и подписаться второй раз не выйдет.

Здесь стоит рассказать о том, что существует два типа стримов: single-subscription и broadcast стримы. Мы создали single-subscription стрим. Такие стримы поставляют все данные подписчику разом и только после самой подписки. Так и происходит в нашем примере.

Broadcast стримы отдают свои данные вне зависимости от того, подписан ли кто-нибудь на них или нет. При этом подписчики стрима получают события только с момента подписки, а не с момента старта жизни стрима. При создании стрима стоит посмотреть документацию к конструктору и разобраться, какие ограничения он накладывает и стрим какого типа создаётся через этот конструктор.

Чтобы увидеть разницу, создадим broadcast стрим. В этом примере для создания стрима мы не будем использовать непосредственно сам Stream. Мы будем работать с классом StreamController. Он предоставляет доступ к самому стриму, даёт возможность управлять им и добавлять в него события.

///пример broadcast стрима  void runBroadcastStreamExample() {    print('Broadcast stream example started');    final streamController = StreamController.broadcast();    streamController.stream.listen((number) {      print('Listener 1: $number');    });    streamController.stream.listen((number) {      print('Listener 2: $number');    });    streamController.sink.add(1);    streamController.sink.add(2);    streamController.sink.add(3);    streamController.sink.add(4);    streamController.sink.add(5);    streamController.close();    print('Broadcast stream example finished');  }

Мы создали StreamController с broadcast стримом, дважды подписались на него и добавили через sink пять чисел, после чего закрыли стрим. Смотрим, что ушло на консоль:

Broadcast stream example started

Broadcast stream example finished

Listener 1: 1

Listener 2: 1

Listener 1: 2

Listener 2: 2

Listener 1: 3

Listener 2: 3

Listener 1: 4

Listener 2: 4

Listener 1: 5

Listener 2: 5

Проблем не возникло: два подписчика отработали, как и ожидалось. На самом деле у StreamController достаточно много функций, рекомендую почитать документацию к нему.

Отписка от стрима с помощью StreamSubscription

Помимо управления самим стримом часто возникает потребность управлять подпиской на него для этого в dart:async добавлен StreamSubscription. Кстати, мы уже неявно работали с ним в наших предыдущих примерах, когда подписывались на стрим: на самом деле метод listen возвращает его, и таким образом мы можем выделить подписку в переменную. Модифицируем предыдущий пример так, чтобы вторая подписка отменялась после числа 3:

///пример broadcast стрима  void runBroadcastStreamExample() {    print('Broadcast stream example started');    final streamController = StreamController.broadcast();    streamController.stream.listen((number) {      print('Listener 1: $number');    });    StreamSubscription sub2;    sub2 = streamController.stream.listen((number) {      print('Listener 2: $number');      if (number == 3) {        sub2.cancel();      }    });    streamController.sink.add(1);    streamController.sink.add(2);    streamController.sink.add(3);    streamController.sink.add(4);    streamController.sink.add(5);    streamController.close();    print('Broadcast stream example finished');  }

Тут без сюрпризов, на консоль выводится то, что мы ожидали:

Broadcast stream example started

Broadcast stream example finished

Listener 1: 1

Listener 2: 1

Listener 1: 2

Listener 2: 2

Listener 1: 3

Listener 2: 3

Listener 1: 4

Listener 1: 5

Стоит отметить, что StreamSubscription не только даёт возможность отменять подписку полностью, но и приостанавливать и возобновлять её, а также предоставляет колбэки на события подписки.

Как упростить работу с асинхронностью

Мы разобрали все самые важные классы для dart:async, но осталось ещё три, о которых я бы хотел рассказать. Возможно, они используются не так часто, но могут быть очень полезны в определённых ситуациях.

Completer

Completer позволяет поставлять Future, отправлять событие о выполнении или событие об ошибке. Это может быть полезно, когда нужно сделать цепочку Future и вернуть результат.

Разберём на примере. Пусть у нас будет completer, который складывает два числа с трёхсекундной задержкой. Это очень простой пример, но важно понимать, что тут можно сделать большую вложенность из Future и компактно уместить в один класс.

class CompleterTester {  void runCompleterInitTest() async {    print('Completer example started');    var sumCompleter = SumCompleter();    var sum = await sumCompleter.sum(20, 22);    print('Completer result: ' + sum.toString());    print('Completer example finished');  }} class SumCompleter {  Completer<int> completer = Completer();   Future<int> sum(int a, int b) {    _sumAsync(a, b);    return completer.future;  }   void _sumAsync(int a, int b) {    Future.delayed(Duration(seconds: 3), () {      return a + b;    }).then((value) {      completer.complete(value);    });  }}

Разберём, что тут произошло. Мы создали класс SumCompleter и создали в нём completer. Затем объявили метод sum, который вызывает приватный метод на сложение и возвращает Future этого completer. Затем этот приватный метод выполняет операцию и вызывает метод complete у комплитера. После этого пользователь метода получает результат.

Такой подход позволяет инкапсулировать в себе любую сложную часто используемую асинхронную логику и удобно с ней работать.

StreamIterator

Представьте, что вам нужно управлять переходом к следующему айтему стрима и делать это именно тогда, когда вам нужно. Именно это и делает StreamIterator. Он предоставляет метод moveNext для перехода к следующему элементу стрима. moveNext вернет true, если элемент пришел, и false, если стрим был закрыт. Также StreamIterator предоставляет свойство current для получения текущего элемента. Ну и конечно, метод cancel для отмены подписки. Небольшой пример по работе класса:

void runStreamIteratorExample() async {    print('StreamIteratorExample started');    var stream = Stream.fromIterable([1, 2, 3]);    var iterator = StreamIterator(stream);    bool moveResult;    do {      moveResult = await iterator.moveNext();      print('number: ${iterator.current}');    } while (moveResult);    print('StreamIteratorExample finished');  }

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

StreamTransformer

На самом деле это немного переусложнённая штука, но она отлично справляется, если вам нужно много раз трансформировать поток в приложении определённым образом. Самый очевидный пример разделение файла на строки. Разберём на примере и напишем трансформер, который будет удваивать приходящее в него число:

void runStreamTransformerExample() async {    print('StreamTransformer example started');    StreamTransformer doubleTransformer =        new StreamTransformer.fromHandlers(handleData: (data, EventSink sink) {      sink.add(data * 2);    });     StreamController controller = StreamController();    controller.stream.transform(doubleTransformer).listen((data) {      print('data: $data');    });     controller.add(1);    controller.add(2);    controller.add(3);    print('StreamTransformer example finished');  }

В нашем случае он будет принимать на вход данные, которые нужно трансформировать, и sink, в который мы должны передать трансформированные данные. В теле метода просто удваиваем приходящее значение. Затем остаётся только трансформировать стрим с помощью метода transform. И вуаля: в методе listen значение удваивается. Обратите внимание: трансформер может и не отдать данные в синк, а может отдать два раза. То есть он работает не только как map или where, а наделён гораздо большей функциональностью.

Рекомендую поиграться с этими примерами они есть на нашем GitHub. Так вы точно поймете, как устроена асинхронность в Dart. Если что-то непонятно, задавайте вопросы я отвечу в комментариях.

Привет!

Уже прошли времена, когда Flutter был просто хайповой технологией, а разработчики при упоминании его закатывали глаза и прогнозировали скорую гибель. Но гибели не случилось: он стабильно развивается уже три года, привлекая на свою сторону всё больше людей. Спрос на Flutter растёт и со стороны бизнеса.

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

Регистрация

Вебинар будет полезен тем, кто интересуется Flutter, чтобы сделать собственный проект, стать мобильным разработчиком или оценить перспективы этой технологии.

Что обсудим:

• Где искать работу Flutter-разработчику. Как меняется спрос и предложение на рынке. Поговорим о цифрах.

• Почему компании всё чаще выбирают Flutter. Как выглядит рынок мобильной разработки сейчас и какое место в нём занимает Flutter.

• Наш опыт: как избежать распространённых ошибок, как лучше начать проект, какие задачи решает Flutter.

Мероприятие пройдёт в формате живого обсуждения между участниками и ведущими разработчиками компании Surf, и займёт это примерно 1,5 часа.

Спикеры

Евгений Сатуров, Flutter TeamLead Surf. Основатель Flutter Dev Podcast. Соорганизатор крупнейшей российской конференции Mobius. Лидер IT-комьюнити Google Developer Group Voronezh. За плечами 14 проектов в Surf среди них Росбанк Бизнес (Flutter), SBI Bank (Android), MDK (Android).

Артём Зайцев, руководитель Flutter-отдела Surf. В прошлом Android-разработчик и тимлид. Стоял у истоков Flutter-отдела в Surf. Сегодня Артём руководит этим отделом и активно продвигает Flutter в российском комьюнити. Приложил руку ко многим проектам, включая Магнит, MDK и KFC.

Михаил Зотьев, Flutter-разработчик Surf.Flutter-разработчик, тимлид. Активный спикер Surf, попал ТОП-3 всех докладчиков на Mobius 2020 и DartUp 2020. Ещё Михаил ведёт телеграм-канал о Flutter-разработке Oh, my Flutter.

Андрей Савостьянов, Flutter-разработчик Surf. В прошлом Андрей работал с Java/Spring/Android создавал железные решения и протоколы, прикладные системы по автоматизации и мониторингу технологических комплексов. Почти 2 года назад сменил специализацию и ни разу не пожалел.

Регистрация

Вебинар начнётся 4 февраля в 18:00 МСК на YouTube-канале Surf.

Чтобы поучаствовать в нём, заполните форму регистрации. Мы отправим напоминание и ссылку на трансляцию за день и за час до начала вебинара.

До встречи!

На живом примере приложения в визуальном стиле игры Cyberpunk 2077 покажем всю мощь фреймворка Flutter и возможность сборки единого кода под разные платформы.

Вместе с вами в прямом эфире соберём по-настоящему мультиплатформенное приложение для веба, iOS, Android и desktop.

РЕГИСТРАЦИЯ

Что будет

• Разработаем вместе аутентичный дизайн, кастомные виджеты и опубликуем.

• В UI ките игры Cyberpunk 2077 рисуем кнопку, панельку, градиентный фон, скролл, вращающийся логотип. Билдим.

• Адаптируем верстку для разных экранов и платформ.

• Реализуем навигацию между экранами.

• Открытый исходный код.

Вебинар проводят разработчики компании Surf

Андрей Савостьянов, Flutter-разработчик Surf. В прошлом Андрей работал с Java/Spring/Android создавал железные решения и протоколы, прикладные системы по автоматизации и мониторингу технологических комплексов. Почти 2 года назад сменил специализацию и ни разу не пожалел. Андрей большой энтузиаст dart/flutter и даже делает fullstack приложения на дарте.

Михаил Зотьев, Flutter-разработчик Surf.Flutter-разработчик, тимлид. Активный спикер Surf, попал ТОП-3 всех докладчиков на Mobius 2020 и DartUp 2020. Ещё Михаил ведёт телеграм-канал о Flutter-разработке Oh, my Flutter

Регистрация

Вебинар начнётся 25 февраля в 18:00 МСК на YouTube-канале Surf.

Чтобы поучаствовать в нём, заполните форму регистрации. Мы отправим напоминание и ссылку на трансляцию за день и за час до начала вебинара.

До встречи!

РЕГИСТРАЦИЯ

Хайди хо, Кайл!

Меня зовут Диана и я бизнес-аналитик в компании Surf. В прошлом году я закончила бакалавриат факультета компьютерных наук в ВГУ: это дало мне базовые теоретические знания. Однако теория мало применима без практики: теперь набиваю шишки в настоящих проектах.

Я пришла к вам для того, чтобы поделиться опытом, который получила на своём первом боевом проекте. Мы делали банковское мобильное приложение со сложной архитектурой и кучей фич.

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

Пристёгивайтесь покрепче: мы начинаем увлекательное путешествие по миру ошибок начинающего аналитика (все трюки были выполнены профессиональными каскадёрами, не повторять в домашних условиях).

Не бойтесь задавать больше вопросов и просить уточнений

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

Лучше задать больше вопросов, чем что-то упустить. Например, когда работаешь над проектом, важно уточнить:

• На чьей стороне будет реализована логика: фронта, middleware, бэка?

• Как определять нужное состояние элемента? Как и где получать и обрабатывать нужные параметры?

• Примерный макет дизайна, потому что он наглядно показывает, что именно должно быть реализовано, проще воспринимать требования.

• Касаются ли вашей стороны эти требования или от вас никаких доработок и не потребуется?

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

Проверяйте и перепроверяйте выполнение договорённостей

Когда в процессе проработки фичи участвует большое количество человек, это как минимум значит, что сторонам будет непросто договориться. А ещё это значит, что сложно будет уследить за всеми требованиями и договорённостями.

Например, на моем проекте в обсуждении новой функциональности могут участвовать проджект-менеджеры и бизнес-аналитики со стороны команд фронта и бэка, продакт-оунеры и тестировщики со стороны заказчика.

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

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

Не стесняйтесь быть настойчивым и даже назойливым, иногда вы и проджект-менеджер единственные, кто может повлиять на то, что договорённости будут выполнены в срок. Если видите, что ответов нет в оговоренное время, не стесняйтесь пинговать коллег. Иначе ожидание может сильно затянуться.

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

Пример из жизни

Мы разрабатывали фичу, которая при выполнении определённого условия отображала кнопку на главном экране. Когда обсуждали реализацию, решили, что условие будет проверяться на бэке, а фронт будет получать поле с признаком выполнения или невыполнения этого условия.

Я не акцентировала внимание бэкендеров и продакт оунера на том, насколько важно, чтобы бэк присылал нам этот признак. Когда фича должна была уже уйти в разработку, этого признака всё ещё не было и в помине, потому что ни бэк, ни сторонний сервис, к API которого мы обращались, не разработали его.

Из-за этого процесс задержался ещё на неделю, потому что пришлось потратить много времени на повторное обсуждение. В итоге решили кнопку отображать всегда:)

Не будьте, как я, обращайте внимание коллег на ключевые моменты, необходимые для выполнения.

Уточняйте, как сделать проще

Бывает, что бизнес-аналитику реализация фичи кажется удобной. Он предлагает её разработчику, а в ответ получает: Чё-то сложно, давай по-другому?. Это нормально: взгляды аналитика и разработчика на реализацию фичи могут разительно отличаться: разработчик понимает, что ему хотят втюхать что-то сложное и заморочное, и идёт в отказ.

Если бизнес-аналитику не хватает опыта, чтобы оценить, насколько сложен вариант реализации, лучше сразу прийти к разработчикам и посоветоваться с ними. Иначе потом придется проходить новый круг ада: обсуждать изменения. Кроме того, это может сдвинуть сроки реализации: не нужно объяснять, почему это плохо:)

Френдли ремайндер

Если встаёт вопрос, на чьей стороне должна быть реализована сложная логика, связанная со сравнениями, вычислениями, сортировкой и так далее, практически всегда логичнее вынести её на бэк. Запомните мой совет и повторяйте его как мантру на всех созвонах (и перед сном).

Будьте внимательным к потенциально проблемным требованиям

Если на этапе верхнеуровневой аналитики чуйка шепчет вам, что требования могут перерасти из маленькой задачи на день в большую и неповоротливую фичу не игнорируйте эти сигналы и не спускайте всё на тормозах, мол, прорвёмся. Обычно я составляю большой список вопросов к заказчику и к бэку по требованиям, где прописываю, правильно ли я поняла формулировку.

Уточните (если нужно, несколько раз), правильно ли вы поняли, что ваша задача просто добавить картинку котика на экран. Может оказаться, что добавить нужно обязательно чеширского кота, а ещё он должен улыбаться в момент, когда вы моргаете. Я специально привела утрированный пример.

А вот пример из жизни. Недавно мы параллельно вели две фичи от разных продакт-оунеров. Фичи были частично взаимосвязаны, но требования во многих местах противоречили друг другу. Каждый продакт видел UI по-своему: договориться было достаточно трудно. Тогда пришлось столкнуть их лбами. После этому мы наконец пришли к варианту, устраивающему всех.

Важно быть начеку и проверять, не противоречат ли новые требования уже реализованной функциональности.

Помните, что есть много требований, которые могут быть не видны не вооруженным опытом взглядом под толщей воды из документа с требованиями. Хорошая новость: чем опытнее становится бизнес-аналитик, тем больше потенциально проблемных мест он видит и тем тщательнее терзает заказчика вопросами и уточнениями. Поэтому сделайте глубокий вдох и наберитесь терпения! Дальше лучше.

Как определить, что перед вами задача-оборотень, которая может превратиться из человечной в дикую? По количеству непоняток. Берегитесь, если:

• Нет точной информации, как обрабатывать значения, каким образом и где они будут вычисляться, как их подставлять и отображать.

• Не очевидна инициализация флоу и переход между экранами.

• Нет четкого понимания логики.

Например, несколько месяцев назад мы начали обсуждение фичи без определённых требований. У продакт-оунера не было четкого понимания, что должно получиться в итоге. Это стоило нам многих часов созвонов-обсуждений и несколько раз перекроенного ТЗ.

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

Пример

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

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

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

_______

Я описала только малую часть ошибок, с которой может столкнуться начинающий бизнес-аналитик. Многие ошибки вам ещё предстоит совершить самим в любом случае. Однако я постаралась поподробнее описать процессы взаимодействия и общения в реальном проекте. Надеюсь, это поможет вам легче влиться в проект.

Вот и всё, мои маленькие хоббиты. Я поделилась с вами своей мудростью, теперь вы сами по себе. Не дрейфте, не теряйтесь, будьте настойчивы и внимательны. В добрый путь!

Привет! Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает мобильные приложения с 2011 года. В этом материале поговорим о тестировании устройств Android, на которых нет поддержки Google Services.

Huawei без Google-сервисов начали массово выпускаться в 2019 году. Мы в Surf, разумеется, задумались о будущем: как сильно пострадают наши процессы и что нужно незамедлительно осваивать.

Я поделюсь впечатлениями от работы с Android без Google-сервисов и расскажу, какие возможности имеют такие мобильные устройства при тестировании.

В начале статьи общая информация про AppGallery и AppGallery Connect. Если вы всё это уже знаете, переходите сразу к сути к особенностям тестирования Android-платформы c поддержкой Huawei без Google-сервисов.

Что такое AppGallery, AppGallery Connect и почему Huawei без поддержки Google

Приложения под iOS- и Android-платформы можно встретить в официальных магазинах AppStore и Google Play. Туда мы идём в первую очередь, когда хотим установить новое мобильное приложение на телефон.

С 2018 года во всем мире (а в Китае ещё раньше) появился другой магазин мобильных приложений AppGallery, а с ним и AppGallery Connect.

AppGallery это менеджер пакетов и платформа распространения приложений, разработанная Huawei для операционной системы Android. AppGallery Connect универсальная платформа для поддержки всего жизненного цикла приложения: разработки, распространения, управления, тестирования и анализа.

За AppGallery последовал и выпуск устройств на базе Huawei: с 2019 года для нихв принципе отсутствует возможность работать с Google-сервисами, поэтому работа с Android стала сложнее. Нужно было оперативно включиться в работу и придумать, какизменить процессы тестирования платформы.

Казалось бы, зачем менять процессы и подстраиваться под ещё один магазин? Как много багов может добавиться к уже существующим? Стоит ли тратить время и деньги? У нас есть два аргумента.

Во-первых, при разработке приложения автор ориентируется не только на качество ПО, но и на качество продукта. Если продукт доступен бОльшей части потенциальных клиентов, это говорит об ответственном подходе к приложению. Нам кажется, что работать с AppGallery можно и нужно, ведь пользователь важное звено в разработке ПО.

Во-вторых, у AppGallery солидное количество пользователей. Магазин появился в 2018 году, к октябрю 2020 года приложение доступно в 170 странах мира, число уникальных пользователей 700 миллионов человек. Как говорит статистика, ежемесячная аудитория составляет 490 миллионов активных пользователей.

При этом для Huawei написали всего 96 000 приложений. Для сравнения в Play Store 2.9 миллиона приложений: это значит что более двух с половиной миллионов приложений отсутствуют в AppGallery.

В AppGallery нет, например, Instagram, Facebook и WhatsАpp. Их, конечно, можно скачать и установить вручную без ограничений: найти по отдельности в браузере или через какой-нибудь агрегатор. Также в сети появились сервисы, с помощью которых можно скачать самые популярные приложения. Но не каждый пользователь захочет выполнять дополнительные манипуляции.

Три вида Android-устройств

Как только кAndroidс Google-сервисами прибавились Huawei с сервисами HMS, некоторые устройства стали автоматически поддерживать оба вида сервисов (например, как Huawei до 2020 года выпуска).

Ниже представлено сравнение трёх типов устройств Android: с Google-cервисами, без них и с поддержкой обоих.

Устройства разные, особенности взаимодействия и тестирования тем более. Казалось бы, все понятно: нужно знать, как с ними работать и никаких проблем. Но ещё очень важно понимать, из чего составить этот рабочий процесс: как выбрать инструменты, чему обучить команду и к каким проблемам подойти с правильной стороны.

Возможности тестирования через AppGallery Connect

Проблемы начинаются при использовании разных библиотек на двух видах устройств Android. Мы в Surf пользуемся различными сервисами для работы с push-уведомлениями, аналитикой, dynamic или deep links, performance-мониторингом. Поэтому когда стали брать на вооружение работу с Huawei без Google-сервисов, волновались, насколько сильно изменится работа QA: получится ли тестировать push-уведомления и dynamic links в привычном ритме или придётся адаптироваться к абсолютно новому процессу? К счастью, сам процесс меняется несильно. Но есть вещи, о которых необходимо знать, прежде чем браться за работу с устройствами без поддержки Google.

Huawei без Google-сервисов не имеет доступа к инструментам, которые работают с Google, например, Firebase. Сервисы для тестирования и работы мобильного приложения нужно настраивать через AppGallery (к счастью, AppGallery Connect имеет базовые возможности из коробки) или другие доступные инструменты. А возможно, придумывать и свои решения.

Ниже приведены базовые инструменты AppGallery Connect, позволяющие без особого труда наладить основные процессы по работе с пуш-уведомлениями, аналитикой, удалённой настройкой и прочими инструментами для удобства тестирования и поддержки.

Аналитика

При тестировании аналитики полезно просматривать события в реальном времени это помогает обеспечить качество реализации отправки событий в мобильном приложении. Проверять аналитику в AppGallery Connect в реальном времени можно, например, с помощью Отладки приложения (аналогично DebugView в Firebase).

Отладка приложения (App Debugging) позволяет смотреть события, приходящие от МП, и их параметры в реальном времени. Чтобы подключить устройство к Отладке приложения в AppGallery Connect, нужно подключить устройство к компьютеру и в терминале выполнить команду:

adb shell setprop debug.huawei.hms.analytics.app <package_name>

Чтобы отключить устройство от отладки, выполнить команду:

adb shell setprop debug.huawei.hms.analytics.app .none.

Чтобы быстрее найти <package_name>, можно воспользоваться командой adb:

adb shell pm list packages

Общий сбор аналитики в AppGallery Connect тоже доступен. Он называется Просмотр в реальном времени (аналогично Events в Firebase)

Просмотр в реальном времени (Real-Time Overview) собирает все события с МП в одном месте. Можно строить графики по выбранным критериям, активировать фильтры и в целом проводить анализ по мобильному приложению.

Удалённая настройка и параметры

Удалённая настройка (Remote Configuration) позволяет управлять различными параметрами для приложения, и при необходимости обращаться к AppGallery Connect прямо из МП для работы с ними (аналогично RemoteConfig в Firebase).

Push-уведомления

При работе с push-уведомлениями Surf использует разные инструменты: Flocktory, Mindbox, Firebase и другие. Не все инструменты пока ещё могут работать с Android без поддержки Google, но базовая возможность подключить push-уведомления для Huawei есть: это их фирменная реализация через AppGallery Connect. Настройка пyшей происходит в PushKit.

Важно отметить, что пушер бэкэнда обязательно должен уметь взаимодействовать с AppGallery PushKit. Иначе push-уведомления придётся отправлять вручную из AppGallery Connect.

App Linking

App Linking сервис для работы с dynamic links. На основании deep links App Linking предоставляет пользователям доступ к нужному контенту непосредственно на веб-страницах и в мобильных приложениях: это повышает конверсию пользователей (аналогично Dynamic Links в Firebase).

На данный момент при работе с AppGallery Connect нет возможности создавать кастомные dynamic links: например, которые были бы одинаковыми и для обоих видов устройств Android (с поддержкой Google и без). Но c deep links всё в порядке.

Crash

Чтобы ловить незаметные с первого взгляда баги, стоит мониторить crash-аналитику даже на debug-версиях. Это необходимо, когда приложение потенциально разрабатывается на большую аудиторию и релиз близко не говоря уже о ситуации, когда МП уже доступно магазине и им пользуется много людей.

Нам было важно, чтобы такой инструмент был доступен и для Huawei без Google-сервисов. Crash плагин, позволяющий отслеживать и анализировать баги, краши и ошибки в приложении (аналогично Crashlytics в Firebase).

APM

Чтобы обеспечить качество клиент-серверного взаимодействия, удобно использовать инструмент, который бы помогал анализировать ответы от сервера и отрисовку экранов и элементов в приложении. В AppGallery Connect такой инструмент APM. Это сервис, который помогает искать и устранять проблемы производительности приложения и улучшать таким образом пользовательский интерфейс (аналогично Performance в Firebase).

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

Особенности тестирования Android-платформы c поддержкой Huawei без Google-сервисов

В первое время при работе с устройствами Huawei без Google-сервисов мы тратили много времени на анализ и выстраивание процессов. Сейчас всё наладилось.

В целом можно выделить следующие проблемы и решения.

Шаринг сборок

На проектах мы часто шарим сборки через Firebase, или напрямую скачиваем .apk из Jenkins, или собираем вручную из Android Studio. Проблем со скачиванием или ручной установкой .apk для Huawei без Google-сервисов нет. Проблем с App Tester приложением Firebase для шаринга сборок тоже нет. Использовать непосредственно приложение не получится, но пройти по invite из почты в браузер для скачивания сборки удастся.

Лайфхак: сохраняйте страницу из браузера на рабочий стол телефона и не знайте горя.

Устройства

Конечно, для тестирования необходимы устройства и эмуляторы без Google-сервисов.

• Если на проекте планируется адаптация под AppGallery, можно отправить заявку Huawei. Они пришлют девайсы для тестирования.Правда, финальное слово всегда за самим Huawei: отправка запроса ничего не гарантирует. Но опция приятная.

• Неплохой вариант использовать эмуляторы. Конечно, они не восполнят полную работу с устройством, но могут помочь в отдельных случаях.

  • Можно работать с эмуляторами через ферму устройств App Gallery.

  • Можно установить HMS Toolkit в Android Studio и работать с Huawei без Google-сервисов прямо из IDE.

На что обратить внимание

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

1. Push-уведомления. На Huawei без Google-сервисов не будут работать push-уведомления, реализованные на backend через Firebase (а такое встречается сейчас часто). Такие устройства имеют свой hms-токен, и для работы с ними нужна специальная реализация.

2. Dynamic links. Инструмент AppGallery Connect не поддерживает кастомный формат dynamic links, поэтому нельзя настроить унифицированную ссылку на оба вида конфигураций устройств Android. Решение: использовать deep links или другой инструмент по работе с ссылками, работающий без Google Services.

3. Библиотеки с Google-сервисами. Различия в реализации и потенциальное скопление багов в логике будут, если в проекте используются библиотеки с Google-сервисами. Для Huawei их придётся заменить на другие фреймворки или if-ответвления. Тогда понадобится более тщательно тестировать оба вида устройств.

• Google Pay. На Android без Google-сервисов можно столкнуться с окном Оплата недоступна, так как для нее нужен доступ к Google-сервисам, которые ваше устройство не поддерживает. Аналогичную ошибку можно встретить при запуске других приложений, не предназначенных для Huawei без Google.

• Google-карты. Работа с Google-картами может содержать проблемы с кластеризацией, поиском, отрисовкой текущего местоположения и так далее.

• Google-аккаунт. Авторизация через Google-аккаунт на Huawei без поддержки Google недоступна. Но реализация авторизации-регистрации через Huawei-аккаунт была бы кстати.

• Магазины. Если мобильное приложение может отправить пользователя в магазин (для оценки, например), то необходимо проверить, что Android без Google Services отправляет в App Gallery, а Android с поддержкой Google в Google Play. Если устройство поддерживает обе конфигурации, было бы здорово, если бы пользователь мог выбрать между магазинами.

4. Сервисы с поддержкой Google. Для Huawei без Google придётся найти аналоги или разработать их самостоятельно. Хорошо, что важные базовые инструменты, как упоминалось выше, доступны в AppGallery Connect из коробки.

Например, на Android-устройствах можно открывать ссылки из приложения тремя разными способами:

• WebView,

• CustomTabs (разработка Google),

• браузер.

Для Huawei без поддержки Google, по умолчанию доступны только два способа или дополнительная разработка вручную.

Android с Google и без: сколько времени понадобится на тестирование

Базовые активности QA:

• планирование,

• ревью ТЗ и дизайна,

• написание проверок,

• прогоны по фиче, итоговые, регрессионные,

• написание отчётности

Это пример активностей QA в среднем по больнице. Мы исключаем особенности компании и проектов и говорим немного в вакууме.

При работе с Huawei без Google-сервисов точно добавляется время к каждой из активностей:

• Ревью ТЗ и дизайна, написание проверок. Будут дополнительные кейсы, отражающие особенности работы с такими устройствами. Можно смело увеличивать оценку временных затрат на это в 1,41,6 раза. Здесь время уйдёт либо на обработку дополнительных сценариев в ТЗ и дизайне, либо на анализ и подтверждение, что никакой особенной реализации для Android без Google-сервисов нет.

• Прогоны. Во время прогонов (по фиче, итоговых, регрессионных) рекомендуется проводить тестирования как на Android с Google-сервисами, так и без. Особое внимание устройствам, где доступны оба вида сервисов. Здесь сокращение количества устройств может когда-нибудь неприятно выстрелить. Время может увеличиться в 1,82 раза и уйдёт на осуществление прогона на всех трёх видах устройств.

• Обратная связь. Под обратной связью мы в Surf подразумеваем просмотр маленьких задач (которые не требует прогона по фиче например, Смену статичного текста) и исправленных багов. При работе с обратной связью, а также при анализе и просмотре импакта от багов и прочих задач, снова не стоит забывать про тот же список устройств (без и с Google-сервисами, а также с двумя видами сервисов) для тестирования. Время увеличивается примерно в 1,3 раза снова для того, чтобы осуществить ретест или проверку задачи на этих видах устройств.

• Послерелизные активности. При релизе приложения в AppGallery необходимо продолжать мониторить работу МП как минимум по crash-сервису, чтобы поддерживать качество и исправлять ошибки вовремя. Если в проекте не используется один инструмент мониторинга обоих видов устройств, то времени на работу с двумя инструментами и анализом багов будет уходить больше. Пожалуй, тут лучше увеличить время в 2 раза.

• Тестируемые устройства. И, конечно, на время может повлиять количество выбранных устройств для тестирования (автоматизированного или ручного). Подходить к выбору устройств стоит ответственно, проанализировав множественные факторы проекта и аудитории.

При тестировании на Android с Google Services хочется покрыть наибольшее количество устройств: разные операционные системы, оболочки, разрешения экранов, внутренние особенности и возможности. Устройств становится ещё больше, когда добавляются девайсы Huawei с HMS-сервисами.

Таким образом, необходимо покрыть бОльшее количество устройств: не забывая про Android с Google-сервисами, Android без их поддержки, и Android с поддержкой HMS-сервисов помимо Google.

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

Время общего тестирования фичи увеличится:

• в 1,82 раза в случае разных инструментов для реализации фичи;

• в 1,31,5 раза в случае одного инструмента для реализации фичи (в том числе при отсутствии отличий на первый взгляд);

• в 1,41,6 раза в случае дополнительных требований и отличительной части реализации.

Таблица-сравнение по тестированию фичи для устройств с Google и без

Мы оценили фичи по пунктам, о которых говорили выше ревью, написание проверок, прогоны по фиче, обратная связь.

_{Значение Х время на тестирование Android с Google-сервисами. Оценка Y*X время на тестирование Android с двумя видами сервисов, где Y коэффициент увеличения времени на работу с Huawei с HMS-сервисами}

Все временные оценки исходя из нашего опыта. Приводим их для примерного понимания.

Что хотелось бы сказать в конце...

Мы в Surf поддерживаем устройства Huawei без Google-сервисов на некоторых проектах и довольны процессами. Конечно, поработать головой иногда приходится чуть дольше: разработчикам чтобы найти универсальное решение. QA чтобы найти максимальное количество дефектов, широко покрыть фичи проверками и обеспечить качественное тестирование. И на мой взгляд, оно того стоит.

Представляем свежий релиз Flutter 2.2, анонсированный на Google I/O. Да, оригинальная статья вышла ещё в мае, но мы считаем, что лучше поздно, чем никогда. Публикуем перевод статьи с комментариями Евгения Сатурова ex-Flutter TeamLead Surf, а ныне DevRel Surf.

Flutter 2.2 лучшая версия Flutter. С последними обновлениями разработчикам станет ещё проще монетизировать приложения через покупки, платежи и рекламу, а также подключить облачные сервисы и API, чтобы расширить функциональность приложений. Благодаря новым инструментам и языковым фичам разработчики смогут избежать целого класса ошибок, повысить производительность приложений и сделать их компактнее.

Основа Flutter 2

За основу Flutter 2.2 взят Flutter 2, который работает не только с мобильными устройствами, но и с вебом, ПК и встраиваемые системами. Он создан специально для мира, где нас окружают компьютеры: множество разных устройств и форм-факторов создают потребность в единообразии интерфейсов.

С помощью Flutter 2.2 все корпорации, стартапы, предприниматели смогут создавать решения высокого качества, способные по-максимуму раскрыть потенциал целевого рынка. Единственным ограничением станет креативность а не целевая платформа.

Flutter стал самым популярным фреймворком для кроссплатформенной разработки.

Рост Flutter отметили в недавнем исследовании мобильной разработки. Компания SlashData провела анализ и выпустила статью Mobile Developer Population Forecast 2021, согласно которой Flutter стал самым популярным фреймворком в кроссплатформенной разработке: его выбирают 45% разработчиков. Рост между Q1 2020 и Q1 2021 составил 47%. Интерес к Flutter продолжает расти: за последние30 дней одно из восьми приложений, загруженных в Play Store, написано на Flutter.

Комментарий Жени Сатурова

Это не удивляет нас в Surf. Нашей Flutter-компетенции уже больше двух лет. За это время мы стали свидетелями того, как мобильная индустрия в России и за её пределами совершила кульбит.

В начале 2019 года нам приходилось буквально защищать технологию перед потенциальными клиентами, отвечая на множество вопросов, реализуя множество PoC. Едва ли не под свою ответственность мы запускали рискованный, как всем казалось, эксперимент.

Сегодня клиенты приходят за Flutter целенаправленно и часто даже не рассматривают нативный подход. В наших кейсах можно найти несколько хороших примеров.

На I/O мы рассказали вам, что только в Play Store загружено более 200 тысяч приложений, написанных на Flutter. Эти приложения пишут очень серьёзные компании. Например:

• Tencent их мессенджером WeChat пользуется более 1,2 миллиарда пользователей iOS и Android.

• ByteDance создатели TikTok, которые уже написали 70 разных приложений на Flutter.

• Другие компании, в том числе BMW, SHEIN, Grab и DiDi.

Конечно, Flutter используют не только крупные корпорации. Некоторые новаторские приложения делают компании, названия которых вы, возможно, и не слышали раньше. Например:

• Wombo вирусное приложение с поющими селфи.

• Fastly приложение для интервального голодания.

• Kite красивое приложение для инвестиций и трейдинга.

Flutter 2.2

Основная цель релиза Flutter 2.2 улучшить процесс разработки, чтобы вы могли писать более надёжные и производительные приложения для клиентов.

Sound null safety теперь по умолчанию работает для новых проектов. Null safety защищает от ошибок типа null reference exception, так как даёт разработчикам возможность указать non-nullable типы в своём коде. А раз Dart абсолютно непротиворечив (sound), компилятор может не проверять на null во время выполнения. В результате производительность приложения повышается. Наша экосистема отреагировала быстро: около 5 000 пакетов уже обновлены и поддерживают null safety.

Комментарий Жени Сатурова

Жить в эпоху перемен всегда непросто, но весело. То же самое я могу сказать про переезд на Flutter 2. Для некоторых особенно масштабных наших проектов это стало настоящим испытанием. Процесс переезда продолжается до сих пор.

Хорошая новость заключается в том, что столь масштабных изменений во фреймворке и языке Dart в ближайшие годы не предвидится. Шутка ли к внедрению null safety в прод шли больше двух лет. Чтобы облегчить переезд коллегам из других компаний, мы оперативно обновили все наши пакеты, входящие в состав репозитория SurfGear.

Кроме того, в этом релизе есть множество возможностей повысить производительность:

• Для веб-приложений фоновое кэширование с помощью сервисных работников.

• Для приложений на Android поддержка отсроченного запуска загружаемых компонентов.

• Для iOS мы разработали инструменты предварительной компиляции шейдеров.

Благодаря им удастся устранить или сократить лаги при первом запуске.

Комментарий Жени Сатурова

Многие ждали, что возможность прекомпиляции шейдеров для Metal поступит в stable уже в этом релизе, но увы. В утешение могу посоветовать попробовать собрать проект из dev-канала. Обещаю, вы непременно заметите разницу в FPS на iOS в анимациях и переходах.

Ещё мы добавили поддержку сторонних инструментов и расширений и несколько фич в DevTools, чтобы вам стало понятнее, как распределяется память в вашем приложении.

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

Мы не только совершенствуем сам Flutter. Вместе с другими командами Google мы работаем над интеграцией Flutter в более масштабный стек технологий компании. В частности мы продолжаем разработку надёжных сервисов, с помощью которых разработчики смогут с умом монетизировать приложения. В этом релизе мы дополнили новый ads SDK: добавили в него null safety и поддержку адаптивных баннеров. Ещё мы добавили новый плагин для оплаты, который написали в сотрудничестве с командой Google Pay. С его помощью можно провести оплату за материальный товар как на iOS, так и на Android. Также мы обновили свой плагин для оплаты из приложения и соответствующую статью на codelab.

Комментарий Жени Сатурова

Радует, что экосистема вокруг Flutter развивается в правильном направлении. Не так много осталось незакрытых официальными плагинами вопросов. Возможность процессинга платежей через Google Pay существовала уже давно, но официальная реализация это гарантия качества решения. В нашем последнем релизе The Hole мы внедрили in_app_purchase ещё до выхода пакета в стабильный релиз. Надеемся, что теперь работать с ним станет ещё приятнее.

Так как Dart секретный ингредиент в составе Flutter, в этом релизе мы обновили и его. В Dart 2.13 мы расширили возможность интеграции нативного кода, добавив в FFI поддержку массивов и упакованных структур. В том числе появилась поддержка псевдонимов типов, с которыми код станет читабельнее, а некоторые сценарии рефакторинга получится осуществить менее болезненно. Мы продолжаем добавлять новые возможности интеграции с более широкой экосистемой через GitHub Action для Dart и Docker Official Image. Последний проходит тщательную проверку и оптимально подходит для внедрения бизнес-логики в облачную среду.

Не просто проект Google

Несмотря на то, что Google остаётся основным контрибьютором в проекты Flutter, нас радует, что экосистема Flutter развивается и за пределами компании.

За последние месяцы больше всего роста было связано с тем, что всё больше платформ и операционных систем стали доступны для Flutter. На Flutter Engage мы объявили, что Toyota собирается использовать Flutter в следующем поколении информационно-развлекательных систем своих автомобилей. А месяц назад Canonical отправили в свободное плаванье первый релиз Ubuntu с поддержкой Flutter, в том числе интеграцией со Snap и поддержкой Wayland.

Рост экосистемы отлично демонстрируют два наших новых партнёра. Samsung портирует Flutter на Tizen и оставляет репозиторий опенсорсным, чтобы остальные тоже могли в него контрибьютить. А Sony руководит разработкой решения для Linux на встраиваемых системах.

Дизайнеры тоже выигрывают от того, что проект опенсорсный: так, Adobe анонсировали, что обновили плагин XD to Flutter. Adobe XD даёт дизайнерам отличную возможность экспериментировать и копировать свои предыдущие работы. С улучшенной поддержкой Flutter дизайнеры и разработчики могут вместе работать над материалами а значит, ещё быстрее выводить классные идеи в продакшн.

И наконец, с нами продолжает сотрудничать Microsoft. Команда Surface разрабатывает с помощью Flutter решения для складных устройств. А на этой неделе в альфа канале появится поддержка Flutter для приложений на UWP, разработанных для Windows 10. Мы очень рады, что всё больше мобильных, десктопных, веб- и других приложений используют способность Flutter подстраиваться под разные платформы.

Комментарий Жени Сатурова

Дух open-source разработки захватывает кроссконтинентальные корпорации. Очень радует тенденция открытости и поддержки, даже когда речь идёт о взаимодействиях таких монстров, как Samsung, Google и Microsoft. Пока разработки ведутся в независимых репозиториях и никакого официального отношения к Flutter не имеют, но существует надежда, что скоро список поддерживаемых платформ расширится в полтора раза.

Создаём отличный пользовательский опыт

Мы в первую очередь стремимся помочь разработчикам создать отличный пользовательский опыт. Нам придаёт сил мысль, что разработка приложений может стать лучше: что мы можем расширить возможности, убрав традиционные препятствия между вами и аудиторией.

Нам нравится смотреть, какое применение вы находите для Flutter. Один из примеров проект от US Veterans Administration. В видео о том, как приложение на Flutter помогаетсолдатам с реабилитацией от посттравматического стрессового расстройства.

Мы проведём множество разных воркшопов, презентаций, посвящённых Flutter и ответим на возникшие у вас вопросы на Google I/O. А пока не забудьте попробовать нашу веб-фотобудку, написанную во Flutter: в ней можно сделать селфи с нашим талисманом Dash и её друзьями!

Вот уже третий год мы разрабатываем на Flutter. Сделали на нём кроссплатформенные приложения для Росбанка, сети аптек Ригла, ресторанов KFC, в разработке ещё много проектов. Буквально на наших глазах Flutter из нишевой технологии стал мощным игроком, который теснит не только React Native, но и нативную разработку.

Бизнес поверил во Flutter. Всё больше компаний хотят приложения на этой технологии, потому что она позволяет существенно экономить при сохранении качества продукта.

Спрос на Flutter-разработчиков очень быстро растёт. Не хватает даже джунов, а у миддлов и сеньоров услуги стоят очень дорого. Толковые ребята нужны и нам.

Команда flutter в Surf собрала серьёзную базу знаний:

• опыт реальных проектов;

• наши статьи о Flutter, его особенностях и проектах на нем;

• методология обучения стажёров;

• open source библиотеки и наработки, которые мы выкладываем в публичном репозитории на Github.

И эти знания должны работать и приносить пользу не только профессиональному сообществу, но и тем, кто только хочет освоить технологию. Так появилась идея создать свой курс по Flutter.

Рынку нужны практики, поэтому основная задача курса это помочь студентам получить реальные знания, познакомиться с наработанными best practice, быстро войти в тему и перейти к реальным задачам.

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

Подробно о курсе можно почитать в статье.

Первый поток стартовал 3 месяца назад. За это время наши студенты не только прокачали свои практические навыки так, что скоро смогут стать Flutter-разработчиками на реальных проектах, но и здорово помогли в развитии курса. Их обратная связь, комментарии и советы стали бустом, который вывел курс на новый уровень.

И за это, ребята, большое вам спасибо!

5 марта стартует новый поток курса, и обновленная программа поможет будущим Flutter-разработчикам еще эффективней отработать практические навыки и освоить технологию.

Но давайте обо всем по порядку.

Можно ли изучить новую технологию самому, или почему практика важна?

Предположим, есть условный Егор. Он разработчик. Видит будущее за мобильными приложениями и хочет освоить новый стек. Ага, Flutter удобный и современный фреймворк для разработки приложений как под IOs, так и под Android, надо попробовать, - думает Егор.

Егор парень въедливый и неглупый, и скорей всего начнет он с документации, тем более, что она по Flutter очень хорошая. А ещё есть бесплатные курсы на разных образовательных платформах, которые тоже помогут составить представление о технологии.

И зачем тогда Егору платный курс? Тут все давно сказано за нас. Вспомним правило 10 000 часов, которое сформулировал психолог Андерс Эриксон чтобы добиться высокого уровня мастерства в своём деле, нужно посвятить практике не менее 10 000 часов. А ещё есть модель 70:20:10 Чарльза Дженнингса, в которой говорится о 70% практики, 20% - работы с наставником и 10% теории, которые необходимы для успешного освоения материала.

Документация и бесплатные курсы дадут Егору те самые 10%. Но одной теории мало для освоения технологии. Рынку нужны опытные разработчики, а не теоретики. И тут перед Егором встает резонный вопрос, как и где получить этот опыт. Отработать на практике под руководством ментора один из наиболее продуктивных вариантов. Именно такой формат мы предлагаем в своем курсе по Flutter.

Егор получит знания из первых рук. И это будут не просто лекции, а экспертиза и лучшие практики разработки из реальных проектов Surf на Flutter, которые дают опытные наставники. Обратная связь, код-ревью, рекомендации по конкретному проекту, как сделать лучше и исправить ошибку этого Егор не найдёт в документации. Но это точно пригодится ему в дальнейших проектах.

Вот что пишут студенты первого потока:

Основная ценность курса взаимодействие с наставниками. Тут дело не в сухой информации, которая и так есть в прекрасной документации flutter.

Этот курс отличная возможность глубоко разобраться в теме и понять, как устроена профессиональная разработка на flutter.

Домашние задания сдаются пулл-реквестами. Проверяют их по-взрослому от соответствия макету в figma до стиля кода. Смотрят код внимательно, замечают разные сомнительные архитектурные решения, проблемы с производительностью, подсказывают, как сделать лучше. Причем проверяют разные специалисты из команды surf.

Кирилл

Большой упор на практику, код ревью от тимлидов surf, и это очень круто. В каждой домашке отписывают более правильный код-стайл, лучшие подходы, отучают от го@нокода и всё в таком духе. Действительно стремятся сделать из вас хорошего разработчика!

Влас

Программа и для джуна, и для тимлида а так бывает?

На первый поток курса пришли ребята с очень разным уровнем подготовки в сфере разработки. Это были:

• начинающие разработчики;

• тимлиды;

• senior-разработчики крупных команд;

• архитектор Frontend-разработки крупного банка.

Потребности у них тоже были разные. Кто-то хотел научиться Flutter-разработке для поиска работы по этой специальности. Кому-то он был нужен для имеющегося проекта. А кто-то просто стремится держать руку на пульсе технологий мобильной разработки.

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

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

А еще студенты отметили, что гораздо удобней, когда загрузка на курсе равномерная, практические задания примерно одного объема и уровня сложности. Поэтому по обратной связи от ребят за 3 месяца мы переработали более 20% курса. Простые задания дополнили, а слишком сложные переформулировали или разделили на части.

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

Второй механизм это много разных мастер-классов с элементами практики по темам, которые были актуальны ребятам. После первого мастер-класса по Figma и Swagger студенты предложили переделать программу мастер-классов так, чтобы каждый смог подобрать темы, которые актуальны для его уровня подготовки.

В итоге, больше половины тем мы переработали. И теперь их список выглядит так:

• Архитектура мобильных приложений в деталях (устройство под капотом, границы применимости различных моделей архитектуры)

• Тестирование Flutter приложений (unit-тестирование, автотесты)

• Взаимодействие с нативным приложением

• Обзор возможностей Flutter Web (чем отличается от нативных приложений, JS/HTML под капотом, безопасность веб-приложений, какие есть возможности и производительность, как работать с поисковой оптимизацией и индексацией, как подготовить к использованию в e-commerce)

• Основы языка Kotlin

• Основы языка Swift

• Обзор возможностей Navigator 2.0

• Обзор возможностей Flutter Desktop

• Взаимодействие с платформой (Advanced)

• DevTools Profiling (Advanced)

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

Спикеры мастер-классов это опытные практики, эксперты в области разработки. Например, одним из выступающих стал Михаил Зотьев, который рассказал про внутреннее устройство и архитектурные особенности Flutter. А на мастер-классе по Flutter Web студенты разбирали и задавали вопросы про тонкости и ограничения применения Flutter в вебе, которые, в принципе, известны мало кому в индустрии.

Главный вопрос

Обычно со стороны студентов он звучит так а с трудоустройством поможете?

Есть 2 возможных направления, в которых курс будет вам полезен.

Наполните портфолио

На рынке труда очень мало соискателей с интересными, а тем более масштабными проектами в портфолио. В основном это небольшие проекты, из которых сложно понять, что знает и умеет кандидат. Мы убедились в этом, когда за полгода изучили более 300 откликов на вакансии и провели более 60 собеседований.

Чтобы выделиться среди других кандидатов, показать работодателю, что вы умеете и знаете, нужен проект, максимально близкий к реальному. Поэтому выпускной проект курса - это на 100% практический кейс, вы сможете добавить его в портфолио и наглядно продемонстрировать опыт для работодателя.

Вы создадите мобильное приложение со списком интересных мест и достопримечательностей для путешествий по миру. Кейс максимально близок к реальным условиям работы в коммерческом проекте. Приложение состоит из 8 экранов. Всё по-взрослому описание требований от заказчика, дизайн-макет в Figma, серверная документация в Swagger.

Разработку приложения вы ведёте в собственном репозитории. По мере продвижения по курсу проводите итерационный рефакторинг кода. Преподаватель делает ревью кода, контролирует, как вы используете EffectiveDart и best practice.

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

Что особенно понравилось и мне кажется очень важным, что идёт разработка приложения с нуля и последовательно по шагам. Особенно прикольно, когда что-то сделаешь, а потом на следующем задании надо всё переделать, потому что узнал новое. То есть это никак не разработка в стиле Лего по шагам к заданной цели. Тут по многу раз всё переделать можно. Как на реальном проекте, когда опыта ещё не набрался.

Виктор

Второе направление карьерные консультации

Вы составите резюме под руководством опытного HR, который специализируется на поиске и найме разработчиков, знает, на что обращают внимание работодатели. Получите рекомендации по поиску работы и консультацию от HR.

Лучшие студенты курса могут пойти на оплачиваемую стажировку в Surf. При е успешном прохождении вы сможете стать частью Surf Flutter team.

На языке цифр

По данным, собранным Кейт Джордан, исследовательницей в сфере образования и технологий, в среднем массовые открытые онлайн-курсы (MOOC) завершают около 15% поступивших.

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

Завершим отзывом студентки:

Про флаттер я узнала случайно, просматривая статьи Хабра и vc. Заинтересовалась, начала искать другие материалы и видео. Данная технология мне показалась очень привлекательной, поэтому следующим шагом была покупка курсов по Flutter и Dart на udemy.

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

На мой взгляд, курс рассчитан не для новичков в программировании. Хорошо, что у меня есть небольшой бэкграунд + прошла предварительно купленные курсы. Отличием курса Surf от других является то, что у тебя постоянно работает мозг, как решить задачу, и никто, кроме тебя, её не решит и не покажут, как. Могут дать наводку, в какую сторону смотреть.

Дан макет приложения в Figma. Дан видеоурок со стандартной темой. Никакого секрета в уроке нет подобные материалы есть в документации и их полно в интернете. Но после каждого урока тебе надо сделать кусочек приложения, и практически всегда того, что показано в уроке, мало, чтобы решить задачу (а что-то мы ещё не проходили, и оно далеко в закрытых разделах). Приходится копаться в документации и других источниках информации. Пока не сделаешь, дальше двигаться не сможешь.

Курс для тех, кто не ленится и не опускает руки, когда что-то не получается. А опытные наставники поправят и направят в нужном направлении.

Татьяна

5 марта стартует новый поток курса по Flutter от команды Surf. Если хотите присоединиться и освоить разработку на Flutter на практике.

Регистрируйтесь на сайте

App Store самая строгая площадка для размещения приложений. Ревью проходит дольше и строже, чем у Google Play и Huawei App Gallery. В 2020 году AppStore отклонил миллион приложений, которые публиковались впервые, и миллион апдейтов.

С одной стороны, такая строгая политика это хорошо: пользователям легче выбрать приложение и быть уверенным, что оно безопасно. Однако для разработчиков это настоящая головная боль.

Например, получить отказ в публикации можно, если в приложении есть контент, защищённый авторскими правами, причём даже если он на скриншотах в магазине Apple. А если приложение связанно со здоровьем, придётся предоставить описание алгоритмов и уровень точности снимаемых приложением показаний.

Мы составили чек-лист очевидных и не очень очевидных причин, по которым AppStore отклоняет приложения. Сам чек-лист в гугл-доке. В статье раскроем подробнее каждый пункт.

Нарушения политики конфиденциальности и пользовательских данных

Нет ссылки на пользовательское соглашение. Ссылка должна быть и внутри приложения, и на странице в магазине. Если ссылка ведёт на сайт компании, соглашение должно быть размещено там и ссылка должна работать.

Данные передаются третьим лицам. Приложения, которые управляют другими мобильными устройствами, не должны продавать или передавать данные с управляемых устройств третьим лицам.Это также касается приложений, которые собирают данные в рамках медицинских исследований или данные о здоровье. Они не должны передавать их третьим лицам и использовать для аналитики и настройки контекстной рекламы.

Нарушение функциональных требований

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

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

У нас в Surf, например, однажды отклонили приложение, потому что в нём была подключена библиотека для Apple Pay, но она нигде не использовалась.

UI, не соответствующий Human Interface Guideline. Сложное для использования приложение, имеющее нелогичное поведение и расположение элементов, отклонят.

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

Пользователь должен понимать, зачем предоставлять доступ, и самостоятельно решать, разрешать его или нет. Если пользователь откажется предоставить доступ к функциям или данным, приложение должно продолжать работать. Но нужно объяснить пользователю, что функциональность в таком случае может быть ограничена.

Несанкционированный доступ к данным пользователя. В 2021 году вступило в силу изменение политики Apple в отношении рекламы. Теперь, чтобы собирать данные для рекламных кампаний, нужно запросить разрешение у пользователя на доступ к отслеживанию активности.

Изменение поведения системных функций, кнопок или жестов. Нельзя изменять поведение кнопок громкости или жестов свайпа панели управления.

Для распознавания по FaceID используются сторонние технологии. Идентификация пользователя по FaceID должна происходить только с помощью библиотеки LocalAuthentication.

Нет входа по AppleID, если есть возможность входа через соцсети. Это обязательно для iOS 13 и новее.

Нарушения в оформлении приложения

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

Описание приложения неполное и вводит в заблуждение. Приложение не должно содержать информации, которая может ввести пользователей в заблуждение: например, описание несуществующих функций или мимикрии под известное приложение. На скриншотах в магазине не должно быть функций, которые не реализованы в приложении.

Есть слова Beta, Demo или Debug в названии приложения. Такие приложения запрещены к публикации в магазине App Store. Для бета-версий есть Test Flight.

Нет описания новой функциональности у обновлённого приложения. Если в приложении появилась новая функциональность, необходимо описать её в поле в App Store Connect. Без чёткого описания приложение ревью не пройдёт.

Скриншоты приложения, иконка и другой контент на странице магазина не подходят для аудитории 4+. И не важно, что приложение может быть не предназначено для такого возраста: аудитория App Store дети от четырёх лет.

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

Не стоит указывать в описании или на скриншотах, что продукт имеет отношение к Apple либо компания отвечает за качество, если это не так. Если приложение станет выбором редакции, Apple автоматически установит на нём соответствующую иконку.

Файл с расширением .ipa превышает размер 50 мб в момент публикации.

Нет демо-пользователя для ревью, если приложение требует обязательной авторизации.

Не указаны правила участия и выигрыша, если в приложении есть розыгрыши, рулетки или казино. Следует явно написать, что Apple не имеет никакого отношения к этим конкурсам и розыгрышам.

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

Приложение опубликовано от имени разработчика. Приложения, которые предоставляют банковские услуги, услуги относящиеся к здравоохранению, авиа- и жд-перевозкам, нужно публиковать от имени компании. Apple не позволит опубликовать такое приложение с собственного аккаунта разработчика.

В период пандемии этот пункт стал особенно важен: Apple строго следит за распространением информации, связанной с COVID-19.

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

Контент оскорбляет людей разных рас, вероисповеданий, сексуальной ориентации, национальности.

Приложение поощряет незаконное использование оружия или позволяет его купить.

Есть откровенно сексуальный или порнографический контент.

Приложение разрешает анонимную отправку смс/ммс, анонимные звонки, розыгрыши.

Поощряется употребление табака, электронных сигарет, запрещённых веществ или чрезмерное употребление алкоголя. Особенно это принципиально, если приложение предназначено для несовершеннолетних.

У карты лояльности в wallet нет контактной информации о компании. Её нужно добавить, чтобы пользователи могли связаться с компанией, если захотят.

Покупки в приложении

Цифровой контент продаётся не через in-app purchase.К цифровому контенту относятся подписки, музыка в приложении, видео, расширенный доступ к функциям.

Не указана вероятность, с которой пользователь получит тот или иной предмет из лутбокса. Вероятность нужно обозначить перед покупкой этого игрового элемента.

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

Приложение не предоставляет пользователю всю необходимую информацию о покупке до момента продажи. Это важно, если приложение использует Apple Pay. Также недопустима кастомизация окна оплаты.

Категория Kids

Kids в App Store отдельный вид приложений. К ним Apple относится максимально строго. Категория Kids делится на три подкатегории: до 5 лет, 68 лет, 911 лет.

Есть внешние ссылки, покупки и другие отвлекающие факторы. Такие элементы требуют дополнительной защиты и отделения от функциональности, которую используют дети. Исключение составляют опции родительского контроля.

Не соблюдены законы, касающиеся защиты конфиденциальности детей в интернете. Запрещено отправлять личную информацию и данные об устройстве третьим лицам.

Есть сторонняя аналитика и реклама. Имеется в виду любая система аналитики, передающая информацию на другой сервер. Разрешены лишь те службы, которые не передают никакую идентифицирующую информацию о детях: местоположение, имя, дату рождения, адрес имейла.

Составили гугл-док с чек-листом требований для ревью App Store.

А по каким причинам App Store отклонял ваши приложения? Расскажите в комментариях.