If your work isn’t tied to a particular screen and should continue even if the user navigates away, the view model scope isn’t what you should be using; you should be using something with a lifecycle that isn’t tied to the screen, this is pretty easy to do
I think the GlobalScope is great for this, I’d think that’s what it was designed for.
Wouldn’t this still mean that as everything, including things initialized in Application, are killed when the app is put to background and killed by the system; then the store state is still lost across process death / low memory condition?
It appears that there was a strange bug involving this which was fixed in 4.2.1, so based on that, if you register a change listener on a RealmList field, you should be notified if the items are modified inside of it. But you must make sure you keep a strong reference to the RealmList.
Ah, context :D I’d love to read a post that explains in such detail why not to use
it all over the place
P.S. hey, you’re the guy who wrote ViewPropertyObjectAnimator. Awesome library and I use it a lot, thanks!
I often see that people misuse Dagger then blame it for “being so complex”, however if that’s not the case then it’s always up to which one is a more suitable tool for your requirements and your team and what problems you want to solve and which not.
While it is true that over time, recommendations have been shifting and changing (and now we have +1 new annotation just to reduce the boilerplate for
@BindsInstance that already came from bringing that in in 2.9 saying “but module constructor params are bad” (wtf)); but Dagger on its own is pretty cool, and saying it’s a “huge pile of mess” is naive.