Office Hours — Today, January 17

← Saturday, January 14

Jan 17
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Steve S.
has entered the room
Steve S.
Hi Mark!
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Let me paste in my question:
View paste 
I'm working on a logout feature for an app. When the user clicks the Logout button, the app uses an IntentService to send a Rest request to the backend to logout. If the request is successful, I want to finish the current activity and start the Login activity.

My question concerns how to start the Login activity. I'm using Greenrobot's EventBus to send events from the IntentService to activities. Because the user can potentially navigate to several different activities while the Rest request is being processed, I've concluded that I need to have an event handler in all those activities that will finish the activity and start the Login activity. is this a reasonable approach? Is there a way I can accomplish the same thing without having the same event handler code in several different activities?
Mark M.
"Because the user can potentially navigate to several different activities while the Rest request is being processed" -- perhaps (part of) the solution is to prevent navigation until the logout request is settled one way or the other
Steve S.
ok.
Mark M.
normally, you don't want to prevent navigation just because you are doing network I/O
login and logout are special cases
Steve S.
Right.
I see
Mark M.
beyond that, you can either use inheritance (activities inheriting from a base that handles the event) or composition (activities hold a controller that handles the event)
Steve S.
Originally I prevented navigation during network I/O but have rewritten my app to allow that (based on prior chats we've had)
Mark M.
and normally that's the right answer
4:00 PM
Mark M.
but, "change the world" events (login, logout, registration, delete account, etc.) may require breaking that pattern
after all, if the user requests logout, then attempts to modify something, what happens?
Steve S.
I see. That's very helpful.
How should I prevent navigation while the logout request is being processed? Use a modal dialog?
Mark M.
possibly
Steve S.
ok
Mark M.
are you holding onto any sort of credentials in memory, based on the login?
(e.g., tokens that you have to place on the REST requests)
Steve S.
no login credentials per se, but other information about the user
Mark M.
ok
Steve S.
yes, oauth tokens.
Mark M.
then another possibility is to clear out those tokens quickly after the logout request is made, and control navigation based on whether you have a token
or, just send them straight to the login screen, on the grounds that "what would a logout failure mean with respect to those tokens anyway?"
Steve S.
what do you mean by "control navigation based on whether you have a token"?
Mark M.
reactively, you would check the token on click listeners and such, deciding whether to navigate based on the existence of the token
4:05 PM
Mark M.
proactively, you would raise a logout-pending event, and disable navigation until... sometime
the more I think about this, the more my gut is telling me that they should just be sent straight to the login screen after choosing logout
if you cannot safely let them log in until the logout wraps up, handle that when they click the "login" button (e.g., queue the login attempt until the logout is confirmed)
Steve S.
so from the user's point of view, the logout request would never fail, even if the internal Rest request fails.
Mark M.
right
simply because your app at that moment is in an iffy state anyway with respect to the pre-logout token
and my guess is that you're safer forcing a fresh login
whoever is handling the server side may have their own opinion on this
Steve S.
ok. that makes a lot of sense. i will test, but i think the behavior of the backend allows logging in twice without logging out.
4:10 PM
Steve S.
your point that allowing navigation while a Rest request is pending is something that's appropriate in many circumstances but not all is very helpful. i'll think through the app's behavior again based on that.
Mark M.
pretty much whenever you see somebody like me speak in absolutes, we're doing that to simplify the discussion :-)
Steve S.
sure.
no more questions today.
Mark M.
OK
Steve S.
by the way, the last time i tried to print out the session, i didn't get the entire transcript - the last part was cut off. i'm wondering if there's something i'm doing on my end that could be causing that.
Mark M.
do you mean the transcripts from https://commonsware.com/office-hours/ ?
or do you mean the current contents of your browser window, like it is now?
Steve S.
yes, the transcripts. we exchanged emails about the problem a few weeks ago.
Mark M.
right, and that was a case where I had screwed up the transcript download, then fixed it
are you still having problems?
and, if so, which transcript are you trying?
I have never tried printing one of these, so I don't know what to expect :-)
Steve S.
it's been a couple of weeks, but it did happen again. i don't remember which transcript - i was able to get what i needed.
Mark M.
if you run into future transcript problems, drop me a line
Steve S.
ok. i'll try printout out the transcript for today's session after its' ended. i'll let you know if there's a problem.
thank you so much! i appreciate your help.
4:15 PM
Mark M.
you're welcome!
Steve S.
have a good rest of the day!
Mark M.
you too!
Steve S.
has left the room
4:55 PM
Mark M.
turned off guest access

← Saturday, January 14

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S