Frank: 00:08 James had fallen a little bit behind Frank: 00:11 and I'm upset because it's actually an area I'm very interested in. But I've been watching the Twitters but not clicking the Twitters. You know like when a thing scrolls by. But you read the headline but you don't actually read the article. I've been doing that a lot. So I need your help buddy. Xamarin has announced hot restart and it sounds hot. I want to know more about it, but I'm too lazy to read. Tell me James, tell me everything you know about it. James: 00:37 I mean, everything is hot nowadays. You got the hot reloads, you've got the hot restarts, you've got the hot UIs, you got the hot hotness, the everything is high. Every, you know, it's so high as it's literally on fire. Like I, you know, it's, it's hot and just, I don't know why, why do you think everyone calls everything hot? Frank: 00:53 I like the idea of hot UI. Is that actually a thing? James: 00:55 Okay. So here's the thing about hot UI. So hot UI is not a Microsoft or Xamarin product. This is something from the, um, the Google team. So what that did is, um, they said we want to have this thing called hot UI. And I was confused. I go, what is a hot UI that this kind of weird. And, and normally they have like a hot reload technology similar to the XAML hot reload, which I'm sure we'll talk about today for like flutter apps and they're going, they ask this hot, you want to go, what? What is that? I don't, I don't quite get it. And what they did is currently like when you use hot reload, you're connected to device or emulator. Like it's the same in Xamarin and in flutter and in react native and all the things really in the, you know, whatever. But you know how um, Swift UI puts the emulator or simulator like right next to the code, Frank: 01:50 like a preview would love that. I was so jealous of that. That's basically all I've wanted out of 90. That's all I want my IDE to be is that split screen of here's my UI and here's my code. It's kind of why I designed continuous that way. Yeah. James: 02:05 So that's kind of what they did. They, they put the Emmy and they said, once you launch in our debugging your app, it puts part of your, your emulator screen into the IDE. And then they sort of took, do you remember the, um, what did we call it? Uh, it was the inspector. Do you remember the inspector? Frank: 02:25 I, yes. I love the inspector. That was a great idea. I never used it though. I was always, I don't know why I didn't use it, I guess whatever for reasons I didn't use it, but I, I love the concept of it. James: 02:39 Yes. So they, they sorta did that where you could see like a property pane of sort of what you did facile. Fascinatingly enough. It's very, very similar to what like WPF and UWP hot reload do already. There's actually a tool when you launch a WPF or UWP app that you can hover over your app and then that will take you like right to the source code. Like so all the, it's like there's all these hot, so many hots everywhere. Doing all rewind, rewind to similar things. I need to know when the hot started. When did this a UWP hotness happen? How many years has that been? Oh, here's the crazy thing is, so is WPF and UWP had XAML hot reloading for years, but they called it something else. They called it XAML editing. Continue. Frank: 03:32 Oh, it wasn't hot. Yeah. So edit and continue is turning into hot. I like that. Hot edit and continue hot editing. Continue, but it's just called hot brand names. They're killing me. You're killing me, but okay, we're going to get through this. Okay. So awesome. So they've had that for a while. Um, we haven't had it on forms. We've tried in different ways. There are different tools. There have always been little tricks you could play, um, ever since we got a dynamic XAML loading to do it manually in Samarin forms. But you're telling me that this UWP hot technology has been made available for forms XAML am I getting that right? James: 04:12 Yes. The hot reloading, the reloading, if you will, of the Xamarin, which means I edit my XAML, my user interface, I hit save and boom, it updates. It's a, it's a hot reload, a hot XAML reload. It's like boom, it's there. It's all up in there. You know what I mean? So that's available. It's been available now for like six months, Frank. So I dunno what you're doing over there, but it's been available for a long time. Uh, I think it rolled out in, it was in preview for, I think since the last build when we announced it. And uh, and then it came in stable I think last October, September, October. So in, in the, in the stable channel for both Mac and PC. Frank: 04:57 So that's it. So that was my next question. Is it on Mac and you just said yes, it's on Mac. So I have been, I'm just out of the loop, man. I have not been keeping up. Um, um, how long ago was that? Six months. You're saying it's stable? James: 05:12 Yes. Yeah, for her, I say I'm wait, what is it? February almost? Yeah, about four or five. Six months now. That's, that's hot. XAML hot reload. Right. So that is just the, the reloading part of it. And now what's cool about this, I do want to preface something that is not talked about enough, which I think will really tickle your fancy because you can use XAML hot reload even if you're not in a 100% Xamarin forms app. Let's say that you're in an app that is maybe fully seen kit, you know, who knows. Maybe that's a possibility. Like I have an iOS app, but maybe two of those screens are XAML. You're like this setting screen, I'm just going to XAML it up. Boom. Right? You can use hot reload, XAML hot reload on those pages inside your app. As long as it's a XAML page, it cannot reload. It's good to go. Frank: 06:00 It's magic. Okay. Love that. Um, and honesty, I assume that's how it works because deep down what's a XAML app, James? It's just an iOS app referencing xamarinforms so it better work for my stupid little instances and all that. So I guess it's just whether you had the um, application class. I guess that's how I would differentiate a forms out from a non forms app. Whether you use the applications class, but one more does it work? Question, does it work on device also or just simulator? James: 06:32 Of course it works everywhere. Can you debug to it? It works if you can debug to it Frank. It works. Frank: 06:38 Yeah. Very nice. Love it. Very good. Okay, so one more question. Does it maintain state James? So say I have a button click and I change a variable inside the view object because I put all my code in the button. The handlers, there's no reason to separate your concerns. That's pointless. So when I'm clicking this button and I'm updating the text field and I changed the XAML, what happens James? James: 07:09 Great. This is a fantastical question. So, uh, in this circumstance here it, it, it will keep your state if your bindings are in place. So if you Frank just do file new page and you lay down some entries and a button and you say username, password, you fill it in, you change the margin you had saved. But nothing is wired up. Everything's going to go back to scratch. It's going to clear it all out. Uh, so it doesn't have the S, it doesn't have a form of its own state management. But if your page has some sort of binding set up some data contacts, so you have a view model or you even say binding context equals this and you have some backing fields, it will rehydrate your view model. So if you do have your view model in place, it will rehire. Frank: 08:04 Okay. So you're getting, you're getting to my questions, man. I was about to ask. So it sounds like it's probably just saving the data context, so that's pretty cool. So if you do everything through binding or at least shove everything into that one object, life is good. Yeah. Okay. That's not too bad. I don't mind writing those classes. Yeah, it's not bad James: 08:25 how I set it up as I usually do my view models first and then my UI. So if you're not in that frame of mind, then it, it obviously it will, you can still lay down the controls, which is probably why you're, you're tinkering with it. Um, so maybe the data matters, maybe it doesn't. Frank: 08:41 So that's just kind of the, yeah, I'm curious. Yeah. I'm curious if there, um, can you control that serialization at all? What if I have like some funky objects inside of my view model because I'm a very sloppy and I don't care. Uh, can I control that serialization or is it all just kind of works or it doesn't work? It's all in memory. There is no serialization man. It's all in memory. Just keep it in memory. Ooh, I love it. Beautiful, great, fantastic. Loving all of this. So if we've had this for six months, that's all. Sounds great. Um, what happened on Twitter? What did I miss recently? Oh, so you, you, you miss out on the other hot, the other Haas, the other hot hot. Can there be in the world change? There can be a lot of hotness from my understanding cause everybody just wants to put the word hot in. Frank: 09:36 Um, or we get all just, you know, maybe like [inaudible] of Waco or something like that. It's, everything's either on fire or it's hot. Um, and so there's another hot, which is in preview now. So this is what you've probably been hearing the rumbles of. If you stepped back into the Twitter sphere, you probably saw people doing this, which is called hot restart, not reload. Restart. What does a reload do? Start. What does a reload do? It reloads. What does a restart do? Frank restarts the app. There you go. Ooh, okay. Nailed it. Okay. Um, I can hot restart. Like I hit restart the computer fan spin a little bit. It gets hot and then the app starts. How is this different from that? James is a great question Frank and I'm glad that you asked. Can I ask you a question though, Frank? Because I think a lot of listeners may not know what happens when you click that button or when you're in a CIC D. cause I saw some people on Twitter recently saying like their bill times are very long and, and their CIC D was very long and, and my first question was maybe you should double check your log, see what's going on. Frank: 10:52 So what I want to ask you is Frank is when you make a change in your code and you hit build or even if it's fresh, you just do file new and you hit build and deploy. What happens? Like what? What is everything that is happening? And let me ask you that twice. What happens first on simulator and then what happens if you go to a device specifically an iOS device? I'm good sir. You really want me to list the steps you think I do remember them all. I mean again, you know in a summary, in a summary form and a summary and it's time, right? Okay, well first, um, all your C sharp code is compiled and all the libraries that you reference are loaded into memory and they're all compiled together. If that succeeds, a bunch of assemblies are output. Then those assemblies go through a linker and that linker tries to throw away as much code as a cat because it's important to get rid of code. Frank: 11:45 Then that code goes through the a O T the ahead of time compiler which converts it down. Depends. In this case, it either goes directly to arm or x86 code or it can go through the V M optimizing compiler, which is what I love to do because I'm a speed freak. Um, but that step is very slow, but either path that you take, now you have executable code that all needs to be packaged up into an iOS app, which involves a lot of nasty things that you really don't want to know about including ping compression. That all gets signed. If the signing succeeds, which is, you know, a 50% shot, uh, then it gets uploaded to the device. But first it has to connect to the device, send a bunch of signatures, do a death star uploading. Once it's uploaded, then it has to tell the device to execute it. Frank: 12:50 Once the app starts executing, the app opens a TCP port and signals that the debugger wants to start debugging the IDE and the app both hope hopefully are talking on the same port and connect to each other. The IDE then sends please execute app signal that signal it's run by the app and the app executes. Done. Beautiful. Yes. That is a, exactly how it works. That's, that's how compilation of apps to a device work. That is, that is 100%. I include a debugging because it's important. You mentioned debugging cause it's, it's hard, but as.net developers, we kind of expect it. That's why we're not net developers. We like our debuggers. That's very true. Now I want to add one additional step here because, Oh shoot, I missed something I thought I would sell thorough. That is if you're on a Mac, what if you're on a windows PC? Frank: 13:45 Well, Frank, you have to connect to via over SSH. You gotta do pairing, you gotta make sure everything's installed. You have to do remote build, compilation, ship assemblies back and forth across the wire. And that's in the middle of all that gobbledygook. And that's not to say that that's like a Xamarin thing. That is like how you compile an iOS app minus the C sharp. It would be Swift, right? And some linker stuff. But I mean it's mostly piling up. I forgot a step that I want to include because it is important. We all put, um, crazy new new gets in that can manipulate the binaries after they've been compiled. So that's an important step that the code has to run through. Also, uh, for those view models, people often use Foti that generates all of your, um, I notify property change events because that's honestly just a painter. Right? So in your compilation step, you have to execute arbitrary code off the internet. How exciting. It's very true. Well, let me tell you how hot restart makes that. Only two steps. The first Frank, let's take a break and thank our good sponsor this week, Ray. That's right. Reagan's James: 14:52 back for 2020 baby, are you struggling to replicate the bugs and performance issues that your customers are reporting? If so, ah, that always stinks. That happens to me all the time and I, I think I'm a pretty good developer. I think I'm not bad. Frank, do you agree? I'm, I'm pretty okay. I like your code. I rarely complain about it. Only rarely, but it's not perfect. And yeah, sometimes I struggle to replicate those bugs and I have performance issues that happens. But don't worry. Reagan is here for all your web and mobile applications. You plug it in just a few seconds and boom, it's going to help you diagnose your problems in a minutes rather than hours. You can kiss goodbye having to dig through log files and frustrating user reports. Ah, no one wants to. Those make development life easier with Reagan's error crash and performance monitoring tools, every single software developer and software development team in the entire world deserves to be using Reagan to help make their software better. Go to [inaudible] dot com to try it for free. Go to a Ray gun.com and thanks Reagan for sponsoring this a week. Speaker 4: 15:53 Uh, Frank: 15:54 thank you Reagan. Yeah, you're a good coder. I wasn't complimentary enough there. I feel bad now. You're a great coder chains. James: 16:02 I'm fine. Mediocre, but all right, so two steps. What if I told you Frank, that it would only have to do the first step and the last step Frank: 16:15 I would say, what are the pros and cons, James? There's nothing free. You can't just throw away these steps without losing something. But I can imagine actually throwing away a bunch of those steps. So which steps do we keep? I guess we'll start there. James: 16:29 Yeah, so hot restart. The idea of it is all Interdev live. We talked about how reloading first of our UI, and that's while our app is running like, Hey, I'm doing stuff, I'm doing stuff. But whenever I make substantial code changes, I add a new gig, I add a page, it's not in my DLL. I need to stop and I need to redeploy. And even when you redeploy a bunch of recompilation step, half have to happen. Now that does become faster than the first packaging of your app, but it still takes time. So hot restart, it says, what if we can help you quickly test your changes whenever you're doing multi file code edits or resource or reference changes and just push those new changes into an existing app, a bundle that's already deployed onto the device. So it keeps that sort of cycle really, really short. Yes. I would say yes, ship it. Now I want this. In fact, Frank, what if I told you that this would make your first build 70% faster and your incremental builds 81% faster? Frank: 17:32 I would say I believe you because a lot of those steps I just listed before, a lot of them are redundant. Uh, it's doing essentially the same thing over and over. They can't do it. They can't store some things for reasons. So that is awesome. I love it. I love it. I love it. Uh, keep going. Keep telling me. Good Mark. Great numbers. Yeah. So, okay, well, so great numbers. So we did a, a, a little test with hot restart with the smart hotel three 60 application, which is a big honkin Xamarin forms application. It's super big, big architecture. Um, and this took the initial build time down from three minutes down to 22 seconds, Frank. Very nice. And that's again from windows. So that's including the transport time, the waiting for the Mac time, I like to call it. That is correct. Very nice. Now, three more steps. Frank: 18:27 Sorry. Okay. Okay. Let me go through. You want a numbers, Frank, let me go through the steps. Yes, please. Okay. Initial deploy, 40 seconds. Hot restart without hot restart. 26 seconds. And you're saying, Hmm. It took longer. We'll get to that in a second. Frank, how about this one? Incremental build without hot restart. No. Hot restart. 40 seconds with hot restart. Three seconds. Yes. That's what I want. All right. Incremental deploy. 14 seconds without seven seconds with 50% slash. Boom, boom, boom. Okay. What's, I'm sorry, what's the point versus run. So build and then deploy. So that's run. Yeah, basically like how long does it take to hit the button and deploy to device? Okay. So, okay, so we're up, I'm sorry. Do the seconds for build and the seconds for deploy again. So first hot seconds. So, so not hot. 40 and 15 hot three and seven. Frank: 19:31 Three and seven. Got it. So 10 seconds versus 55 seconds. Very good. And are you going to give me numbers for running or we're just assuming running as deploy. Running as deploy? Yeah, correct. Cool. Awesome. Love it. Okay. Um, this is cool. I'm not even gonna dig into the details because you said one thing that kind of peaked my interest that it could handle images and things like that. Those are always kind of one of the nastiest parts of the process. It's funny, but like you change resources and it always can trigger weird things. Like sometimes the IDE even today will get a little confused and maybe not deploy your app. And I always wonder about that, like PNGs and things like that. So it was a handle resources like that. Sure does. Yeah, sure. Nice. EPZ man. Yeah. So, so, um, so it'll deploy all of your changes into an existing, um, app, the debug app, if it's there on your device. If it's not there, it will, um, um, just deploy it. We'll figure it all out. James: 20:48 There's magic that happens and then it deploys into it now. And this is all so, so this preview, it's in previous only available, uh, for the windows machine currently. So windows and iOS in Xamarin forms only. So there's your restrictions, Frank Xamarin forms apps only iOS only and windows only with an iOS device. So there's four things that you have to have. You have to have an iPhone or an iOS device, got to have on a windows machine using visual studio 20, 19. This preview gotta be Xamarin forms and it's gotta be iOS obviously. Frank: 21:23 Hm. Hm Hm. I have fields, we'll call those the limitations. Um, so what does a Xamarin forms app count as it does that mean? Like I have my application class like we were talking about before, or if I just reference forms at all, is that good enough? James: 21:41 It's gotta be a full, full blown shebang. Xamarin forms app Abdallah get whole kicking caboodle. Frank: 21:48 Well, no biggie. You can always hide whatever windows that creates. So that's funny James: 21:55 it does that. It doesn't support storyboards or nibs or anything like that, but if you're doing all code, that should work just fine. So Frank: 22:03 that's what I was thinking. So I'm curious this push that limitation a little bit to the edges. Um, that's awesome news for all the windows people. And I mean that wholeheartedly because I, it's always been a bit of a frustration, I think with Xamarin is deployment times from windows. It can be a tricky process and all that. And so not having like a 10% or 20% improvement, but these big radical 80% improvements, that's really impressive. And so while I dislike the, you got to run on windows limitation because gosh, I run windows less and less these days. Um, James: 22:42 they deserve it. I think that's awesome. Yeah, it's, it's pretty nifty. Um, yeah, so, so it's only for a debug purposes and, and yeah, you, you just plug in your iPhone into your windows P sheet and PC and it just connects to that iPhone on your windows PC and goes like, it doesn't, you don't have to connect to a Mac. You don't need a Mac or anything. You need an Apple account and you need to install some iTunes prerequisite stuff and, uh, does magic, I don't, I don't know how any of it works, so I'm not going into how it works about magic, but, uh, just know that you just take an iPhone, you plug it into your computer, pewter and boom and boom. It's done. And I think there's, it's, it's the start of it. So, um, immediately are like, Oh, okay, well this doesn't seem like a tool for me because I'm doing X, Y, Zed. James: 23:30 And while it's called the hot restart, I think how the team and all the blog posts, and if you were to talk to me after I, I announced it@the.net comp keynote last year was that it should just kind of be how you debug an app. And this is the starting point where based on the type of app you're, you're, you are based on your deployment, it'll just sort of deploy, right? It'll just happen. Like whether it needs to do a full shebang, here's everything under the sun compilation, it'll do that. And if it doesn't need to, then it'll just do a quick restart and then just go. So that's really what the from from the team's vision is there. And even though it has this fancy name called hot restart, I kind of think of it as just in the future, let's say if I'm future looking forward, like ideal is just how you debug an app. And then visual studio is just smart enough to figure out what to do, like make my, make everything faster. Visual studio do that. And I think that's in the far into the future that that's kind of what it's going to do, Frank: 24:33 hopefully. [inaudible] so, uh, we talked about limitations. I don't want to stay in the negative side, but are there any, um, other limitations or more like downsides? Like any new technology? There's something I can't do. Like do any of those blog posts that I didn't read, do they list any like known bugs? Any gotchas? Like if you're doing this, it won't work any little things like that. James: 24:57 So if you're using storyboards or nibs, it's not going to support that and just doesn't work. Um, so if you're, if you're using any of that, it's not gonna work. Um, if you're using static iOS libraries and frameworks, they're not currently supported. However, dynamic iOS libraries are supported. Frank: 25:15 Uh, this is the die lib versus dot a thing. So how did you package up your native code? Is it that question? Yeah, I think, um, yeah, this is something I've actually had to learn as a side tangent here. Uh, back in the day we always created static libraries. Dot. A files because iOS did not support dynamic libraries, which is the, um, Darwin, the ma, the macro S, uh, version of DLLs. Uh, so that's cool. Um, that, uh, di libs are actually supported. So I'll make sure anything that I have native code and I'll make sure to, I'll put those. Neat. James: 25:53 Yeah, I think that's really nice. I think the problem with static libraries, I think they have to, they, I think they also have to be signed, I believe. Frank: 26:02 Yeah. It's, I think everything has to be signed. I mean, if you're it, it's weird. I mean the static library goes into your executable and your executable gets signed, so everything gets signed in the end. I don't know. James: 26:15 Oh, magic. That's it. That's basically it. Now obviously you're not using hot restart for publishing your app at that, uh, for debug purposes only. So that there's that obviously part of it. But yeah, that's pretty much it. I think. Oh, you have to turn on the interpreter. So that's, that's the only thing you have to be, I wonder how it all works if you have to turn on the interpreter. Frank: 26:35 Yeah, well then it might have some performance things too, but hopefully you won't run into that unless you're writing a game or something. That's true. That's a good uh, point. Uh, and I haven't actually asked the, asked the team. That kind of doesn't matter though. That's not what you're optimizing for here, which I really appreciate because, um, that scene cat app that you're talking about, I think I'm going to convert it over to be at Xamarin forms app just to be able to use technology like this because I, uh, I had that terrible thing where a lot of the UI is built in code and I change a number and I have to restart the whole, I have to see what the effect of changing that number is. And you know, it's not bad. I made the app fast loads that fails as that runs fast, but it's still terrible. Frank: 27:23 So any little advantages here, I'll take, you could totally have that application. You could just have a custom control, which is your current scene and then all of your stuff around it to be honest with you. Oh, that's fascinating. Oh yeah, no problem. Yep, I can, it's easy to run a Xamarin forms control. You just shove a, what do you, you have to, uh, create those Xamarin forms control. Then you have to go over to your native code and create a renderer for it. Add an attribute and that's about it. And you're kind of good to go. That's it. I have no trouble doing any of that. Easy peasy to be honest with you. I mean that's it. Yeah, it's pretty exciting. The, the, the, the, the development team is just doing some awesome stuff and it's quite exciting cause, uh, I don't know, for me, I don't know if you remember when you got started with, uh, Xamarin over a decade ago. Frank: 28:20 Um, um, yeah. W you know, no, nothing existed. I mean, it, I, I could, you didn't, I couldn't deploy if to an iOS device via windows machine. Like, I think that Zara might be the only thing that you can, I mean we didn't have a debugger James in the beginning. It was all print F debugging when I first started. Yeah. My good. Yeah. So like the fact that I could deploy it all was a small miracle. If you use generics it would crash. So you know, we've come a little ways dynamically to point generic code through [inaudible] interpreters and all that. Great. So, uh, I have to ask the obvious question now. It's the XAML hot reload work with hot restart. Can you enable both technologies at the same time or does the universe like, I don't know, implode? This is an absolutely fantastical question and I'm so glad that you asked an absolutely yes. So the, the cool part here, you kind of sad if they didn't, if I'm on the cool part here is when XAML hot reload was enabled, the development team did something really cool. They told visual studio, this must be, might be a windows limitation, but it used to be like if you were debugging you try to change source James: 29:42 code, it would be like, nah, you can't change source code. Frank: 29:45 Oh my God, I hated that. I hated that so much. I think that kind of drove me away from visual studio for awhile. I, I, there maybe was an option, a way to turn that off, but overall I just found it insulting. I'm like, no, I want to have the app running while I mess with the code. How else do I know what code to mess with? Yeah, James: 30:03 don't tell him, don't tell me how to code IDE. I'll tell you why. I'll tell you what to do. I paid for a license. Um, so they turn that off. And what's nice is when you do your XAML stuff, you hit save it updates and if you go make code changes, um, it will do, squiggly is under all of the new code that you wrote and say, Hey, you need to restart your app to get these code changes so you could write full new pages. Frank: 30:34 Yeah, it's nice. So fancy. I love visual studio. Gosh, it's such a good ID. I shouldn't use it. You really shed. You get, let me think about using it. At least at a minimum. So it sounds fine on a Mac. I can run it in a virtual machine. That's true. That's true. You got that Mac pro, iMac pro Mac pro. You get the Mac iMac pro. No, but you know what James, I kind of like it, so I figure, okay, something happened with my iMac. Sorry. Quick, quick divergence here. What? What happened? That's not hot. That's cold. Cold, hot. Oh my gosh. Oh my God. It did hot. It literally did. It did well, not that bad. I blew up one USB port though. So I was playing with my electronic stuff as I do and little PSA, little public service announcement here. I assumed that if you go through a few USB hubs, that there's gotta be some circuit protection involved in that. Frank: 31:35 You know, just a little bit like a few somewhere, something. I don't know anything. Well, I was fine with the electronics. I did something bad, something terrible. And all of a sudden a bunch of USB devices stopped working. The computer was fine, but the devices stopped working, troubleshoot, troubleshoot, you know, unplug replug play, play, play, play, play, play. Find out that the USB port on the iMac itself is blowed up and won't recognize any devices. So I got a piece of red tape and I put it over the port. I played taps, said a little prayer, and I said one port down, four to go. It's just so sad. So sad. Oh, not okay. So what I decided is when I've blown up all four ports that I'm buying a macro. Yeah, there you go. Buy that Mac pro. Get the Mac pro. Do it. Do it. I'm ready. Ah, that's not this year. No, I know. I felt like such an idiot. So everyone be more cautious than me. James: 32:40 Don't, don't run your IOT electronics off your computer power supply. It's just dangerous. It seems dangerous. Yeah. Uh, I'm sorry Frank. Oh wow. Thanks. I didn't mean to end the episode on a downer there. I just had to tell you it's, it's been weighing on my mind all week. Uh, well that's going to do it for this week's podcast. On that note too hot, too hot, too hot. Frank got too hot. Yeah. Anyways. Um, that's it. That's all I got. Anything else you need to know about that? Did I just do very much? Yes you did. Uh, and I'm filling in so many details in my head with my imagination. So I think it's awesome technology and I'm glad that you were here to explain it to me so I didn't have to use my eyeballs. I also want to say that I think that it's good that you can come into the podcast and say, listen James, I'm, I'm way behind. James: 33:36 Please catch me up. And I think that's okay. Because technology and the libraries, we use, the IDs that we use, the features you use, they change so fast, Frank, everything does change really fast. It is highly fascinating. I was talking to someone on Twitter and they um, they were wishing that they had a relative source binding in Xamarin forms like WPF and UWP does. And I go, relative source binding, let me give a breakdown here. And normally a binding is, I have this view model, I bind it to username property done. But let's say you're inside of a list and you have a button inside that list and you want to actually bind a parent up. That's relative source binding. You're saying, I would like to bind to my parents instead of this. And you go up, I'll chain basically it's a feature, it's been around for awhile and they're like, you know, I don't have it. James: 34:24 I go, you mean this, this feature. And I sent them the documentation and they go, I don't see it. You know, I'm using Xamarin forms four dot two or whatever, which is now six months old. And I go, yeah, we released it in four dot. Three you know, Oh, you know, and you know, just one version. We like added this whole new feature. You know, it just blows your mind, but it's hard to keep up. So I get it, I get it. So yeah, I couldn't even track what you just said that or we might have to do a whole episode on that. So I won't pick your brain now. But I have questions. Well, if there are features that you want to be updated on, let us know. Good. Or merge conflict out of fam or hit up. Hit us up on Twitter at merge conflict FM and yeah, let us know. Hopefully you enjoyed this podcast. Maybe you love other pro developer productivity tools right into the show. Let us know that you're like, Whoa, this thing is so cool. I use it and this is so awesome. We would love to know about it. Hit us up, let us know. But it's gonna do it for this week's merge conflicts. So until next time, I'm James and mag now. Frank: 35:21 Okay. I'm Frank Krueger. Thanks for this.