True, but this is a whole different approach. In this one, let’s say a view comes to foreground and requests data and you make a network call (no cache available) to get it, now user moves to a different view and you need to make another network call along with the previous one still running in parallel. Which means you are sharing resources fully meant for foreground view for the view on which user might not go back again.

IMO the moment view is destroyed all the resources including network call should be stopped and resources should be released.

Again, even this approach will not solve the view reloading issue. View reloading will be faster, second time onwards but still it’s reloading, and if you use a loading animation user will notice it.