Hola, Amigos!

Мы у себя раскатали крутую систему мотивации для разработчиков. Просто, понятно, а главное — схема рабочая, и, конечно, хотим этим поделиться. Поэтому 7 октября в Технопарке на конфереции Битва за IT выступит teamlead Amiga Руслан Ревель.

Он расскажет:
- как мотивитровать команду разработчиков с помощью метода one-to-one;
- поделится секретами работы с внешней командой;
- на примерах из практики подскажет, как привлечь разработчиков в off-top общение;
- про трекинг и нагрузку тоже не забыли.

Доклад Руслана в 16:30, готовьте вопросы, будем вас ждать! Ссылка на участие в конференции: https://it-forums.ru/.

Создали мобильное приложение на Flutter, которое умеет распозновать товары из видеопотока

Вместе с AGIMA AI мы разработали мобильное приложение, в котором вы можете купить любой товар из фильма или сериала.

Все очень просто:

— Заходите в приложение и открываете камеру.
— Наводите смартфон на экран телевизора, монитора или другого устройства.
— Получаете название фильма, имена героев, а главное список товаров и ссылку, где купить.

Мы интегрировали ML-модель, которая за доли секунд распознает видео и предлагает товары в нем присутствующие. В кейсе рассказали и про техническую часть проекта.

Пишите вопросы в комментарии, мы готовы на них ответить.

Flutter vs native Android 📱

Привет, меня зовут Антон Мартышков, я Flutter-разработчик в Amiga, сейчас хочу рассказать, чем же меня как нативного разработчика заинтересовал Flutter.

✅Декларативный ui

В нативном Android весь пользовательский интерфейс создается в отдельных файлах – xml. Оперируя тегами, мы строим иерархию view, наполняем контентом или же будем делать это в процессе выполнения программы. Затем разметку нужно подключить в Activity, fragment и др., если мы планируем менять данные в ходе выполнения программы или обрабатывать нажатие на кнопку пользователем. Конечно, можно сказать, что в Android тоже появился декларативный стиль – Jetpack Compose. Но, когда я лично его опробовал, то понял, что делать это на Flutter намного удобнее.

✅Hot reload

Hot reload – это когда вносишь изменения в коде, и можно тут же увидеть результат изменений на экране. Очень крутая и полезная вещь для разработчика. Достигается это благодаря JIT (Just in time) компиляции. В то время как в Android все время приходится перезапускать приложение и снова «доходить» до тестируемого места.

✅Гибкость в реализации элементов

Боль Android-разработчика – это когда заказчик хочет, чтобы Android выглядел также как IOS. Во Flutter можно использовать элементы пользовательского интерфейса как Material, так и Cupertino на любой платформе. А если чего-то не хватает, то всегда можно сделать руками.

✅Адаптивный ui

У разных устройств размеры экрана и плотность пикселей отличается. Android их разделяет на 6 dimensions, базовым считается mdpi, это когда 1px = 1dp. Зачастую разработчику приходится тратить много сил на адаптивы, поскольку из mdpi нужно будет создать dimensions еще для: ldpi, hdpi, xhdpi, xxhdpi, xxxhdpi.

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

✅Множество поддерживаемых ОС

Создавая Flutter-приложение мы можем запустить его на Android, iOS, windows, linux, macOs, web. Это дает возможность для реализации pet-проектов, а еще упрощает рутину по типу тайм-трекинга задач в доске (мы используем Jira).

✅Поддержка
В Android api много легаси и костылей. Мне сразу вспоминается, как до появления Camera2 приходилось работать с камерой. И почему-то до сих пор не придумали Pub.dev.

Над Flutter же, как мне кажется, Google старается больше, он не мог случайно получиться таким удобным и продуманным😉.

Поделитесь в комментариях, какие плюсы и минусы нашли у Flutter.

#flutter #native

Мнение разработчиков: лайфхаки для дизайнеров, ч1.🖥

Hola, Amigos! На связи Flutter-разработчики Amiga: Саша Чаплыгин и Антон Мартышков.

Мы поделимся «болями» из личного опыта при работе с дизайнерами. Обозначим общие ошибки и дадим рекомендации, как при дизайне для Flutter не переделывать бизнес-логику и дизайн-системы по несколько раз. Поехали!

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

Кейс из практики: мы делаем проект, на главной странице размещаются нижний bottom navigation bar с активными окнами: главная, запись, приемы, чат. Дизайнер решил в этот момент добавить кнопку выхода на главную страницу как в iOS на всех вкладках. Это дублирует функционал bottom navigation bar.

