Office Hours — Today, October 20

← Tuesday, October 18

Oct 20
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Hi, Mark!
Let me paste in my question...
View paste (2 more lines) 
I'm wondering how to display a progress indicator while a Rest request is being processed. 

I'm using an IntentService to make the Rest requests. The requests are initiated by activities in response to onClick events, and LocalBroadcastManagers in the activities receive a response from the IntentService when the request has completed. I want to use a modal progress dialog (e.g. ProgressDialog) as the progress indicator to prevent navigating to a different activity or carrying out other operations while waiting for the Rest requests to complete.

A naive approach would be to display the progress dialog from the activity just before the IntentService is started, and to dismiss the dialog in the BroadcastReceiver in the activity when the BroadcastReceiver receives a message indicating that the Rest request has completed. But if the device is rotated after the request has been initiated but before it has completed, an additional mechanism would be needed to keep track of the state of the Rest request.

I have wondered about using a DialogFragment instead of a ProgressDialog to better handle rotation, but would want to make sure that this wouldn't result in memory leaks since the Dialo
...
Mark M.
OK, give me a moment to absorb this
"But if the device is rotated after the request has been initiated but before it has completed, an additional mechanism would be needed to keep track of the state of the Rest request" -- use a DialogFragment
Steve S.
OK.
Not sure the whole thing made it in. Let me try pasting the rest.
Mark M.
"but would want to make sure that this wouldn't result in memory leaks since the DialogFragment would presumably hold a reference to the activity that put up the DialogFragment" -- no, it shouldn't
unless you add one
Steve S.
View paste 
I have wondered about using a DialogFragment instead of a ProgressDialog to better handle rotation, but would want to make sure that this wouldn't result in memory leaks since the DialogFragment would presumably hold a reference to the activity that put up the DialogFragment.

