Введение

Я начала изучать Flutter и недавно потратила целый день пытаясь внедрить архитектуру Model-View-ViewModel в свое приложение на Flutter. Обычно я пишу под Андроид на Java, MVVM реализую с помощью AndroidViewModel и LiveData/MutableLiveData. То есть опыт программирования и применения паттерна есть, приложение — простой таймер. Так что ничто не предвещало столь больших временных затрат на простую задачу.

Поиски статей и инструкций по MVVM во Flutter (без использования RxDart) дали один пример причем без ссылки на полный исходник, так что хочу немного облегчить для интересующихся изучение этого паттерна во Flutter.

Фреймворк Flutter по умолчанию работает хорошо и быстро, но означает ли это, что вам вообще не нужно думать о производительности? Нет. Абсолютно реально писать приложения Flutter, которые будут медленными. С другой стороны, также можно использовать фреймворк максимально и делать ваши приложения не только быстрыми, но и эффективными, потребляя меньше времени процессора и батареи.

Это то, что мы хотим видеть: статистически значимый результат сравнения двух версий вашего приложения по какой-то значимой метрике. Читайте дальше, чтобы узнать, как такое получить.

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

Можно ли в iOS работать с геолокацией, когда приложение свернули и отправлять данные на сервер?

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

Чтобы была какая-то конкретика, я предположил, что перед нами стоит задача написать вело-трекер. Со стороны пользователя это выглядит так:

1. Скачиваю приложение
2. Запускаю
3. Регистрируюсь
4. Нажимаю куда просят
5. Закрываю
6. Катаюсь
7. Запускаю
8. Вижу результат

p.s. финальный код здесь.

Предисловие

В статьях о функциональном программировании много пишут о том, как ФП подход улучшает разработку: код становится легко писать, читать, разбивать на потоки и тестировать, построить плохую архитектуру невозможно, а волосы становятся мягкими и шелковистыми.

Недостаток один — высокий порог входа. Пытаясь разобраться в ФП, я столкнулся с огромным количеством теории, функторами, монадами, теорией категорий и алгебраическими типами данных. А как применять ФП на практике, было неясно. Кроме того, примеры приводились на незнакомых мне языках — хаскеле и скале.

Тогда я решил разобраться в ФП самого начала. Разобрался и рассказал на codefest о том, что ФП — это на самом деле просто, что мы уже им пользуемся в Swift и можем пользоваться еще эффективнее.

Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.

Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.

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

Изначально весь проект был написан на Objective-C и использовал ReactiveCocoa версии 2.0

Взаимодействие между View и ViewModel осуществлялось посредствам биндингов свойств вью модели, и все бы ничего, за исключением того, что отладкой такого кода заниматься было очень сложно. Все из-за отсутствия типизации и каши в стек-трейсе :(

И вот настало время использовать Swift. Поначалу мы решили попробовать вообще без реактивщины.

Сегодня поговорим об архитектурных подходах в iOS-разработке, про некоторые нюансы и наработки реализации отдельных вещей. Расскажу, каких подходов придерживаемся мы и немного углубимся в детали.