iOS *

Об управление памятью в iOS ходят много слухов, поэтому я собрал все самые интересные в интернете и попробовал их структурировать в один большой

В свободное время (а иногда и в рабочее) я изучаю микроконтроллеры и собираю умный дом у себя в квартире, а так как по профессии я iOS-разработчик, то на умный дом я смотрю через призму iPhone и HomeKit. После сборки более-менее рабочего умного дома и, столкнувшись с кучей проблем, решил рассказать про свой опыт и устройства в цикле из 2 статей. Первая статья будет небольшим ликбезом в теорию микроконтроллеров и протоколов, а во второй уже поделюсь конкретным применением этих протоколов и фреймворков в моем умном доме.

Сегодня делимся видео для мобильных разработчиков с IT-конференции ЮMoneyDay.

Начнём с процессов в UI. Что помогает команде работать быстро и слаженно и как срезать углы в работе с дизайн-системой? В первом докладе поделились, как наладить разработку в iOS-команде.

Далее перейдем к Android. Во втором докладе рассказали, как подружить мобильное приложение на сотню экранов с серверным API. В третьем докладе показали, как один (!) плагин на Kotlin позволяет опубликовать артефакты в разные репозитории.

Примечание

Слова layout, autolayout и constraints я перевёл, соответственно, как вёрстка, автовёрстка и ограничения.

Работа с автовёрсткой

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

Interface Builder неплох как визуальный редактор вёрстки. В нём есть индикация некорректных граничных параметров. Однако ваша вёрстка может отличаться от видимой в IB. На экран приложения могут влиять различные параметры — например, ответы на сетевые запросы или локально сохранённые данные. Более того, могут быть экраны, частично или полностью построенные на информации, заданной сервером. От сервера может поступать вообще всё что угодно, в том числе шрифты, цвета и формы.

Кажется, остаётся только вручную разбирать гигантский лог ошибок автовёрстки. Но есть и другие варианты.

Обновление данных в интерфейсе всегда задействует немало ресурсов а его реализация может быть выполнена множеством неоптимальных способов. Повышение производительности, не только радует пользователя, но и расширяет круг целевой аудитории с более старыми устройствами. State management Как? Когда? Почему? Каким способом? Лучше всего изменять состояние виджета/древа виджетов? Сейчас можно увидеть большое кол-во различных библиотек и подходов для решения данной задачи. Вопрос обновления данных интерфейса настолько большой, что библиотеки, которые помогают с управлением состояний становятся Архитектурными подходами, паттернами, а статей про то какой подход лучше еще больше. Данное решение подойдет к любому проекту, ему не нужна библиотека и вовсе не обязательно использовать данный виджет.

Первое приложение со SwiftUI

- Шпаргалка по SwiftUI

- Некоторые нюансы работы SwiftUI

- PageView на SwiftUI

- WebImage на SwiftUI (AsyncImage)

Спойлер - нет! Ну, не совсем. Мы привыкли воспринимать UI как визуальную составляющую, но ведь UI – это User Interface. Так вот, интерфейс – это то, с помощью чего пользователь взаимодействует с нашим приложением. В случае с графическим интерфейсом пользователь его видел и воспринимает информацию. Однако он статичный и, когда пользователь хочет взаимодействовать с ним, он использует другие интерфейсы: тачскрин, клавиатуру или мышку. Да, это тоже интерфейсы. И UIKit как раз таки отвечает не за графический интерфейс, а за распознавание пользовательских жестов и их обработку.

Когда я начинал писать эту статью, хотелось рассказать много фундаментальных вещей. Одновременно с этим хотелось, чтобы она была понятна всем, поэтому я начал с описательной части. Со временем понял, что материала получается слишком много и я решил разбить ее на несколько частей. Возможно какие-то вещи для вас покажутся совсем простыми и очевидными, но они нужны для того, чтобы хорошо разобраться и ориентироваться, как же все-таки устроен UI.

Так как же он устроен? У нас же есть базовый класс UIView и куча его стандартных наследников. Мы можем сами создавать свои вью и как угодно их кастомизировать. И все это видим на экране. Почему тогда UIKit и UIView – это не про графический интерфейс? Давайте разбираться.

Я человек далекий от программирования и люблю бить баклуши. Но случилось непредвиденное, моему сербскому другу Джонни, приехавшему в гости, понадобился QR-код. Пришлось расчехлить клавиатуру.

Монолитный проект порос мхом, и хочется разбить его на модули? Рассказываем, какие инструменты помогут сделать это быстрее.

Run Loop (цикл исполнения) является механизмом, который позволяет потокам обрабатывать события (events) бесконечно в любое время.

Run Loop представляет из себя объект, который управляет событиями и сообщениями, обрабатывает их, и предоставляет функцию точки входа для выполнения логики события.

