Speaker 1: 00:00 Thanks to [inaudible] for sponsoring this week's podcast. Had to inhibit [inaudible] dot com slash merge to start your free trial and get a free tee shirt. All right, Frank, it's time it finally happened. It took us basically a month and a half or finally talking about dark mode. It's happening. Everybody's talking about it. We're going to talk about it. It's happening. Devices are in our hands. We've updated our applications. It is dark mode. Go time. Frank, Speaker 2: 00:32 this is the fun part. I think of operating system updates of when the OS gets a little bit of a updated look and feel. I'd say overall iOS 13 didn't change much, but we're getting this new dark mode and it's a little bit exciting, but at the same time, James, I support a dark mode forever. Like, jeez, why? Why'd you wait this long? Speaker 1: 00:54 That's a good question. Uh, so I also, in my very first application mobile app that I ever created, uh, was it, that was on Android. I saw my second ever mobile app, my media center. That application on Android supported three different modes, three or four different colors, themes, if you will, light mode, dark mode, things like that. Because Android, so this was just normal Android. Okay, I do want to talk about, this is perfect opening. It had always had the ability to have default theme, a light theme and a dark theme and default took whatever the OEM, so Samsung, LG or whatever spiced up their UI to be. So if they wanted to use comic Sans for their fonts, now your app is using comic fonts, comic Sans. So I would never use defaults and I would always use light theme or dark theme. And what was cool about Android is you set a theme like one string, and if you're using the default native controls, that theme cascades to every single applicant, every single thing across the board. So as long as you weren't hard coding background colors or techs colors and just use the defaults, that theme would do everything for you. So it was really nice from a developer perspective because I didn't have to think about font color black or font color white for lighter dark theme. It just kind of worked. Now my other apps didn't do anything [inaudible] Speaker 2: 02:23 but on pump. So you did, you did really great on one app. Um, the, uh, was that user selectable or once you set it, that was kinda static for the runtime of your app? Speaker 1: 02:36 Great question. So traditionally in the world of Android, it has never been a user selectable until Android 10, which it is officially user selectable from the device. Speaker 2: 02:50 So that's this year. So this really is the year of user selectable dark and light themes, which is funny. You just reminded me that like windows, phone supported user selectable dark and light things from the beginning, it always goes back to windows, phone.net live on forever. Uh, but you know, even early iOS, we did a lot of theming, especially iOS six and below. We were all about apps having very dramatically different themes from one another. It wasn't until iOS seven that everything became boring and just started looking ugly. Um, we used to spend so much time, they even created this whole API, the appearance API so that you could globally override things throughout iOS. But like I said, after iOS seven and I guess for the last five years we've been keeping our apps pretty plain. So this dark delight thing that's come out on iOS 13, it's pretty much the biggest appearance thing that's happened since iOS seven. Speaker 1: 03:50 Yeah, the Android Google has pushed and nudged people before this. So in my media center, that application, you go into settings and select the theme and a lot of Android apps have this because it was so easy to theme and you could have accent colors and you have the red theme and the blue theme. And there was all sorts of libraries that easily switched things. But the one thing that Google did, I think it was in Android, we're on 10 so maybe eight, maybe nine in there is the user could put their device into a battery save mode and the battery save mode would trigger applications that were running that they should go into low energy mode. And do you know what a low energy mode is? Frank dark mode, dark mode. That is correct. It is dark. Speaker 2: 04:41 That's cool. It actually doesn't save any power on an LCD screens. That's a little silly, but absolutely do that. And the, that was not an official thing. Just app developers did that or did the Google apps do that? Speaker 1: 04:53 Well most of the, well that's the thing is some of the Google apps did it. And the Google apps that did it were able to easily adopt the Android 10 API because you are just flipping styles or whatever in your app based on whatever the flag is. There's this, it says it's either night, yes or night. Know that that's kind of what it does. Um, from the API perspective. And um, I would say that yeah, most people, some applications in it, but a lot didn't. I think it's a lot easier to just have one theme. And that's what I've almost always done is I've, I've been a light theme person and I said every single app is a light theme ever. And that's what I've hard coded into my apps and never looked back. Frank. That's been my way Speaker 2: 05:38 until now. It's been different for me because I'm, my first big app I circuit was um, in the earliest days with all the steaming stuff. So from the very beginning I had a theme class in it and it was user selectable and I had, I had like five or different themes to start with. Right now I'm only shipping three. Um, so and then, uh, because that app was successful, I was like, well, all my apps should have theming. And so I just kept copying that code over and over and over and to all my apps. And so every app I've released, I've included it to some degree or another. Sometimes I would just flat out opt out and say I want to dark only UI. So Mo cast is, has always just been a dark mode UI, but continuous had dark and light, Coca dark and light I circuit dark and light. Speaker 1: 06:35 Love it. And in that instance, so I believe that w w we are talking about here, two different things. The Android theme that was built in, you're going to have to correct me if I'm wrong, that is in implicit style and yours are coded, which are explicit styles or do I have those reversed? Speaker 2: 07:00 Uh, I would say, Oh gosh. Well, I mean it's just what perspective are you taking it? So in the case of, uh, my earliest code, that was definitely explicit because I'm just going around saying this should be black, that should be gray, that should be white, that should be yellow. You know, I'm differentiating between darks and lights. So I guess I'm in control. I, I would term that as explicit, but I don't know about these. Uh, I don't know if this is an actual definition somewhere. The implicit ones are what we just gained in iOS six. And it sounds like you also just gained an Android, whereas where if you're using system resources, then they just magically update for you magically. Speaker 1: 07:43 That is correct. And Android, there's a new theme that's not [inaudible]. There's a light theme, a dark theme. So what do you think the new theme is, Frank, please call it gray thing. Please call it gray theme gray theme. So it's not a gray theme. This is a new system Y theme that automatically triggers and changes for you automatically should be great because it's in between. Who knows what it's going to do. Great beam is not the gray theme. It is day, night by night. Speaker 2: 08:15 It's just one word. Or do you capitalize night also or is it day night or day? Night. Speaker 1: 08:21 Capital day. Capital night. One word smooshed together. Cause it's like a big string, right? It's like a Gwinett almost day night. Day, night, day, night. Night, day, day night. And let me actually, I wrote a blog post on how to opt out of of it, which we get to say this for the rest of the podcast. I'm saying sorry everyone. Yeah, it's, it's a theme. Dot app. compat.day night dot. Dark action bar, no action bar, whatever. So Speaker 2: 08:49 some kind of action bar, gray action bar. But should we compare iOS and Android? Should we look at like the implicit system on iOS versus the implicit system on Android? Like how do you take advantage of it? Because we should definitely talk about native stuff. But then I'm gonna need your help. If we ever talked about Xamarin forms on this podcast. Well that's what I, that's what I wanted to kind of talk about because not to say about Xamarin forms, but about this implicit versus explicit and what we should really call it is OSTP control versus developer. Like I am either in control or the OLS is in control. So it sounds like for Android, traditionally the optin here, the default, the default from Google is the S will handle it. Don't worry about theming and setting colors and doing stuff. We got you. Right. Speaker 2: 09:38 And that's also the same for windows. UWP applications have had a requested theme, light or dark. And as long as you don't set any background colors or don't do anything, it handles everything for you. So that's O S operated. And we've never had that in iOS. From my understand. Uh, it was technically there because the operating system technically supported it. Um, because those appearance things that I mentioned before, those were there. And those could technically change any time on you. It's just that they didn't just so it's kind of funny. We've been waiting for dark mode and iOS for years because the infrastructure has been there. And so the changes that happen to make all this work aren't that large, honestly. Uh, it takes very few changes to your apps. If you, if you wrote your app without overriding too many colors, chances are the majority of your app is going to be just fine automagically because of the implicit system and because of the appearance system. Speaker 2: 10:45 But yeah, they did have to add some things to make it easier to use. So what all did they add in? Like, did you have to change stuff in either one? Did you have to change stuff in I circuit, which had or continues? There's had very specific your developer commands versus, um, I'm not sure how you did. Did you have any that didn't have explicit styles in them or have every one of your applications been, I'm in control. I'm Frank Krueger. I'm going to tell you how to look and feel. Um, I would say all my big released apps, I'm fully in control because I'm paranoid like that and I've lived through way too many iOS versions where I want to lock down a few things and make sure things act the same way. But at the same time you develop a, um, a knowledge of what are the minimal things that I have to change to get the style that I want because the less that you override, the better yo adapt into the new environments. Speaker 2: 11:46 And so I've generally taken either very minimalist approach to apply my themes or collaborated all the way down and controlled every little detail of it. So what do I have to do? Uh, right now and pretty much all my apps except the ice circuit because it has multiple themes. The rest of the apps have a settings variable and probably using your library. Jane's a called dark mode is dark mode, whatever I called it and it's a Boolean right now and I'm going to have to move away from that. Basically it's going to be a three way, uh, choice now. Dark mode, light mode, auto detector, use operating system. So that's what I decided because even if I'm the operating systems and a light mode, I think some people prefer some of my apps in a dark mode, so I don't want it to lose the manual control. So I'm trying to have my cake and eat it too. I want all three. I'm fully in control, dark falling and control light, and then give up and let the operating system do what at once or by using the implicit system or just detect which mode the operating systems in and apply my system. I have those two choices. Speaker 1: 13:05 Yeah, this is the exact thing that I did in my live stream last week and I'll put a link to it because I was working on theming and dark mode for Hanselman forms. Cool. And what what I did is I said, okay, let's just see what the app looks like out of the box because Xamarin is using native controls. So it should be okay or so I assume a, but also what I found is that I'm hard coding a lot of background colors. I'm applying different, you know, grays for text and this and that. So these are generic colors. So when I flipped on dark mode, a bunch of stuff just went away. Or for instance, some things are using the material compat which are currently just set to light mode by default. And um, they don't have a API to change it to dark mode. Speaker 1: 13:54 So the background is just white or I manually am setting the background to white. So the operating system would change some things under the hood to make it dark mode, like text entry or a picker or something. And then my other parts of my application would be vanished because if I have set the text to black than iOS doesn't know to change that because I've said it to black. So I started to think about light theme, dark theme, and Frank, I S I, I kid you not, I am literally doing the same thing that you did. I have a of a setting which is an easy new, which I save as an integer, which is a theme app theme. And the app theme is light, dark, or default device. All right. So, uh, and what I'll do is, uh, if you're running iOS 10 13 or Android 10, if that's the how you installed the app, I'll set it to device default, but you can override it to say always want it to be light. Speaker 1: 14:56 That was my thinking at least. And I have these like different API checks to kind of do it and then I went on implementing. But I think that's before we get into that cause, um, you know, I think there's that decision you have to make now at some point is am I always going to have light? Am I always just going to have dark or am I going to have light, dark or, and then how is that gonna work? Both because before you always had to have the setting and now it's like other things to think about which are kind of funny. Yeah. Speaker 2: 15:25 Yeah. If I was going to hardcode just one please. Everyone hard coded dark theme because that means if someone's running dark and the app is dark, that's good. If they're running a home dark and your and you hard code light, then you blind the poor person and it's just rude. So if you're going to do one theme, please, please make it a dark theme. But given the implicit systems that we should talk about eventually, um, it's pretty easy to make an adaptable UI. Now I, I, I would almost argue it's trivial. It's a little trickier when, um, we have to talk about colors and we have to talk. We got so much to talk about in this episode. Um, but Speaker 1: 16:06 well let's first take a quick break and thank our sponsor this week. Insta bug in Sebagh is here to help you understand how your app is doing with realtime contextual insights from your users. That sounds complex, but it's absolutely amazing. What in Sebagh does is it helps you in your mobile team, connect with your customers, accelerate your workflow, and help you release new products with confidence. They of course have best in class bug and feedback tracking, secure crash reporting, intuitive inept surveys. I've used these. They are phenomenal. Just have one or two lines of code. You have in-app surveys and they of course have reliable infrastructure supports over 2 billion devices worldwide in Sebagh is here to help your development team create absolutely astonishing products by helping you easily collect bug reports and feedback from beta testers and real world customers. You can start your free trial today and get a free tee shirt cause who doesn't love t-shirts by going to Insta bug.com/merge. That's [inaudible] dot com slash Mertz and thanks [inaudible] for sponsoring this week's pod. Thanks. It's the bug. They just redid their website. It's very nice. So we just want to, if you haven't gotten there, it's very, very nice. So colors, Frank colors. Because after I had decided toggles, the next thing I did was colors and I ran into, how do I do this now? Because um, there are different things in iOS versus versus Android and there's new things in iOS, correct? Yeah, Speaker 2: 17:39 yeah. Lots of new things. A where to begin. Okay. So we've always had a couple system defined colors. We've had, uh, text color and I think we had, God, I don't even, it was like background coding, you know, it was some other one than we had basically two. They were useless, so no one used them. Uh, so what Apple did was added a bunch of system color defines on UI color itself. I'm an old WinForms programmer. I remember there used to always be a collection of colors that you could query to get, like, what's the system color for this? What's the system color for that? It's the same exact system. The neat thing is, um, if you use these colors without using their RGB values, never inspect them. Don't look, don't look into the box, just use them. Um, then your app just automatically updates magically whenever the OSTP changes. Speaker 2: 18:33 A fun way to find out if you're doing this correctly, uh, if you have an iPad, go to your task switcher and that will pop up all your windows, uh, in a little thumbnail form. Now go to settings, toggle dark motor, light mode, whatever toggle. Then bring up that tax task switcher. Again, if you're using all system colors, it'll actually rerender your thumbnail in, um, the appropriate theme. I find that to be the fastest way to debug. Uh, if I'm doing all my switching correctly, so just go into settings at the toggle, bring up tasks switcher, hit the toggle, bring up tasks switcher. It's annoying, but it's worth it. You can fix all the bugs very quickly. So that would it be your inputs? It's system. And if you're just writing an iPhone app without a overly graphical UI, just re rely on those. There's like 10 of these system colors, maybe even a few more than that. I think that that's the simplest way to start. Is there an Android of equivalent to system colors? Speaker 1: 19:37 So the default for Android system colors is to not set any Android system and it's not set any colors. So when you apply a theme, when you apply it, there are some default theme colors like built into the box. Like Android defines them and the theming, the theme itself inherently has colors that are built in. So there, there are a bunch of them that here at color, blah, blah blah. And there are like the different tax colors and things like that. So those are built in very, very similar, um, to how you do iOS. So I would say they're almost one-to-one. Uh, so if you either don't set it that we'll use the control default, which uses the themes default. So it's kind of like a nice cascading thing. But there is a set of colors from the theme. So if the theme changes, it's good to go. Speaker 1: 20:27 And what I would do in the past is I would actually have a light theme and a dark theme. And when you boot up your application or restart your application, you apply a theme. So when the user would select, I want to go to dark theme, I would actually reboot the application. Finally, there's better ways of doing this was sure circa 2008. So, um, um, but don't be ashamed what I would do or I worked, it was great, it was great. So now at times there's a lot more dynamic stuff that you can do and I think it's a lot better. But back in the day, this is how I did it, so, um, it would just apply the theme and all the colors in it. So you could have, you could have colors in each of those different themes, like your own custom ones. And then if you needed a custom color for white and you wanted it to be black on one and white and the other, then you could flip it based on the theme and they would still have the same index or color ID basically. It's kind of cool like way of overriding of doing it. So very similar to that regard. Um, okay. So there and Speaker 2: 21:32 yeah. Yeah. There's so yeah, that sounds pretty similar except I like the freedom that UI kit gives you because you can still have these in variables and you can still set them as properties. I don't have to put them into XML or give them funny names, they're just variables and I can still pass them around. So I kind of prefer that. But I want to talk about one other color that's uh, brings up a whole nother set of issues. And iOS, we have an accent color. Every app, um, should assign a unique accent color. It's how you separate your app now that we're iOS seven and ugly and boring. Um, so this accent color brings up a few things and it's the general topic of your color colors, things that aren't gray scale, things that aren't black or white. They also have to change between dark and light mode. Speaker 2: 22:23 The way a color looks with a white background is very different from how that same color looks with a dark background. All human vision is relative. We have no absolute concept of color. It's all contextual. It's all about what environment is that being presented in. And so that means for every color color that you use in your app, and that includes accent colors, you need a dark and a light mode of that color. So that means your blue in dark mode might be a brighter blue and in light mode might be a darker blue. It kind of goes the opposite of the direction. And so Apple has set up ways to create uh, your own named colors. That will also implicitly change with the system. You can register saying, this is the color with this name, when it's dark, this is the color with this name when it's light. And so you can create your own colors. But they always come in combinations. You never say my accent colors blue. You say my accent color is these variations on blue. Speaker 1: 23:26 Got it. Yeah. And I'm looking at the dynamic system colors. I think they call them semantic colors. Sure. There because Speaker 2: 23:35 you get the name them cause it's up to you. You're saying what is this color and then how does it adapt under these circumstances. It's kind of an open ended system. You can really leverage it in a lot of different ways. I think it can also take advantage of the image asset catalogs. And so if you have static images in your app, you may want different versions of those images for dark and light mode. And you can do that in your active, um, asset catalogs. Yeah, we'd even talk about assets yet. Speaker 1: 24:06 Oh boy. I cannot wait to talk about that. No, I'm looking at the colors. They have a good, they actually have like the RGB side-by-side to show you what it would look like in dark versus light mode. And they have system TEALS, system rad. They also have a graze, but they also have like labels, secondary label, tertiary label separator. So these are all colors Speaker 2: 24:25 and up that are usable. Yeah, and I want to applaud Apple for actually giving those two different versions of say red because a lot of libraries stop at that point. They'll give you, they'll say, I remember from the old WinForms days like this is the control background color and this is the control text color. The gray color is basically, but they never helped you out with what are good contrasting reds or what's a good looking red. So it's about time that we got good looking colors and not just pure RGB two 55 zero zero red. Speaker 1: 24:58 Well, what I appreciate about this too is that as a developer, that's not necessarily a designer. I might be creating explicit styles. So my own controlled colors and not using the system colors, which is what I opted to do in Hanselman forms. I can now go and wherever I have green I can use different color greens under the hood. So you know, I think that this is pretty good. They actually say in here don't hard-code system color values into your app. Like don't do that. You know? And that makes sense. And how I looked at, you know how we do cross platform is even harder because if you're have a cross platform system color well that doesn't know about the design time. Right. And the Xamarin forms color for all intensive purposes is that now they have a whole iOS or Android tone like specification where they would introduce system blue system, green system orange. But I think the problem here is like what happens when you get outside of this box? Like what happens when you have a designer that's like, I want you to use this color here and this color here. You need to have explicit colors at some point and theming options that you're changing between, right? Yeah. You just have to have that. It sounds like iOS has some sort of mechanism built built Speaker 2: 26:09 in there and it's always pairs of colors. It's always going to be, what does that color with a black background, what is that color? With a white background, you never want to hardcode just one color. It's just gonna look different and it looks terrible. Usually what happens when you do it the default way, your colors just look muddy and dark and so what you end up doing is increasing their brightness and increasing their saturation a little bit. Technically you could write a little automated script that like given one color with a neutral background, give me a variation on dark. Give me a variation on light, but that's just automating the task of the designer. But now that I said that out loud, I'll probably add that to my apps. A continuous did that already. It's dark and light modes. It actually just has a light mode and then I have a bunch of color functions that get applied to all the different colors, so if it sees a black background, it'll turn into a white background. If it sees the color blue, it'll change at saturation and brightness to adjust for being on a dark background. So I got a dark mode algorithmically, I didn't hardcode all of the values. Some of them I did to override them. Speaker 1: 27:22 I really like that method of defining one theme color and hoping that everything works. I mean you've got to test stuff I'm sure, uh, to make sure that those values are changing back and forth. What I decided to do for Hanselman forms, cause I stole this from Kim Phillpotts, he had this theme app theming thing. And traditionally in Xamarin applications you would define a color and then you would say go find this static resource from my XAML or somewhere else in CSS and then go apply it. But a static resource never changes because it's static, Speaker 2: 27:57 it's static. Do we have dynamic resources? Speaker 1: 28:02 Yeah, there's this other thing called dynamic resources and you're good to go. So yeah. So so far they've been around for awhile. Oh they've been around for a long time. What do you use them for in the past? Nothing. Never. I like, I would use them for, so the one thing I would use them for is I would use them for fonts because based on the platform that it's on, if you have a caller or you have a string or you have something that is, um, changed based on the runtime, that's dynamic. So you want it to change? I believe so. Like I would use that, but I'd probably even use that wrong. I don't even know if you have to. The OSTP doesn't change I guess. But, um, yeah, I would like never use them. And the instances where people would show them would be like, you have a string and it's a countdown timer. Speaker 1: 28:52 And you know, I'm like, well, I could do data binding for that I guess. But, uh, so, so one thing that I decided to do for this app, what Kim kind of showed me, there's a bunch of different ways is since, since really there's no way to have a good abstraction of color until Xamarin forms or somebody else creates a great abstraction of iOS, Android and windows system colors and magically gets that working. I said, I'm going to style Frank, every single background, every single control, everything, everything. 100% I said, I am in control of everything. Speaker 2: 29:28 I thought this was the whole point of running a Xamarin forms app. I think I might've said on this podcast, I think the default theme is a little bit ugly. And so I think if you're releasing a Xamarin forms app, I think your app XAML file should be all resources and styles. It should just, but how big does it get? Because I remember maybe even going back to the windows phone days of this just giant hunk of XAML being in my project, I didn't know what it was, but everyone's like, don't delete that file or your Apple work. And so is that what you've created or is it a little better than like a hundred kilobyte Sam old file? Speaker 1: 30:09 It's really not that bad. So let me see if I can find, I have a file called base theme. So the base theme does two things. So I'm going to go ahead and link this to you in our Zen caster and it's not even optimized yet. So I have more things in here then I need to. So what I've defined as, here's a bunch of colors that I want to use and this is the base theme that will be overwritten by a dark theme. So for all intents and purposes, this is my light theme with my application. Yeah. So I have like a primary color and accent color, a windows background, color label color, some colors for like the tab bar and link colors and some things like that. So maybe that's 2030 values. And then what I did is underneath that I've created a style for every single control I'm going to use. Speaker 1: 31:04 So I have a style for a picker, for a frame, for a label, for a refresh view. There's really not that many controls that I use, but basically every control that I use in my app, I say apply this style. And inside of that I'll set the text color, the background color, the placeholder color to a dynamic resource of what I just set up top. So, for instance, on a label, I will set the text color to a dynamic resource of label color, which changes from basically white or black or it's like a gray and then a, a white, you know, type of, of change. So now I can go and apply a style. So it's one property on every single control and I'm say use this thing and there might be a way to say, use this on every frame, but I can at least be selective if I want to have different modes. Speaker 1: 31:53 But yeah, this is what I do and this is what I have like come up with. And I just have a theme changer that what it does is it looks at the dictionary and it says, Hey, I, if I'm enlight mode, merge mail, merge mail, merge, um, the current resource dictionary with the light theme, or if it's dark theme, go to the dark theme and just mashed together as resources. So 20 keys at super fast and since everything is dynamic, it just updates. And that took me honestly four hours to do. And you'll see in the pull request that I showed you. It looks pretty okay. I mean I didn't optimize anything yet, but it looks pretty good. Speaker 2: 32:31 Let me describe it for everyone. Uh, yeah, it looks excellent. It's, it's not nearly as bad as I was fearing. It's not a giant Kong [inaudible]. Okay, wait, it is tech technically, but um, you're not doing too many controls so you have button and labels. So this is a pretty simple app, but at the same time for each of those, you only have five to 10 ish properties. So it's pretty easy to override. I would say the majority of your app with just the small amount of code, about a hundred lines of code, I want to critique a few things in it. You're setting something for that. Have nothing to do with the theme. Like you're changing the default vertical options, the default horizontal options. So I don't like that. But aside from everything else, this is an absolutely perfect way to do it. The neat thing about doing this in XAML is you could share it between apps too. So you could have, I mean it's getting back to the old days of styling your app, uh, as branding. Like this is a Frank app, this is a James app. This is what they look like. So I have absolutely no problem with this. I welcome the days when apps had distinct personalities and a developer controlled site themes. Speaker 1: 33:45 Yeah. And what I'm going to do is I'm going, it's going to go to that Apple page and I'm going to add all those light and dark colors. So when I need a blue, I just use system blue, which Apple has now told me the RGB values of, you know what I mean? You're going to copy it. It's good. Yeah. They already did the hard work of figuring out the RB RG RGB. So like in some instances I might use blue, right. And blue for instance, looks good in light and dark theme, but Apple has told us that it should be a little bit different, which is kind of what you're saying. So I'm going to go apply that. I didn't actually know that until we recorded this podcast. So I learned something today, Frank. I learned. Speaker 2: 34:24 Yeah, it's important. And that's when you can tell someone who did a proper dark mode versus a cheating dark mode because the colors will just look dark and washed out. They have to be bumped up a little bit. Uh, but let's talk about, we haven't talked, we just did a whole lot of explicit stuff for Xamarin forms using your resources ammo file. But, uh, how would you do this on iOS? I just want to mention that all of the UI objects have a thing called a trait collection and iOS developers, we should all know trait collection because it tells us what mode our app is in. Is that iPhone sized or is that iPad sized? And this is important for supporting like side by side mode and all of that. So your app should already be tracking this tray collection. But in that tray collection is a very little simple property called user interface style. And it's either dark or light, easy peasy. So it's just a property on all the UI objects. Now, um, if you want to know when that changes because you should, you should respond to the changes, not just read them once. A, there's also a, a Speaker 1: 35:38 trait collection did change events on all those objects. So you can just subscribe to that event or override the method. However it goes. I don't remember how it works. Something along those lines probably override a method and then that method will get called anytime a the OSTP changes things on you. Yeah. That's the other thing to think about too is you do want it to change the application when it changes, like when the user like are going to pull down from the top or from the bottom and they're gonna go into dark mode and they're going to expect that your application completely updates. And that's what happens to today and it seems to work fairly well. Um, well even with my style, cause what I do is, um, I register for those changes, uh, the same exact way. So I can, um, how Android would work is they will put your app to sleep and then it'll come back and then you'll, you can look at your theme and say, did my theme change? Speaker 1: 36:34 And there's just like a few lines of code, um, to detect it. And then for Xamarin forms, what you do is you create a page renderer and you say, Hey, for every page of my app, here's a page renderer and the page render you can register for changes to the UI and then it'll update automatically and apply the theme for all intensive purposes. So it's kind of cool because when you change a dynamic theme, it changes through your entire application. So it's very similar in a way. And it's, it's quite cool. And in fact to detect like there's two parts, there's the detection and the changing this weekend, Frank. So this would be a week and a half or know sometime in the past based on when this podcast comes out, I did a pull request to Xamarin essentials to enable people to detect app theme, not to register for changes, but to actually get the app theme, the user interface style, light, dark. Speaker 1: 37:29 So you can create, you know, your own employee start start of your implementation in a way. So you don't have to Parson you have something cross-platform. So, Oh, that's real good. That's fantastic. Um, if I could make one suggestion on your PR, you absolutely need that event given what you just said on a Android. I know it's a real pain in the bottom, but there has to be a way to do it. Even if you have to spin up a background thread and have it polling or something like that. I think that if you have the properties without the event, you're encouraging people to lock in. Maybe it's not the worst thing on the planet now that I think about it, but chances are they won't have a dynamic UI then they're just gonna adopt whatever mode the OSTP was in when their apps started. Speaker 1: 38:13 Now that I said that out loud, it's not that big of an issue. It's fine, but you do. I like to encourage people to do the right thing, not discourage them. And that event is really easy on iOS. Maybe it's harder on Android, but ah, whatever. Androids Android is not too bad. The cool thing about Xamarin essentials is that we've already all of the start stop commands for your application. So most likely I just need to hook into that and expose it and I think it would work. Actually. I think it'd be pretty halfway decent, so I need to look into that. I'm on it. [inaudible] UWP literally has a event that you subscribe to. Yeah, it was quite beautiful. Yeah, so, and I think I'm UI screen on iOS implements the tray collection also, so you can just subscribe to the screen. Ah, Ooh, that's really cool part. Speaker 1: 39:08 That was the cool part of iOS is that as I dug in deeper, I realized that it wasn't just a UI view controller that had this property. It's anything up the stack like UI window, UI screen, like they all, they all have one theme. It's actually a general face. Um, it's something like, um, I trait environment because again, it's a part of the trait system. So let's say in the environment that your app is running in, is it a iPhone size is a dark mode, light mode. It's, they're called traits and uh, you can, atop that interface and a lot of the builtin types do. Now here's my fear, Frank, before we wrap up. This podcast on dark theme is opting into that. Do you think that in the future, Apple or Google or Microsoft that they will allow you to configure if an app stays in light or dark, like apps specifics? Speaker 1: 40:04 Like, Hey, I want my system to go in dark, but I want a circuit to stay in light. I, eh, uh, gut feel is no, but Apple surprises me sometimes with the things they choose to implement, but I think that that is such a niche feature that it's just not gonna happen. Okay. Yeah. Alright. So we'll leave it in our app setting screen then. That's what we'll do. Yeah. So for now, iOS now before, yeah. Okay. Cool. Anything else you want to say on dark mode? Light theme? It's really not that common. I thought it was going to be way more complicated. Take a lot of time. It does take time. Yeah, it is for sure. But it's not free. You shouldn't, you need to do some testing. That's what I found. I would tell everyone, if you're doing Xamarin forms, do exactly what you did. Speaker 1: 40:55 If you're doing iOS native, we should, uh, use all those system colors and ignore the problem because hopefully the OSTP will just take care of it for you. Um, and again, uh, if you have to pick one, please choose dark. That's all. Okay. All right. You when Frank, I will change all my apps over to be dark mode, I guess. But yeah, I dunno. I've gone back and forth. I've, I mostly like light theme all the time except for when it's really dark outside. And now that it's getting darker outside, earlier here in Seattle, I actually prefer flipping it, but that's a, that's what I found. It's the old led screen on the iPhone because black is actually not emitting light in your face. That's when you start to appreciate dark mode because it's just not shoving light in your eyes. That makes sense. Pro tip. Speaker 1: 41:48 Don't shove light in your eyes hurt. Hello. It hurts. Duh. All right. Um, that's it. 40 minutes on dark mode. I love it. And uh, I'm excited to finish this fully up and I want to put a package out there, do something, make it really simple for developers to implement it because I went through it. It was easy, but it wasn't as easy as I would have liked. So I'm going to be building those libraries. We're going to be building those libraries. It's all gonna happen. If you have ideas, reach out to us, a merge conflict out, FM hop in our discord, a chat with us. We have a nice little community. There are people also, I put out a request months ago for reviews. We have not had a review on this podcast on Apple podcasts in seven months. Oh, I'll go review it. Okay. Frank will go review, but if you go on reviewed, we will read it back right here. And in fact, we might even send you some goodies in the mail. Um, but you know, go to leave us a review, check out a page on if you do all the things you can find as ever around the internet at James Monson. Magno apropos for Clair M uh, the podcast is at merge conflict of M. those are all the places. Go do the things, click the buttons. And until next time there's been another merge comp. Speaker 3: 42:54 Clicked on Jane's monster Magnum and I ranked sugar. Thanks for listening.