Why integrate Lifecycle
Lifecycle is almost already a standard library for Android development, LiveData, ViewModel and even coroutines have extensions for Lifecycle, and without a doubt we are integrating with it in order to keep up with the trend. Data Adapter in order to better management on the other hand, we all know that Adapter has a onDetachedFromRecyclerView method, the Adapter from RecyclerView unbundling of time is called, but have you ever noticed a detail, After the Activity onDestroy doesn’t trigger onDetachedFromRecyclerView, instead, is that you take the initiative to call RecyclerView. Adapter = null is called only when, So that’s a big reason why I want to integrate With Lifecycle.
How do you integrate?
Why are there arrayLifeObservers? Because the framework itself extends animation, radio, multiple options, and so on, any extended functionality can be monitored for life cycle callbacks, for example
This is my extended animation list, which is a constant animationArray cache, why should I keep it when the current page is onDestroy? Just clean it up and free up memory in time. That’s why we have an observer model, right
Finally, we integrated the LifecycleAdapter into the framework
Just to give you a little bit of detail, this BaseAdapter was ViewHolderCacheAdapter, and it was refactored into BaseAdapter, so it’s easier to extend inheritance, so it’s more appropriately named. Let BaseAdapter inherit LifecycleAdapter to implement arrayLifeObservers
Then implement onStateChanged function, life cycle in ON_DESTROY calls, recyclerView. Adapter = null, trigger onDetachedFromRecyclerView finally
Then release all caches and dependencies
Does the ViewModel layer also need Lifecycle?
Answer: Yes
When implementing a ViewModel, it is inevitable that there will be some cache, which is stored in the object of the ViewModel. When releasing the cache, we can clear it completely, as shown in the following figure:
This makes it easy to be collected by the garbage collector, reducing dependencies and improving the efficiency of collection. Where does the ViewModel lifecycle come from? See figure
Why use a new LifecycleViewModel here? Partly because of the open close principle, partly because of the interface isolation, which really makes sense, and then let DefaultViewModel implement LifecycleViewModel
Finally, call onStateChanged to ViewModel within the ListAdapter lifecycle and check whether the ViewModel inherits from LifecycleViewModel. If not, no processing is required
Override BaseAdapter onStateChange in ListAdapter to notify ViewModel of life cycle changes. When was Adapter added to the life cycle observation?
In the previous dynamic extension into function, we only need to add such a piece of code, isn’t it easy? The goal is also to keep the framework extensible, and we can call our extensions without implementing a LifecycleAdapter without problems.
conclusion
Well, that’s life cycle integration, hopefully that’s helpful.
The project address
Github.com/ibaozi-cn/R…
The author
I the principal
- Jane books www.jianshu.com/u/77699cd41…
- The nuggets juejin. Cn/user / 131597…
- Personal websites: Jetpack.net.cn, ibaozi.cn