• ImageLoaders: Продолжение
    0
    Не могли бы вы скинуть лог этого native exception'а в личку?
  • ImageLoaders: Продолжение
    0
    Последний — это 1.9.1?
  • Экономим память: Picasso vs UniversalImageLoader
    0
    Кстати, какие версии библиотек использовались в бенчмарке? Это важно.
  • Экономим память: Picasso vs UniversalImageLoader
    0
    Да, пока это такой workaround. Хорошего решения, встроенного в текущую логику библиотеки, я пока не придумал.
  • Экономим память: Picasso vs UniversalImageLoader
    0
    Да, возможность конфигурить извне memoryCacheKey (типа MemoryCacheKeyGenarator) — это в ближайших планах.
  • Экономим память: Picasso vs UniversalImageLoader
    +1
    Дублированиения на диске нет. Дублирование в памяти можно предотвратить с помощью опции конфигурации ImageLoaderConfiguration.denyCacheImageMultipleSizesInMemory().

    А проблема с первым проходом при match_parent/wrap_content — да, существует. На данный момент выход — это вызывать ImageLoader через post():
    imageView.post(new Runnable() {
        @Override
        public void run() {
            imageLoader.displayImage(...);
        }
    });
    
  • Встраиваем опросы для пользователей Android-приложений
    0
    А исходникик открывать не будете? Честно говоря, что-то стремно встравиать jar-ку неизвестного содержания себе в проект. К тому не самую лекговесную.
    «Дырка» эта, для удаления Profit-кнопки которая, по-моему, не очень очевидное назначение имеет. Иконку мусорного ведра на ней изобразить может? К тому же в демо приложении на Galaxy Nexus этот black-hole вообще не показывается.
  • Подготовка к экзамену Oracle Java SE 7 Programmer II (1Z0-804)
    0
    На самом деле никто не запрещает сначала сдать 1Z0-804. Просто сертификат по OCPJP 7 вы не поолучите, пока не сдадите и 1Z0-803 тоже. В книжке «Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804 and 1Z0-805» так написано.
  • Ресурсы, о которых должен знать каждый Android-разработчик
    +1
    Спасибо за включение Universal Image Loader в список самых полезных библиотек, только лучше вместо ссылки на мой профиль в Google+ поставить ссылку на GitHub репозиторий. А то перекруглили уже меня.
  • Ресурсы, о которых должен знать каждый Android-разработчик
    0
    Тогда уж и androidweekly.net/toolbox
    Что интересно www.theultimateandroidlibrary.com упорно не желает добавлять Universal-Image-Loader в список. Где-то там подвох кроется…
  • Eclipse for Java Developers. Навигация и редактирование
    +3
    Ctrl+Shift+L вы имели в виду.
    Ctrl+L — показать строку по номеру.
  • Общение между потоками через ResultReceiver
    0
    Как член класса? Не очень красивое решение.
  • Общение между потоками через ResultReceiver
    0
    Если я вызову startService() снова, то и onHandleIntent() у меня вызовется снова (после того как отработает предыдущий). Это что, тогда сколько раз я экран поверну, столько раз и и выполнится onHandleIntent()? Зачем мне такая логика?
  • Общение между потоками через ResultReceiver
    +1
    Тут как раз и начинается самое интересное. Чтобы его сохранять, надо пихать его в BundleonSaveInstanceState()). ResulReceiver у нас Parceable, так что проблем вроде как нет. Осатается только считать его из savedInstanceState в onCreate().

    Вот только я столкнулся с таким непредвиденным поведением: после долгого нахождения приложения в бэкграунде (свернутом сосотянии), когда активити будет разрушена для освобождения памяти для других приложений, а потом когда вы снова развернете ее — то вызовется onCreate(), но в savedInstanceState будет лежать не ваш AppResultsReceiver, а почему-то простой ResultsReceiver. И при попытке закастить его к своему классу получите ClassCastException.

    Почему так просходит — для меня загадка. Но именно из-за этого я отказался от ResultReceiver'ов, и стал использовать LocalBroadcastManager как замену. Надо сказать более удобно и менее геморно стало.
  • Общение между потоками через ResultReceiver
    0
    Хм, взяли мы запустили сервис, повернули экран — и все поломалося. Ресивер уже создался новый, а в сервисе лежит старый. Такие ситуации никак не хэндлятся у вас?
  • Выбор Pull To Refresh инструмента
    0
    Ага, я смотрю вы очень внимательно прочитали статью…
  • Создаём новый проект для Android по-новому
    +1
    Спасибо за информацию по проблеме с support-package. Так бы сидел, мучался.
  • Универсальный ImageLoader для Android
    0
    Здравствуйте, при создании ImageView в конструктор надо передавать текущий Activity, а не getApplicationContext().
    Если у вас аллергия на большое количество классов — используйте jar-ку.
  • Простой шаринг c Facebook и Twitter
    0
    Какое отношение данный «deprecated share» имеет к шарингу в Android?
  • Простой шаринг c Facebook и Twitter
    +2
    Посколько Android в этой стране никому не нужен, то:
    if (androidSmartphone.isAvailable()) {
        throwInTrash(androidSmartphone);
        buy(«Nokia 3310»);
    }

    Или вы только для российской аудитории приложения пишете?
  • .NET компонент — Tree View с поиском
    0
    > P.S Автор поста, мой брат SergejSh — все вопросы и замечания к нему.

    Ну да, моторолер не мой... Приведите код в порядок.
  • Выбор Pull To Refresh инструмента
    0
    Кстати, реализация от Криса Бэйнса — единственная, которая до сих пор активно развивается (последний коммит был буквально позавчера). Остальные же либо обошлись одноразовым коммитом, либо забросили развитие проекта.
  • Универсальный ImageLoader для Android
    0
    Не особо дружу с Maven'ом, но не в этом дело.
    На текущий момент, я считаю, проект не готов в качестве отдельной библиотеки. Сейчас многие параметры ImageLoader'а можно настраивать под себя (они у меня сейчас в Constants). А когда все задуманные фичи будут завершены, и я придумаю красивый способ предоставить настройку ImageLoader'а не меняя исходники — тогда, почему бы и нет, можно и в maven-репозиторий закинуть.
  • Универсальный ImageLoader для Android
    0
    Хотя нет, судя по всему этот проект и есть родоначальник всего. А индус (по упомянутой мной ссылке) просто скопипастил его в свой блог.
  • Универсальный ImageLoader для Android
    0
    При превышении размера кэша удаляется «сильная» ссылка на Bitmap, но остается «слабая». Я не знаю, когда Bitmap будет собран сборщиком, а до этого делать recycle() ему нельзя, т.к. он может быть ещё переиспользован. В окончательном стирании Bitmap'ов полагаюсь на Android, ибо
    "This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap."
  • Универсальный ImageLoader для Android
    0
    Ох, давно это было, но смотрели мы на эти опции. Почему-то не заюзали, возможно были причины. Но, пожалуй, ещё раз поизучаю этот вопрос. Спасибо.
  • Универсальный ImageLoader для Android
    0
    Этот проект (LazyList), как и мой, базировался на LazyImageLoader'e (ссылку на который я давал в статье). Там (в LazyList) приведена в порядок работа с потоками, своя реализация кэша, и другие мелкие улучшения. Кое-что там действительно можно подсмотреть :) Но, на мой взгляд, UniversalImageLoader более гибкий, ибо с этой целью он разрабатывается.
  • Универсальный ImageLoader для Android
    0
    Всмысле приостановить загрузку пока список мотается? Зачем?
  • Универсальный ImageLoader для Android
    0
    Работать будет, но не совсем нормально :)
    Спасибо за замечания, все учту.
  • Универсальный ImageLoader для Android
    0
    Если я правильно понял первый пункт — это для того если уменьшенная картинка уже есть в кэше в памяти, а мы хотим ее отобразить в ImageView больше предыдущего по размерам. Справедливо. В «дисковом» кэше хранятся полноразмерные картинки, если что.
    Насчет второго пункта, гугло-доки гласят:
    «Note: the decoder will try to fulfill this request, but the resulting bitmap may have different dimensions that precisely what has been requested. Also, powers of 2 are often faster/easier for the decoder to honor. „
    И я боюсь что декодирование до точных размеров снизит производительность, может даже и существенно. Тут, пожалуй, можно отдать данное решение на выбор разработчику, что для него приоритетнее: память или процессорное время.
  • Универсальный ImageLoader для Android
    0
    Хотя для совместмости с GPL пожалуй BSD будет лучше.
  • Универсальный ImageLoader для Android
    0
    Под лицензией «юзай, изменяй, распространяй без ограничений» :) Но для формальности пусть будет Apache License v2.0.
  • Универсальный ImageLoader для Android
    0
    Кстати любые предложения по улучшению функциональности ImageLoader'а приветствуются. Возможно кто-то имеет свои use-case'ы, для которых ImageLoader можно адаптировать.
  • Универсальный ImageLoader для Android
    0
    Проекту есть куда развиваться, поэтому это возможно его будущие фичи :) Спасибо, надо будет подумать над их реализацией.