hello, Paul!

how can I help you today?

Greetings.

I have a question I will paste to you and then we can discuss it.

Is that clear enough for you to grok?

um, well, to be honest, I'm having some trouble

first, "two panels in a view pager" -- do you mean two pages in a ViewPager?

IOW, only one of those is visible at a time?

Yes.

Correct, User sees only one at a time.

OK

I guess I don't understand what Y is exactly

The number of distinct menus

do you really mean "menus"? or do you mean "menu items"?

(where a menu has 1+ items)

menus

um, well, IMHO, if Y>1, I really don't understand

I am trying to make the point that managing 1 menu is way harder than showing 3 different menus.

um, if you say so

from what I can see, your entire UI would consist of floating buttons

on the whole, I'm really not a fan of FAB/FAM

I think you are answering my question as "context" not "popup", editorial comments aside. :-)

I am using them in CWAC-Cam2, because there isn't anything else that's better

is your distinction between "context" and "popup" is coming from some Google terminology in their design guide?

Google advertises three types of menus: options, context and popup.

The latter two I ill understand, or at least when to use one vs the other.

well, when I last looked at their design guide, they didn't even have guidance for a FAM

What I'm reading is apart from the FAB docs.

Currently I have a single menu associated with the FAB that is really just a layout menu. But I am reaching limits with that approach and have to find a better solution.

Or to be accurate, each of the pages uses this approach.

One fab with menu per page.

OK

let's back up a step

sure

why FAM vs. action bar/toolbar items (including overflow)?

there are fairly clear patterns for fragments contributing to those based on visibility

is there a reason, from the user's standpoint, why these menu choices are tied to a floating button?

I currently use action bar/toolbar with overflow for other things, like settings, help, learn more, etc.

The fab menu is for doing new things pertinent to each fragment.

OK

what is the actual thing that represents one of your panels/ViewPager pages?

is it a fragment, and you're using nested fragments?

or are you using something else?

One page is for "chat", the other page is for "games", like chess, checkers and tictactoe

OK, but is "chat" a fragment, containing other fragments?

or is "chat" a View, holding fragments?

Yes.

The chat panel shows grooups, rooms and messages each in it's own fragment.

you said "yes"... but I gave you two options (chat panel is a fragment, chat panel is a View)

Chat panel is a fragment.

OK

Game panel is a fragment.

IMHO, then, the chat panel owns its FAM, and the game panel owns its FAM

Correct.

why can't the nested fragments just tell their parent fragment what things to contribute to the panel's FAM?

basically, rolling your own mechanism akin to how fragments contribute to action bar/toolbar based on visibility

That's what I currently do and I find it a little messy, too many moving parts.

messy in terms of code? or messy in terms of UX?

in terms of code

UX looks good.

but, my interpretation of your original pasted-in material is that you want to change the UX

if you like the UX, isn't this a matter of figuring out what makes you feel the code is messy, and figure out how to improve upon that?

Not really. My bad if I misled you.

then I'm a bit lost again

I am trying to figure out to improve the current code.

Now I ssy, remove this item, add these and change the order. It would be easier if I could say, just use this named menu instead of the last one.

what are you using for your FAM implementation?

IIRC, the Design Support library has a FAB but no FAM

Correct, so I am using standard layout code using image views and text views in a linear layout. I control the visibility of the layout on a FAB press.

oh, OK, I thought perhaps you were using an existing FAM library

I figured Menu objects would be better.

I try to avoid third party libraries in general.

Some are compelling though.

I haven't looked at trying to reuse Menu for things other than what the framework/support library uses them for

so I don't know how practical that is

but if you're then rolling this all yourself, you're in charge of your own API

Me either but I figured if anyone would know it would be you. :-)

so if you want to have a higher level of abstraction, with the child fragments telling the panel fragment to use a menu by some name, go right ahead

your panel fragment would need to know how to obtain the details about the named menu to be able to fill in your widgets

