I have a recyclerview that loads a set of items which mainly display an image. I retrieve this items in the background, in batches of 100. I load the images using Picasso. Images are quite big, but I resize them using fit().
Whenever the screen is loaded or refreshed using SwipeRefreshLayout, the UI blocks for less than a second, but enough to be noticeable. If I dont load the images but put just the text, then the UI block does not happen.
I put logging lines on Picasso and on every refresh the 100 images are retrieved, but I would guess Picasso is working in a background thread?
Adapter:
#ActivityScope
class LimitableListAdapter #Inject constructor() : RecyclerView.Adapter<LimitableListAdapter.ViewHolder>() {
private var events: MutableList<Event> = mutableListOf()
private var itemClick: ((Event, View) -> Unit)? = null
override fun onBindViewHolder(holder: ViewHolder, position: Int) {
val binding : ItemVideoGridScoreBinding = holder.binding
var viewModel = binding.viewModel
val event = events[position]
//Unbind old viewModel if we have one
viewModel?.unbind()
// Create new ViewModel, set it, and bind it
viewModel = EventViewModel(event)
binding.viewModel = viewModel
viewModel.bind()
holder.setClickListener(itemClick)
}
override fun getItemCount(): Int = events.size
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
val binding = DataBindingUtil.inflate<ItemVideoGridScoreBinding>(
LayoutInflater.from(parent.context),
R.layout.item_video_grid_score,
parent,
false
)
return ViewHolder(binding)
}
fun updateEvents(events: List<Event>, stride: Int) {
var size = this.events.size
Timber.w("Updating with: " + events.joinToString(",", transform = { e -> e.id.toString() }))
this.events = events.toMutableList()
notifyDataSetChanged()
/*if (size == 0) {
Timber.w("branch 1")
var mutableList = events.toMutableList()
if(mutableList.size == 0)
return
mutableList.add(Event.mockEvent(stride))
this.events.addAll(mutableList)
notifyDataSetChanged()
} else {
if (size > 2) {
Timber.w("branch 2.1")
this.events.addAll(size - 1, events.toMutableList())
notifyItemRangeChanged(size-1, events.size)
}
else {
Timber.w("branch 2.2")
this.events.addAll(size, events.toMutableList())
notifyItemRangeChanged(size, events.size)
}
}*/
Timber.i("New list is: " + this.events.joinToString(",", transform = { e -> e.id.toString() }))
}
fun clearList(){
this.events.clear()
notifyDataSetChanged()
}
fun setClickListener(itemClick: ((Event, View) -> Unit)?) {
this.itemClick = itemClick
}
class ViewHolder(val binding: ItemVideoGridScoreBinding) : RecyclerView.ViewHolder(binding.root) {
fun setClickListener(callback: ((Event, View) -> Unit)?) {
binding.viewModel.clicks().subscribe() {
callback?.invoke(binding.viewModel.event, itemView)
}
}
}
}
BindingUtils:
#BindingAdapter({"app:coverUrl"})
public static void loadCover(ImageView view, String imageUrl) {
Picasso p = Picasso.with(view
.getContext());
p.setIndicatorsEnabled(true);
p.load(imageUrl)
.fit()
.centerInside()
.error(R.drawable.ic_broken_image)
.into(view);
}
}
xml:
(...)
<ImageView
android:id="#+id/event_cover"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:scaleType="centerCrop"
app:coverUrl="#{videoItem.cover}"
tools:src="#drawable/img"
/>
(...)
Assuming you are not able to create thumbnails on the server side (which would be the easiest solution), my suggestion would be to go with one of the following
Using a local drawable as a Placeholder. This will not block the UI thread and the image can load in the background. Behaviour will be similar to how Instagram behaves when you load the grid of images. Something like below.
p.load(imageurl).placeholder(R.drawable.localFile).fit().centerInside().error(R.drawable.ic_broken_image).into(view)
Use Glide. Glide does have powerful capability to create Thumbnails. And you can load the Thumbnails into the view much faster than the full images.
Resizing several big images takes some time. While Picasso does caching over the resized images, the first time it will still need to resize every one (and subsequent times it will just use the resized ones on the cache, thus taking less time).
Also, using fit can take more time than just using resize because it needs to calculate the size depending on the layout. If you can calculate the static size yourself (just once) and then use resize it should improve loading times.
But most of the times, it would be better if your server could send you smaller images/thumbnails when previewing, and then a full size image if you want to see it on some detail screen.
As you are loading 100 images and as you mentioned images are big,
so it will block the UI Thread for sure, if you want to avoid this so You can resize the images with Picasso:
Picasso.with(context)
.load(-yourImgURL-)
.resize(450, 200) // resizes image to desired dimensions here
.into(-yourImageView);
Related
When I click on an image within a RecyclerView, I try to enlarge it. So far everything works wonderfully. The only problem I have now is that the image of its output position is always the same. In other words, if I click on the 3rd picture, the 2nd picture enlarges with the correct content but in the wrong position. The same applies to the click on the 1st picture.
This is my AdapterDetail.kt class:
class AdapterDetail(val context: Context, private val listImg:ArrayList<String>,private var listen: CustomerAdapter.OnItemClickListener): RecyclerView.Adapter<AdapterDetail.MyCustomViewHolder>() {
...
inner class MyCustomViewHolder(view: View):RecyclerView.ViewHolder(view){
val preview_img:ImageView = view.findViewById(R.id.preview_img)
fun bind(item: String){
imgView = itemView.findViewById(R.id.preview_img)
imgView.setOnClickListener {
listen.onItemClick(imgView, adapterPosition)
}
}
}
override fun onBindViewHolder(holder: MyCustomViewHolder, position: Int) {
val item = listImg[position]
holder.bind(item)
}
In the Activity i need the correct ImageView position to inflate them:
adapterDetail = AdapterDetail(this, house!!.objektBilder as ArrayList<String>,object: CustomerAdapter.OnItemClickListener{
override fun onItemClick(view: View, position: Int) {
//Here I need the ImageView that was clicked on in the RecyclerView
var viewPosition = view
zoomImageFromThumb(viewPosition, house!!.objektBilder!![position])
}
})
Sounds like an off by one issue, since you are using the deprecated adapterPosition. Use bindingAdapterPosition instead, which gives the position as RecyclerView sees it:
listen.onItemClick(imgView, bindingAdapterPosition)
I've created an adapter (extending ListAdapter with DiffUtil.ItemCallback) for my RecyclerView. It's an ordinary adapter with several itemViewTypes, but it should be smth like cyclic, if API sends flag and dataset size is > 1 (made by overriding getItemCount() to return 1000 when conditions == true).
When I change app locale through app settings, my fragment recreates, data loads asynchronously (reactively, several times in a row, from different requests, depending on several rx fields, which causes data set to be a combination of data on different languages just after locale is changed (in the end all dataset is correctly translated btw) (make it more like synchronous is not possible because of feature specifics)), posting its values to LiveData, which triggers updates of recycler view, the problem appears:
After last data set update some of the views (nearest to currently displayed and currently displayed) appear not to be translated.
Final data set, which is posted to LiveData is translated correctly, it even has correct locale tag in its id. Also after views are recycled and we return back to them - they are also correct.
DiffUtil is computed correctly also (I've tried to return only false in item callbacks and recycler view still didn't update its view holders correctly).
When itemCount == list.size everything works fine.
When adapter is pretending to be cyclic and itemCount == 1000 - no.
Can somebody explain this behaviour and help to figure out how to solve this?
Adapter Code Sample:
private const val TYPE_0 = 0
private const val TYPE_1 = 1
class CyclicAdapter(
val onClickedCallback: (id: String) -> Unit,
val onCloseClickedCallback: (id: String) -> Unit,
) : ListAdapter<IViewData, RecyclerView.ViewHolder>(DataDiffCallback()) {
var isCyclic: Boolean = false
set(value) {
if (field != value) {
field = value
}
}
override fun getItemCount(): Int {
return if (isCyclic) {
AdapterUtils.MAX_ITEMS // 1000
} else {
currentList.size
}
}
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
return when (viewType) {
TYPE_0 -> Type0.from(parent)
TYPE_1 -> Type1.from(parent)
else -> throw ClassCastException("View Holder for ${viewType} is not specified")
}
}
override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
when (holder) {
is Type0 -> {
val item = getItem(
AdapterUtils.actualPosition(
position,
currentList.size
)
) as ViewData.Type0
holder.setData(item, onClickedCallback)
}
is Type1 -> {
val item = getItem(
AdapterUtils.actualPosition(
position,
currentList.size
)
) as ViewData.Type1
holder.setData(item, onClickedCallback, onCloseClickedCallback)
}
}
}
override fun getItemViewType(position: Int): Int {
return when (val item = getItem(AdapterUtils.actualPosition(position, currentList.size))) {
is ViewData.Type0 -> TYPE_0
is ViewData.Type1 -> TYPE_1
else -> throw ClassCastException("View Type for ${item.javaClass} is not specified")
}
}
class Type0 private constructor(itemView: View) :
RecyclerView.ViewHolder(itemView) {
fun setData(
viewData: ViewData.Type0,
onClickedCallback: (id: String) -> Unit
) {
(itemView as Type0View).apply {
acceptData(viewData)
setOnClickedCallback { url ->
onClickedCallback(viewData.id,)
}
}
}
companion object {
fun from(parent: ViewGroup): Type0 {
val view = Type0View(parent.context).apply {
layoutParams =
LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)
}
return Type0(view)
}
}
}
class Type1 private constructor(itemView: View) :
RecyclerView.ViewHolder(itemView) {
fun setData(
viewData: ViewData.Type1,
onClickedCallback: (id: String) -> Unit,
onCloseClickedCallback: (id: String) -> Unit
) {
(itemView as Type1View).apply {
acceptData(viewData)
setOnClickedCallback { url ->
onClickedCallback(viewData.id)
}
setOnCloseClickedCallback(onCloseClickedCallback)
}
}
companion object {
fun from(parent: ViewGroup): Type1 {
val view = Type1View(parent.context).apply {
layoutParams =
LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)
}
return Type1(view)
}
}
}
}
ViewPager Code Sample:
class CyclicViewPager #JvmOverloads constructor(
context: Context,
attrs: AttributeSet? = null,
defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr),
ICyclicViewPager {
private val cyclicViewPager: ViewPager2
private lateinit var onClickedCallback: (id: String) -> Unit
private lateinit var onCloseClickedCallback: (id: String) -> Unit
private lateinit var adapter: CyclicAdapter
init {
LayoutInflater
.from(context)
.inflate(R.layout.v_cyclic_view_pager, this, true)
cyclicViewPager = findViewById(R.id.cyclic_view_pager)
(cyclicViewPager.getChildAt(0) as RecyclerView).apply {
addItemDecoration(SpacingDecorator().apply {
dpBetweenItems = 12
})
clipToPadding = false
clipChildren = false
overScrollMode = RecyclerView.OVER_SCROLL_NEVER
}
cyclicViewPager.offscreenPageLimit = 3
}
override fun initialize(
onClickedCallback: (id: String) -> Unit,
onCloseClickedCallback: (id: String) -> Unit
) {
this.onClickedCallback = onClickedCallback
this.onCloseClickedCallback = onCloseClickedCallback
adapter = CyclicAdapter(
onClickedCallback,
onCloseClickedCallback,
).apply {
stateRestorationPolicy = RecyclerView.Adapter.StateRestorationPolicy.PREVENT_WHEN_EMPTY
}
cyclicViewPager.adapter = adapter
}
override fun setState(viewPagerState: CyclicViewPagerState) {
when (viewPagerState.cyclicityState) {
is CyclicViewPagerState.CyclicityState.Enabled -> {
adapter.submitList(viewPagerState.pages) {
adapter.isCyclic = true
cyclicViewPager.post {
cyclicViewPager.setCurrentItem(
// Setting view pager item to +- 500
AdapterUtils.getCyclicInitialPosition(
adapter.currentList.size
), false
)
}
}
}
is CyclicViewPagerState.CyclicityState.Disabled -> {
if (viewPagerState.pages.size == 1 && adapter.isCyclic) {
cyclicViewPager.setCurrentItem(0, false)
adapter.isCyclic = false
}
adapter.submitList(viewPagerState.pages)
}
}
}
}
Adapter Utils Code:
object AdapterUtils {
const val MAX_ITEMS = 1000
fun actualPosition(position: Int, listSize: Int): Int {
return if (listSize == 0) {
0
} else {
(position + listSize) % listSize
}
}
fun getCyclicInitialPosition(listSize: Int): Int {
return if (listSize > 0) {
MAX_ITEMS / 2 - ((MAX_ITEMS / 2) % listSize)
} else {
0
}
}
}
Have tried not to use default itemView variable of RecyclerView (became even worse).
Tried to make diff utils always return false, to check if it calculates diff correctly (yes, correctly)
Tried to add locale tags to ids of data set items (didn't help to solve)
Tried to post empty dataset on locale change before setting new data to it (shame on me, shouldn't even think about it)
Tried do add debounce to rx to make it wait a bit before update (didn't help)
UPD: When I call adapter.notifyDatasetChanged() manually, which is not the preferred way, everything works fine, so the question is why ListAdapter doesn't dispatch notify callbacks properly in my case?
The issue with ListAdapter is that it doesn't clearly state that you need to supply a new list for it to function.
In other words, the documentation says: (and I quote the source code):
/**
* Submits a new list to be diffed, and displayed.
* <p>
* If a list is already being displayed, a diff will be computed on a background thread, which
* will dispatch Adapter.notifyItem events on the main thread.
*
* #param list The new list to be displayed.
*/
public void submitList(#Nullable List<T> list) {
mDiffer.submitList(list);
}
The key word being new list.
However, as you can see there, all the adapter does is defer to the DiffUtil and calls submitList there.
So when you look at the actual source code of the AsyncListDiffer you will notice it does, at the beginning of its code block:
if (newList == mList) {
// nothing to do (Note - still had to inc generation, since may have ongoing work)
if (commitCallback != null) {
commitCallback.run();
}
return;
}
In other words, if the new list (reference) is the same as the old one, regardless of their contents, don't do anything.
This may sound cool but it means that if you have this code, the adapter will not really update:
(pseudo...)
var list1 = mutableListOf(...)
adapter.submitList(list1)
list1.add(...)
adapter.submitList(list1)
The reason is list1 is the same reference your adapter has, so the differ exits prematurely, and doesn't dispatch any changes to the adapter.
Quite obscure, I know.
The solution, as pointed in many SO answers is to create a copy of the list itself.
Most users do
var list1 = mutableListOf(...)
adapter.submitList(list1)
var list2 = list1.toMutableList()
list2.add(...)
adapter.submitList(list2)
The call to toMutableList() creates a new list containing the items of list1 and so the comparison above if (newList == mList) { should now be false and the normal code should execute.
UPDATE
Keep in mind that a lot of developers make the mistake of...
var list = mutableListOf...
adapter.submitList(list)
list.add(xxx)
adapter.submitList(list.toList())
This doesn't work, because the new list you create, is referencing the same objects the adapter has. This means that both lists list and list.toList() are pointing to the same things despite being two instances of an ArrayList.
But the side-effect is that DiffUtil compares the items and they are the same, so no diff is dispatched to the adapter either.
The correct sequence is...
val list = mutableListOf(...)
adapter.submitList(list.toList())
// Make a copy first, so we can alter it as we please without the *current list held by the adapter* from being affected.
var modified = list.toMutableList()
modified.add(...)
adapter.submitList(modified)
After taking a look at your sample in GitHub, I was able to reproduce the issue. With only about 30-40 minutes of playing with it, I can say that I'm not 100% sure what component is not updating.
Things I've noticed.
The onBindViewHolder method is not called when you change the locale (except maybe the 1st time?).
I do not understand why the need to post to the adapter after you've submitted the list in the callback:
cyclicViewPager.setCurrentItem(
// Setting view pager item to +- 500
AdapterUtils.getCyclicInitialPosition(
adapter.currentList.size
), false
)
Why ? This means the user loses their current position.
Why not keep the existing?
I noticed you do cyclicViewPager.offscreenPageLimit = 3 this effectively disables the RecyclerView "logic" for handling changes, and uses instead the usual ViewPager state adapter logic of "prefetching/keeping" N (3 in your case) pages in "advance".
At first I thought this was causing issues, but removing it (which sets it to -1 which is the default and the "use RecyclerView" value, didn't make a big change (though I did notice some changes here and there, as in it would sometimes update the current one -but not the next ones within 2~3 pages).
The documentation says:
Set the number of pages that should be retained to either side of the currently visible page(s). Pages beyond this limit will be recreated from the adapter when needed. Set this to OFFSCREEN_PAGE_LIMIT_DEFAULT to use RecyclerView's caching strategy.
So I would have imagined that the default value would be aided by the ListAdapter and its DiffUtil. Doesn't seem to be the case.
What I did try (among a few other things) was to see if the issue was in the actual adapter (or at least the viewPager dependency on its adapter). I ran out of time (work!) but I noticed that if you do:
override fun setState(viewPagerState: CyclicViewPagerState) {
when (viewPagerState.cyclicityState) {
is CyclicViewPagerState.CyclicityState.Enabled -> {
// call initialize again, to recreate the adapter
initialize(this.onClickedCallback, this.onCloseClickedCallback)
adapter.submitList(viewPagerState.pages) {
adapter.isCyclic = true
// Setting vp item to ... (code omitted for brevity)
}
This works. It's theoretically less efficient as you're recreating the whole adapter, but in your example you're effectively creating an ENTIRE new set of data changing every ID, so in terms of performance, I'd argue this is more efficient as there's no need to recalculate changes and dispatch them, since to the eyes of the Diff Util, all the rows are different. By recreating the adapter, well... the VP has to reinit anyway.
I noticed this worked fine in your example.
I went ahead and added two more things, because the "silly" adapter cannot reliably tell you which position is the current... you can naively save it:
In CyclicViewPager:
var currentPos: Int = 0
init {
...
this.cyclicViewPager.registerOnPageChangeCallback(object : OnPageChangeCallback() {
override fun onPageSelected(position: Int)
currentPos = position
}
})
}
And then
is CyclicViewPagerState.CyclicityState.Enabled -> {
initialize(this.onClickedCallback, this.onCloseClickedCallback)
adapter.submitList(viewPagerState.pages) {
adapter.isCyclic = true
if (adapter.currentList.size <= currentPos) {
cyclicViewPager.setCurrentItem(currentPos, false)
} else {
cyclicViewPager.setCurrentItem(
// Setting view pager item to +- 500
AdapterUtils.getCyclicInitialPosition(
adapter.currentList.size
), false
)
}
}
}
This does work, but of course, you're recreating the entire VP adapter again, so it may not be desired.
At this point, I'd either need to spend much more time trying to figure out which part of VP, RV, or its dependencies is not "dispatching" the correct data. My guess would be somewhere around some silly ViewPager optimization combined with Android terribly unreliable View system, not picking a message in the queue; but I may be also terribly wrong ;)
I hope someone smarter and/or with more coffee in their system can find out a simpler solution.
(all in all, I found the sample project relatively easy to navigate, but the design of your data a bit convoluted, but... as it was a sample, it's hard to tell what "real-life" data structures you really have).
I'm trying to display a low-res image as a full tv background while loading the high quality image. With this solution I could avoid the Black-To-image blink effect.
My low-res image is loaded in a previous fragment and is stored in the cache.
I try to achieve this with Coil. I've seen there is a memoryCachePlaceholder, but I couldn't make it work with my solution. Any hint ?
requireContext().imageLoader.enqueue(ImageRequest.Builder(requireContext())
.data(myLowResUrl)
.crossfade(0)
.target(object : TransitionTarget {
override val drawable get() = showImageView!!.drawable
override val view get() = showImageView!!
override fun onSuccess(result: Drawable) {
showImageView?.setImageDrawable(result)
showImageView?.load(myHighResUrl) {
placeholderMemoryCacheKey(showImageView?.result?.request?.memoryCacheKey)
}
}
})
.build())
I have a recyclerview which shows a list of images in horizontal view. I want to show a gif around each imageview like an outline similar to instagram's story view.
Here is the code for loading the same.
GlideApp
.with(itemView.context).asGif()
.load(R.drawable.red)
.error(R.drawable.red)
.diskCacheStrategy(DiskCacheStrategy.DATA)
.into(ivBackground)
I tried adding this code on both places i.e. onCreateViewHolder as well as onBindViewHolder but the gif is not playing properly.
It only shows one frame at a time. If I pause current activity by pressing the back button and then from recent app menu, navigate back to the app, then it shows the next frame.
My gif is stored in the drawable folder and I have the exact same gif working properly in an activity/fragment.
Issue is it's not playing properly inside a recyclerview adapter.
This is the complete adapter class.
class LiveViewAdapter(
val context: Context,
val liveList: ArrayList<DataItem>,
private val listener: LiveViewAdapterListener
) :
RecyclerView.Adapter<LiveViewHolder>() {
private val inflater: LayoutInflater
interface LiveViewAdapterListener {
fun onLiveClicked(url: String)
}
init {
inflater = LayoutInflater.from(context)
}
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): LiveViewHolder {
val view = inflater.inflate(R.layout.item_live, parent, false)
return LiveViewHolder(view)
}
override fun getItemCount(): Int {
return liveList.size
}
override fun onBindViewHolder(holder: LiveViewHolder, position: Int) {
val requestOptions = RequestOptions().apply {
placeholder(R.mipmap.ic_launcher_round)
error(R.mipmap.ic_launcher_round)
}
val videoId = liveList[holder.adapterPosition].liveUrl?.substring(liveList[holder.adapterPosition].liveUrl?.lastIndexOf("=")!! + 1)
val imageUrl = "https://img.youtube.com/vi/$videoId/hqdefault.jpg"
Glide.with(context)
.load(liveList[position].liveUrl)
.apply(requestOptions)
.thumbnail(Glide.with(context).load(imageUrl))
.into(holder.ivLive)
holder.ivLive.setOnClickListener {
listener.onLiveClicked(liveList[holder.adapterPosition].liveUrl!!)
}
}
}
Glide version used
implementation 'com.github.bumptech.glide:glide:4.8.0'
kapt 'com.github.bumptech.glide:compiler:4.8.0'
UPDATE
I figured out that the above code works fine on android devices which have sdk version less than pie. On devices with android pie, it's not working properly.
Are you using roundedImageView or just native imageview ?
I met the same the same problem while using roundedImageView. I replace it with native ImageView, the gif play.
I just tried to use glide recyclerview integration and read a document about it and it said: "The RecyclerView integration library makes the RecyclerViewPreloader available in your application. RecyclerViewPreloader can automatically load images just ahead of where a user is scrolling in a RecyclerView", but I don't realise any difference between glide recyclerview integration and only glide, please explain what are advances of glide recyclerview integration? And how can I see the difference?
Here's my code:
GlideModule.kt
#GlideModule
class GlideModule : AppGlideModule() {
override fun applyOptions(context: Context?, builder: GlideBuilder?) {
val requestOp = RequestOptions.noAnimation()
.priority(Priority.LOW)
builder?.setDefaultRequestOptions(requestOp)
?.setLogLevel(Log.VERBOSE)
super.applyOptions(context, builder)
}
// Disable manifest parsing to avoid adding similar modules twice.
override fun isManifestParsingEnabled(): Boolean {
return false
}
}
MyPreloadModelProvide.kt
class MyPreloadModelProvide(val listUrls: List<String>, val context: Context) : PreloadModelProvider<Any> {
override fun getPreloadItems(position: Int): MutableList<Any> {
val url = listUrls.get(position)
if (TextUtils.isEmpty(url)) {
return Collections.emptyList();
}
return Collections.singletonList(url);
}
override fun getPreloadRequestBuilder(url: Any?): RequestBuilder<*>? {
return GlideApp.with(context)
.load(url)
}
}
MyAdapter.kt
class MyAdapter(val listUrl: List<String>, val context: Context) : RecyclerView.Adapter<MyViewHolder>() {
override fun getItemCount(): Int = listUrl.size
#SuppressLint("CheckResult")
override fun onBindViewHolder(holder: MyViewHolder?, position: Int) {
GlideApp.with(context)
.load(listUrl[position])
.into(holder?.imageView)
holder?.imageView?.setOnClickListener { Toast.makeText(context, listUrl[position], Toast.LENGTH_LONG).show() }
}
override fun onCreateViewHolder(parent: ViewGroup?, viewType: Int): MyViewHolder = MyViewHolder(LayoutInflater.from(parent?.context).inflate(R.layout.item, parent, false))
}
class MyViewHolder(view: View?) : RecyclerView.ViewHolder(view) {
var imageView: ImageView
init {
imageView = view!!.findViewById(R.id.img)
}
}
MainActivity.kt
class MainActivity : AppCompatActivity() {
private lateinit var preloadSizeProvider: ViewPreloadSizeProvider<Any>
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// glide
var listUrls = listOf(
"https://img.pokemondb.net/artwork/bulbasaur.jpg",
"https://img.pokemondb.net/artwork/ivysaur.jpg",
"https://img.pokemondb.net/artwork/komala.jpg",
"https://img.pokemondb.net/artwork/turtonator.jpg",
"https://img.pokemondb.net/artwork/togedemaru.jpg",
"https://img.pokemondb.net/artwork/mimikyu.jpg",
"https://img.pokemondb.net/artwork/nihilego.jpg",
"https://img.pokemondb.net/artwork/buzzwole.jpg",
"https://img.pokemondb.net/artwork/pheromosa.jpg",
"https://img.pokemondb.net/artwork/xurkitree.jpg",
"https://img.pokemondb.net/artwork/celesteela.jpg",
"https://img.pokemondb.net/artwork/kartana.jpg",
"https://img.pokemondb.net/artwork/guzzlord.jpg",
"https://img.pokemondb.net/artwork/necrozma.jpg",
"https://img.pokemondb.net/artwork/magearna.jpg",
"https://img.pokemondb.net/artwork/marshadow.jpg"
)
preloadSizeProvider = ViewPreloadSizeProvider<Any>()
val modelProvider = MyPreloadModelProvide(listUrls, this)
val preloader = RecyclerViewPreloader(GlideApp.with(this), modelProvider, preloadSizeProvider, 2 /*maxPreload*/)
// recycler view
recycler_view.layoutManager = LinearLayoutManager(this)
recycler_view.setHasFixedSize(true)
recycler_view.adapter = MyAdapter(listUrls, this)
// THERE ARE NO DIFFERENCES IF I COMMENT THIS LINE
recycler_view.addOnScrollListener(preloader)
}
}
THERE ARE NO DIFFERENCES IF I COMMENT THIS LINE
recycler_view.addOnScrollListener(preloader)
The RecyclerView integration library makes the RecyclerViewPreloader available in your application.
And RecyclerViewPreloader can automatically load images just ahead of where a user is scrolling in a RecyclerView.
Combined with the right image size and an effective disk cache strategy, this library can dramatically decrease the number of loading tiles/indicators users see when scrolling through lists of images by ensuring that the images the user is about to reach are already in memory.
To use the RecyclerView integration library, add a dependency on it in your build.gradle file:
compile ("com.github.bumptech.glide:recyclerview-integration:4.4.0") {
/*Excludes the support library
because it's already included by Glide.*/
transitive = false
}
The issue in your code is that you create preloadSizeProvider of type ViewPreloadSizeProvider, but you never call preloadSizeProvider.setView(...) on it. So it doesn't know the size of your target view, so it can't preload images in correct size, so you see no improvement.
I recommend first trying to make it work with fixed size. So instead of using ViewPreloadSizeProvider create FixedPreloadSizeProvider(WIDTH, HEIGHT) and make sure to use same size when loading images via Glide as such Glide.with(this).load(imageUri).override(WIDTH, HEIGHT).into(imageView);
If you want to check if it works, enable logging for both Glide requests like this (I used Java code there for my simplicity):
MyPreloadModelProvide.kt
class MyPreloadModelProvide(val listUrls: List<String>, val context: Context) : PreloadModelProvider<Any> {
override fun getPreloadRequestBuilder(url: Any?): RequestBuilder<*>? {
return GlideApp.with(context)
.override(250, 250)
.dontTransform()
.listener(new RequestListener<Drawable>() {
#Override
public boolean onLoadFailed(#Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
return false;
}
#Override
public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) {
Log.d("IMAGE PRELOAD", "onResourceReady() called with: model = [" + model + "], target = [" + target + "], dataSource = [" + dataSource + "]");
return false;
}
})
.load(url)
}
}
MyAdapter.kt
class MyAdapter(val listUrl: List<String>, val context: Context) : RecyclerView.Adapter<MyViewHolder>() {
override fun getItemCount(): Int = listUrl.size
#SuppressLint("CheckResult")
override fun onBindViewHolder(holder: MyViewHolder?, position: Int) {
GlideApp.with(context)
.load(listUrl[position])
.override(250, 250)
.dontTransform()
.listener(new RequestListener<Drawable>() {
#Override
public boolean onLoadFailed(#Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
return false;
}
#Override
public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) {
Log.d("IMAGE LOAD", "onResourceReady() called with: model = [" + model + "], target = [" + target + "], dataSource = [" + dataSource + "]");
return false;
}
})
.into(holder?.imageView)
holder?.imageView?.setOnClickListener { Toast.makeText(context, listUrl[position], Toast.LENGTH_LONG).show() }
}
}
And in logcat you should see that PRELOAD requests have dataSource = [LOCAL] or [RESOURCE_DISK_CACHE] and LOAD requests have dataSource = [MEMORY_CACHE].
It if works, great. Then you can rewrite it to use ViewPreloadSizeProvider. In that case you remove the fixed image size (.override(250,250)) from Glide requests and then don't forget to call preloadSizeProvider.setView(holder.imageView) for example in onCreateViewHolder method.
Suppose the user is scrolling a RecyclerView that loads large images, so, the user should wait the delay of loading the image before seeing it in the corresponding list item. RecyclerViewPreloader loads the images in advance, so when the user scrolls, there are already loaded and ere displayed instantly.
In your code you are using a small list, and a small maxPreload value, so you won't notice the difference of using RecyclerViewPreloader. To see it in action you should use a long list with many different images, and scroll fast with and without the preloader. Without the preloader you will see empty images until loaded, and with it, images should be displayed rapidly and smoothly.
My previous answer to this question was deleted, probably as from a quick glance of a moderator, it looks like it was totally unrelated, so I'll try and rephrase and add some meat.
Glide has a RecyclerView integration page that you might assume is the required way to get Glide working with an Android RecycerView. But it really just adds a memory cache preloader, which is a bit complicated to implement; the simple way of just adding Glide.with(view.context).load(url) into your RecyclerView onBindViewHolder works just as well and won't result in any memory leaks. And by default, Glide has a built in disk cache which works great.
So OP's question is what are the advantages of this memory preloader. The stated advantages are obvious, preloading images before the user scrolls to them.
But a better question is are the advantages worth the extra effort to get it working. This is a subjective question. It's only noticeable for users with slow Internet connections, and even then, I'm not sure it's worth the hassle. You've no idea where the user will scroll, you could preload images and then the user will scroll to the very bottom and images will need to be loaded new anyway. So IMO, it's not worth the hassle. But you'll have to make up your own mind.