Привет, Хабр! Меня зовут Сергей, я занимаюсь мобильной разработкой 13 лет и недавно стал руководителем разработки мобильного приложения «Пункты выдачи заказов» в Ozon. Невольно став сместителем существующего строя в проекте (фреймворки, технологии, подход), я стал часто слышать вопрос: «Почему вы отказались от Flutter?».

Слышал я этот вопрос прежде всего от разработчиков моей команды и соискателей на наши вакансии, потом во время доклада на эту же тему на конференции Panda Meetup, в конце концов, даже менеджер нашего проекта подошёл с вопросом: «Ну а всё же почему?». Настолько людей захватывает эта тема, что я решил поделиться развёрнутым ответом.

Сейчас существует широкий спектр кроссплатформенных технологий, среди которых Flutter, React Native и, конечно же, Kotlin Multiplatform Mobile (KMP). Какую технологию стоит выбрать и почему именно ее? Давайте попробуем разобраться!

Почему Flutter должен быть выбран в качестве фреймворка для вашего следующего проекта?

Разбираем популярные высказывания о несостоятельности Flutter как технологии и доказываем обратное.

Ошибка в консоли вашего браузера

1. YAGNI

В этой статье мы исследуем две фундаментальные структуры данных, которые являются неотъемлемой частью программирования на Swift: стеки и очереди. Они представляют собой коллекции элементов с особыми правилами для добавления и удаления элементов. Стеки работают по принципу "последним пришел, первым ушел" (LIFO), что делает их идеальными для задач, связанных с обратной навигацией или отменой действий. Очереди, следуя принципу "первым пришел, первым ушел" (FIFO), идеально подходят для задач, требующих обработки элементов в порядке их поступления, например, в управлении задачами или потоками данных.

Simon Wirtz в своем блоге публикует достаточно много интересных постов о Kotlin.
Представляю вашему вниманию перевод одного из них.

В этой статье мы рассмотрим, как и почему изменилась реализация примитивов синхронизации из стандартной библиотеки Java и пакета java.util.concurrent для Kotlin Coroutines и для языка Kotlin в целом.

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

Оценим готовность текущих решений к использованию в Kotlin Multiplatform.

Разработаем аналоги нескольких полезных классов пакета java.util.concurrent, до которых еще не добрались разработчики корутин.

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

Привет! Меня зовут Александр Миронычев. Я занимаюсь инфраструктурой приложения Яндекс Маркет под Android. Около двух лет назад при работе над модульностью у меня появилось желание написать собственную библиотеку для внедрения зависимостей, которая позволила бы ускорить сборку приложения и упростить процесс модуляризации. Так появился Scout. Сегодня его код мы выложили в открытый доступ.

Эта статья — рассказ о том, как пройти путь от безумной идеи до конкурентоспособного опенсорс-фреймворка. Статья будет полезна тем, кто ищет замену DI-фреймворку в своем проекте, а также тем, кто мечтает написать свою библиотеку, но никак не может начать.

Kotlin — это статически типизированный язык программирования на основе JVM, разработанный компанией JetBrains. Он был представлен Google в первую очередь для создания мобильных приложений на платформе Android. Используя Kotlin, разработчики могут писать код быстрее и более качественно. Тем не менее, как и в случае с любым другим языком программирования, важно соблюдать набор правил, чтобы обеспечить высокую производительность и читаемость кода.

Привет, Хабр! На связи Александр, iOS‑эксперт компании KTS.

В это время мы обычно строим планы на будущее, и я уверен, что лучшее начало нового года — обучение новому и развитие навыков. Надеюсь, что в этом вам помогут видео докладов с осенних митапов, которые мы провели с командой iOS-разработки и на которых разобрали темы с последней конференции Apple: WWDC 2023.

Собрал в одной статье все вебинары и их краткое содержание.

В 2022 году с приложениями Netflix для iOS и Android произошли серьезные изменения. Мы перевели мобильные приложения Netflix на GraphQL с нулевым временем простоя, что повлекло за собой полное перепроектирование от клиента до уровня API.

До недавнего времени наши мобильные приложения работали на внутреннем API-фреймворке Falcor. Теперь они поддерживаются Federated GraphQL — распределенным подходом к API, при котором доменные команды могут независимо управлять и владеть определенными разделами API.

Сделать это безопасно и без сбоев для 100 миллионов клиентов — чрезвычайно сложная задача, особенно учитывая множество аспектов изменений. В этой статье мы расскажем о широко применяемых методах (помимо GraphQL), которые мы использовали для осуществления этой миграции. Мы обсудим три стратегии — A/B-тестирование, Replay Testing и Sticky Canaries.

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

В этом посте я хочу рассказать про архитектуру Flutter-приложений, о том, как мы в билайне это делаем, чего мы достигли и как это у нас работает. Поговорим о создании архитектуры, организации управления состояниями и зависимостями, о привычных и не очень методах и концепциях, затронем Mobx, GetX и Flutter modular, а также разберём всё это на живом примере — на нашем мобильном приложении для дилеров.

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

Привет! В данной статье мы разберём процесс разработки веб-приложения на основе подхода микрофронтендов с использованием технологии Module Federation

Декабрь в офисе не проходит без традиции тайного Санты. Мой вишлист остался пустым, но подарок, который я получила, удивил своей точностью. А вместе с ним пришло загадочное послание. Как новичку в компании, мне было трудно с первого взгляда угадать отправителя, поэтому я решила использовать TypeScript, чтобы найти своего Санту.

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

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

В этом (спойлер — и не только в этом) нам сильно помогает единое хранилище данных, далее просто ЕХД.

Всем привет! Меня зовут Олег и я fullstack-программист в компании Тензор. Опыт в разработке, без малого, 20 лет (как-то раз батя спаял на кухне ZX Spectrum и все заверте..., сам не понял как так вышло). В данный момент являюсь тимлидом собственной команды разработчиков, которая периодически нуждается в пополнении толковыми программистами.

Как и многие руководители, я активно принимаю участие в подборе сотрудников для себя и помогаю на собесах коллегам соседних отделов.

Наша команда занимается разработкой веб-приложения на React. Соответственно, мне важно найти программистов уверенно владеющих основами (!) этого фреймворка. Есть много способов проверки компетенций на собеседовании, один из любимых - задача по написанию hook для загрузки данных.

Если вы тоже в вечном поиске классных фронтендеров или сами часто проходите собесы - велком в эту статью :)