hello, roberto!

how can I help you today?

Hi Mark, how are you doing today ?.

A kind of conceptual question...

OK, and yourself?

Fine, thks

I've an app that has a good number of forms to add data to a database (remote)

and for each form, I need to do an screen showing the data

most of the app is about it... but the number of forms/screens displaying data is big

questino

would you use databinding for an app like that ?

(jth: hi! I'll be with you shortly!)

sure

Do you think data binding is stable a good library to use

roberto: um, well, I do not see where the number of layouts matters as to whether or not you would use the data binding framework

Or the price of saving some findViewById might be too expensive

my #1 problem with the data binding framework right now is that it does not work with Jack/Java 8

which makes things like RxJava messy (no lambda expressions)

if you're willing to live without Java 8 features, then I haven't seen too many problems with the data binding framework

No RxJava

with respect to findViewById, again, that has little to do with the *number* of layouts

findViewById gets more expensive with *big* layouts

and you have plenty of options for caching those, whether manually, automatically via data binding, or automatically via the seemingly infinite number of libraries that offer that sort of thing via annotations and stuff

so, I would not necessarily fear data binding in your case, from a runtime standpoint

I don't have a good sense for how much overhead builds incur due to data binding code generation, though

you might work up a script that wraps your layouts in <layout> tags, and see how the build goes, without doing anything else

if the build now takes forever... that may make your decision much easier :-)

Makes sense

let me take a question from jth, and I'll be back with you in a bit

jth: your turn! do you have a question?

Sure, thanks

Yes First one

go right ahead

I have a Fragment with a ListView. On that fragment there is a filter button. When the user clicks the filter button I need a full screen view to show with filter/options. And when the user select one of those, another view needs to show full screen with a list of options based on that choice

Right now I am using 2 PopupWindows

Is that a good idea, or should those be separate activities. There is just a lot of objects/data that need to be passed back and forth

I would argue "neither"

what would you use?

use fragments or some other replaceable UI

Well the issue is that the user can cancel at each step and I do not want to redraw the listview unless the user selects apply

fragments do not preclude that

personally, this sounds like a wizard-style UI

yes it is

so, use a wizard :-)

there's some libraries for that out in the Android Arsenal

ok

I recently yanked the standard Android setup wizard bar out of the AOSP and used that in a project

even if you decide that you do need floating things (e.g., it won't be full-screen on tablet-sized screens), I'd lean towards dialogs than PopupWindow

And that still should work if the original fragment with the listview has an toolbar and menu, and the "wizard" views need to be full screen

um

well, let's roll back to a comment I just made: what are you doing on tablets?

same thing

really?

phone and tablet will have the same UI

ok

yes :(

not my call

ah

ok, you mentioned "lots of objects/data being passed" -- is that between pages of the wizard, or is it also to/from the list?

IOW, is the pair of PopupWindows that you're using now tightly coupled to each other but loosely coupled to the rest of this chunk of the UI?

to/from the list to the first page of the filter, and then to the 2nd page of the filter

hmmmmm

I agree that having something float probably results in a cleaner UI than having to hide/show the action bar

I'd lean towards dialogs over PopupWindow, but that's more "personal preference" than anything else

I get the list of objects to display in the listview call from an API, that also returns the filter data in the same call, so I have to store the filter data and pass it

the tight coupling does suggest that you should aim to keep this all in one activity

ok

That was all from me, thanks a lot. Be back soon for sure!

so, in absence of any other criteria, I'd be seeing if a full screen DialogFragment would work, where that hosted the two-page wizard

roberto: OK -- you're welcome!

and just transition between the two fragments. And they can be on top of the original view?

a DialogFragment is (mostly) just a Dialog that uses a Fragment for defining its contents

and the dialog floats over top of the main activity content

ok I have used DialogFragments before, but just for Yes/No alerts etc

this is definitely pushing the boundaries of it

and I haven't really run into a scenario like yours in my own work, so I might have different ideas when truly faced with the problem

yeah its not great, because I have to handle the back button, which cancels what "view" you are on

again PM and UX people designing, I am implementing

when I have the dialogfragment in view, will each step be its own fragment?

possibly, using nested fragments

though nested fragments make me queasy

I'd lean more towards a single fragment, using something else (ViewPager, ViewFlipper) to switch between the two steps

ah ok

next question, hopefully easier

The app uses some xml layouts, but since most data is from APIs and dynamic, much of the layouts are programmatically created

is there an issue besides readability in doing layout not in xml?

less tooling support (e.g., GUI designer, data binding code generation)

more difficulty in dealing with configuration changes

those would be the big ones

ok, in the new code I am trying to use xml layouts when I can, but sometimes I still have to inflate the layout and then findbyid and objects to modify them

sure, that's normal

ok

thank you, I am off to try switch to a dialogfragment and viewPager/flipper

OK