hello, Ed!

how can I help you today?

Hi Mark!

Struggling with something on ConstraintLayout this week

I've got a bunch of label-data rows

trying to get it to collapse an absorb the space

if I set the row to INVISIBLE or GONE

it doesn't fill the space

what is "the row"? do you mean two widgets that are children of the ConstraintLayout?

yes, I have a bunch of TextView items

and under certain scenarios an option might not be valid

so imagine a 'SWITCH' widget

if you turn it off fields go away and the view collapses

turn it on and they show up and the layout expands

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

Hi, everyone.

okay, thanks.

do the things that you expect to fill the space have 0dp for the desired axis?

looking

basically, you need the things that are to fill the space have flexible sizing

if they have a fixed size (dimension or wrap_content), then it doesn't matter what happens around them

while you're looking, let me take a question from gonzobrains, and I'll be back with you in a bit

gonzobrains: your turn! do you have a question?

I'm writing it right now.

that should collapse in the white space.... checking what you suggested... thanks

I have a problem where an AlertDialog remains on the screen after the user resumes an app from device sleep. I have tried to dismiss the dialog in the OnPause() of its containing fragment, however the OnPause() is not getting called. I notice that the fragment's OnPause() doesn't get called if the fragment is is displayed from another fragment, but if I allow the user to view this fragment from an option in the sidebar menu, the OnPause() method gets called.

That's the only difference I can seem to find between fragment's that have OnPause() called and those that do not, ie. where they are called from.

There is only one activity in this application, and the previous developer created a "hamburger menu" for displaying fragments and also allows fragments to display other fragments.

they are all full-screen and only one fragment is displayed at any time.

it's possible that you are encountering some issue with nested fragments

Does nesting have anything to do with the backstack?

um, presumably

I'm trying to figure out the previous developer's navigation setup. He disabled the back button and forces navigation through the hamburger menu and other fragments.

insofar as if the parent is popped off the back stack, it should pop its children

ick

I've tried forcing everything on the stack to be popped off when the sole activity's OnPause() is called, but nothing happens.

I'm not sure what to tell you

in the scenario where the child fragment is not getting called with onPause(), is its parent fragment being called with onPause()?

what is a good resource, besides developer.android.com, I could use to understand more about fragments and navigation?

frankly, after the docs and experimentation, we're down to ouija boards and reading the future in tea leaves

this stuff can get fractally complicated

hmm, parent fragment. I'll have to look into that because the way I see this should work is only one fragment at any given time associated with the main activity since the back button has been disabled.

I thought your problem case was where the DialogFragment was shown by another fragment

the code calls supportfragmentmanager.begintransaction().replace().addtobackstack().Commit() all in one go.

ahh, no I solved that problem after your last office hour.

"I have tried to dismiss the dialog in the OnPause() of its containing fragment, however the OnPause() is not getting called"

that's in today's chat

this is kind of separate. not to do with DialogFragment. In this situation, a fragment is calling an AlertDialog. It's similar though.

all dialogs should be wrapped in a DialogFragment

oh, well, I'm not using DialogFragment here. It is an AlertDialog that's not getting dismissed.

otherwise, you're unlikely to get configuration changes correct

so, try wrapping this dialog in a DialogFragment, and see if that helps your case any

could you elaborate? This codebase seems to make ample use of AlertDialog.

Do I have to replace all of them with DialogFragment?

I wouldn't say "replace" as much as "wrap"

have your DialogFragment override onCreateDialog(), and in there put your AlertDialog code

then, show() the DialogFragment

I will need to research that.

so any dialogs that are displayed from a fragment should be wrapped in DialogFragment then?

any dialogs *period* should be wrapped in a DialogFragment

(note: a few ancient book examples of mine need updating in this regard)

again: otherwise, you lose the dialog on a configuration change (e.g., screen rotation)

unless this code is using the long-since-deprecated managed dialog stuff

This AlertDialog class appears to be derived from AppCompatDialog (support v7).

Does your busy coder's guide have an example of how to do what you suggest?

