Comments 36
приходилось делать одну и туже роботу
Простите, что придираюсь, но как-же повторное использование кода?
Разве не предполагается, что один раз решив какую-то задачу в следующий вы будете использовать тоже самое уже готовое решение?
Мне кажется у любого разработчика со временем появляется свой «Droidutils», который состоит из универсальных решений созданных ранее.
+1
Проблема Java в том, что этот «свой Droidutils» нельзя свести до уровня header-only библиотеки, нужно таскать в проект дополнительные jar'ы (которые сперва нужно собрать), плюс порой отдавать клиентам полный код (что вредно с точки зрения трат времени на code review).
имхо, иногда лучше иметь свою библиотеку в виде разрозненных .java в выделенном неймспейсе, иногда лучше использовать Apache'вские либы, и… иногда стоит махнуть рукой и взять чужой DroidUtils, раз в нем есть именно то, что нужно ).
имхо, иногда лучше иметь свою библиотеку в виде разрозненных .java в выделенном неймспейсе, иногда лучше использовать Apache'вские либы, и… иногда стоит махнуть рукой и взять чужой DroidUtils, раз в нем есть именно то, что нужно ).
+1
A Retrofit и GSON вам не нравятся?
а для асинхронности есть groundy
а для асинхронности есть groundy
+5
Мне кажется, ваш кастомный семафор будет работать неправильно. Например, после проверки наличия таска в мапе он может быть туда добавлен или удален из другого потока.
А кроме того, сам HashMap не потоко-безопасен.
if (!mRunningTask.containsKey(taskTag)) {
semaphore = new Semaphore(1);
} else {
semaphore = mRunningTask.get(taskTag);
}
semaphore.acquire();
mRunningTask.put(taskTag, semaphore);
А кроме того, сам HashMap не потоко-безопасен.
0
А почему бы Вам не собрать jar и не залить в центральный репозитоий maven?
0
Я немного отстал и пока пишу json парсеры вручную для каждого класса. Скажите, пожалуйста, использование подобных библиотек для парсинга не сильно тормозит работу приложения? Ну то есть понятно, что, наверное, в какой-то степени тормозит, но критично ли это?
0
Тормозит, так как там рефлексия, но вы не заметите разницу.
Так что смело можете использовать. А скорость и удобство при разработке вы почувствуете.
Так что смело можете использовать. А скорость и удобство при разработке вы почувствуете.
+1
Я когда то сам вручную парсил и скажу что это очень затратно по времени. Даже если вы потеряете немного в скорости из-за рефлексии, это намного практичнее использовать готовые парсеры, либо напишите свой.
+1
JSON — Gson
Http — OkHttp + Retrofit или свой слой с OkHttp
Многопоточность — PriorityJobQueue, RxJava, но тут у меня свое
Http — OkHttp + Retrofit или свой слой с OkHttp
Многопоточность — PriorityJobQueue, RxJava, но тут у меня свое
+5
Не знаю как с многопоточностью, но для роботы с http не советую эту библиотеку. Она использует сервис для выполнения работы, а этот сервис использует биндинг для подключения к Activity, таким образом они могут синхронно общаться. Что не очень то и удобно для выполнения запросов. Когда мы закрываем Activity, она отключается от сервиса, в этот момент мы можем выполнять запрос, результаты которого мы не узнаем.
0
Асинхронно они общаются.
0
Там все выполняется асинхронно, результат кидается через callback.
Когда activity закрывается, кто вам мешает остановить запрос?
Если не верите на слово, вот тут рассмотрены три паттерна, robospice реализует паттерн A, хотя при необходимости использование можно упростить до обычного callback общения.
Когда activity закрывается, кто вам мешает остановить запрос?
Если не верите на слово, вот тут рассмотрены три паттерна, robospice реализует паттерн A, хотя при необходимости использование можно упростить до обычного callback общения.
0
Асинхронно.
Можно использовать кэшируемые запросы, тогда при следующем запросе данные сразу загрузятся. Но это не очень безопасно.
Вариант еще написать менеджер запросов, который будет отслеживать доставку ответов.
Можно использовать кэшируемые запросы, тогда при следующем запросе данные сразу загрузятся. Но это не очень безопасно.
Вариант еще написать менеджер запросов, который будет отслеживать доставку ответов.
0
А чем не безопасны кэшируемые запросы?
Просто нужно правильно задавать ключ для кэша.
Просто нужно правильно задавать ключ для кэша.
0
Ключ где то хранить надо :) Тут от требований к безопасности зависит.
0
Ключ генерируется определенным образом для получения нужного кэшированного запроса, его нигде хранить не надо.
Кэш хранится в sqlitе базе, к которой есть доступ только у вашего приложения.
Кэш хранится в sqlitе базе, к которой есть доступ только у вашего приложения.
0
Если очень хочется, то и генерацию можно подсмотреть. 100% безопасный случай — ничего не хранить на устройстве.
0
если следовать вашей логике то и не передавать ничего
0
Такой кейс — приложение, с аккаунтами пользователя, у каждого аккаунта сотни тысяч на счету. Будете ли вы хранить эти данные в кэше на Android-устройстве?
0
Вас никто не заставляет кэшировать, я описал возможность работы без кэша
0
тоже потихоньку пилю свою либу https://github.com/wizzardo/Tools, мой json-парсер, кстати, в несколько раз быстрее gson'а
0
Зачем вообще создавать DroidUtils, когда есть Retrofit, JobQueue, GSON и другие проверенные библиотеки.
+1
Sign up to leave a comment.
Droidutils — набор решений, которые ускоряют разработку приложений под Android