Otto and Volley on orientation

2
votes

I am integrating both Volley and Otto in a project to handle all service calls and at the same time considering orientation changing. By using Otto i can unregister and re-register the bus on orientation change and then when the Volley returns a response i can then post back the result to the activity, this works perfectly. BUT i believe i have a gap that I have not yet handled and that is, What if i unregister my bus on pause, and then the response from volley is returned while the activity is still destroyed, volley then posts the response,(but no activity will get it), the activity is then resumed, bus is re-registered again and will receive not response since the broadcast has been already posted.

Is there any way to solve this? My first thought is to implement something like a how the Android sticky broadcast works? any other better ideas or thoughts?

1
androidandroid-orientationottoandroid-volley
What network request are you making that needs to be consistent between orientations? Volley was designed for very short network calls only, the network call should just be abandonned on orientation and re-submitted when the activity is recreated. – rperryng
Lets say a user clicks sign in and changes orientation, it is a rare case but it will happen, when the requested is returned back and posted back to the activity by Otto but the activity will not be there(since it will be recreating) – N Jay
Even then, just save the information in between rotations via a saveInstanceState() and resubmit the request. A log in is a very small network request and other approaches would require too much overhead for such a small benefit – rperryng
maybe i game the wrong example of a login but any other service that is called will cause an issue, and you cannot save the information on saveInstanceSate() because your data will not be returned to the activity in the first place. see the link i added before and you will understand the issue exactly – N Jay

1 Answers

3
votes

If the activityids match, the actual APIResult is posted to the bus so the Activity can receive it like normal. If it doesn't match, then it is as if the event wasn't handled at all. For Otto, this results in a DeadEvent that wraps the Object that wasn't handled. APIService listens for DeadEvents and hangs on to ones containing an APIResult or APIResult.ActivityProxy. When an Activity registers to the bus, APIService posts all DeadEvents with the same activityid the bus so the Activity can receive the results.

Answer found here.