Дублированиения на диске нет. Дублирование в памяти можно предотвратить с помощью опции конфигурации ImageLoaderConfiguration.denyCacheImageMultipleSizesInMemory().
А проблема с первым проходом при match_parent/wrap_content — да, существует. На данный момент выход — это вызывать ImageLoader через post():
А исходникик открывать не будете? Честно говоря, что-то стремно встравиать jar-ку неизвестного содержания себе в проект. К тому не самую лекговесную.
«Дырка» эта, для удаления Profit-кнопки которая, по-моему, не очень очевидное назначение имеет. Иконку мусорного ведра на ней изобразить может? К тому же в демо приложении на Galaxy Nexus этот black-hole вообще не показывается.
На самом деле никто не запрещает сначала сдать 1Z0-804. Просто сертификат по OCPJP 7 вы не поолучите, пока не сдадите и 1Z0-803 тоже. В книжке «Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804 and 1Z0-805» так написано.
Спасибо за включение Universal Image Loader в список самых полезных библиотек, только лучше вместо ссылки на мой профиль в Google+ поставить ссылку на GitHub репозиторий. А то перекруглили уже меня.
Если я вызову startService() снова, то и onHandleIntent() у меня вызовется снова (после того как отработает предыдущий). Это что, тогда сколько раз я экран поверну, столько раз и и выполнится onHandleIntent()? Зачем мне такая логика?
Тут как раз и начинается самое интересное. Чтобы его сохранять, надо пихать его в Bundle (в onSaveInstanceState()). ResulReceiver у нас Parceable, так что проблем вроде как нет. Осатается только считать его из savedInstanceState в onCreate().
Вот только я столкнулся с таким непредвиденным поведением: после долгого нахождения приложения в бэкграунде (свернутом сосотянии), когда активити будет разрушена для освобождения памяти для других приложений, а потом когда вы снова развернете ее — то вызовется onCreate(), но в savedInstanceState будет лежать не ваш AppResultsReceiver, а почему-то простой ResultsReceiver. И при попытке закастить его к своему классу получите ClassCastException.
Почему так просходит — для меня загадка. Но именно из-за этого я отказался от ResultReceiver'ов, и стал использовать LocalBroadcastManager как замену. Надо сказать более удобно и менее геморно стало.
Хм, взяли мы запустили сервис, повернули экран — и все поломалося. Ресивер уже создался новый, а в сервисе лежит старый. Такие ситуации никак не хэндлятся у вас?
Здравствуйте, при создании ImageView в конструктор надо передавать текущий Activity, а не getApplicationContext().
Если у вас аллергия на большое количество классов — используйте jar-ку.
MemoryCacheKeyGenarator) — это в ближайших планах.А проблема с первым проходом при match_parent/wrap_content — да, существует. На данный момент выход — это вызывать ImageLoader через post():
«Дырка» эта, для удаления Profit-кнопки которая, по-моему, не очень очевидное назначение имеет. Иконку мусорного ведра на ней изобразить может? К тому же в демо приложении на Galaxy Nexus этот black-hole вообще не показывается.
Что интересно www.theultimateandroidlibrary.com упорно не желает добавлять Universal-Image-Loader в список. Где-то там подвох кроется…
Ctrl+L — показать строку по номеру.
Вот только я столкнулся с таким непредвиденным поведением: после долгого нахождения приложения в бэкграунде (свернутом сосотянии), когда активити будет разрушена для освобождения памяти для других приложений, а потом когда вы снова развернете ее — то вызовется onCreate(), но в savedInstanceState будет лежать не ваш AppResultsReceiver, а почему-то простой ResultsReceiver. И при попытке закастить его к своему классу получите ClassCastException.
Почему так просходит — для меня загадка. Но именно из-за этого я отказался от ResultReceiver'ов, и стал использовать LocalBroadcastManager как замену. Надо сказать более удобно и менее геморно стало.
Если у вас аллергия на большое количество классов — используйте jar-ку.
if (androidSmartphone.isAvailable()) {
throwInTrash(androidSmartphone);
buy(«Nokia 3310»);
}
Или вы только для российской аудитории приложения пишете?