search

digitalbuddha / RxStarter

Showcase Project using RxJava and RxDAO pattern
75 stars 5 forks source link

handling orientation changes #8

Open fahimk opened 9 years ago

fahimk commented 9 years ago
  1. right now, the image search presenter looks like it's reloading results on an orientation change (even though it may be reading from cache) the experience is jarring
  2. rotating the device from history goes back to search
digitalbuddha commented 9 years ago

Will figure out a better strategy. I'd like to avoid needing a static or globally scoped presenter that persists config changes. Open to suggestions.

fahimk commented 9 years ago

I think the most common ways for a traditional list view a retained fragment or saving something in the instance state. I personally don't like either of those solutions. I stumbled across this article today:

http://doridori.github.io/Android%20App%20Architecture-%20Lifecycle%20Events%20and%20Asynchronicity/

There's a library that's been created based on that, I'm looking into it right now:

https://github.com/doridori/Dynamo

RxStarter is one of the few RxJava examples I've found that addresses orientation changes with respect to the network calls (at least that's what I understood from your blogpost about the RxCommander pattern, still looking through the RxJava code). I'm curious to know what you've traditionally used for handling orientation changes in UI.

digitalbuddha commented 9 years ago

Definitely would like to avoid the fragments route. 2 is solvable with another icicle'd variable. I see no reason why reading data from cache, if optimized well, would be any slower than saving/reading from instance state. For use cases I've actually had at work I never had to reload and render 64 images coming from 8 different endpoints, this example was an odd use case that tried to jam a lot of concepts together. Personally, I've had success caching models rather than UI state and reloading when the activity gets recreated. Nucleus is another library that takes a novel approach to the decoupling problem. Thanks for sharing your PRs, I'll polish up some rough edges shortly :-)

fahimk commented 9 years ago

I agree that reading the model from the cache is a good approach. I think the issue for me is more UX based which I've seen in a lot of apps, where even though as developers we know the activity is being re-created, the user should have a seamless experience as if the same activity is being presented at a different angle. It could just boil down to an icicle'd variable with the scroll offset, but since it's a LinearLayout it will be a little harder than that. I don't know if this issue is beyond the scope of this example, but let me know what you think.

btw, thanks for the awesome blog posts and for sharing this example, makes it a lot easier to get into RxJava!

digitalbuddha commented 9 years ago

I'll play with it tomorrow with a grid view/adapter, should make it better from UX standpoint. The less android classes for state management the easier everything will be to unit test. I'll add roboelectric tests this week as well. On Apr 19, 2015 12:21 AM, "Fahim" notifications@github.com wrote:

I agree that reading the model from the cache is a good approach. I think the issue for me is more UX based which I've seen in a lot of apps, where even though as developers we know the activity is being re-created, the user should have a seamless experience as if the same activity is being presented at a different angle. It could just boil down to an icicle'd variable with the scroll offset, but since it's a LinearLayout it will be a little harder than that. I don't know if this issue is beyond the scope of this example, but let me know what you think.

btw, thanks for the awesome blog posts and for sharing this example, makes it a lot easier to get into RxJava!

— Reply to this email directly or view it on GitHub https://github.com/digitalbuddha/RxStarter/issues/8#issuecomment-94233630 .

fahimk commented 9 years ago

Sounds good, let me know if there's anything I can help with.