What is a robust way to display a modal progress indicator while a Rest request is being processed that will accommodate the activity lifecycle and avoid memory leaks?
4:00 PM
Steve S.
ok. so just use a regular DialogFragment?
Mark M.
yes
though if you could figure out a way to avoid a blocking dialog in the first place, that'd be my preferred approach
Steve S.
ok.
I'm not sure that I have everything worked out to accommodate cases where the user navigates away from an activity before the rest activity has completed. That's the reason for using a blocking dialog.
Mark M.
um, OK
Steve S.
But it sounds like going forward I need to work that out.
Mark M.
blocking dialogs aren't the most user-friendly things around
Steve S.
ok
what happens if the rest request completes while the device is being rotated? How would I know to dismiss the DialogFragment?
Mark M.
your LocalBroadcastManager message will either be picked up before or after the configuration change is complete
and at either point, it can safely dismiss the dialog
Steve S.
ok
Mark M.
so long as the IntentService does not care whether the dialog goes away within milliseconds, you should be fine
4:05 PM
Steve S.
So the strategy you're recommending is the following as I understand it. Display the DialogFragment from the activity in response to relevant onClick events, and dismiss the DialogFragment in the BroadcastReceiver. And that's it. Is that right?
Mark M.
in general, that should be fine
Steve S.
Great. That's very helpful.
Mark M.
now, this assumes that you're using fragments in general, or are otherwise not opposed to using DialogFragment
Steve S.
I'm using DialogFragments elsewhere. Are there reasons why I should be opposed to using fragments in general?
Mark M.
well, some developers love fragments, some developers hate fragments
for example, Square avoids fragments like the plague
Steve S.
ok. but from a robustness/correctness perspective, fragments are ok?
i see.
Mark M.
I would phrase it as "used carefully, fragments can be fine"
Steve S.
what do i need to do to use them carefully?
Mark M.
um, try to have a really simple app :-)
Steve S.
what are the problems i need to be concerned about? memory leaks?
Mark M.
it's difficult to explain in the abstract
Steve S.
ok
Mark M.
possibly, though it's more that the FragmentManager state machine can sometimes get itself tied in knots
Steve S.
i see
4:10 PM
Mark M.
leading to unexpected results when going through a configuration change, or executing a FragmentTransaction
the more things you try doing with fragments, the more likely it is that you will wind up running into these sorts of quirks
and, the more *complex* the things that you try doing with fragments, the more likely it is that you will wind up running into these sorts of quirks
Square got tired of the quirks and threw fragments out on their collective ear
Steve S.
i see
Mark M.
and there are other developers who have been doing their own sort of controller/presenter thing that doesn't involve fragments
off the cuff, few of the MVP/MVVM frameworks that I have see floating about seem to use fragments
Steve S.
can you direct me to any discussions or examples of how to avoid using fragments? for instance, how to use progress indicators that would handle rotations that don't depend on DialogFragment?
Mark M.
for the former, I don't have links handy, if that's what you're seeking
Steve S.
ok
Mark M.
for the latter, you would basically need to do what DialogFragment does: arrange to dismiss the dialog when the activity is destroyed, using the saved instance state Bundle to propagate the fact that "hey, we're s'posed to have this dialog showing!" info to the new activity
Steve S.
ok
Mark M.
the new activity sees that flag (or whatever you put in the Bundle) and shows the dialog when it the new activity gets created
4:15 PM
Steve S.
ok. that seems clear and relatively easy to implement.
Mark M.
yeah, well, it does on the surface
then you realize that DialogFragment is 570 lines of code: https://github.com/android/platform_frameworks_...
(only 463 for the backport, though: https://github.com/android/platform_frameworks_...)
now, DialogFragment probably handles cases that you may not care about
but, if you're using fragments in general, you may as well use DialogFragment and save yourself some potential debugging time, fixing your own implementation
Steve S.
ok
i'm trying to get this app finished up, and will probably just use a DialogFragment to make things easy. But I'll definitely think about the concerns with fragments going forward.
Mark M.
for an existing code base using fragments, I wouldn't necessarily rip them out without a concrete reason
Steve S.
ok
Mark M.
but, if you encounter your 29th "dammit, why aren't these fragments working the way I want?" issue, make yourself a note to try something else on the next app :-)
Steve S.
sounds reasonable
4:20 PM
Steve S.
anything else on the progress indicator/fragments issue? i have another question on a different topic
Mark M.
I'm good if you're good! :-)
Steve S.
ok
i'm wondering about how to determine whether the network is reachable before making a rest request.
Mark M.
make some benign request of the server that is your REST endpoint
if that succeeds, great
Steve S.
ok. that's what i ended up doing.
Mark M.
the problem is that there are lots of moving parts with a network request
Steve S.
what about also using NetworkInfo per Google's documentation. that seems to just indicate whether the device has wifi turned on. i'm doing that first (before a ping). Should i do that?
Mark M.
I would not bother until you have a failure, and then only if you want to enact some sort of decision tree to try to refine the error message that you provide to the user
Steve S.
ok. so just the ping.
4:25 PM
Steve S.
the other thing i've done is to set timeouts on the HttpURLConnection object. i can't directly ping our server and am pinging a Google name server to see if there's a network connection. does this seem reasonable?
Mark M.
um, by "ping", do you literally mean the ping protocol (ICMP, etc.)?
Steve S.
yes. is that ok?
Mark M.
that depends on what the criteria are for "ok" :-)
Steve S.
i found something in stack overflow that uses the Android Unix ping command, which I've copied.
Mark M.
IMHO, ping would provide too many false positives and false negatives
Steve S.
ok.
Mark M.
that's why I suggested a benign request of the actual server (e.g., /robots.txt) or something
Steve S.
i see
Mark M.
now you're using the desired protocol (HTTP over TCP, not ping) to the right server
Steve S.
i see. so just try e.g. a get on robots.txt?
Mark M.
yes
Steve S.
ok
Mark M.
or whatever the server folk would prefer that you use, assuming that you are in communications with said server folk
4:30 PM
Steve S.
i see. i'll check with him then.
so if i do a get on robots.txt or something along those lines to check the connection, should i also set timeouts on the HttpURLConnection object?
Mark M.
well, you always want some sort of timeout
Steve S.
ok
Mark M.
beyond the fact that network conditions are constantly changing, the test request will still have differences from the real request
for example, /robots.txt is probably a static file, whereas the real REST request is hitting some sort of Web service
Steve S.
i see
Mark M.
perhaps the network and Web server themselves are fine, but the Web service is borked
Steve S.
ok. so a decently robust approach would be to do a get on e.g. robots.txt and to also set timeouts on the HttpURLConnection object.
Mark M.
yes
Steve S.
no more questions today. as always, this has been very helpful and informative. lots of food for thought. thank you so much!
4:35 PM
Mark M.
you are very welcome
4:35 PM
Steve S.
have a good rest of the day!
Mark M.
you too!
Steve S.
has left the room
5:00 PM
Mark M.
turned off guest access

← Tuesday, October 18

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S