Android, iOS, Windows Phone и прочие
«Сделай удобно» #1. «Сделай удобно» #2. «Сделай удобно» #3. «Сделай удобно» #4, «Сделай удобно» #5.
Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.
Под катом: Яндекс.Лавка, Airbnb, Daylio, Waterllama.
В прошлой статье многие подметили некорректность сравнения Deepseek и ChatGPT-4o. Изначально идея была сравнить максимально доступные пользователю версии.
Но сперва всё же хочется посмотреть как с одной и той же задачей справляются разные версии ChatGPT. Я в прошлом году делала анимацию (да, мне прям нравится по выходным, когда отдыхаю, кодить что-то максимально ненапряжное), так вот я её сделала в ChatGPT-4o.
Не сказать, что я прям получила удовольствие, скорее наоборот, выбесилась знатно. А на этой неделе решила её повторить уже с ChatGPT-o3-mini-high. Разница, конечно, колоссальная. Но обо всём по порядку.
Что может быть лучше, чем оглянуться и вспомнить, как команды разработчиков, бизнес-аналитиков и тестировщиков Surf провели прошедший год? Предлагаем погрузиться в то, как мы творили, экспериментировали, добивались результатов и делились ими со всеми желающими.
Будет много видео 😁
Хабр не раз выручал нашу команду, когда заказчик ставил задачу, которую мы никогда не делали. В недавнем кейсе по разработке демо-приложения PWA мы подсмотрели в статьях несколько полезных советов и тоже решили написать о своем опыте. Поговорим о PWA, развитие технологии и про то, кому это выгодно и не очень. Кстати, меня зовут Сергей Филатов и я веб-разработчик в R-Style Softlab.
Привет, меня зовут Михаил Шевченко. В Авито я проектирую и разрабатываю backend low-code платформы Bricks. В этой статье рассказываю о том, почему в Авито было принято решение развивать собственные low-code-решения и Backend-Driven UI, объясняю их устройство и делюсь достигнутыми результатами.
Будучи Flutter-разработчиками, мы часто сталкиваемся с необходимостью написания кода, ориентированного на конкретную платформу. Хоть Flutter и предоставляет полноценный фреймворк для создания кроссплатформенных приложений, интеграция нативного функционала иногда может быть весьма обременительной. Именно здесь на помощь приходит Kotlin Multiplatform (KMP). На мой взгляд, KMP — это не просто инструмент, который конкурирует с Flutter, скорее, он предлагает мощный способ рационализировать разработку плагинов, позволяя разработчикам экономить время, беречь силы и писать эффективный, легко сопровождаемый код.
В этой статье я поделюсь своим опытом использования KMP для создания библиотеки общих настроек (Shared Preferences) для Flutter под названием SharedPrefsKMP. Эта библиотека упрощает управление общими настройками в Android и iOS, демонстрируя, как KMP может улучшить процесс разработки на Flutter.
Всем привет. Работаю мобильным разработчиком в Narisuemvse. В настоящий момент для разработки используем Flutter и в наших проектах стараемся придерживаться принципов чистой архитектуры типа feature-first. Из-за этого приходится создавать множество папок и файлов по одному и тому же шаблону, поэтому в целях ускорения разработки было принято решение по написанию простого плагина для Android Studio.
В данной статье я хочу затронуть такую интересную тему, как обновление бандла Capacitor-приложений (CodePush, live update и т.д).
Сталкивались ли Вы когда-нибудь с ситуацией, когда необходимо незначительно обновить мобильное приложение, написанное на Capacitor?
Предположим такую ситуацию: Вы выпустили релиз приложения, где все изменения не связаны с обновлением нативного кода, то есть Вы не добавляли новых библиотек в приложение, которые содержат нативный код (доступ к камере, NFC и т. д.). Или, допустим, Вы обновили пару строчек в спецификации. Даже ради таких, казалось бы, небольших изменений вам придется делать как минимум один релиз в магазин приложений (а их бывает много).
А если нужно сделать релизы во всех популярных магазинах? Google Play, RuStore, AppGallery и, конечно же, самые нерасторопные из существующих — App Store. Выпуск во всех интересующих магазинах может занять значительное время. Вы, конечно, можете автоматизировать этот процесс при помощи различных инструментов, но, так или иначе, это занимает время на одобрение модераторами.
Привет, Хабр! Меня зовут Никита, я занимаюсь iOS-разработкой в Яндекс Диске. Как вы знаете, прошлой осенью зарелизился Swift 6, а вместе c ним появились и строгие проверки для защиты от датарейсов, связанные со Swift Concurrency.
В этой статье я постараюсь разобраться с основными изменениями в каждом пропозале и поделюсь своими заметками, тем, что мне показалось самым важным или интересным. В конце статьи бонус — Playground с тестами для каждого пропозала, чтобы можно было поиграть с кодом, детальнее разобраться с изменениями и понять, как они влияют на код, написанный на Swift 5.
В этой статье я расскажу о том, как создать нативный Sheet, который автоматически подсчитывает свою высоту в зависимости от котента (SwiftUI View). Задача была в том, чтобы решение было c минимумом костылей и сохраняло поддержку iOS 15. Готового похожего решения мне не удалось найти, поэтому решил создать свой вариант.
Привет, Хаброжители!
Сервисы по доставке готовой еды и продуктов встроили блок с чаевыми прямо во флоу оформления заказа: Glovo, Яндекс.Еда, Snoonu, Wolt и другие.
На себе заметил, что такая схема создает две проблемы для меня, как пользователя.
Всем привет! Меня зовут Вова я разработчик СБОЛа в web-канале.
Наверное, каждый фронтенд‑разработчик, по крайней мере на собеседовании, сталкивался с вопросами: «Какие единицы измерения существуют в CSS?» или «Какие единицы измерения ты использовал для CSS?», и т. п. Скорее всего, большинство интервьюеров удовлетворил бы ответ: «Абсолютные и относительные». И в целом, это, по‑своему, правильно. Но зададим себе вопрос: если разделить множество единиц измерения на два подмножества — абсолютные и относительные, — то будут ли внутри этих подмножеств единицы измерения действительно взаимозаменяемыми? Скорее нет, чем да. Тогда по какому признаку мы могли бы их разделить? По функциональному использованию.
Привет! Я Александр Сычев, iOS‑эксперт в KTS. В этой статье поговорю о потоках.
В решении рабочих задач и прохождении собеседований часто затрагиваются вопросы, связанные с многопоточностью и самими потоками, а также с необходимостью их синхронизации. Однако что происходит за кулисами этих процессов? Как функционирует механизм потоков изнутри?
В данной статье мы рассмотрим детали этой темы, а именно:
• проанализируем работу потоков;
• выявим скрытые механизмы, обеспечивающие их функционирование;
• определим, какую пользу практикующим iOS‑разработчикам приносит понимание внутреннего устройства потоков.
Градиентное текстурирование — это методика оптимизации 3D-текстурирования, в первую очередь предназначенная для мобильных видеоигр. В ней используются текстурные карты низкого разрешения и градиентные цвета, позволяющие снизить ресурсную нагрузку на игровые без ущерба качеству графики. Благодаря применению градиентов в низкополигональных 3D-моделях симулируются такие эффекты, как освещение, тени и глубина, позволяя избавиться от необходимости в текстурах высокого разрешения, потребляющих больше ресурсов.
Эта методика обеспечивает эффективный баланс между производительностью и визуальным качеством, оптимизирует время загрузки и улучшает игровой процесс. Кроме того, она позволяет гибко менять цветовые палитры и может адаптироваться под разные 3D-модели, снижая размеры файлов и оптимизируя использование памяти.
Без лишних предисловий - давайте сделаем два абсолютно одинаковых запроса для создания приложения на SwiftUI и сравним, какая модель лучше справится с этими задачами.
Я решила дать два задания. Начнём с первого: нужно написать игру "Змейка", вот мой промпт:
Если лень читать - в конце ссылка на короткое видео сравнения (в телеграм канале).
🔥 Дисклеймер: возможен нагрев пятой точки! 🔥
Если вы фрилансер или владелец/сотрудник классической IT-компании и при чтении почувствовали, что сейчас начнётся небольшое возгорание в районе кресла — дышите глубже! Это исключительно моё субъективное мнение, основанное на опыте работы в разных форматах — от фриланса до полноценной студии.
В то же время, это хорошая возможность посмотреть на себя со стороны. Возможно, кто-то из фрилансеров увидит, что не хватает системного подхода, а в классических IT-компаниях задумаются, не перегибают ли они с бюрократией и подумают об эффективности. В любом случае, если есть желание подискутировать — пишите в комментариях, обсудим!