I've done some more research on this problem, which seems to me to be pretty important. I do not see how anyone is going to be able to incorporate full OAUTH into their applications, and use the new AccountManager functionality.
Looking at my situation more, I think that what I'm actually seeing are two tasks. Task T1 is my original flow, up to the browser, like I describe above. Task T2 starts when I press Accept in the Twitter OAUTH window in the browser. So, keeping the notation from above, the Activity stack is: | M -> O -> B | B -> O | |----- T1 ----|-- T2 --| This is how things end up. When Activity O does a finish, we are left at the Browser. I don't know how to get back to task T1. It seems that since the steps in B2 are dictated by the Browser and how the redirection from browser to activity O happens, I have no control over that process and can't pass any flags in the Intent that kicks off Activity O from the Browser. Can someone help me out here, please? On Feb 3, 11:55 am, Brion Emde <[email protected]> wrote: > I think that I've found the problem I am having with AccountManager > that I described in an earlier thread that got no responses on the > board. > > I think it is a problem with the way that theActivityStack is > working during the OAUTH workflow. Here's the workflow as I see it. I > found this problem by separating out myActivity, which I'll call M, > from the oauthActivity, which I'll call O. In the course of > authentication, the web browser is invoked and let's call that B. > > When a user needs to start over with authentication, my application, > throughActivityM, startsActivityO. That, in turn, generates some > magic URL that is sent to the web browser. So the browser is fired up > and information was sent to the OAUTH provider to do a redirect back > through the browser back toActivityO. > > So, this how the OAUTH workflow looks up to the browser: > > M -> O -> B > > At this point the user logs in and hits the Accept button and the > browser then invokes my BROWSABLEactivity, which, again, is O. I had > thought this would unwind the above stack, but it seems that above > situation disappears and what I have after the user hits Accept in the > browser is this: > > B -> O > > What I did to work around that is that I put a startActity(M) in O and > that seems to work, but it is a workaround. > > I believe there is something that I could do with launch modes > oractivitymodes to fix this problem and maintain the originalactivity > stack. > > All that is happening, really, is that the Oactivitypauses for > little while, then comes back with the goods, the login credentials. > But when I tried to return the information via startActivityForResult > (), nothing. Because M is no longer on theActivityStack. > > Can someone enlighten me here, please? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
