hello, Bryan!

how can I help you today?

Hey Mark, how are you?

I was in last week asking about an issue I had where I was getting IllegalStateException Fragment already added. I was able to find out what was causing the issue

but not sure how to fix it

or rather, not sure how to fix it like I would like to

yeah, that's sometimes a problem...

essentially, what happens is, due to a the ability to click on multiple events at once, I can get to a place where I am on Fragment A

and the back button takes me to fragment A

and I get the exception

(BTW, hello, Yogesh -- I will be with you shortly!)

hello mark

Bryan: um, so you're showing A, and BACK is supposed to take you back to A?

I can fix it by just doing a try catch for the IllegalStateException, but i would rather fix it by being able to know where I am going "back" to and comparing it to where I am

no, it shouldn't, but because of the messed up navigation I end up in that state

ah, OK

If I have Frag B on the backstack, and when that get's undone, it goes back to Frag A, is there a way to get that info?

I am not sure if I am asking that right

so, you're showing B, and you want to know whether or not if the user presses BACK, you would wind up at A?

no, I want to know what I am going to go to if the user presses back

whether B, C, eetc

etc

not really

unless you track that yourself

Ok, so even though Android knows the transaction it will go back to, there is no easy way to pull that out of accessible information?

unless I track it

or try using the string passed into addToBackStack() to track it

Well, in this case A was never added to the back stack

B was the first thing added, but obviously Android knows that B goes back to A even though I didn't add A to the backstack

then Android does not know that B goes back to A

the only "goes back to" that Android applies at the fragment level automatically is via adding to the back stack

anything else you are doing yourself, or you are transitioning an activity boundary (and so it's the overall task's back stack that you're seeing)

the definition says that addobackstack adds the current transaction

and popping that "undoes" the transacgtion

right

it doesn't speak to what shows up when it is "undone"

well, if there's any question about it, you've got other issues

that is true

since you're using capital letters, let me use a different naming scheme

please do

you start off with F1 and F2 in the FragmentManager, both visible

you create a FragmentTransaction to replace() F2 with F3, and use addToBackStack() on that transaction

you commit() the transaction, and you wind up with F1 and F3

as being the visible fragments

user now presses BACK, or you pop the back stack via FragmentManager

"undoes" means "undo the replace()"

yes

so F3 is removed and F2 is put back

and so you're back to F1 and F2

right

but if I didn't track that myself, there is no way to know that information from the FragmentManager, right?

well, addToBackStack() takes a String "name" parameter

but F1 and F2 are not in the backstack, right?

in your example

principally, that's used to pop several entries off the stack, to jump back to the named state

correct

well, it depends on what you mean by "in the backstack"

the stack itself is transactions, not fragments

depending on nomenclature, one could argue that F2 is on the back stack

insofar as pressing back returns you to F2

anyway, back to the name

yes

I haven't used the name, as I haven't had a case where I needed it

if you're not looking to use the name for anything else, you could use the name as a string sort of "tag" to help you identify what the transaction was

such as "F2->F3"

or whatever

FragmentManager lets you iterate over the back stack entries, and one thing that you can get is that name

so I can use that string to know

however, details of what the actual transaction was that will be rolled back are not in those back stack entries

I see what you are getting at

since there is nobody else here yet, can I try to explain better how my app works, I would be curious to have you critique it anyway

now, it's possible that this won't work, if they require uniqueness and you determine that you don't have unique strings

and it might show my problem more clearly

yeah, hopefully Yogesh will return

lol

Ok, I am trying to write a single activity app that just uses replace for fragments

I have a nav drawer with home/activity/profile/contest/logout

when you launch the app, the activity loads a blank page that never gets shown, and it does fm.replace(R.id.Container, HomeFrag)

with no back stack

all of the nav drawers do the same calls, fm.replace(R.id.Container, HomeFrag/ActivityFrag/etc)

with no back stack

OK

but any clicks inside (like clicking on a list entry in HomeFrag) call fm.replace(R.id.Container, DetailFrag)

WITH backstack

OK

so what is happening is that for different reasons, people are able to click on the list to get to the DetailPostFrag (which then should go back to HomeFrag) AND at the same time get into the HomeFrag

i know one way they are doing it (by clicking on the menu at the same time as the post)

and then while they are in the HomeFrag, they press back, which takes them to HomeFrag firing off the exception

I have found a number of smaller fixes to take care of some individual things

but I was hoping that I could just say....If my back takes me to the same place I am, ignore

else, super.onBackPressed()

you should be clearing the back stack on any trip back to HomeFrag

any time you go to an item in your nav drawer, clear the back stack

I did that, but I was still getting the crash from live users

I was not able to duplicate it for myself

I use crashlytics, and it was still showing users getting that error even with the patched version (that cleared the backstack on menu item)

obviously can't expect you to fix that one since I don't have enough data, but.....

I think last time, I suggested that you use dump() on FragmentManager

yes

you did

but, that was thinking that you were able to reproduce the problem

and we were (one way) and we fixed it, but there were other ways people were getting into the same situation

unless for some reason, crashlytics was mis-reporting the version

well, it's unlikely that they'll make up a version code :-)

so presumably their info is correct

short of a code review, to ensure that you are *only* using addToBackStack() on transactions that are drilling down into detail (and not going to a nav drawer entry), I don't really know what to tell you

somehow, you are adding a HomeFrag where there's a back stack entry that would return the user to HomeFrag

yeah, this has been helpful regardless, I like using the transaction name to track where it came from, that might work

yes

another thing that might help with diagnostics is to add a back stack change listener

and in your debug builds, use it to dump what's currently in the back stack

to see if it makes sense

since you can no longer reproduce the problem, it won't help you directly here, but it may help suss out where you have other back stack problems

I can reproduce the problem at this point, because I undid my "fixes"

and, perhaps, tugging on that thread will unravel the knot that is causing your crashes

ok, thanks Mark, I appreciate it

what are your thoughts on single activity apps?

problems like this make them painful, akin to the equivalent sort of problem in single-page Web apps

in theory, they're fine

:)

how long have you been programming android?

(java)

February 2008

(light poking at it before then, but nothing serious)

nice, well, thanks again, I really like what you are doing here, with the book, updating regularly and office hours

it is hugely helpful!

I aim to be useful

what do you charge for code review?

or per hour/day or however you would do it

actually, when I mentioned a code review, I wasn't implying that I'd be doing the review :-)

I try to avoid getting into other firms' proprietary code, just because the legal agreements get icky

I know, but I saw that you do consulting like that, right?

yes, but more on a Q&A/discussion sort of basis

the sort of thing a garden-variety NDA can cover

gotcha

thank you!

have a great night, go cavs!

lucky for you, I'm not in the Bay Area, like lots of Android devs :-)

lol :), it was worth the risk

and the Sixers aren't going to be making the NBA Finals any time soon

But I grew up in the bay area, so I am covered either way

who knows, they have an interesting rebuilding scheme

maybe it will be like moneyball

adios sir, I am sure I will see you again soon

have a pleasant day!