hello, Kai!

how can I help you today?

Hi there

Do you happen to know how to "globally" change the Font/Typeface of DialogFragments?

have them use a theme that changes the font/typeface

How would I do that?

call setStyle() on the DialogFragment, passing the theme resource ID as a parameter

do that in onCreate(), before you're asked to inflate any layouts

alternatively, don't worry about at the level of the DialogFragment, but instead deal with it at the level of the individual widgets, pointing them to an appropriate textAppearance or style

You mean like a TextView?

yes (or Button or other things that extend from it)

TextViews in general pick up the font and color I have set in my theme. It's Dialogs that give me a hard time.

well, a dialog does not have a font, as a dialog does not have text -- widgets inside the dialog have fonts and text

Some pieces of DialogFragment seems to not pick up those changes.

As far as I can see those Widgets inside the Dialog don't pick up what they should.

But tbh I am quite confused about themes and styling. It seems to be quite the pile

it is a mess

of things one needs to know in Order to do it properly

warning: it looks like 37 Signals is having Campfire problems: https://www.basecampstatus.com/

so, we may have some chat interruptions, since this is a Campfire chat room

getting back to your problem, push comes to shove, control it at the individual widget level

Like setting a custom font and fontcolor for all TextViews? And that will be picked up by a DialogFragment?

Or rather the TextViews inside it.

yes, either by android:textAppearance or style attributes on the <TextView> element

Hi.

Hello

Kai: let me take a question from Mohd, and I will come back to you in a bit

Mohd: hi! how can I help you today?

Yeah Mark, I need some projects or libraries suggestion to showcase on Github.

um, I don't know if I can really help with that -- create something that you think that you will use enough to be willing to maintain over time, I guess

Okay..No issues.

if this is to try to impress recruiters, I can tell you that I am looking more at general programming techniques and the overall presentation of the project, rather than what problem the project is trying to solve

so, for example, a well-done README is well worth the time to write, as it is the first thing that a reviewer will see

and it shows your communication skills, in ways that pure code cannot

but, in terms of what the project should do... ¯\_(ツ)_/¯

Good suggestion. Thanks.

let me take another question from Kai, and I will switch back to you shortly

Kai: back to you! do you have another question?

Not right now. I am just baffled at the complexity of something as seeminly simple as "change the font and font color for the whole app"

well, bear in mind that fonts were not a first-class resource until Android 8.0

prior to that, we were using libraries like Calligraphy

And trying to understand why a particular Dialog in our App doesn't pick up the font in the "Title" (if it is the real title, that is).

if you are using onCreateDialog() and AlertDialog.Builder, you are probably picking up a system theme

(BTW, hello marekdef -- I will be with you shortly!)

It is the "alertTitle" apparently.

A system theme that is not the Theme I have set, you mean?

It does pick up my color though.

yes, I mean Theme.Material

(or some variation on that)

but, like you said, it's a mess, and on my client projects, we typically just hammer on things until they behave

I run out of places to hammer on ;-)

(and on my own projects, I just don't change the font, because life's too short)

Or rather ideas on how to hammer and where to hammer.

But I'll try the ones you suggested.

if it is your widget: use textAppearance or style

if it is not your widget: that's likely to be a problem

I think it's the "built in" Dialog-thing.

Even though I could probably replace it. If I understand how our Dialog classes are made up. There is like 15 of them, with 3 base classes.

if you want complete control over the look, do not use AlertDialog.Builder and onCreateDialog() -- use onCreateView() and inflate your own layout that you control

let me take questions from the others, and I will come back to you in a while

marekdef: hi! how can I help you today?

Hi!

let's say we have some product catalogue with pictures

in the designs some have dp(s)

some are full screen width

and now there is idea to conserve space to request images according to device density and resoltion

so if the device is small it will request for smaller picture

by "request images", do you mean downloading them from a Web service or other online source?

yes they are dynamic

some url(s)

probably fetched with glide

I just wonder if it really makes sense

I can tell you that I have not done much of that sort of thing

assuming we care about offline first

and we fetch those only once

I have used different requests for different image sizes, but that was for cases where there were clearly different roles (thumbnail versus full size)

I tend to think that downloading biggest image

and scaling it down for the views would really be no different

the difference would be in bandwidth and storage, mostly

but there is another argument that scaling images drains the battery

but I think that code to download images would become more complex

while scaling images may consume more CPU time, that's really not a thing that I would worry about

by which, I mean that there are lots of other things that I would worry about first from a battery consumption standpoint

allright

and, depending on your use case, you might elect to only scale once (and persist the scaled image), rather than scale on each read

so, for a thumbnail-versus-full-size situation, having separate URLs for that is reasonable, as the resolution difference may be massive, and you may want better server-side scaling algorithms

but for smaller differences in size, I agree that it seems unlikely to be worth the engineering effort

however, your server team may have other arguments, such as server bandwidth

well in fact this is server team initiative

but as I said, once downloaded I hope glide is aware of cache headers on the server

and will not download images twice

I am uncertain whether Glide does that or it relies on the underlying HTTP client (such as OkHttp)

yes, maybe there

but, one way or another, you should be able to get HTTP caching working, if the server is setting the appropriate headers

yes I think they do

let me quick check in with Kai, and I will return to you in a bit

Kai: back to you! do you have another question?

Nah, still trying to figure out my "special case"

OK, if you come up with another question, let me know so I can come back to you

in the meantime...

marekdef: back to you!

oh :)

very random questions then

I have custom view

it needs two constructors as far I am aware

I have private method that initilizes the view

called in each constructor

I would like to keep it under the constructor so is easy to glimpse there

what the method is doing

but there are some purist around :)

that say "private method must be at the end of the file"!

ofc you can browse in studio the private method

and hit return ctrl, alt <- (AFAIR) to go back to the constructor

but I prefer visible distance

I guess that's a question of preferences

or believes

beliefs

yeah, I can't tell you what coding style to use

sure

related question, you have attrs, styles, dimens files

for custom view I create custom_view.xml I put all attrs styles dimens related to that custom view

but I wonder should I create cust_view_attrs.xml, custom_view_styles.xml ...

or put everything in global files

I try to minimize the use of custom views

historically, my client projects that have used them just have attrs.xml for the project, not one per custom view

but, your approach seems reasonable

I am getting to the same conclusion, using custom views is very expensive

I just find them to be a pain to maintain

like they always behave bit differently than system views

and they lack features

that you would expect by just looking at them as system views

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

next chat is Saturday at 4pm US Eastern

thank you

have a pleasant day!