Совет: не смешивайте User experience элементы iOS и Android, которые отвечают за один и тот же функционал, сразу. Вместо этого проанализируйте, не дублирует ли дизайн возможности Flutter.

Привычная работа с iOS и Android может выйти боком. Flutter подходит под все операционные системы, а их больше 10. Часто дизайнеры автоматически подстраивают макеты под 1 платформу, еще реже под 2. Но тут нужно поменять сам подход.

Кейс из практики: дизайнер создал кнопки навигации, которые красиво и гармонично смотрелись на iOS. Но при тестировании на Huawei эти же кнопки занимали пол экрана.

Совет: абстрагируйтесь от привычных операционок iOS и Android. Подумайте, как приложение будет выглядеть на Windows, Web и других.

Когда создается кроссплатформенное приложение, то видно заимствованные элементы. Когда ты пользуешься Android и видишь в приложении виджет iOS, то сразу становится понятно – это Flutter.

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

В следующем посте поделимся еще 3 лайфхаками, не переключайтесь!

Hola, Amigos!

Мы разработали мобильное приложение на Flutter с интеграцией программы лояльности PRO.Expert

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

Что мы сделали:

— разработали приложение с нуля;
— сократили время заполнения данных с 5 минут до 30 секунд;
— создали упрощенный функционал регистрации работы;
— внедрили офлайн-регистрацию;
— унифицировали сбор данных и соединили их в единую систему.

Задавайте вопросы, мы обязательно ответим на них.

Кейс: что делать с большим APK-файлом?⚙️

Hola, Amigos! На связи Антон Мартышков, Flutter-разработчик Amiga. Сегодня на реальном примере проекта расскажу, как сократить вес APK-файла за 10 минут работы.

Одна из важных метрик Android-приложения наряду со скоростью запуска — вес установочного файла. Большой APK-файл долго скачивается на устройствах с небольшой объемом внутренней памяти, из-за этого могут быть проблемы с установкой. Это повлияет на конверсию и удовлетворенность пользователя

Пример из практики: когда я начал работать над проектом, установочный файл весил примерно 126 Мб. Проведя исследование, я заметил, что мы используем общую ML-библиотеку от Google «google_ml_kit», хотя большая часть функционала не была нужна. Увидев, что Google раздробил большую библиотеку на маленькие, я принялся их заменять. Убедился, что библиотека работает также, а функционал приложения не изменился, провел замеры. По итогу установочный файл уменьшился примерно на 46 Мб.

Очень здорово, подумал я, но все равно многовато. Продолжил поиски и наткнулся на большой gif-файл, 18,8Мб, длиной в 6 секунд. И тут же сжал его без потерь до 6Мб.
Показал небольшую оптимизацию тимлиду, получил одобрение на MR в релизную ветку.

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

Что делать с большим APK-файлом?
— Проведите исследование, действительно ли вы используете подходящую библиотеку.
— Тестируйте, не изменился ли функционал приложения после изменений.
— Все, что можно оптимизировать – оптимизируйте.
— Не забудьте про согласование с тимлидом, это важно.

Мнение разработчиков: послание для бэка, ч1.🔙

Hola, Amigos! С вами Саша Чаплыгин, Flutter-dev Amiga. Сегодня поделюсь примерами из практики в работе с back-end.

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

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

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

Кейс из практики: бэк заказчика отдавал разные форматы даты и времени – timestamp и ISO 8601. В итоге сделали обработку и того и другого формата сразу.

Послание бэкендщикам от мобильщиков:
1. Делайте поля объекта такими, какими они должны быть. К примеру, из того что я встречал:
• Присылали булево значение строкой. “false” вместо false;
• Если значение поля всегда число – делайте это поле числом, а не строкой.

2. Тестируйте API самостоятельно или же подключите автотестирование. Мобильщики не должны проверять его.

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

3. Всегда нужно чтобы API придерживалось схеме «ключ» – «значение».

Пример:
Плохая реализация поля fullName
{
“id”: “124314dfsdffd”,
“fullName” : [“John”, “Jameson”]
}

