hello, Shay!

how can I help you today?

Hi Mark, Good afternoon (I think)

(though I must say

rhyming is not normally my way)

hehe

So, I haven't yet read everything about Navigation component, but I'm trying to understand something more related to the concept

I have been away from Android dev for quite some time now, and I remember doing some Fragment transactions and stuff like that (ViewPage et al)

those are still there if you want them

From my understanding, Navigation architecture component is not to be used for a whole app, right? For example, if some Activities have different theme styles, is is possible to still use them with one navigation?

themes should not impact the Navigation component

it does not care what your themes are for any given activity

I see. So, If I have a navigation component, I should separate it from activities that, for example are using a theme with no ActionBar?

the Navigation component may not handle all patterns (e.g., your aforementioned ViewPager), but if your UI fits within its supported patterns, you could use it for the whole app

the Navigation component itself won't care about that theme, but your integration code with the Navigation component will

just skip trying to tie Navigation into the action bar on that activity

In my case it's a splash screen. I thought of using one Navigation for splash screen and login screen, and then set destination to the "Main" activity if user is logged in

Does that sound plausible?

IIRC, that is the recommended pattern: have a dedicated nav graph for that sort of onboarding, which then leads to a nav graph for the "main" section of the app

however, if you wanted to skip Navigation for the onboarding and only jump into it when you started the main activity, that is reasonable

Nice, that's what I thought

Right, skipping navigation for first activity sounds good too

One other thing I was wondering, do fragments inside navigation are saved in memory or created anew every time you go to a "destination"? Do you have an idea about it?

IIRC, they are created anew

hmm

they definitely are not just hidden and shown again, and I do not think they are detached and later re-attached

Well, that could be a problem

It sounds a bit silly to do that

from a memory management standpoint, their approach makes sense

from a CPU usage standpoint, less so

It's like if you use Whatsapp and every time you go back to a chat the whole screen is reloaded

It also sounds like bad UX

it might be reloaded, for all we know -- if the chat data is already in memory, you are not necessarily going to know if they are a new set of views or not

part of the Navigation component is an assumption that you're doing other things in terms of app architecture: ViewModel, repository pattern, etc.

so that the fragment is only a manager of views

ah I see

so basically letting the ViewModel/LiveData handle in-memory "remembering" stuff

I am probably not using correct terminology...

that, plus perhaps caching at the repository level, if appropriate and practical

for the level of a chat, that was fine :-)

Well, it HAS been around two years since I've worked with Android, so I might forgive myself

yeah, and those were two kinda busy years, in terms of how Android apps get developed

Yes, this is why I asked general questions only. I like knowing more than being fed how to do every samll step

I also need to read the Jetpack book thouroughly

there will be portions of that you can skim through, as it is a replacement for the core chapters of *The Busy Coder's Guide to Android Development*

other portions, such as the Navigation component, are likely to be new to you

Yes, exactly. I was happy when I saw Navigation, as it reminded me of iOS/macOS storyboard

BTW, if you have another question, go right ahead

Well, to be honest, if I ask now it would be more like teaching instead of giving the right direction

I would ask more about Navigation, but as I said, I am no well versed enough in the new way

um, OK

no problem

Something else though, small thing. I am trying to create a theme for the ActionBar

Everything is working, besides giving the text a different colour than the default white

(i.e. I have my gradient background and stuff)

I have a theme for the App, referencing a theme for TextAppearance, but android:textColor is not working for some reason

first, are you using AppCompatActivity or something else?

Yes, AppCompat, based on androidx.appCompat

OK, and you are using the default action bar, not a Toolbar that you constructed?

The default, but it has a custom actionBarStyle

and, in there, are you setting titleTextStyle and android:titleTextStyle?

no, I set that inside the AppTheme

I should explain myself better

At the moment, I am talking about the OverFlowMenu text color

sorry for misleading you

oh, sorry, I thought you meant the title

No, it was my bad :)

try actionMenuTextColor and android:actionMenuTextColor

will do. I did put the code here: https://paste.ubuntu.com/p/WTScYQTvXb/

It'll probably be more clear like this

"actionMenuTextColor and android:actionMenuTextColor" this didn't do the trick unfortunately

parent="android:style/TextAppearance.Holo.Widget.ActionBar.Title" worries me, as I doubt that you want a reference to Holo there

and, to be clear, you are saying that this theme is not working either?

Yes, the theme is not working

OK, then, off the top of my head (and with a bit of light searching), I don't have an answer for you, sorry

other than my Holo note, which probably is not the source of your difficulty

frankly, all of this is just a mess at this point

(not your code, referring to styling the action bar)

That's fine. I have combed stackoverflow, and it seems I am using the "right" solution :)

you might consider using a Toolbar

Yes, I will consider a Toolbar.

And the Actionbar styling is a mess indeed

Tbh, it seems as if all of android styling is a mess

yes

and, in two years, Jetpack Compose is going to replace all of this, and we will have new and exciting under-documented stuff to work with

so true

Only reason I don't do iOS dev is the need to buy an iPhone, and the pesky yearly 99$

if you have an international market, Android is a wee bit larger -- in the US, I think it's close to a 50/50 split with iOS

I think going into the international market is always better. For example, my country is small, so local market makes no sense

but the price of getting "inside" for android is much cheaper

and with iOS, some things like camera, you Must have a real device

well, I wouldn't trust the Android emulator for camera stuff either -- *way* too many hardware-specific issues

which is why it will be interesting to see how Google's CameraX fares

I won't trust it either tbh, but an Android device cost much less than an iPhone, even an old one (and an old iPhone will not support the user-wanted features, in any case)

agreed, though at least with iPhone, there are only so many models you need to worry about

I wrote two CameraX-ish equivalents, and gave up on both, after concluding I wasn't sure if I would run out of device budget or patience first

sounds right

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

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

Nice

the next chat is Thursday at 9am US Eastern

have a pleasant evening!

Hope you'll have a great evening, I am going to sleep (12AM here :) )