Hello

How are you?

hello, Kai!

OK, and you?

Ok also.

how can I help you today?

We support different screen sizes, the most different ones being "smartphone" and "tablet". For that we have different ParentActivities that hold either a one-pane or a two pane view.

Would it still be done like this nowadays?

one could reasonably argue that it would not have been done that way back when... your predecessors did it that way :-)

:D

the approach I have generally advocated is a single activity, rather than two, where it sets up its contents in single-pane or dual-pane modes based on screen size

you might have your single-pane layout in res/layout/thingy.xml

and your dual-pane layout in res/layout-w800dp/thingy.xml

so when the activity does setContentView(R.layout.thingy), it gets the right one based on size

at that point, your if logic is checking for the availability of the second pane

IOW, if the second pane exists, configure it

while *The Busy Coder's Guide* is a bit old, and so the actual code is not great, the chapter on large screen strategies is still not a bad intro to master-detail patterns

Google, however, is trying to steer away from master-detail, as it does not work well with resizeable windows

or, at least, set it up so the dual-pane UI can gracefully deal with the user shrinking the windo

er, window

for example, the left-hand pane might collapse down into a drawer that can be opened

I have not written much about these approaches in my second-generation books, for the simple reason that getting designers to care about *landscape* is a struggle -- tablets are "a bridge too far" for lots of places

Ok

but, I hope to cover more of it in the next, say, 18 months

I fail to grasp the difference between my approach and the approach you described.

It might be that we use it a bit like that.

that could be

but, I doubt it, given your two activities

if you think of your desktop OS that you are using for development, windows can be resized

with Android, that too is possible, on Chrome OS and select other environments

suppose your app starts off in a big window, and so you are displaying TabletActivity

I think my example is a bit flawed, now that I look at it again.

now the user grabs the window corner and shrinks the window

if you are still showing TabletActivity, and you are still showing a dual-pane UI, there might not be window space to render that UI well

I think "PhoneActivity" should be "DetailsActivity". On the tablet, a detail is in the right pane of the TabletActivity. On the phone it's in a DetailActivity.

and you're reusing a fragment or something, for a common implementation of that portion of the UI?

IOW, do you have DetailFragment that is the right pane of TabletActivity and the whole UI of DetailActivity?

Yes.

if so, that's another approach for a classic master-detail presentation... and it's unlikely to handle resizeable windows well

the percentage of Android app developers who worry about resizeable windows is really low

Yes, it doesn't handle resizeable Windows at all I think.

If Android doesn't reload on resize or something.

Google would prefer that developers use more sophisticated patterns, to handle resizeable windows as well -- alas, we have very little code for those patterns, at least at present

you will eventually undergo a configuration change

I just tried the "split screen mode" of the tablet and it seems to load the smart phone view then.

that would cause your UI to reload a layout

that is probably based on your logic for deciding whether to show TabletActivity or DetailActivity

Probably :D

where the resize stuff becomes a problem is when your UI is already on the screen, and then that UI gets resized

the resize probably will not trigger you to switch activities, so your pre-resize activity is the same as your post-resize activity, and the UI might not work well

the approach I described originally, with one activity and two layouts, would handle this a bit better, but with a "smash cut" transition between single-pane and dual-pane modes

Google would prefer some sort of animated transition between those modes

Google would prefer a lot of things that I don't have time for :-)

I was just about to say

and I have a *lot* more patience for these sorts of considerations than do a lot of designers and developers

so, what you have, for a strict phone vs. tablet setup, can work

It seems to work.

earlier, you asked "Would it still be done like this nowadays?" -- the answer is "no, because probably nobody thinks about tablets"

So there would just not be a tablet layout?

We seem to think about it still.

and I am grateful for it!

but, yeah, most app developers wind up optimizing for the phone, and, in terms of the tablet, "it is what it is"

Nah. I always have to think for both and cover both cases.

in some cases, there are ways of just tweaking the UI a bit to look better on tablets, while retaining the same overall navigation

We have three main layouts: layout, layout-large and layout-large-land.

what you're doing is the next step: optimizing presentation and navigation for tablets (e.g., dual-pane UI)

basically, overall, there just is not a lot of focus right now for truly optimized tablet experiences

certainly, places like yours do it, but it is not as common as some would like

I do expect there to be renewed interest in the concept, courtesy of Jetpack Compose and Compose for Desktop

