mishamhoyan Oct 24 2014 at 10:40

Droidutils — набор решений, которые ускоряют разработку приложений под Android

7 min

20K

Programming*Development of mobile applications*Development for Android*

From sandbox

+13

Comments 36

AllexIn Oct 24 2014 at 10:46

приходилось делать одну и туже роботу

Простите, что придираюсь, но как-же повторное использование кода?
Разве не предполагается, что один раз решив какую-то задачу в следующий вы будете использовать тоже самое уже готовое решение?
Мне кажется у любого разработчика со временем появляется свой «Droidutils», который состоит из универсальных решений созданных ранее.

selenite Oct 24 2014 at 13:26

Проблема Java в том, что этот «свой Droidutils» нельзя свести до уровня header-only библиотеки, нужно таскать в проект дополнительные jar'ы (которые сперва нужно собрать), плюс порой отдавать клиентам полный код (что вредно с точки зрения трат времени на code review).

имхо, иногда лучше иметь свою библиотеку в виде разрозненных .java в выделенном неймспейсе, иногда лучше использовать Apache'вские либы, и… иногда стоит махнуть рукой и взять чужой DroidUtils, раз в нем есть именно то, что нужно ).

hamsterksu Oct 24 2014 at 10:49

A Retrofit и GSON вам не нравятся?
а для асинхронности есть groundy

mishamhoyan Oct 25 2014 at 11:46

Да они хорошие, но хотелось сделать что-то подобное самому, плюс это интересный опыт.

GreyCat Oct 24 2014 at 10:51

У меня стойкое впечатление, что Droidutils почти полностью повторяет Volley, который весь из себя такой рекомендованный Google, активно форсируется на всяких I/O и т.д.

Tishka17 Oct 24 2014 at 11:50

Мне кажется, ваш кастомный семафор будет работать неправильно. Например, после проверки наличия таска в мапе он может быть туда добавлен или удален из другого потока.

if (!mRunningTask.containsKey(taskTag)) {
    semaphore = new Semaphore(1);
} else {
    semaphore = mRunningTask.get(taskTag);
}
semaphore.acquire();
mRunningTask.put(taskTag, semaphore);

А кроме того, сам HashMap не потоко-безопасен.

mishamhoyan Oct 25 2014 at 11:38

Вы правы по поводу не потоко-безопасной HashMap, нужно пофиксить.

Sicness Oct 24 2014 at 11:51

А почему бы Вам не собрать jar и не залить в центральный репозитоий maven?

mishamhoyan Oct 25 2014 at 11:39

Хорошая идея.

ren_h Oct 24 2014 at 11:57

Я немного отстал и пока пишу json парсеры вручную для каждого класса. Скажите, пожалуйста, использование подобных библиотек для парсинга не сильно тормозит работу приложения? Ну то есть понятно, что, наверное, в какой-то степени тормозит, но критично ли это?

andreich Oct 25 2014 at 10:19

Тормозит, так как там рефлексия, но вы не заметите разницу.
Так что смело можете использовать. А скорость и удобство при разработке вы почувствуете.

Moxa Oct 25 2014 at 11:23

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

mishamhoyan Oct 25 2014 at 11:53

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

Artem_zin Oct 24 2014 at 12:15

JSON — Gson
Http — OkHttp + Retrofit или свой слой с OkHttp
Многопоточность — PriorityJobQueue, RxJava, но тут у меня свое

andreich Oct 25 2014 at 10:20

Многопоточность хорошо реализует RoboSpice

mishamhoyan Oct 25 2014 at 18:11

Не знаю как с многопоточностью, но для роботы с http не советую эту библиотеку. Она использует сервис для выполнения работы, а этот сервис использует биндинг для подключения к Activity, таким образом они могут синхронно общаться. Что не очень то и удобно для выполнения запросов. Когда мы закрываем Activity, она отключается от сервиса, в этот момент мы можем выполнять запрос, результаты которого мы не узнаем.

Divers Oct 26 2014 at 22:43

Асинхронно они общаются.

mishamhoyan Oct 27 2014 at 11:30

Вы правы. Это я ошибся.

andreich Oct 27 2014 at 08:42

Там все выполняется асинхронно, результат кидается через callback.
Когда activity закрывается, кто вам мешает остановить запрос?
Если не верите на слово, вот тут рассмотрены три паттерна, robospice реализует паттерн A, хотя при необходимости использование можно упростить до обычного callback общения.

mishamhoyan Oct 27 2014 at 11:35

Есть ситуации когда нужно, что бы запрос выполнился до конца и результат записался в базу или кеш, независимо от того закрывается activity или нет.

andreich Oct 27 2014 at 11:41

Да, согласен, и это делается.
Я пользуюсь RoboSpice и у меня не зависимо от состояния активити все сохраняется в базу.

jaleel Oct 27 2014 at 10:49

Асинхронно.
Можно использовать кэшируемые запросы, тогда при следующем запросе данные сразу загрузятся. Но это не очень безопасно.
Вариант еще написать менеджер запросов, который будет отслеживать доставку ответов.

andreich Oct 27 2014 at 11:42

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

jaleel Oct 27 2014 at 12:27

Ключ где то хранить надо :) Тут от требований к безопасности зависит.

andreich Oct 27 2014 at 12:29

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

jaleel Oct 27 2014 at 13:00

Если очень хочется, то и генерацию можно подсмотреть. 100% безопасный случай — ничего не хранить на устройстве.

andreich Oct 27 2014 at 13:54

если следовать вашей логике то и не передавать ничего

jaleel Oct 27 2014 at 14:09

Такой кейс — приложение, с аккаунтами пользователя, у каждого аккаунта сотни тысяч на счету. Будете ли вы хранить эти данные в кэше на Android-устройстве?

andreich Oct 27 2014 at 14:11

Вас никто не заставляет кэшировать, я описал возможность работы без кэша

jaleel Oct 27 2014 at 14:19

Так у меня в предложении про безопасность и кэшируемые запросы. И про них мы вроде в ветке говорим? :)

andreich Oct 27 2014 at 14:21

да, верно, я просто отредактировал по невнимательности, обратно вернуть не смог.
Если по сабжу, коли хранить данные в принципе не безопасно, то речь о кэше даже и заводить не стоит :)