Правильная реализация
{
“id”: “124314dfsdffd”,
“fullName” : {“name”: “John”, “surname” : “Jameson”}

Hola, Amigos!

Как начать разрабатывать на Flutter и найти работу? Как быстро повышать скиллы и расти разработке? Саша Чаплыгин, Flutter-dev Amiga, рассказал о том, как стать разработчиком на Flutter.

В этой статье Саша поделился:
— своим опытом поиска работы;
— материалами для изучения Flutter;
— личным опытом взлетов и факапов;
— чек-листом по устранению ошибок новичков.

Почитать статью можно тут. Если есть вопросы — пишите, Саша обязательно на все ответит.

Мнение разработчиков: послание для бэка, ч.2.🔙

Hola, Amigos! На связи Антон Мартышков, Flutter-dev Amiga. Здесь Саша рассказал свой опыт в совместной работе с Backend-разработчиками. Сегодня я продолжу эту тему и дам несколько рекомендаций для бэка.

1. Документируйте свое API. Невозможно качественно подключить клиентскую часть, когда не знаешь, что нужно передать серверу, и что он вернет. Эту документацию нужно поддерживать в актуальном состоянии чаще, чем любую другую. Ведь от актуальности API зависит качество разработки продукта.

2. Изучайте дизайн и ТЗ. Не нужно слать лишние данные, а при изучении дизайна, поймете какие данные нам нужны для отображения пользователю.

3. Не переносите функционал, который должен делать back на front-часть.

Пример из практики: был у меня случай, когда backend-разработчик не хотел делать оплату по карте на своей стороне. Он всячески убеждал руководство о необходимости делать это на Android и iOS. Но именно backend отвечает за этот функционал.

4. Следите за чистотой код и рефакторите его. Не нужно в разных запросах отправлять похожие сущности (img, image, img_url и тд).

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

Задавайте вопросы, если они есть, с радостью отвечу и подискутируем!

Советы Junior-разработчикам🦾

Hola, Amigos! С вами Flutter-разрабы Amiga – Антон Мартышков и Саша Чаплыгин. Вас уже 200+, и это очень круто! Спасибо, что читаете и доверяете нам.

Большая часть подписчиков пришли после статьи Саши о том, как стать Flutter-разработчиком. Поэтому мы решили собрать 9 советов для джунов, которые помогут не совершать те же ошибки, что в свое время делали мы. Поехали!

1. Cмотрите widget of the week от команды Flutter. Возможно, там вы вспомните о необходимом виджете, который поможет решить задачу быстро и точно.

2. Изучайте, как Flutter работает «под капотом». То есть, углубляйтесь в то, как все работает во Flutter. Например, как работает сборщик мусора, как строится дерево виджетов, какие есть возможности в общении с нативом и т.д.

3. Изучайте Dart и его возможности. Читайте техническую документацию Flutter и Dart.

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

5. Выбирая библиотеку, посмотрите, нет ли аналогов. Изучите и сравните, какой плагин в каком случае лучше использовать.

6. Следите за чистотой кода, учитесь писать чистый код. Изучайте паттерны и применяйте их на практике.

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

8. Всегда аккуратно относитесь к null-safety. Проверяйте, пришла ли переменная null, или же подставляйте дефолтное значение с помощью "??"

9. Помните, что объем кода не показывает ваше знание и профпригодность. Очень часто 1 строка чистого и правильного кода может заменить 10-ки плохо написанных строк.

История кросплатформы, ч.1.⏳

Hola, Amigos!

С вами Flutter-разработчик Amiga Антон Мартышков. Нередко можем услышать разные мнения о Flutter или React Native. Но не многие знаю, что попытки создать успешный кроссплатформенный фреймворк начались незадолго до появления Android.

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

Первый кроссплатформенный фреймворк — это PWA (Progressive Web Application). Веб-технология, которая визуально и функционально трансформирует сайт в мобильное приложение. Технология PWA была создана корпорацией Microsoft в 2000 году. На текущий момент все еще используется, но не стала популярным решением.

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

Изначально разрабатывался как кроссплатформа для десктопа фреймворк QT. Его основной язык C++. Для Android и iOS это не чужой язык, поэтому создатели решили захватить еще и мобильные платформы. При этом пользователь ощущал «ненативность» приложения, а писать UI на C++ можно только представить, как увлекательно (нет). К тому же это платный фреймворк, у которого есть бесплатная версия, но на ней многого не напишешь + и скудная IDE. В итоге решение не умерло, но используется очень редко.

Еще одна попытка сделать кроссплатформу от Microsoft, в этот раз на C# — это Xamarin. Без проблем переносится бизнес-логика, но вот сложный UI может быть сопоставим с разработкой 2-3 нативных решений. В итоге Xamarin все еще живет, но масштабной популярности не обрел.

Во втором посте расскажу о React.Native и Flutter подробнее, ведь они следующие по разработке кроссплаторфменных фреймворков. Есть вопросы? Задавайте!