То есть в такой ситуации надо делать тайп адаптер? А то мне прошлый разраб заложил как раз архитектуру с BaseResponse потому что сервер вместо ответа может вернуть поле error. А то мне что то очень не нравится иметь класс враппер для List<Object> и тд

То есть в такой ситуации надо делать тайп адаптер? А то мне прошлый разраб заложил как раз архитектуру с BaseResponse потому что сервер вместо ответа может вернуть поле error. А то мне что то очень не нравится иметь класс враппер для List<Object> и тд

https://youtu.be/t34AQlblSeE?t=27m56s

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

что это такое и какое отношение имеет к разработке под андроид?

Аргумент очень простой. Путь - это путь, параметры запроса - это параметры запроса, заголовки - это заголовки, и коды ошибок - это коды ошибок. Если на сервере ошибки не возникло, или она предусмотренная и обрабатываемая, то за каким рожном на уровне ЗАПРОСА её возвращать. Заверни в ответ.

А что значит «ошибки не возникло»? Если из базки пришёл пустой result set, это не ошибка? А если сервер должен сделать запрос на другой сервер и тот не удался, это не ошибка?

Первое - не ошибка. Второе - ошибка.

Тебе БД вместо пустого сета ошибку что ли выдаёт?

Ну, как упомянул @Harmonizr, можно также сделать типизированную обёртку

Если запрашиваешь список, то не ошибка. Если запрашиваешь одну сущность по айди, то ошибка и формат ответа удовлетворить невозможно.

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

сделать, чтобы удовлетворял — это выдать пользователя с пустым именем и минус одним другом?)

Мне сейчас от Бека на логин приходит что то вроде { status : ok, token : .... } Вот вряд ли этот вариант жизнеспособен ) Точнее он есть и работает, но это ли не ублюдство?

Нет, предусмотреть некое сообщение и код ошибки в базовом формате ответа.

Это что то вроде Result Success<T> Error ?

В этом треде имелась ввиду ситуация, тогда ответ приходит завёрнутый в объекте и на верхнем уровне может находиться какая-то метадата. В таких случае, можно сделать Result<T> { metadata: Metadata, body: T } А дальше, если не хотите видеть Result<T> в каждой сигнатуре в сервисе - то можно сделать type converter

HTTP уже предусмотрел, но тебя опять тянет велосипедить

ну оборачивайте все свичкейсами в три уровня, нет проблем.

Так у вас тоже будет этот свич кейс, так как вы же сами говорили про "ошибки сервиса", для которых уже нужно смотреть на код

у меня это будет иф-элс в единственном экземпляре, и на уровне обработки ответа определенные действия в зависимости от внутреннего кода ошибки.

Вы осуждаете подход, даже не зная, как он работает

Как правильно называются классы которые в поле другого класса? inner? Мне прогуард ломает тут, не знаю как правильно прогуглить

окей, без сарказма, расскажи как, может я и правда чего не знаю.

Ретрофит по дефолту на все кроме 2хх кидает экспкшн

не правда

опять не правда

может, развёрнуто пояснишь?)

в ретрофит нужно проверять через isSuccessful хттп код

в ретрофит нужно проверять через isSuccessful хттп код

в ретрофит нужно проверять через isSuccessful хттп код

И ваще если список запрашиваешь, то, уж извините меня, totalCount и currentPage это обязательно. Предположим, у вас там список со скроллом, а в БД пятьсот тысяч значений. Ну мотни вниз, чо, андроиду-то памяти хватит на это говно? Или будем БД вкручивать, подзасрем одним экраном всю флешку?

эм, текущая страница — это параметр запроса, а не ответа. с total не сталкивался, идея хорошая, в заголовках ему самое место

супернеудобно, что нужно из ответа повыковыривать урлы, прежде чем сходить на них

Этого что мало? Не пойму что ему не нравится то

Этого что мало? Не пойму что ему не нравится то

Дело в том, что урлы то и не нужны совсем Ты знаешь на какой ты странице, ты знаешь сколько их всего Зачем остальное - я без понятия

Остальное - для пагинации в стиле "нажми на номер страницы, чтобы перейти". Там как раз есть кнопки последней и первой страницы обычно

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

эм, текущая страница — это параметр запроса, а не ответа. с total не сталкивался, идея хорошая, в заголовках ему самое место

не из того parent'а удаляешь, видать

Ну там ещё есть, обычно, и по 2 страницы от текущей туда и сюда Я все равно не понимаю для чего все это нужно

Потому что в FrameLayout от позиции разные вью, а делать fixed size тупо (список большой)

а какой тогда смысл Single<List> делать? Ты шо консюмеру отдашь? Pair?

а какой тогда смысл Single<List> делать? Ты шо консюмеру отдашь? Pair?

Вы про Single из rx?

да

вопрос был в том почему Single<List<UserInfo>> полный феншуй, а Single<UserInfosResponse> - гавно.

Ребят, а sha256 ключ от названия пакета не зависит?