Pull to refresh

Comments 5

Рад, что мои статьи действительно помогают, а не просто осели в избранном )
До юнит тестов у меня руки не дошли (планировал 4й в цикле статей), так что Ваша статья — очень нужна.
К сожалению 3я статья в состоянии «заморозки», она была посвящена архитектурным решениям RxSwift в сравнении с другими (MVC, MVVM без RxSwift). Но в процессе написания пришло понимание, что у меня не хватает времени и опыта практической работы с RxSwift, чтобы написать действительно достойный материал, а писать «чтобы было» не хочется.
В комментариях к другой статье по RxSwift я попробовал попытать автора на интересовавшие меня вопросы, но обьем текста в вопросах стал приближаться к обьему написанной им статьи и общение как то сошло на нет )

Так что сделаю еще одну попытку затронуть интересующие темы, если позволите.
1) Вы, я так понимаю, активно применяете RxSwift в production коде. Это приложения для клиентов или для себя? Если для клиентов — как они смотрят на то, что код будет «нестандартным»?
2) Не сталкивались ли с проседанием производительности в RxSwift?
3) Сколько добавляет в весе использование RxSwift в релизе?
4) RxSwift используется повсеместно во всем приложении или в основном для GUI привязок?

Просто RxSwift подразумевает под собой реализацию парадигмы функционально-реактивного программирования, которая включает в себя неизменяемость, что довольно тяжело выполнить везде. Достаточно посмотреть на их попытку продемонстрировать работу с TableView в RxSwift (TableViewWithEditingCommands).
Так что часто приходится в VM использовать изменяемые модели.
А вообще беда в том, что технология все же еще молода, и нет нормально выкристализованных best practice. Хотя мне очень понравилось работать с RxSwift, так что через время наверное сделаю еще одну попытку.
Здравствуйте, Александр! Ещё раз спасибо большое за статьи, это действительно огромный труд. Я рад что наши с Вами статьи дополняют друг друга и знакомят русскоязычное сообщество с более совершенными технологиями программирования, коей безусловно является RxSwift. IMHO, конечно :-)

Теперь отвечаю на Ваши вопросы:
1) Да, я активно применяю RxSwift в production code. На своей основной работе я главный iOS-разработчик и то, какие технологии и библиотеки будут в iOS-проекте, решаю я. У меня есть личные проекты, которые я делаю в свободное от работы время и в выходные, там также активно используется RxSwift, т.к. в этом случае тоже только я решаю, что будет использоваться в проекте. Что касается клиентов — я давно перестал брать фриланс, если честно, потому что большинство заказчиков не знакомы со спецификой программирования и иногда достаточно тяжело закрывать заказы. Но даже если и взять фриланс, то заказчику, в принципе, всё равно на каком языке я буду писать и какие технологии использовать — обычно они оставляют выбор способа для реализации задачи, им важен сам результат — наличие работающего приложения.
2) С проседанием производительности не сталкивался, но если верить отладчику, то уровень потребления памяти и загрузка процессора в моих проектах с RxSwift и без него не сильно отличаются — всё достаточно стабильно, хотя параметр Energy Impact для RxSwift совсем немного выше, чем без него. Это я провёл некий «экспресс-анализ» на своёи рабочем проекте с RxSwift и на своём старом личном проекте без RxSwift, хотя, строго говоря, чтобы это замерить, нужно написать 2 приложения с одинаковыми функциями и замерять их параметры производительности. Если брать в целом, то приложения что с RxSwift, что без него, работают хорошо с точки зрения скорости работы и плавности. Может быть, вы предложите другие параметры для замеров?
3) Честно сказать — не задавался этим вопросом. Тут опять же, нужно написать 2 одинаковых приложения и замерить их вес в релизе. RxSwift сокращает количество кода, но сама библиотека имеет определенный вес, поэтому я думаю, что вряд ли будет какое-то сильное отличие этих параметров. Хотя, свечку не держал, как говорится, ничего не могу утверждать, только предполагаю :-)
4) Я использую RxSwift для UI-привязок, сетевой части, иногда я пишу Rx делегаты для сторонних библиотек, чтобы можно было реактивно обработать события делегатов. Но тут тоже нужно знать меру — если где-то можно сделать проще, не используя Rx (принцип KISS), то я так и сделаю.

Да, по поводу молодости технологии — согласен с Вами, но согласитесь — у неё огромные возможности, одно только избегание callback-hell и удобных UI-привязок чего стоит. Я думаю что за этим будущее и с нетерпением жду Вашу третью статью! :-)
Здравствуйте, Святослав )
Времени статьи отняли конечно порядочно, но просто захотелось хоть немного вернуть долг сообществу. Ведь сколько было за эти годы прочитано статей. Есть время разбрасывать камни, и время собирать камни )
Спасибо Вам за ответы.
По поводу вопросов 2 и 3. Для 3ей статьи я как раз создал приложение имеющее идентичный функционал но с разными архитектурными подходами. Производительность правда там особо не померяешь, не те нагрузки. А вот по поводу веса вполне можно было бы сказать, но нужно делать полноценный билд для App Store, там же собирается «по уму», то что не нужно отрезается и все в таком духе.
4) Золотые слова. Я как раз слишком увлекся Rx-фикацией, когда пытался сделать clear Rx везде где только можно. Урок был усвоен )

В последнее время я заинтересовался immutable моделями, судя по WWDC 2016, Apple тоже стала её продвигать. Но тут своих нюансов тоже хватает, как и в Rx. Если в итоге паззл в голове сложится — будет и 3я статья )
Коллега, hard work beats talent, так что сложится паззл в Вашей голове или нет — зависит только от вас. Я уверен в Ваших способностях, и вместе со всем сообществом жду Вашу третью статью! :-)
Надеюсь оправдать доверие партии )
Sign up to leave a comment.

Articles