hello, Sainath!

how can I help you today?

Hello Mark. How are you doing today?

OK, and you?

Im doing good too.

do you have a question that I can try to answer?

I do not have any questions as of now.

OK

thanks for the kind words!

I was reading the Elements of Kotlin book and saw that the chat session is live.

ah!

I dropped in just to say Hi.

usually, people only come to the office hours when they have questions

hello, Anshul!

Is there a place where we can know the schedule for the next office hours?

Hi Mark, hope you are doing well!

Sainath: in the Warescription site, click on Ask > Office Hours in the nav bar

Anshul: I am doing well -- and you?

Anshul: do you have any questions that I can answer?

I am doing good, thank you for asking!

Thanks Mark, found it. Will keep an eye and join in the future.

sounds good!

if either of you have a question, just ask!

Yes, it is more of a design question. I am making an API call, and the result is a list<Profiles>, now depending on the age range of profiles, I need to show either a different screen layout with the list of profiles as radio button options or if there are no eligible profiles, I need to show a different layout. Should I implement two separate activities for this or should I just do setContentView() after the API call is completed and render the view accordingly?

what is in the layout for the no-eligible-profiles case?

it just displays a text view saying no eligible profiles and a button to let the user add another profile within the age range if he/she wants to

usually, that is handled by a single layout

you would have a RecyclerView (or, in older days, a ListView) for the list of profiles

the layout would also have widgets representing the "empty state", to show when the list is empty

sometimes, there is also 1+ widgets for a "loading state", such as during the network I/O

you toggle the visibility of the widgets as needed

so, for example, your layout resource might start with the loading state widgets as visible and the list and empty states as invisible/gone

then, when your network call completes, you make the loading state widgets be invisible/gone and make either the list or the empty state widgets be visible, depending on whether you have any data to display

Ah, I see, so if the list is there, no eligible screen views remain hidden, but if it is the other way around, list becomes hidden and the other views are shown.

correct

and all of that is managed by a single activity or fragment

in "Exploring Android", the sample app has this sort of setup... or it did in Version 0.3

I just released Version 0.4 ~10 hours ago, and as part of rewriting the book for Kotlin and the Jetpack libraries, I only have a subset of the tutorials right now

but if you happen to have a copy of Version 0.3 that you downloaded, that will show the list + empty state approach

hmm, okay! Now, I am not sure if recycler view is a way to go since I am adding radio buttons dynamically based on the size of list, so user can choose any one of them and proceed with that profile.

Oh, yes, I do have v0.3 of the book! Thanks, I will check it out

the same principle would hold if you are using a RadioGroup wrapped in a ScrollView

That makes sense, RadioGroup wrapped in a ScrollView

so long as your list is not too long, and you really really really want radio buttons, that's the approach to take

Now, since the radiobuttons are being populated dynamically, we do not have any way to modify how we display those, for ex, spacing, or a view separator in between, do we depend on Android to render the views by itself?

Yes, that is the case, list not too long, and I really really really need radio buttons

"we do not have any way to modify how we display those, for ex, spacing, or a view separator in between" -- padding, margins, and other Views interspersed in the list are all possible dynamically

"do we depend on Android to render the views by itself?" -- sorry, but I am not certain what you mean by this

and having radio buttons in a RecyclerView should be possible, though I haven't done that personally, and you would need to manage the mutual-exclusion stuff yourself

well, I implemented the dynamic populating of radio buttons with a radio group, and I did not mention any sort of conditions on how the layout should look like, but it gets populated as a list of radio buttons by itself without me mentioning any layout paddings/margins

you used addView() to add the RadioButton widgets to the RadioGroup, right?

yes, that is correct

one flavor of addView() takes a LayoutParams along with the View to be added, and in there, you specify margins

Ah, that is GTK!

for padding, you call setPadding() on the RadioButton

for a divider, you would create a View with a background color, and you would use addView() to add it with your desired height (to control the thickness of the divider)

or, if you don't want a solid-color divider, use some sort of drawable as the background

RadioGroup is really just a vertical LinearLayout with special support for RadioButton, so AFAIK you can add other non-RadioButton widgets to the RadioGroup if needed

that's awesome, I did not know that! I'd definitely add a solid-color layout

solid-color separator*

Now, building on the previous question, it might be the case that there's an intent from outside the app (a web deep link) can request either the radio button list view, or the no eligible profile views, does it still makes sense to keep them in the single activity?

how would an outside party know whether or not there are eligible profile views?

regardless, you could still handle that all in one activity, using an Intent extra, query parameter on the URL, or something else in the deep link to indicate what UI to use

well, via an email sent to the user who has created a profile/some profiles previously.

unless you have something that limits the time for how long those URLs are good for, you cannot assume the state of your server when the user clicks the link

yep, the deep link has two separate paths, /no_eligible_profile and /select_profile

so basically 2 deep links

if the normal case can be handled by a single activity toggling the visibility of widgets based on the API call response, supporting an "override" based on a path segment of the URL could still be handled by that activity

I think you may run into problems, but those problems are more tied to assumptions about the state of the server, not so much rendering the UI

for example...

1. user creates a profile

2. user gets email with the /select_profile link

3. the profile is deleted (by the user, by a server problem, whatever)

4. user clicks the /select_profile link

if my understanding is correct, the default result would be that the user gets an empty list

because you are trying to say "show the profiles" and there are none

now, with sufficient smarts in the activity, you can try to handle these edge cases

but -- bearing in mind that I know nothing about your app other than what you have written here -- my preference would be for there to be one deep link, just to the activity, which displays whatever it would normally display, based on the server contents

hmm, I see. Yes, that would be the way to go. Server checks the state of the saved user and based on that will send either /select_profile or /no_eligible_profile

so a user cannot receive /no_eligible_profile if he/she has made 1 or more profiles which are in the age range

so, there will be 2 methods in the activity toggling the views visibility based on the deep link received/or the api call contents, is what you'd suggest I do?

in terms of whether to have one activity or two, yes

okay, thank you! Mark, this helps :)

Have a good evening!

you too!

Sainath: if you have a question, feel free to ask!

Have a good evening!!

you too!

thanks!