desktop UIs really hammer home the need to support resizeable windows

and large windows in general

Right.

Then it's not just the "table edge case" anymore.

so, in the coming years, I expect that we will have lots more UI patterns that can work across a range of window sizes with resize support, and actual implementations of those patterns

Not for us :D Compose requires Kotlin iirc.

;-)

so long as what you have for a tablet UI works well enough for your needs, I would not worry about it, unless you need to re-engineer stuff for other reasons

Nah. I just wanted to know what is current and such.

I don't know if you remember that we have several apps for several "versions" of the server.

But we are now going towards a unified app that will have "switches" or something, depending on which server version is connected.

that sounds like a long-term maintenance improvement

Switching on or off functionality depending on the server version, I mean.

I am bit concerned on how these "switches" will look like and how to make them maintainable and clean

Do you have experience with that?

are your servers customer-installed, or are they maintained and operated by your firm?

Customer-installed.

And it's not about preventing a feature because it wasn't paid for, but more about what sever is capable of what features.

technically, I have not dealt with your scenario -- I have dealt with the other scenario, where your firm has N servers that it maintains

for example, you might have the real production server, plus one or more servers set up for development and testing

Version 10 of the server can do Blarfurg, which Version 9 can't do, so it should not show up when connected.

That sounds like a good solution for flavors.

But that wouldn't work in our case.

why not?

Because we don't know which server version the customer will connect to.

ah, OK -- I interpreted "unified app" as meaning a single project, but you really mean distributing a single overall app

Sorry, yes.

somehow, your app is going to need to know the server version, and I do not know if you have an automated way of determining that or if you will need the end user to say the version they want

but, given that, you can have a object that represents the mix of supported features, where you create instances of that object based on the server version

We have an automated way.

so, you have a ServerFeatures class with a supportsBlafurg boolean field

once you automatically detect the server version, you set up an instance of ServerFeatures where supportsBlafurg is true or false

and the rest of your app gets access to that ServerFeatures and branches accordingly where needed based on whether Blafurg is supported or not

oh, wait, my apologies -- I was missing an r in Blarfurg :-)

How could you??? ;-)

So Blarfurg is pretty much a feature repository?

Sounds like a singleton.

if you mean ServerFeatures, it could be a singleton, though you need to be careful if users might switch between servers -- the values might change while your app is in operation

Yes, I mean that.

if ServerFeatures itself is not a singleton, it might be supplied by a ServerFeaturesRepository or something that *is* a singleton, where you ask the repository for the current features object

or, it may be that ServerFeatures is merely a field on some other object that represents the server connection

the details will depend a lot on your existing architecture

my primary recommendation, though, is to have the bulk of your code thinking in terms of features, not versions

IOW, most of your code should be thinking in terms of "is Blarfurg supported?", rather than "is the server version greater than N?"

And the "feature repository" approach is how I would have done it, I guess.

Features, not versions.

Thanks for the tip.

the problem with sprinkling version checks around is that the business rules can get more complicated

suppose someday you need to remove Blarfurg support -- "is Blarfurg supported?" still works, but "is the server version greater than N?" does not

Yes. And there is no clear place where to look.

right

Remove Blarfurg? Never!

yeah, well, Blarfurg might be banned in some jurisdictions, on account of its tendency to cause spontaneous human combustion

so, while you might continue offering Blarfurg to some customers, others need new Blarfurg-free servers

That's just a myth, by Blarfurg opponents who are afraid of its power.

my scneario is another reason for not tying the Blarfurg check to versions, as it may be that you wind up with a version where Blarfurg capability is conditional

and while you said originally that this is not tied to whether they paid for a feature... you may as well work that into the overall system

And it's nice to have one place where to change it?

yes

the determination of whether the app should offer Blarfurg-related UI is a business rule, and business rules have this nasty habit of changing

so, try to isolate that business rule, and have most of the app only care about whether Blarfurg should be an option or not based on a simple boolean or enum or something

Sounds dreamy.

that's also a reported Blarfurg side effect -- please talk to your doctor

I might have had too much exposure

We have an inhouse doctor for that.

I'll send myself to him.

A Blarfurgologist.

:D

and with that, I need to wrap up today's chat

next one is Thursday in the 7:30pm US Eastern time slot

Stay healthy.

you too!

And thanks.