I think that only ensures that your Theme.AppCompat-based themes work,

let me switch back to Ed for a bit, and I'll return to you shortly

Ed: back to you!

Ed, if you have follow-up from the earlier stuff, or another question, let me know and I can turn back to you

gonzobrains: back to you in the interim

ok.

I'm here

Ed: your turn! do you have any follow-up from the earlier stuff, or another question?

in your screenshot, what is the second heading (the "CREDIT CHECK" one) anchored to for its top edge?

A divider

oh, those horizontal bars are separate widgets

what is the upper divider anchored to for its top edge?

so it will go white when I throw the switch off and on

but I was expecting it to collapse

like it does in the other layouts

a LinearLayout would collapse

this doesn't. :-)

:-(

so, the divider above "NO CREDIT CHECK REQUIRED!" -- what is its top edge connected to, via a constraint?

A Text View

the "Down Payment $" one?

Everything has a vertical constraint flowing from the top... down

to the item above it

OK, and so you're saying that when you make all the widgets between "Finance this plan at 0% interest" to the divider above "NO CREDIT CHECK REQUIRED!" set to View.GONE, that the layout is not collapsing?

if you set it to View.INVISIBLE, then I would expect the results that you're seeing

in principle, if those constraints are set up as you describe, GONE should work

testing it now

that got it!

woot!

thanks Mark

um, you're welcome!

I guess I misunderstood what you tried before, because I thought you had tried that and it didn't work

but, if you have working code, that's all that matters right now

I did try it earlier and it didn't work

but I'm betting I didn't have 'wrap_contents' the last time I tried it

lot of moving pieces there

OK

anyway, glad it is working!

so easy to move a TextView and it switch to a size on you

:-(

ah, OK

yes, the drag-and-drop editing has its issues, even with ConstraintLayout

if you're not careful

I moved them around a lot

let me switch back to gonzobrains, and I'll return to you in a bit

gonzobrains: back to you!

sure thing

I'm just researching all the options now.

OK

I'm not completely convinced the navigation is set up right, especially because the back button is programmatically disabled.

I can understand that

I agree that the user should be able to get around without the BACK button, but disabling it seems harsh

Can you explain the reason for wrapping with DialogFragment?

configuration changes

by default, rotating the screen, etc. destroys and recreates the activity

that wipes out any dialog you were displaying

configuration as in the user rotating the screen to landscape or something else?

right

or any one of the configuration changes, though that's the most common one for mobile devies

er, devices

ahh, okay. I need to see if the app even permits that. it is an in-house corporate app for use on a single device, so it may be forcing portrait.

but it's good to know that anyway for future reference.

the recommended approach is to show all dialogs via a DialogFragment

i will look into that.

then, when the fragment is recreated after the configuration change, it will re-display the dialog

basically, the app disables the back button to force the user to navigate through the hamburger menu.

I think it was a "cheating" way to avoid more complicated navigation issues.

will this re-create the dialog when the device's screen is turned off?

if needed, yes, it should

what's happening is that my yes/no alert dialog still remains even though the underlying fragment that created it went away. when the user taps the "yes" button it crashes.

what does "went away" mean?

I'm still thinking that I need to find a way for the underlying "parent" fragment to get its OnPause() called so I can call the dialog fragment's Dismiss() method.

something with the navigation just isn't right, as if there are two backstacks being created by virtue of how the fragments are being displayed.

I'm not sure.

ah, OK

what is the expected behavior? is the dialog supposed to be there at that point (and work), or not?

"went away" = the user presses the power button to make the screen go off.

well, that doesn't directly affect a fragment

any more than it directly affects a TextView

so, a fragment won't "go away" just because the power button is pressed

IIRC, it *should* get paused, as its containing activity is paused

I see the Main Activity's OnPause() being called, but this particular fragment doesn't get it's OnPause() called if it was displayed by another fragment displaying it. but if I put a menu option for this fragment in the side navbar, it will get its OnPause() called.

The exact same fragment, just shown a different way and its OnPause() works.

OK, let's give some names here

sure.

can you give me a name (fake or real) for the fragment that is giving you trouble, and for the fragment that is the "another fragment" in the phrase "if it was displayed by another fragment displaying it"?

I have one activity named MainActivity. Then there is a list of completed purchase orders in a fragment called PoListFragment.

I mean, we can use A and B for all I care -- I just want us to agree on the names :-)

If you touch on a PO in the listview within PoListFragment, the PO will open up in PrintPreviewFragment.

I choose the print button in PrintPreviewFragment, and a printing progress dialog comes up. if there is a printing error (no printer connected), another yes/no alert comes up and asks if you want to go to the settings screen.

at that point, if the user turns of the screen and turns the screen back on, the application will resume with the main fragment that starts up every time the app starts, but this yes/no dialog remains on the screen.

OK, stop there for a moment

ok.

isn't the bug that your PrintPreviewFragment went away?

IOW, shouldn't your app be in the same state after the screen turns back on as it was just before the screen was turned off?

well, yes and no. I agree with you that the menu should allow the user to resume where they left off, but as the app is currently designed the user is supposed to be forced back to the main screen.

oy

so for the time being I have to work with that restriction.

sorry, i meant "that the app should"

OK, so, what exactly is causing PrintPreviewFragment to go away? are you specifically running a FragmentTransaction to detach/hide/replace/whatever it?

or popping the back stack?

lemme check.

dismissing the dialog should be tied to whatever happened to the fragment

so, if the fragment was detached, you'd dismiss the dialog in onDetach()

ahh, I see that OnStart() for the activity navigates to the start fragment by popping the back stack (inclusive) and then beginning a new transaction to add the "home" fragment to the backstack.

OK, so, your PrintPreviewFragment should be getting a callback at that point

what callback would depend a bit on the transaction that caused it to be displayed

worst-case, temporarily override all the "negative" callbacks (onDetach(), onDestroy(), onDestroyView(), onHiddenChanged()), see which are getting invoked, then choose the best candidate in which to dismiss the dialog

yeah, but that doesn't happen if PrintPreviewFragment is called from PoListFragment. It does if I started it from the side-drawer. I see there are two different methods depending on whether another fragment shows a new fragment of if the side-drawer started it. I will try to compare the two.

okay, lemme soak that in.

when PoListFragment shows PrintPreviewFragment, which FragmentManager is it using? getSupportFragmentManager() or getChildFragmentManager()?

ahh, I haven't tried all of them. I think I only tried onDetach() and onDestroy(). if OnHiddenChanged() works, then that will fix this dialog problem in the short-term, but I should still see if the code is abusing this navigation/backstack system.

getSupportFragmentManager()

oh, it probably is :-)

hmmm, OK, that's the same as what MainActivity is using, so it's not a nested fragment issue

you know, I solved my last problem i discussed with you a few days ago by invoking the DialogFragments using getChildFragmentManager() though.

I didn't think I should use child in this case though.

it doesn't feel like it is a child fragment scenario to me either

but, I don't know much about your code base

BTW, Ed: any quick final questions?

it's a simple one if you have time

I was wondering, since the back button is disabled, if I should just pop whatever is currently on the backstack before navigating to any new fragment.

if not... you can cal lit

'call it'

go for it, Ed.

Ed: go ahead

is there an easy way to do a "%S Customers"

where that is a var passed in

to a strings.xml resource

or would you advise against it?

no, that's fine

use a lowercase s

"%s Customers"

will do

thanks!

have a great evening

and there's a variant of getString() that takes a varargs that can be used to fill in the %s, akin to String.format()

ty

you might also look into plural resources, since you wouldn't want "1 Customers"

have a great evening Mark!

cheers

OK, that's a wrap for today's chat

thanks again!

you're welcome!

the transcript will go up on https://commonsware.com/office-hours/ shortly

ok.

the next chat is Monday at 9am US Eastern

have a pleasant day!

cool, thanks.