Библиотека Android Data Processor для легкого построения REST запросов и их обработки

[Terranz]

а как насчёт в запрос добавить куку?
у меня есть сервис, который авторизует по куке

[lordtao]

Теперь есть возможность при построении добавить HttpContext

[lordtao]

Теперь есть возможность при построении добавить HttpContext

[sapl]

Спасибо за труд. Действительно хорошо бы иметь подобный готовый инструмент.

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

[lordtao]

Если происходит исключение то оно передается в объекте сообщения Handler вместо подготовленного объекта

private Handler getLoginHandler () {
return new Handler () {

	@ Override
	public void handleMessage (Message msg) {
	if (msg.what == ProcessingCentre.SUCCESS) {
		LoginResult resultObject = (LoginResult) msg.obj;
		...
		} Else {
			Exception ex = (Exception) msg.obj;
			if (ex instanceof IOException) {
				Log.e("IO Error", ex);
			} else {
				Log.w ("Can't login");
			}
		}
	};
	
	}
}

Обработка различных кодов ошибки по отдельности сейчас не предусмотрена. В конечном итоге нам обычно требуется лишь два варианта — запрос успешен либо нет. Ошибки самого парсинга можно обрабатывать при реализации интерфейсов ...DataInterface в методе public void fillFrom… Тем не менее я подумаю как лучше сделать подобную обработку.

[sapl]

В конечном итоге нам обычно требуется лишь два варианта — запрос успешен либо нет

Не совсем так. Логика обработки ошибок разная.
Не всегда достаточно Да или Нет.

Например, HTTP ошибки 401,403 — часто используются согласно протоколу.
Т.е требуется авторизация и нужно показать это в интерфейсе.
Ошибка 500 на сервере, это не тоже самое что SocketTimeout
В первом случае это косяк на сервере, во втором пользователю можно сообщить
что соединение оборвалось и стоит попробовать еще раз.
Исключения работы с сетью также могут быть разные — Например при GPRS соединении могут вываливаться NoHttpResponseException,
в случае которых можно сразу делать вторую попытку отправки запроса.

Может вам просто сделать свой тип исключения — для всех HTTP кодов ошибок?

[lordtao]

Спасибо за совет! Доделаем

[lordtao]

Сделал немного по другому. Теперь HTTP код высылается в msg.what и может обрабатываться в Handler

[sapl]

Спасибо.
Будем пробовать

[lordtao]

Не люблю аннотации

[falstaf]

Существующие библиотеки помогающие в построении запросов и их обработку не слишком меня устраивали по ряду причин.

Гм. Интересно. Можете в двух словах написать, чем вас не устроили retrofit, Spring Android (RestTemplate), Robospice, OkHttp — качественные и гораздо более функциональные решения? И чем ваша библиотека лучше? Ну, помимо того, что своё — всегда милее. :)

[lordtao]

Как я уже сказал выше я не люблю пользоваться аннотациями. Это личное мнение не для спора. Поэтому некоторые из перечисленных библиотек не подходят. Далеко не все проекты требуют привлечения сильных но немного громоздких библиотек типа Spring Android или Robospice. Наиболее подходящим для моих целей был бы OkHttp, но там нет готовой возможности Mumultipart путем добавления данных как части запроса через один простой метод. По крайней мере так было некоторое время назад.
Цель создания моей библиотеки — легковесное конструирование типичных запросов, выполнение и получение данных для дальнейшей обработки.

[falstaf]

Как я уже сказал выше я не люблю пользоваться аннотациями.

Но ведь аннотации — это часть языка, и довольно удобная часть языка. Для отказа от них должны быть какие-то весомые причины.

Вообще, в случае с REST — маппинги URL, параметры, сериализация/десериализация параметров запросов и респонсов в целом — всё это очень удобно описывать неким подобием DSL, коим, в данном случае, и выступают аннотации. Вы же предлагаете те же параметры GET-запроса вбивать как гвозди явными вызовами addGetParam(), вместо того, чтобы просто и элегантно передать аннотированную сущность предметной области.

Далеко не все проекты требуют привлечения сильных но немного громоздких библиотек типа Spring Android или Robospice.

Предрелизный запуск ProGuard'а с включённой опцией shrinking'а решает эту проблему, оставляя ровно то, что использовалось в приложении. Т.е. от нескольких мегабайт того же Robospice останется от силы килобайт 100-150. И, сдаётся мне, гибкость и мощь этих библиотек и удобство дальнейшего развития приложения вполне стоят этих лишних 100-150 килобайт. Впрочем, это лишь моё мнение и я могу ошибаться. :)

[vovkab]

Проблема с multipart была решена больше года назад:
github.com/square/okhttp/issues/50

В качестве тренировки конечно классно написать свою библиотеку, но вот если начать использовать ее, то:
1. сильно многословная, что бы привести все к меняемому виду(retrofit), нужно будет писать кучу оберток.
2. почему для результата нужно создавать именно хэндлер, не поимеем ли мы кучу утечек с таким «калбэком»?
3. конвертер нельзя просто взять и подключить, его нужно обязательно делать базовым классом для всех респонзов + тягать парсер библиотеку(jackson, gson etc) кругом
4. парсер класс, создается еще до того как известен ответ от сервера
5. куча ручной работы по передачи параметров и чтению результатов

К сожалению оно того не стоит, есть куча библиотек, с апи по лучше, из не упомянутых добавлю: volley, ion.
Но retrofit, имхо, один из лучших, он именно решает ежедневные проблемы, заметно уменьшает количество писанины, так еще и тестировать достаточно легко.

p.s. официальный андроид стиль, рекомендует использовать 4 пробела для исходных кодов. Если вы решили использовать табы, то возможно стоит научиться ими пользоваться, у вас сорсы везде разъехались. Классическая проблема при использовании табов.

[cry_san]

А чем это лучше jsoup?

[falstaf]

Ну, jsoup всё же немного из другой оперы.

[Divers]

Тем же чем чёрный лучше сладкого )