mishamhoyan24 окт 2014 в 06:40

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

7 мин

20K

Разработка мобильных приложений * Программирование * Android *

Из песочницы

+13

Комментарии 36

AllexIn 24 окт 2014 в 06:46

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

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

selenite 24 окт 2014 в 09:26

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

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

hamsterksu 24 окт 2014 в 06:49

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

mishamhoyan 25 окт 2014 в 07:46

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

GreyCat 24 окт 2014 в 06:51

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

Tishka17 24 окт 2014 в 07:50

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

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

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

mishamhoyan 25 окт 2014 в 07:38

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

Sicness 24 окт 2014 в 07:51

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

mishamhoyan 25 окт 2014 в 07:39

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

ren_h 24 окт 2014 в 07:57

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

andreich 25 окт 2014 в 06:19

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

Moxa 25 окт 2014 в 07:23

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

mishamhoyan 25 окт 2014 в 07:53

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

Artem_zin 24 окт 2014 в 08:15

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

andreich 25 окт 2014 в 06:20

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

mishamhoyan 25 окт 2014 в 14:11

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

Divers 26 окт 2014 в 19:43

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

mishamhoyan 27 окт 2014 в 08:30

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

andreich 27 окт 2014 в 05:42

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

mishamhoyan 27 окт 2014 в 08:35

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

andreich 27 окт 2014 в 08:41

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

jaleel 27 окт 2014 в 07:49

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

andreich 27 окт 2014 в 08:42

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

jaleel 27 окт 2014 в 09:27

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

andreich 27 окт 2014 в 09:29

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

jaleel 27 окт 2014 в 10:00

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

andreich 27 окт 2014 в 10:54

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

jaleel 27 окт 2014 в 11:09

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

andreich 27 окт 2014 в 11:11

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

jaleel 27 окт 2014 в 11:19

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

andreich 27 окт 2014 в 11:21

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