Android, iOS, Windows Phone и прочие
«Возьмите картошку и колу», — говорит пользователям баннер перед кнопкой «Оформить заказ». Он мешает и раздражает, хотя должен побуждать купить больше. Что делать, если именно вы отвечаете за баннеры в приложении: отпугивать пользователей и поднимать средний чек или задуматься о жалобах? В какой момент пользователь удалит приложение и уйдёт к конкурентам?
Привет, Хабр! Меня зовут Александр, я — руководитель группы тестирования в мобильном приложении для продавцов «Ozon Seller». Общаясь с тестировщиками из разных компаний, часто слышу про одну и ту же боль — долгий регресс руками, который из раза в раз отнимает уйму времени, сил и мотивации.
Хочу поделиться с вами историей о том, как мы работали над улучшением релизного процесса и что из этого вышло. Думаю, что статья будет полезна для QA-специалистов, команд тестирования и в целом для команд, занимающихся мобильной разработкой.
Написав в 2023 году своего второго бота — картинную галерею (функционал которого был достаточно прост — выдавать пользователю по запросу примеры картин художников, экспонирующиеся в крупных российских музеях), во мне зародилась мысль трансформировать его в викторину, где пользователь должен угадать художника той или иной картины.
Будучи Flutter-разработчиками, мы часто сталкиваемся с необходимостью написания кода, ориентированного на конкретную платформу. Хоть Flutter и предоставляет полноценный фреймворк для создания кроссплатформенных приложений, интеграция нативного функционала иногда может быть весьма обременительной. Именно здесь на помощь приходит Kotlin Multiplatform (KMP). На мой взгляд, KMP — это не просто инструмент, который конкурирует с Flutter, скорее, он предлагает мощный способ рационализировать разработку плагинов, позволяя разработчикам экономить время, беречь силы и писать эффективный, легко сопровождаемый код.
В этой статье я поделюсь своим опытом использования KMP для создания библиотеки общих настроек (Shared Preferences) для Flutter под названием SharedPrefsKMP. Эта библиотека упрощает управление общими настройками в Android и iOS, демонстрируя, как KMP может улучшить процесс разработки на Flutter.
Всем привет, на связи Василий Боровой и Иван Козловский – Flutter-разработчики из The Head. В этой статье хотим поделиться с вами опытом работы над YPay и YPay inventory для Flutter, рассказать про возможности библиотек и как их использовать, а также о проблемах, с которыми столкнулись.
Сегодня с вами Никита, iOS Team Lead в Surf. Никита объяснит, почему мы в Surf решили создать собственную архитектуру для разработки на SwiftUI.
Привет, Хабр! Меня зовут Артем, я автор и ведущий YouTube и Telegram каналов Android Insights.
Данная статья - идейный продолжатель моей предыдущей статьи Создание Custom Layout в Jetpack Compose
Сегодня мы создадим настоящий дисковый телефон с помощью Jetpack Compose! Вы узнаете, как реализовать жесты, анимации и механику вращения диска, чтобы получить максимально аутентичный опыт взаимодействия со старым добрым телефоном в современном Android приложении.
Привет, меня зовут Иван Курак, я Android-разработчик приложения Ozon Job. Если в первой статье мы разбирали фреймворк Koin, то во второй на наш исследовательский стол попадёт Dagger, который мы используем на большинстве проектов Ozon, в том числе на приложении Ozon Курьер Экспресс, за которое отвечает наш отдел. Это мобильное приложение, которое позволяет курьерам-фрилансерам и водителям службы доставки взять подработку в Ozon и доставлять экспресс-заказы от селлера напрямую клиенту или в ПВЗ Ozon.
В проекте мы используем Dagger 2 согласно его основной функциональности — собирать общие компоненты и навигацию между модулями, изолировать зависимости, улучшить тестируемость и поддерживаемость.
Его важный плюс в том, что он строит дерево зависимостей и может в момент компиляции узнать, какие зависимости достижимы, а какие нет. Стоит сказать, что мы не будет разбирать механизм кодогенерации, а сосредоточимся именно на классах, которые Dagger 2 создаёт для своей работы.
Эта статья будет полезна тем, кто использует Dagger 2 в своих приложениях и иногда/часто попадает в ситуации непонимания, почему Dagger 2 ведёт себя не так, как мы ожидаем. А это может создавать определённые трудности, особенно при отладке сложных проблем или при необходимости настройки более сложных сценариев внедрения зависимостей.
Например, в приложении Ozon Курьер Экспресс ведутся большие работы по переписыванию приложения на новую архитектуру. Поэтому рядом с существующей DI-архитектурой появилась вторая DI-архитектура. Чтобы их подружить, пришлось покопаться во внутренностях кода, что генерирует Dagger 2.
Дополнительная (но не менее важная) цель статьи — показать, что базовый код, который генерирует Dagger, не такой уж и страшный :).
Мне хотелось посмотреть, как работает ИИ Редактор кода Cursor AI на примере создания iOS приложения с выборкой данных с ресурса, который не требует API key и платной подписки. И этим ресурсом оказались публичные фотографии с Flickr.com.
Необходимо создать UI iOS приложения со строкой поиска вверху и сеткой Grid под ней для отображения миниатюр фотографий.
Пользователь должен иметь возможность вводить текст в строку поиска и видеть набор фотографий, теги которых tags соответствуют строке поиска. Строка поиска может содержать одно слово (например, «rose») или разделенные пробелами слова(например, «forest bird» (лес птица)).
А вы знали, что 70% пользователей покидают сайт или приложение, если сталкиваются с непонятными или неинформативными сообщениями об ошибках?
Привет! Сегодня поговорим о том, что такое плохо написанное сообщение об ошибке. Разберемся, почему непонятные сообщения об ошибках портят не только UX, но также вредят продукту и бизнесу. Конечно, также покумекаем о формуле, благодаря которой слагаются классные сообщения, и о важности коммуникации UX-редактора с командой разработки.
Все началось осенью 2017 года, тогда у нас уже был опыт разработки веб-приложений. Искали проект, удовлетворяющий следующим условиям:
1. Можно сделать небольшой командой.
2. Проверенная идея и большой потенциал роста.
3. Понимание как сделать лучше.
4. Оптимальное время разработки и выход на самоокупаемость.
5. Отсутствие проблем с правообладателями и законом.
История о том, как нам надоело искать приложение по зарядке и мы создали своё. Конфиденциально, бесплатно и без рекламы. Для узкой, но заинтересованной аудитории.
Долгое время интернет-банкинг и мобильное приложение Газпромбанка разрабатывалось и поддерживалось внешним подрядчиком. Но около двух лет назад мы решили, что такими вещами надо заниматься самим, собрали команду и полностью перевели разработку на себя. В этой статье расскажем, как прошел этот переход, почему переписали код с нуля и какие выводы сделали из этого опыта. А также поделимся неочевидными выгодами инхаус-разработки.
Все мы любим, когда приложение, которым пользуемся работает отзывчиво, быстро, а так же те операции, которые мы хотим совершить происходили максимально быстро: буть то банковское приложение, буть то приложением в коммерции и тд.
Но как мы можем отслеживать и мерить метрики скорости нашего приложения? Этим вопросом задаются многие разработчики и компании, которые получили негативную реакцию или думают наперед, когда кодовая база и сложность приложения будет расти. Существует два пути: либо мы изучаем на реальных пользователях нашего приложения, либо мы ищем какой-то другой способ, который позволяет нам статистически проверить гипотезу.
Редизайн — это инструмент, с помощью которого можно решать конкретные задачи: улучшать пользовательский опыт, устранять накопившиеся проблемы в продукте и влиять на ключевые бизнес-метрики. Он приносит результат только тогда, когда основан на данных и встроен в стратегию развития продукта.
В этой статье наш дизайнер интерфейсов Фёдор Миронов расскажет какие бывают типы редизайна, как определить целесообразность изменений, какие исследования важно провести до начала работ и как избежать ошибок, которые могут стоить слишком дорого.
Привет, Хабр! Меня зовут Никита Синявин, я ведущий Flutter-разработчик в компании BetBoom, а сегодня еще и гостевой автор Friflex. В этой статье я расскажу о своем Opus Magnum — создании эффективного Backend-Driven UI под названием Duit.
Всем привет. Меня зовут Татьяна Цикунова. Я системный аналитик в компании МойСклад. В этой статье расскажу о том, как организовать оперативный обмен информацией между участниками проекта и поддерживать документацию в актуальном состоянии Отдельное внимание уделю работе с таск‑трекерами — подробно опишу шаблон тикета, который успешно используется в нашей компании. Однако — если вы работаете без трекера задач, например, в ворд‑файлах, суть от этого не меняется ‑такой подход работает и с другими инструментами.
Я документирую системы больше 3 лет, и за это время успела поработать в разных сферах.. Начинала в финтехе, где успела поработать в разных командах. Потом перешла в МойСклад — здесь углубилась в e‑commerce направление. Сейчас вместе с командой делаем интеграции с интернет‑магазинами и маркетплейсами. За годы работы я убедилась, что не существует единого стандарта ведения документации — каждая компания и даже отдельные команды внутри одной организации вырабатывают свои подходы. маркетплейсами. В разных компаниях свой подход к ведению документации, даже в разных командах одной компании бывают разные подходы.
Однажды в МоемСкладе мы задумались: почему бы не начать системно собирать важные данные, которые появляются на разных этапах разработки? Ведь эти сведения могли бы стать отличной основой для обновления документации к реализованному ПО. Так и появились требования и рекомендации по описанию тикета.
Этот релиз приносит обновления форматера, null-aware элементы для коллекций, новые возможности кросс-платформенной разработки, лучший способ находить трендовые пакеты на pub.dev, доступность горячей перезагрузки (hot reload) для веба и многое другое! Мы также надеемся, что найдутся разработчики, заинтересованные в участии в нашей программе раннего доступа к FFigen и JNIgen.
При разработке современных приложений важнейшую роль играет качество клиент‑серверного взаимодействия. Для достижения стабильной связи между мобильными и веб приложениями и серверной частью необходимо стремиться к созданию надежного и эффективного механизма обмена данными. Это подразумевает создание устойчивого API, которое трудно сломать даже при изменениях в архитектуре сервера, а также легкость интеграции новых клиентов.
Кроме того, одним из ключевых приоритетов становится повышение продуктивности команд разработчиков. Важно сократить цикл разработки новых функций и обновлений, позволив разработчикам быстро вносить изменения и выпускать обновления, ускоряя процесс итераций.