Привет! Вот и новая часть серии статей про многопоточность дождалась своей очереди (ну вы поняли, да, типа очередь статей последовательная (͡° ͜ʖ ͡°) ). В этот раз мы поднимемся на ступеньку выше, рассмотрим фреймфорк Dispatch, разберем большую часть GCD примитивов, распространенные проблемы и поищем решения.
Всем доброго дня! С вами Анна Жаркова, ведущий мобильный разработчик компании Usetech. Продолжаем рассматривать способы многопоточный работы в Kotlin Native. В предыдущих статьях мы уже рассмотрели существующие способы работы с многопоточностью с корутинами и без, и что делать с имеющимися болями. Теперь поговорим о новой модели управления памятью, которая появилась совсем недавно.
31 августа компания JetBrains представили превью новой модели управления памятью в Kotlin Native. Основной упор команда разработчиков сделала на безопасность шаринга между потоками, устранение утечек памяти и освобождение нас от использования специальных аннотаций. Также доработка коснулась Coroutines, и теперь можно без опаски переключаться между контекстами корутин без заморозки. Обновления подхватили и Ktor:
Итак, что же нового появится в версии Kotlin 1.6.0-M1-139:
1. Заявлено, что мы можем убрать все freeze() блоки (в том числе и во всех фоновых Worker), и переключаться между контекстами и потоками без каких-либо проблем.
2.Использование AtomicReference или FreezableAtomicReference не приводит к утечкам памяти.
3.При работе с глобальными константами не нужно теперь использовать SharedImmutable.
4.При работе с Worker.execute producer больше не требует возвращать изолированный подграф объектов.
Однако есть и нюансы:
Сегодня разбираем, как реализовать скидки на iOS: стартовое предложение, промо-предложение и промокод. Это шестая из серии статей про подключению внутренних покупок в приложениях App Store, в которой мы с командой описываем весь процесс включения in-app purchases. Остальные доступны по ссылкам:
1. iOS in-app purchases, часть 1: Конфигурация и добавление в проект.
2. iOS in-app purchases, часть 2: Инициализация и обработка покупок.
3. iOS in-app purchases, часть 4: Тестирование покупок.
4. iOS in-app purchases, часть 3: Серверная верификация покупок.
5. iOS in-app purchases, часть 5: Обработка ошибок.
6. iOS in-app purchases, часть 6: Скидки для iOS in-apps purchases. — Вы тут.
14 сентября Apple провела традиционную сентябрьскую конференцию, на которой анонсировала обновления своих флагманских продуктов. Новые iPhone, редизайн iPad mini и Apple Watch — что еще нового? В основном — эволюционные, а не революционные улучшения, но обо всем по порядку.
Здравствуйте, уважаемые поклонники и ненавистники техники Apple. С вами Сергей Вильянов, который снимал SIM-lock еще у первых iPhone, когда работал в "Компьютерре", а теперь покупает айфоны для издевательств строго за свои.
Сейчас мы вместе посмотрим презентацию Apple и узнаем - за что эти обаятельные парни в Купертино опять хотят много денег. И, скорее всего, получат.
Вот здесь собраны самые влажные предвкушения фанатов насчет того, что они ждут от новых iPhone. А мы просто внимательно посмотрим и послушаем презентацию, медленно пропитываясь негодованием и восторгом.
И да, если вам померещились ирония и сарказм, ВАМ НЕ ПОМЕРЕЩИЛОСЬ.
Погнали.
В предыдущей статье мы сформулировали нашу главную проблему при масштабировании Unidirectional Data Flow (UDF) — модуляризацию. Сегодня существует много UDF-фреймворков на Swift, но мало кто уточняет, как их масштабировать на большое, многомодульное приложение. Мы решили поделиться, с какими сложностями столкнулись и к каким решениям пришли.
В статье рассмотрим 3 проблемы, с которыми столкнулись, и сравним, как разные фреймворки их решают. Для сравнения мы выбрали одни из самых популярных — ReSwift и The Composable Architecture (TCA). В конце расскажем, какое решение мы в итоге реализовали. Приступим!
Всем доброго дня! С вами Анна Жаркова, ведущий мобильный разработчик компании Usetech. Продолжаем рассматривать способы многопоточный работы в Kotlin Native.
В предыдущей части мы посмотрели некоторые нюансы работы с корутинами, как работать с Worker и AtomicReference.
Еще одним возможным API для работы с многопоточностью является DetachedObjectGraph.
Всем доброго дня! С вами Анна Жаркова, ведущий мобильный разработчик компании Usetech. Совсем недавно компания JetBrains выпустила preview новой модели управления памятью. Это отличный повод сделать подробный ее разбор на практике, а также сравнить с моделью, используемой в KMM в текущих версиях. Но для начала неплохо было бы поговорить о тех возможностях работы в Kotlin Native, которые мы на практике не используем.
Если вы уже знакомы с тем, как работать с корутинами в Kotlin/Native и/или читали предыдущие статьи 1 и 2 автора, то пролистайте немного вниз. Материал может немного повторяться.
Когда мы работаем с Kotlin и Kotlin Multiplatform, то самым и простым удобным способом для настройки работы с многопоточностью в приложении являются Kotlin Coroutines. Наша задача сводится к настройке скоупов CoroutineScope для запуска корутин и suspend функций в основном потоке и фоновом. Т.к. в разных платформенных версиях языка Kotlin этот механизм реализуется по-разному, то необходимо кастомизировать получение контекста корутин с помощью expect/actual:
Изучая тему мобильной разработки, не стал ограничиваться только переводом Apple Human Interface Guidelines for iOS на русский язык.
Решил перевести и App store rewiev guidelines. Ранее на хабре уже публиковался перевод этого руководства, но по прошествии семи лет, думаю, обновление перевода будет не лишним.
Если увидите, что в каких-то местах текст переведен некорректно или плохо, и у вас есть идея о более правильном варианте, прошу написать на почту hamvestor@gmail.com, указав в теме письма "App store RG - перевод".
Перевод размещен здесь: App Store Review Guidelines (Google Docs).
Недавно я столкнулся с задачей об отображении иерархических данных в виде списков с возможностью поиска для платформы iOS. Так как подходящий инструмент не был найден, было решено написать свой компонент, который позволял бы решать поставленные задачи.
В данной статье на примере проекта, архитектура которого приведена на фото, вы сможете найти ответы на следующие вопросы:
- Как работает алгоритм нахождения слов в игре типа Boggle?
- Как предобработать изображение для дальнейшего распознавания букв с помощью OpenCV?
- Как распознать буквы с помощью pytesseract?
- Как происходит клиент-серверное взаимодействие через TCP сокеты?
- Как связать Shortcut и приложение Pythonista?
- Как пробросить порты для взаимодействия с сервером в Docker?
Привет, я Антон, iOS-разработчик в inDriver. Год назад я присоединился к компании и стал одним из первых разработчиков в новой платформенной команде. Перед платформенными командами, в отличии от продуктовых, стоят задачи по разработке, а не по продукту как таковому. Мы выделили основные направления: создание общих компонент и стандартов разработки, а также развитие и поддержка архитектуры проекта. В этой статье остановимся на архитектуре. Разберем, с какими проблемами столкнулись в процессе ее масштабирования, какие ошибки допустили и как исправили. Обо всем по порядку.
UPD: технические детали подробнее рассказаны во второй части.
Занимаясь на курсах или обучаясь по различным туториалам, книгам и статьям, начинающие разработчики не слишком заботятся о том, как называть свои константы, переменные, классы, протоколы и т.п. во время написания кода. А ведь код пишется прежде всего для людей, а не для машины (машина понимает лишь язык нулей и единиц). Соответственно, для того, чтобы работать в команде, нужно позаботиться о том, чтобы код был понятен другим разработчикам (или понятен самому себе спустя несколько месяцев). Понятный код - один из важнейших критериев отбора джунов на работу. Ни один работодатель не захочет брать на работу кодера, у которого в коде "без бутылки не разберешься".
Как и множество других компаний, мы в hh.ru с интересом приглядываемся к Kotlin Mobile Multiplatform. Особенно нас заинтересовал вопрос, связанный с удобством работы iOS-разработчиков с общим SDK. Наши iOS-инженеры пишут на Swift, поэтому нам важно было убедиться: то публичное API, которое мы сформируем, будет выглядеть на Swift так же удобно и классно, как и в Kotlin. Мы провели объёмный ресёрч, в рамках которого подготовили специальный репозиторий "Kotlin-Swift-Interopedia", которым и хотим поделиться с сообществом.
На портале документации KMM можно найти страницу, посвящённую интеропу между Kotlin и Swift. Но в ней не рассматриваются все возможные конструкции языка Kotlin-а, поэтому даже после чтения документации оставалось множество вопросов.
Как поведут себя abstract-классы? Что будет с sealed-интерфейсами? Удобно ли мне будет работать с лямбдами в качестве аргументов функций? Enum-ы превратятся в Swift-овые enum-ы?
Чтобы ответить на эти и множество других вопросов, мы и создали нашу "интеропедию". В ней мы собрали в единую табличку часто встречающиеся фичи языка Kotlin и указали, чем можно пользоваться без проблем, с какими придётся произвести дополнительные манипуляции , а какие пока что не работают совсем. Мы запилили этот репозиторий, чтобы помочь всем, кто тоже проводит ресёрч KMM, определиться с использованием этой технологии.
Относительно недавно на Хабре анонсировали специальный инструмент, который может немного улучшить опыт iOS-разработчиков — плагин moko-kswift от компании IceRock. Но даже с его помощью не все боли могут быть исправлены прямо сейчас.
Всем привет! Меня зовут Илья, и я провожу собеседования *хлоп-хлоп-хлоп*. Сейчас работаю на позиции Principal iOS Engineer в inDriver, и мой фокус смещен в сторону технических собеседований. До этого руководил мобильной разработкой в в «Альфа-Банке» и был кем-то вроде нанимающего менеджера. Это тот человек, который говорит финальное слово по кандидату и определяет, какую циферку написать в оффере. Помимо «рабочих» собеседований, я иногда собеседую на аутсорсе, а также помогаю разработчикам к ним готовиться.
В общем, собеседования давно стали частью моей жизни. В этой статье мы верхнеуровнево пройдемся по всем этапам этого процесса, от идеи до офера, и обсудим, как успешно дойти до конца.
Всем привет!
Меня зовут Илья и я являюсь одним из разработчиков в команде in3D - мы делаем технологию по созданию 3D модели человека с помощью телефона. Мы начали еще в далеком 2019 году и с тех пор мы сильно продвинулись вперед. Давайте вместе посмотрим на прогресс нашей технологии и на основные шаги улучшения.
Спойлер для самых нетерпеливых, тут можно посмотреть как выглядит наше приложение и результат, а так же сравнение с некоторыми другими приложениями для сканирования:
Создание нового проекта на Flutter - это благословение - свежая кодовая база, никакого легаси кода (пока что), null safety, самые последние версии ваших любимых библиотек и так далее. Однако, в то же время, необходимо принять критические решения в самом начале, которые будут лежать в основании для будущего, такие как инструменты, пакеты, файловая структура, решение для менеджмента состояния, тестирование и планирование. В противном случае, в итоге, проект превратится в еще одну чашу спагетти с фрикадельками. Чтобы избежать этого, я подготовил список наиболее важных, по моему мнению, частей проекта, которые должны быть решены как можно раньше. Я надеюсь, что это поможет вам. Приятного чтения!
