Pull to refresh

Comments 14

Какой мин. target sdk для этой библиотеки? Не 4.2.2 же?)
Она уже работает в Google Play.
Я уверен вы, еще не слышали слово «Volley»

Ну почему же, слышал. Я сейчас пользуюсь библиотекой DataDroid уважаемого товарища foxykeep. Штука просто отличная, очень советую. Каждая операция выносится в свой класс, запросы формируются с помощью класса-билдера Request, который сам по себе очень удобен для передачи между процессами и экранами, так как является Parcelable. Можно легко сделать повторение запроса, просто переслав этот же Request.

Без допила конечно не обошлось, там он использует для своих Listeners WeakReference, которые мрут как мухи. Ну и совместимость с 2.3 подпилил, HttpUrlConnection почему-то не шлет Content-Lenght по умолчанию. Сделаю чуть позже форк.
Еще там вроде нет поддержки cookie.
А вот это уже серьезный минус(
Сам недавно написал библиотеку по работе с REST / JSON API. Таких библиотек кучи, хотелось свой велосипед с удобным интерфейсом.
https://github.com/kodart/Httpzoid

Для ленивых приложу пример использования:

Http http = HttpFactory.create(context);
http.post("http://example.com/users")
    .data(new User("John"))
    .send();


Тут мы имеем POST запрос на создание объекта User
Вся работа строится с использованием типизированых объектов а не JSONObject.
Если нужно будет прикурутить кеширование то думаю это не сложно.
UFO just landed and posted this here
Из него вытаскивается ConnectivityManager сервис для контроля online / offline статуса.
С прогрессбаром на мой взгляд как-то не очень все очевидно и прозрачно. Да и в статье не видно ссылки на документацию и описание всех фич библиотеки. Но в целом спасибо, погуглю, поизучаю :)
тоже использовал в нескольки проектах aQuery действительно оочень крутая библиотка. Volley пока какая то сырая и не очень функциональная, все равно придется дописывать.
Volley вызывет у меня чуть большее негодование, чем авторы, оставляющие в коде // TODO Auto-generated method stub.

Они предлагают вместо ImageView использовать NetworkImageView и вызывать public void setImageUrl(...). Это ужасный дизайн, когда вьюха привязывается к источнику данных.

Ещё про картинки. Они не используют inBitmap. Хотя это известный вопрос, ему даже посвящён выпуск DevBytes.

Затем, c json они делают ту же глупость, что и создатель android-async-http: объект загружается в фоне, но возвращается в UI потоке. Т.е. вся работа с json будет уже в main thread. Ну или же нужно запускать что-то (типа AsyncTask), что обработает его в фоне.

LruCache? Не, не слышали. Вообще, складывается впечатление, что у них была задача написать либу с минимальным использованием стандартных компонент Android. И свалить всё в кучу.

VolleyError(и его наследники), который на самом деле не Error, а Exception.

В общем, по моему мнению, эта либа — пример посредственного дизайна, и лучше бы она из недр Play Store не вылазила.
Как тут выше уже отмечали, у нее нет нормальной доки, и нормальный ресурс, где бы можно было посмотреть текущую стабильную версию и пр, Ficus сделать не озаботился, и это грустно.

Было бы интересно посмотреть сравнения с уже известными аналогичными либами, типа android-async-http или Android-query. А то неясно, чего уж там такого необычного, все перечисленное в том или ином виде есть в существующих решениях.
Sign up to leave a comment.

Articles

Change theme settings