15-17 октября Банк Хоум Кредит провел онлайн-хакатон Home Credit Hack для специалистов из Казахстана. Участникам нужно было создать приложение для клиентов и партнеров для автономных покупок. Эксперты и организаторы хакатона Ян Ценкр, директор IT департамента Банка Хоум Кредит, Станислав Тян, директор департамента онлайн-бизнеса и Илья Линицкий, сооснователь Phystech.Genesis рассказывают, как проходило соревнование, сколько было заявок на участие, как отбирали конкурсантов и какие идеи предлагали команды. 

Привет, меня зовут Сергей, я Android Lead в компании Broniboy —  сервисе мультидоставки, который работает не только с ресторанами, но и с магазинами, аптеками и обычными людьми. Учитывая уровень конкуренции на этом рынке, каждый клиент на счету. Достаточно одной ошибки, чтобы потерять его, поэтому нам нужен надёжный канал поддержки пользователей. Наш выбор пал на чат, простой и понятный пользователю канал связи. Он позволяет не только оперативно реагировать на жалобы, но и привности частичку «человечности» в общение с техподдержкой.

Изучив готовые SDK и взвесив все «за» и «против», мы решили написать собственный SDK чата. Одна из основных идей — переиспользование кода между платформами, а сегодня это Android, iOS и Web. Поэтому, для MVP мы решили попробовать Kotlin Multiplatform.

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

●      Подробно расскажем про переиспользуемый провайдер табличного источника данных,

●      Покажем использование на конкретном примере,

●      Опишем результат с позиции SOLID,

●      Обсудим достоинства и недостатки подхода.

В основе решения лежат принципы SOLID. Цель состоит в том, чтобы составляющие элементы нашего подхода были независимыми, не влияющими друг на друга.

Когда-то Стив Джобс назвал Android «украденным продуктом» и поклялся его уничтожить. 

Но «отец Android» Энди Рубин совершенно не считал, что все фичи iPhone — исключительно заслуга Apple. 

А позже сторонники Android и вовсе стали говорить, что это в Apple все у них копируют (например, когда в iOS 14 добавили виджеты, приложение Translation и технологию App Clips).

Так какая же сторона права? (Спойлер: обе.)

Боб Ли из команды Android писал, что схожесть Android и iPhone была «связана с общим путем, по которому развиваются технологии». 

Например, инновации в технологиях мультитач — то, без чего не было бы современного смартфона — насчитывают десятилетия. Первые устройства с мультитачем были созданы еще в 1980-х годах. Поэтому и iPhone, и Android несут в себе скопированные идеи своих предшественников. 

Идеи витают в воздухе, наступает время для той или иной технологии, поэтому взаимное «воровство» двух гигантов продолжается и по сей день.

В этой статье мы кратко рассмотрим, что iPhone и Android позаимствовали друг у друга и обойдемся без заезженных цитат про «крадущих великих художников».

Мой путь в ИТ почти 20 лет, начинал с SQL/1С/эникейщика, потом немного .net, немного Java, ГИС, потом несколько лет менеджерская история в разработке, которую я прервал в 2016 году. До этого времени мой путь был скорее хаотичным и не спланированным. Далее я осознанно начал подходить к планированию своей карьеры в ИТ, когда захотел вернуться в разработку. Чтобы возвращение в разработку не сменилось страхами связанными с выгоранием в Enterprise, я захотел заняться мобильной разработкой, которая максимально близка к пользователям, что лично меня сильно вдохновляет. Кроме того, невероятно заряжает на работу возможность использовать то, что ты делаешь. У меня уже были пара устройств от Apple, и мне, субъективно, интерфейс iOS нравился больше Android. Чтобы начать что-то пробовать я купил старый MacBook Air "на максималках", уехал на зимовку на Филиппины, чтобы отойти от менеджерского стресса, и начал разбираться "как там все устроено в этом XCode". Уже почти 5 лет я работаю как iOS-разработчик в лучших банках (Альфа, Сбер) и классном стартапе (БестДоктор) с разными небольшими тимлидскими историями, которые я осознанно стараюсь избегать, чтобы быть сфокусированным на разработке.

Акторы (Actors) — это фича, являющаяся частью структурированного параллелизма (Structured Concurrency) Swift, которая предлагает совершенно новый формат для написания и обработки асинхронного кода. Хотя они и являются чем-то инновационным для языка Swift, сама технология новой не является. Многие языки успели обзавестись поддержкой акторов и async/await раньше, чем Swift, но что интересно, так то, что везде они реализованы одинаково. Только-только получив этот функционал в Swift, мы уже можем многому научиться на опыте разработчиков, использовавших их в других языках.

Привет, я Денис Соколов, руковожу R&D в Zenia — это платформа для йоги и фитнеса, которая использует ИИ для трекинга поз человека (подробнее об этом — в другой моей статье). Наша система распознавания работает на трёх платформах — iOS, Android, Web. В этой статье поговорим о ключевых отличиях между ними. Расскажу, как устроена подготовка моделей компьютерного зрения к использованию, какими фреймворками пользуемся для запуска на устройствах клиентов, какие сложности решали и чем остались довольны. Если вы занимаетесь запуском нейронных сетей на мобильных устройствах или вебе, статья для вас.