Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><ul><li><a>Координация навигации по вью в SwiftUI с помощью паттерна Flow Coordinator</a></li>

2 <li><a>Kotlin Multiplatform Mobile - совместное управление состоянием пользовательского интерфейса</a></li>

3 <li><a>Облегчаем внедрение зависимостей и модульное тестирование с помощью асинхронных функций</a></li>

4 <li><a>Не совсем очевидные тренды развития рынка приложений, как к ним подготовиться мобильному разработчику?</a></li>

5 <li><a>Развитие способностей коллекций в Swift (на примере функции suffix)</a></li>

6 <li><a>Золотые правила “weak self”</a></li>

7 <li><a>Память в Swift (куча, стек, ARC)</a></li>

8 </ul><li><a>Записи открытых занятий курса "iOS Developer. Professional":</a></li>

9 </ul><h3><a>Координация навигации по вью в SwiftUI с помощью паттерна Flow Coordinator</a></h3>

10 <p>В этой статье я продемонстрирую, как можно использовать паттерн Flow Coordinator (далее флоу-координатор) в SwiftUI, чтобы отделить логику навигации от логики представления.</p>

11 <p>В UIKit этот шаблон был очень популярен - координаторы такого рода позволяют легко заменять или создавать новые вью-контроллеры (view controller), отделяя эту работу от кода вью-контроллеров и вью-моделей (view model). Это позволяет разделить во вью-контроллере код, затрагивающий саму вьюху, и навигацию, что в свою очередь облегчает изменение “потока приложения” (того самого флоу).</p>

12 <p>В некоторой степени подобное можно реализовать и в SwiftUI.</p>

13 <h3><a>Kotlin Multiplatform Mobile - совместное управление состоянием пользовательского интерфейса</a></h3>

14 <p>В своей <a>предыдущей</a> статье я рассказал о том, почему считаю, что мы можем значительно улучшить управление UI State (состояние пользовательского интерфейса) между View (представление) и ViewModel (модель представления) в Android, используя архитектуру Model-View-Intent (модель-представление-намерение) (MVI) с помощью Finite State Machine (машина с конечным числом состояний. конечный автомат) (FSM).</p>

15 <p>В этой статье я подскажу вам шаги, необходимые для модернизации этого решения до уровня Kotlin Multiplatform Mobile (KMM), где можно воспользоваться общим исходным кодом, содержащим MVI+FSM, так что обе платформы - Android и iOS - могут унаследовать его преимущества, отвечая только за платформозависимые реализации: UI/UX.</p>

16 <h3><a>Облегчаем внедрение зависимостей и модульное тестирование с помощью асинхронных функций</a></h3>

17 <p>Очень часто подготовка кода к модульному (или юнит-) тестированию имеет обыкновение идти рука об руку с работой по разделению ответственности, улучшению управления состояниями и его архитектуры в целом. Как правило, чем лучше абстрагирован и организован ваш код, тем легче его будет покрыть автоматизированными тестами.</p>

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

19 <p>Но <em>действительно</em> <em>ли</em> мы обречены платить такую цену за тестируемость? Что, если бы мы могли сделать наш код полностью пригодным для тестирования таким образом, чтобы от нас не требовалось вводить какие-либо новые протоколы, всевозможные моки или сложные абстракции? Давайте же разберемся, как мы могли бы реализовать это, используя новые возможности async/await Swift.</p>

20 <h3><a>Не совсем очевидные тренды развития рынка приложений, как к ним подготовиться мобильному разработчику?</a></h3>

21 <p>Когда платформа погибает, вакансий становится мало и остается пару лет подумать куда идти. С какого-то момента я стал заранее анализировать куда пойдет платформа, на которой я зарабатываю деньги. Мобильные приложения - это растущий рынок: за 2021 пользователи потратили в 142 млрд. долларов в App Store (92B $) и Google Play (50B $) на цифровые сервисы. Сегодня регуляторы вынуждают магазины приложений добавлять сторонние платежные сервисы, что создает хорошую перспективу для развития индустрии. Я преподаю разработку под iOS 8 лет, и в своих поздних авторских курсах мне уже удается прогнозировать рынок на несколько лет вперед и заранее готовить студентов к технологическому стеку, который будет востребован в будущем. </p>

22 <p>Хочу не просто рассказать про тренды, а проанализировать, какой технический стек будет важен на первых этапах развития ниши.</p>

23 <h3><a>Развитие способностей коллекций в Swift (на примере функции suffix)</a></h3>

24 <p>Протоколы иерархии Sequence/Collection имеют одно из самых важных значений в Swift, начиная со встроенности в язык (например, конструкция цикла for in) и заканчивая популярными функциями высшего порядка map, reduce и т.п. Часто разработчики путаются в особенностях, не осознавая возможности, предоставляемые отдельными протоколами иерархии коллекций. Давайте попробуем разобраться с этими особенностями на примере одной функции, которая по разному реализуется в этих протоколах - функция suffix.</p>

25 <h3><a>Золотые правила “weak self”</a></h3>

26 <p>Захват self в замыкании - обычная вещь в Swift, которая скрывает множество нюансов. Нужно ли делать его weak, чтобы избежать цикла ссылок? И является ли проблемой сделать его weak постоянно?</p>

27 <p>На прошлой неделе в iOS Dev Weekly была опубликована статья Benoit Pasquier, посвященная захвату self в замыканиях. Моя статья будет ей противоречить. И это нормально! Примите все эти советы с определенной долей скептицизма, разберитесь в компромиссах и выберите те техники, которые подходят вам лучше всего.</p>

28 <h3><a>Память в Swift (куча, стек, ARC)</a></h3>

29 <p>Для хранения объектов Swift использует две структуры данных: стек и кучу. Управление распределением памяти подразумевает выделение памяти под объект (аллокацию) и ее последующее высвобождение (деаллокацию).</p>

30 <p>В iOS существуют две модели управления памятью:</p>

31 <ol><li>MRC: manual reference counting (ручной подсчет ссылок)</li>

32 <li>ARC: automatic reference counting (автоматический подсчет ссылок)</li>

33 </ol><h2>Записи открытых занятий курса <a>"iOS Developer. Professional"</a>:</h2>