I'll give it a shot and see how I like it. And let you know at some future office hour.

whether that's really using Menu and menu resources (but perhaps only as model objects), or whether that's something else that you cook up, is your call

It's either Menu or View objects as near as I can tell.

well, not necessarily

I'm all ears.

android.view.Menu is an interface

really, it's a view model, describing a UI, but not actually implementing much of it directly

e.g., it does not have onDraw() or other rendering-related logic

there's nothing stopping you from creating your own Menu implementation, perhaps cribbing parts of it from the AOSP

that is used by your existing rendering code

personally, I'd consider that overkill

Truly.

but, it would allow you to use the existing menu inflation logic, if you wanted to use menu resources

It is clear to me that I will be inflating if I use menu objects.

That's ok.

the problem is that neither of the concrete Menu implementations has a constructor

so they aren't much help

the Menu classes really are designed to be driven by the framework, not by SDK apps

we just implement the requisite callbacks (e.g., onCreateOptionsMenu())

and the existing menu UIs aren't a FAM

so, if you want to keep the FAM, as that's the UX you want, either you're creating your own Menu implementation, or you're eschewing Menu and doing your own thing entirely

I can't rule out the possibility that there's a way to use Menu for a FAM without you creating your own implementation of the Menu interface, but I don't see how

I don't know that I agree with you. And I think I will soon know if you are correct.

oh, it's entirely possible that I'm wrong here

this isn't the sort of thing that I think about much

If the menu approach get's messier than the current approach, then I'll toss the menu approach.

And live with my current "poor man's" FAM.

your FAM implementation probably isn't a problem

it's how you want to populate that FAM that's your problem, in terms of messy code

at least, as I understand it

Correct. And I might be able to modularize that to make it more appealing.

At this point, I'm going to bid you good afternoon and start working on my menu solution. Thanks for your help.

sorry I didn't have a magic bullet for you

Talk to you again soon, I'm sure.

No problem.

I learned it is not an easy problem to solve.

That is good to know.

Hi Mark!

hello, Lucy!

how can I help you today?

Glad I made it before its over. I have two questions:

1. I have a Fragment that takes an argument and based on that argument the Fragment populates a ListView. In order to refresh the list with a new set of data I am currently calling, from the Activity, fragmentTransaction.replace(). I replace the Fragment with a new copy of itself with a new argument. I'm wondering if this is a pattern that is OK?

that seems like overkill

Oh

why not just call a method on the fragment to say "here's your new argument?"

that method can update the arguments Bundle plus reload the list

:-)

the arguments Bundle can be modified beyond when it is first created

and this would save you fragment transaction overhead

Absolutely. It didn't feel right. I'm looking at my code now. I pass the argument to newInstance().

and for providing the starting value, that's fine, but you can still have a method that replaces the argument value and reloads the ListView with a fresh adapter

I see. And keep the same instance of the Fragment.

yes

When I call: MyFragment myFrag = MyFragment.newInstance(arg1)

Is it OK to make myFrag an instance variable, say, mMyFrag instead?

um, sure

that's fairly typical when an activity needs to work with the fragment after the fragment was initially created

Oh cool. So far I've only made myFrag local to the newInstance() method.

wait, what?

Oh well of course it gets returned by newInstance()

ah, OK

Sorry I see now how it works.

I will have that reference already!

Second question, quickly...I am storing a value that I need globally in the SharedPreferences. Not sure there is a better way to store a value globally? Its a String value.

SharedPreferences itself is effectively a global

So for each Activity/Fragment that needs to the value I then fetch it from SharedPreferences

OK cool

it gets cached at the process level automatically

right

Oh fab. I didn't know that. So it will be both fast and reliable.

Thank you! I see time is almost up. Have a nice weekend.

fast *after* the first access, when the SharedPreferences get read in from disk

you too!

OK fast after the first read. This is excellent.

Thanks!