Comments 21
-
Спасибо за труд. Что касается PDF-ки, то Adobe Acrobat Reader утверждает что она испорченная.
Странно. Вы скачиваете с гитхаба и смотрите на PC, Маке или iPad? PDF я ровнял в деме Acrobat DC под маком. Открывается встроенным просмотрщиком.
На PC у меня стоит PDF-XChange View, показывает прекрасно даже при заходе через браузер в предпросмотре. Поставил читалку от Adobe — тоже все читает.
Попробуйте обновить Acrobat или сменить PDF читалку и отпишитесь о результате, если не сложно. А может PDF скачался ошибками?
На PC у меня стоит PDF-XChange View, показывает прекрасно даже при заходе через браузер в предпросмотре. Поставил читалку от Adobe — тоже все читает.
Попробуйте обновить Acrobat или сменить PDF читалку и отпишитесь о результате, если не сложно. А может PDF скачался ошибками?
Спасибо!
Спасибо за статью.
Скажите, в чем создавали графики?
Скажите, в чем создавали графики?
Спасибо
Автор, ты большой молодец! Это действительно большой труд и лично от себя говорю огромное спасибо! Я сам писал статью про RxSwift и рад, что в русскоязычном сообществе наконец-то подхватили эту тему :-)
Спасибо на добром слове. Тема действительно очень интересная, но при этом относиться к ней нужно с осторожностью. Мало того что нужно переформатировать в голове подход к написанию кода, есть очень много нюансов: потоки, использование последних значений, горячая/холодная подписка и т.д. Чтобы написать качественный материал, нужно самому хорошо во всем разобраться. Сейчас отвлекся на другие проекты, но надеюсь попозже осветить RxSwift и со стороны GUI.
хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка
Сильное заявление, конечно, особенно учитывая тот факт, что RAC 4 использует куда больше плюшек языка, несмотря на то что «вырос с Objective-C».
Мог быть не прав, судил по тем обзорам, что были на момент выбора.
Если у вас есть опыт, — может поделитесь чем RAC лучше RxSwift? Я думаю всем будет интересно, мне в первую очередь.
Если у вас есть опыт, — может поделитесь чем RAC лучше RxSwift? Я думаю всем будет интересно, мне в первую очередь.
- RAC рзаличает холодные и горячие observables на уровне типов, их нельзя просто так скомпоновать, что увеличивает количество ошибок, обнаруживаемых компилятором. Однако RxSwift считает это недостатком, и это можно понять, так как это увеличивает порог входа для новых разработчиков.
- RAC позволяет задать тип ошибки сигнала. Если использовать тип NoError (специальный тип, фактически enum без единого кейза) в качестве типа ошибки, получим compile-time гарантию того, что этот сигнал действительно никогда не завершится ошибкой. Это очень важно, например, для UI-биндингов.
В целом сложно однозначно сказать, что хуже, а что лучше. RxSwift — почти идетничный порт Rx.NET, что дает пользователям RxSwift возможность легко переносить опыт с других платформ, на которых есть Rx, это однозначно плюс.
RAC же, в свою очередь, пытается решить проблемы оригинального Rx, предоставить больше compile-time гарантий ценой ухода от оригинального Rx API.
Да, про эти два различия я уже встречал. И пожалуй по обоим пунктах мне более импонирует подход RAC.
Т.к. все что отслеживается на уровне компиляции — благо.
В RxSwift нужно при работе с GUI постоянно перехватывать ошибки и наворачивать защиту вида catchError и возвращать другой Observable, или полноценно работать с retry/retryWhen.
С другой стороны — переносимость Rx меня и подкупила.
Но вы упомянули про большее количество Swift плюшек у RAC 4, не моли бы вы привести примеры, если не сложно.
Т.к. все что отслеживается на уровне компиляции — благо.
В RxSwift нужно при работе с GUI постоянно перехватывать ошибки и наворачивать защиту вида catchError и возвращать другой Observable, или полноценно работать с retry/retryWhen.
С другой стороны — переносимость Rx меня и подкупила.
Но вы упомянули про большее количество Swift плюшек у RAC 4, не моли бы вы привести примеры, если не сложно.
Мы выложили RxMarbles в опенсорс https://github.com/RxSwiftCommunity/RxMarbles.
Sign up to leave a comment.
RxSwift шпаргалка по операторам (+ PDF)