мне показалось, что там больше на минусы акцент, чем не устроил retrofit и rxjava,это библиотеки избавляют от тонны боли, расширяемые интегрируемые. Все в статье перемешано.
Акцент сделан на негатив.

у констрейинта в преимуществах не хватает пункта про анимации, вся эта плоская верстка, не просто так сделана. Там же стоит упомянуть про МоушинЛейаут

Там написано, чем не устровил. Ни от чего они не избавляют.

А это один пункт или два отдельных? Анимации без моушена там тоже получше работают?

ну типа транзишин менеджер + констреинт, но щас уже на первый план выходит МЛ

Понял, спасибо.

Я вам ответил выше, писать руками многопоточно, это очень очень больно, хороший надежный http клиент-это очень здорово.
Если вы считаете, что jake warton написал то, что не решает проблем это ваше право, тем более что вы админ, но мир с вами не согласен. :)

Что очень больно, фьючу на экзекьютор закинуть? Какой бред.
Хороший HTTP-клиент — это правда здорово, поэтому я и рекомендую всем OkHttp.
Джейк — живой человек, у него есть удачные и неудачные решения (помянём баттерНайф).
Как мило, что админство ставится мне в вину.

Простите за многабукаф :)

а можешь разбить на отдельные сообщения? Тогда отвечать будет проще

ок, сейчас

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

Первый основной флоу - регистрация пользователя в системе. Регистрация включает в себя генерацию пары ключей, шифрование данных, несколько хттпс реквестов, парсинг пушей с фаербейса, сохранение данных пользовательской учётки (типа юзернейм и юзерсид для секьюрческих целей) в бд.

Вопросы у меня такие:
1. Насколько критично выпиливать зависимости от ырыкса и уретрофита по шкале от 1 до 100, учитывая, что первое сильно замедлит перенос существующего функционала в отдельный модуль, который по задумке должен быть общим для нас и для разрабов у клиента, а времени и знаний альтернатив не очень много?

2. Нормально ли тянуть туда рум и вообще зашивать ответственность за сохранение данных для регистрации в библиотеку, или есть какие-то принципиальные вещи, по которым этого лучше не делать?

3. Как лучше настроить проброс пушей внутрь либы? Есть ли какие-то проработанные практики, или тупо в онресиве и методе получения токена просить проставлять какие-то перехватчики?

4. Какие ещё могут быть подводные камни?

Что мешает перенести в модуль вместе с ырыксом и ретрофитом? А потом, когда фичи сделаны, играться с выпиливанием.

2. Нормально, но нужно предоставить клиенту библиотеки выбор, в каком файле и в каких таблицах (или с каким префиксом) хранить.

@Harmonizr по поводу абзаца про нул и рх: суть в том, что эта "фп парадигма" (еще называют Railway oriented programming) подразумевает, что в success ветке всегда будут корректные значения, иначе флоу уходит в fail. т.е. нулл маппится в дефолт значение или emptyList или бросается какая-нибудь ошибка типа MyNotFoundError. Ветвление на success\fail происходит на ранней стадии (у источника данных), а делать проверки на нул в колбеке success - это уже поздно, двойная проверка получается.

null вполне может быть успешным результатом.
К ФП это отношения не имеет.

Вдруг кодеры у клиента посмотрят и скажут "ну нафиг, у них артефакт за 10 мегабайт, стопудняк дурачок туда фреймворков натаскал", вот этого боюсь))