Speaker 1 (00:09):
Frank, I have some exciting news. Oh, I love news. Please don't let it be virus related. Not interested

Speaker 2 (00:17):
for the very first time. Frank [inaudible] adjacent for the very first time. Frank, I'm attending WWDC.

Speaker 1 (00:25):
Rob. Oh, now I get the joke. Yeah. Punchline. But I'm bump, sad trombone. Um, do you want to explain yourself?

Speaker 2 (00:36):
You're all attending WWDC. Yes. And we're all attending build angle IO. We're attending all of them. Frank. We're doing it.

Speaker 1 (00:42):
I made a, I think it was a really funny joke on Twitter. I said, these virtual conferences are going viral. I thought it was kind of funny. It's funny. They're going by. Okay. I get, Oh, I get it. Yeah, I got it. I got to stop. Okay. Uh, but I'm pumped now.

Speaker 2 (01:01):
Traditionally we have always watched the WWDC keynote live usually together. Back in the day, in the Xamarin days, we would all get into a room in Boston and like we would all, or in San Francisco, we'd all watch it together, like all the engineering and the evangelists. We would all be there during this time. Um, I've also gone to Google. I, yeah, but for dub dub DC it's a lot harder to get tickets, so it's hard to get tickets for all of them. But I'm really excited this year because there are so many interesting topics that I don't want to have to wait weeks or even days for. I there I can just tune in if I want to. I think, I don't know. No one's announced anything. I'm just assuming that this is how it's going to work. I can just go and watch stuff on demand, like live and I'm excited.

Speaker 1 (01:46):
Yeah. I, I'm hoping so too. Um, I think the general trend has been in that direction as far as I know. Um, they were releasing videos maybe the day after last year. This is Apple and Microsoft has oof. Wow. Like they have, they usually release videos right. For at least for their big conferences and things like that. So I think, um, the big companies have definitely been gearing up for this. This is really just like the stress here where they're just, you know, it's all in and so they have to rely on it. I'm curious to see if, um, the WWDC app gets any like, cool upgrades or any like, I don't know, chat room stuff. Maybe that would be disastrous. Maybe they better not change it.

Speaker 2 (02:30):
Well, I dunno, it works fairly well on Twitch, but the problem is if you have too many people, you have to have moderators. It's a whole big or deal. And sometimes people can't be trusted. Frank, that's

Speaker 1 (02:40):
it. Bots really, bots can't be trusted. Yeah, let's just be honest. Well, they would have to invent some kind of virtual currency. They would have to come up with a subscription model, some kind of emoji support. Like, yeah, it's a whole thing.

Speaker 2 (02:51):
There's only some digital streaming software that was out there that already did this, that we had talked about last week, funnily enough. But, you know, I'm actually, uh, I listened to another podcast, a gaming podcast that you've asked gamer podcasts for like years upon years now, and they were disappointed that [inaudible] was getting canceled. Um, and that everyone's doing sort of streaming keynotes. And I've, I've went to a knee three a long time ago, but I've always watched Nintendo, Sony and Microsoft stream their keynotes. And they were joking that maybe all three of them will fly to a remote location and I'll watch all the keynotes in any sessions from a hotel and like have like a spa [inaudible] kind of a keynote. And I was like, Oh, that's kind of interesting. Maybe I'll do like a WDC like mini destination, like just you and I can drive somewhere, maybe a to Brian's house, cabin in the woods and then watch the WWC keynote.

Speaker 1 (03:43):
I liked the idea of having like a big projector. Maybe we can just get like a nice big room with a nice big projector. That'd be kind of fun. I think the flying part doesn't sound too attractive, at least today. Hopefully things will calm down by June a little bit hopefully. And so, yeah. Um, but yeah, I would drive, we can do a driving destination dumped up DC destination dub dub, dub DC. Nope. Doesn't make any sense. Don't go with that. Anyways, that was my big exciting news. So there's that. I, it really is kind of crazy. I didn't know they were going to, I didn't, when I've made that terrible joke, I honestly didn't think that so many things would change. So it's going to be a really interesting year and it is, I mean you made a point. It's going to be kind of fun because yeah, everyone will be able to attend. Maybe I'll actually pay attention to Google IO this year. Who knows. Stay tuned.

Speaker 2 (04:34):
You never know. Will Frank care about a Google product? Who knows? It's a mystery. Uh, all right, well I have an actual topic, so no more virus talk, um, because we're five minutes in. So that's as much as we're allowed to talk about it on this podcast because I have been building an app live streaming for a year and a half now. The Hanselman out forever. Right. And I recently started to swap out a bunch of third party, like media playback controls and a bunch of other third party controls with a built in video players and audio players that Samarin forms has. I started to actually add more functionality due to this, to the application. And when I started to do non data things. Okay. Because when you do data things like displaying a list, doing some input, navigating around, um, the entire model of architecture, whether using MVC and VU MVVM the data binding stuff, that all works really well.

Speaker 2 (05:45):
The whole idea of here's a bunch of data, display the data and when I click on something, go get the data. The problem I started to have when I started to go deeper into making my application play audio and video back elegantly is that that stuff doesn't really play nice with these architectural models of completely separating your view model and your view. So what I started to do, Frank, was just put all the code in the code behind or wrong in the code behind the UI. No one cares. It doesn't matter. Frank put it all the co bind and I was very happy. And that's what I want to talk about today.

Speaker 1 (06:32):
We're talking about not MVVM. Is that a thing? Like it's going to be not, um, this is scary chains because I know you love your MVVM and I use your MVVM helpers. So this is, this is quite radical. I hope it's just a temporary thing, but we'll, we'll talk our way through it and find out what's really happening here. But I can take some guesses. Um, I, I deal with media elements too from time to time and they're quite procedural. It's like call this function, wait for this event, do this thing, do that thing, coordinate with this other thing. There's a lot of procedural wisdom and coordination to be done and it's hard to do that in a declarative way with data binding and view models. Did something like that occur? I'm guessing?

Speaker 2 (07:21):
Yeah, I mean I think you really somewhat hit the nail on the head. I think it comes also down to that there is fundamentally a piece of user interface that has so much to it. It's not just displaying, it's not just displaying data or something that's static. It is dynamic. There is something that has to load that you have to skip forward or back that um, requires input that requires a direct connection to the source. And that's the difference in something like this media playback is that all of the other UI can be very loosely coupled. But this specific piece of user interface I think really needs to be tightly coupled to make it good. Um, to be honest with you because of the points that you made.

Speaker 1 (08:18):
Yeah. Um, so I want to delve into whether it's a performance thing or if it's a correctness thing, like why do you feel the need to kind of abandoned the binding system? But I'm also playing devil's advocate because I don't use data binding. I've never, I've never bought fully into it. I think it's very nice for, this is all my opinion. This is, you know, speaking for myself here, it's nice for entry forms, data forms, like web forms. Honestly. Where do you have a bunch of text boxes, very basic input controls and you know, some validation stuff like that. MVVM absolutely glorious for those scenarios. Um, but when you're coordinating of million different services and trying to pipe through a bunch of data, uh, designing declarative models, I keep falling back on that, these declarative models. Cause that's what I think of with um, data binding and MVVM is you're saying, here's the data I want to present. It's nothing about behavior. It doesn't talk anything about change or what happened? How did this change data change, how should it react to it? It's just here's the data, do something with that.

Speaker 2 (09:25):
Yeah. And and specifically I'm still using a lot of MVVM data binding in the application and even on this page to display the title to um, to navigate back and forth between some different pieces of content. So to display some things and gather the data. There's a view model. And when I went into this sort of user interface, um, set up, I started headed to take a step back and say, well why, why would I want to put it in the view model? Right? The whole idea of the view model is to separate my, my general business logic from a UI and also to make it very testable, right? Cause the ideas, I can have a, a can call a method in my view model. It should go do something in return, something. And that should be testable. But what am I testing if I'm somehow telling the media player to start buffering, stop or start like it didn't really make a lot of sense to me in a way because the media element in its entirety is doing all of the heavy lifting. I am just giving it commands to do. And those commands are all 100% UI commands.

Speaker 1 (10:43):
Yeah. That's why I just keep falling back on. This is procedural ism versus data here. You know, this is step one, step two, step three, wait for event, step four, step five versus here's what I want in the end. That declarative thing, I keep falling back on it. Um, um, uh, yeah. So I'm glad that you're sticking with data binding for the majority of your app cause that makes absolute perfect sense. Um, I'm trying to think though. Um, could you give me a little high level overview of what media controls you're talking about? Informed. So you mentioned like it's going to have play pause, probably some kind of skip forward, skip back. And are these like async functions I assume?

Speaker 2 (11:24):
Yeah. So, so here's the, how it's, it's sort of set up in a way is there's a new media element control inside of Xamarin forms. And this is a very, very cool control because what it does is it can play audio and video on a control, just it's there. Um, and it does a few things. So it is able to seek to a location. You just set the current position to whatever you want. Um, you can tell it to start playing, to stop playing. You can have it autoplay. Um, you can, um, yeah, that's basically about it. It's all you start, stop, you know, load, here's the, here's the, the thing to play and then go from there. And you get events, right? So you get an event when the media is opened. So here's an example is when the media is opened, which means that it either is a file on disc or it's a URL and it's, it, it, it's candy played.

Speaker 2 (12:27):
Um, I do want to, two things. I, uh, first see if I should seek. So if I should go to a position. So whenever the user is watching a video, I sort of save the position like when they stop or whatever. So if they have never watched the video before, as soon as the media is opened, I say media element play. Um, and, and then I'm done. Um, else what I'll do is I will tell it to go to a position of specific position and then hit play basically. So that's what I'll do. And whenever the user navigates away, I will save the current position and stop the video.

Speaker 1 (13:05):
Yeah. So did you try the MVVM way? So I guess the MVVM way would have been, you would have a, is playing Boolean property on a um, view model and then you would have a trigger on that whenever it changed. You would try to keep the state of the view model in sync with the state of the media player control. Even though it's not a view, it's acting as the view here. Did you try that approach at all and you just didn't like it? Is that what happened?

Speaker 2 (13:33):
I think what I would have had to have done well here is that I would have had to, um, I would've had to pass the media element to my view model. And that way I could actually set, I could always day to bind the position, but I could have said I couldn't hit, I can't hit player stop. Right? There's no way to from my view model tell it to go right. I could have done, um, something that we call event two command. So this is a cool thing in MVVM which allows you to take any event. So normal event handler, like, um, someone clicked on something or the media opened. In this case you can create like a little adapter that says, Hey, whenever this event happens, actually call this command in my view control or my view model. So when that media opened or when the media failed or something, I could have gotten a command that I then could have played it or done the position. But then again, like how do I tell it? How do I go the other way around where I'm telling from the view model, go call this method on the element. And that just seemed like a lot of hoopla I guess. Like how do I even text that? You know, I mean

Speaker 1 (14:52):
it sounded, you know, just high level architecturally it didn't sound too bad. Like if everything you just said could be expressed in, you know, three words and code fine, right. You know, turn this event and do a command on this command, you know, hit play, hit pause, whatever you gotta do to that object. Um, but I guess it's really just, it comes down to how much work is it actually to set up all that infrastructure and as you said, is it worth it? Like what, what are you buying yourself? And I'm trying to decide if there's anything to be gained by testability and I'm still debating honestly, um, if your view model needs a direct reference to the media element, but I think, um, unless the media element was set up itself to have like bondable properties and all that, yeah. You're kind of stuck with that procedural. Yeah. Play, pause calling commands. Yeah.

Speaker 2 (15:46):
Here's another one. Here's another one for you is, um, I have this in a modal dialogue pop up and um, whenever the user wants to leave that page, there's a X on the top right to like close it, uh, you know, standard sort of modal dialogue that you would expect. Um, but I don't want that X to always be there when the user is playing the video. That'd be kind of annoying, right? So what I do is I have a little timer that says, Hey, every after three seconds fade away, like fade that button to zero. And then if someone taps on the screen, it will fade that X back in and restart the timer and then faded away so you can then close the application. But that is 100% UI work. I mean, I'm literally checking opacity, I'm doing an animation and I'm, you know, checking, um, I'm starting and stopping timers to fade in and out that control. And I was like, I don't, I could do that I guess in my view model, but I'm not really sure what I'm buying there. Does that make sense? Like that's just another example from this page.

Speaker 1 (16:59):
Yeah. Yeah. I mean these are all the arguments I was giving 10 years ago. I just really want to hear them echoed back to me cause it's just delightful.

Speaker 2 (17:06):
Well, let's be back going Frank, but let's first take a break and thank our amazing sponsor this week. Sing fusion. Yessing fusion is back sponsoring the pod for 2020 and we cannot thank them enough. Listen, if you have never using fusion, today is the day, March 16th that day when this podcast comes on, when you're probably listening or after today's the day for you to try seeing fusion in your application. Listen, go to sync fusion.com/merge conflict. They have the world's best UI component suite for billing applications, for anything, web, desktop, mobile apps, you name it. Basically any language, any platform, you're there. I use it in a bunch of my Xamarin applications. It gives you beautiful charts, graphs, clickers, tree views, tab, use cards, carousel view list, views, dashboards, anything that you could possibly think of. They even have a free community edition. It's absolutely stunning. You can go on there, download the trial applications, give it a go.

Speaker 2 (18:04):
They just updated their website. It looks absolutely stunning. They're doing great work. Today's a day. Go putting fusion into your applications. Sync fusion.com/merge conflict. Thanks. This infusion for sponsoring this week's pod. Thank you. Think fusion. It's good to have them back. Yeah. Awesome. Oh, fancy controls. Hey, so I think something we're getting at here, um, that we don't talk about enough, but I love talking about is just how messy UIs are and how convoluted some of the code gets to be. Humans are kind of messy, funny creatures. The way we want things to work, the way we expect things to work, and that always, it doesn't always fit with our beautiful ontologies of how code should work and our architectures and all these things. We, I mean, if you want to make a user interface that is delightful to use and just feels natural and feels, yeah, just good from a user perspective, you have to put in a ton of code and a ton of work.

Speaker 2 (19:10):
None of that is free. The default controls are okay. They're satisfactory, but to make a UI good. It's a lot of effort and it's a lot of messy code to be thoroughly honest. And I've kind of always felt that way. So all these attempts to make that code organized and to deal with it, they're great attempts. They're Valeant efforts, but sometimes they break down. Yeah. I just think when you're dealing directly with the UI Soma and interactions with the UI, anything beyond a simple button click. I just feel like he got to get in there. And in fact, I look at a lot what like Kim, Phil Potts does on his stream when he's building these beautiful, um, user interfaces and they're all almost Penske sharp, which by itself is a very UI driven, um, or a code driven UI. But when I look at his, um, source code, all of his animations, all of his touch, the drag events, I mean, those are UI interactions.

Speaker 2 (20:08):
And for those you just can't put them into another source. Father intrinsically, you can put those together. And it brings me back to the day, like I remember the first iOS application I made and the MVC sort of approach of it, the controller approach of it, which was, Hey, you have at the time and NID file, but you have this Nim file and there is a button. And when you just access it from the code behind and like you do all of your interactions in that view controller because it's a view controller and it's going to control the view. And when you're doing interactions, when you're doing anything, you simply do it there. And I'm like, why am I trying to make my XAML. Dot. CS file clean? Why does it have to be one line of code, which is initialize and create the binding? Like if I want to create these beautiful sending things, you're right. UI is messy and I think it's okay to have a little bit of messy stuff back there. Yeah,

Speaker 1 (21:15):
that's what private is for. Yeah, that's true. That's true. No one's allowed to see that. Or Recode regions, uh, below be animations. Do not read the animation code. Uh, you're making me think though. Um, we do like our extremes because you said MVC and that's kind of my preferred model. That's how I generally write my apps. I'm a little shorter than that sometimes. Usually I'm MC model or MV I guess. Yeah. Skipsy um, but the problem with MVC is when you're doing something that's, you know, a big long form or has a million different labels in it, each one dynamically updating, it's honestly a pain. It's a pain cause you have to subscribe to events, manually set the properties on the views, do all that stuff. Uh, so I think that's why MVVM was created because we're all like data bindings, a pain, we need a better way to do data binding. But it's funny because we swung 100% in the other direction of, okay, let's do everything with data binding. It's like, no, you know, actually the happy. Maybe there's a happy medium ground between NBC, NBC and MVVM or maybe just one suitable in some scenarios, whereas the others less suitable. It's interesting. I'm really liking this topic anytime I can. Are you, sorry. Anytime I can argue MVC versus MVM it's a good time.

Speaker 2 (22:40):
No, I mean I think that's a good way of putting it. Where is that happy medium in between? Because that's what I'm trying to reach in my code. And I also believe that when you swing too far in one way it becomes, it becomes a little bit hard to attract a new developers or have it the onboarding process easily. Because if someone just wants to create an application for iOS or Android or even was Amerind right, you should be able to just file new, put some stuff in there, do some things in the code behind and be done. Like that should be sort of the on nice elegant onboarding when you have to learn an entire architecture to get hello world on the page. I feel like that is an issue. Yeah.

Speaker 1 (23:28):
I was trying to think also, um, the new kind of react architectures out there. So react itself, um, fabulous in the F sharp world or um, blazer itself or even, um, w what's the blazer for? What's it called? Blazer. Mobile bindings. Blaser mobile bindings. Experimental, experimental flays or mobile binding. That's kind of the react model. Also, it's the component componentized, you know, generate the date, uh, generate the UI from the data. But I'm thinking that kind of has the same shortcomings of MVVM in this case because in your case, again procedural, you want to be like, do this, do this, do this, wait for this, do this, do this, do this. And I'm not even sure if you can represent that that well in the react style of programming. So NBC is really coming out King here.

Speaker 2 (24:26):
Yeah. And I think that at least having some sort of hybrid approach by it. One thing that I've always done that I think a lot of people were like, some people have been disappointed in me that I never went to the extent of putting a lot of my um, navigation into my view model or having some sort of viewed a view model binding layer. Like, Hey, this thing is associated with it. And I guess I could have, but I never thought it was naughty to say I'm on page one. And when someone clicks a button, tell it in the code behind to go to page two. I always thought that that was okay for me because that's how I've always done it in iOS and Android in my activity or my fragment or in my UI view controller. I always thought that that was okay.

Speaker 2 (25:09):
You know, because even when I did iOS work, by the way, I still use MVVM in quotes because the architectural pattern I did was that my view controller was my view and I still had a view model and my models over here, but I would just call methods in a weight on them and it didn't have any binding glue in between. You know, I just sort of use it how I used to and I sort of think that like maybe that is okay to do it that way. Hey, let my, my, um, let my models, uh, bind. Like, I have an observer, I have an observable collection, I have, you know, things that have properties on them, but maybe it's okay that I have a button click and when I have a button click I, you know, show a little spinner or do a little animation and then go get the data. Like I think that might be okay, maybe I'm wrong, I don't know.

Speaker 1 (25:59):
No, you should have 30 different properties describing exactly what you want the animation to do and make that all test. Um, navigation is hard. Every app navigation is hard. I was actually just writing an app and we, my own UI library and I was like, Ooh, navigation is hard. There's some features that I need and we to make navigation a little bit better and things like that. So, you know, even things I've designed myself, I'm, I still screw up navigation. I really applaud, um, uh, shell, the Xamarin forms shell work. I don't personally use it, but I kind of wish I did because I think that's a really nice way to structure an app. Even when you're just thinking through an app. Like, here are the pages of the app. Anytime anyone's ever come, um, with an idea for an app for me and they want to work it out, I'm like, okay, let's write down all the pages, which page goes to which page, that kind of stuff.

Speaker 3 (26:55):
Um, and then

Speaker 1 (26:57):
how do you feel about URLs as your navigation item? I think it's kind of, it was the technique, uh, used in depth I think. Oh gosh, I can't even remember. Did WPF Silverlight definitely use it. And I think Xamarin forms has adopted it. So their answer to navigation generally is a tag something with a URL.

Speaker 2 (27:22):
So with shell that is the new shell URL navigation and yeah, I think a silver light and windows phone did it right. Maybe others have done it. So here's my ups and downs of it. I'm actually converting Hanselman forms to be 100%. It already is shell based, but it's not all in on shell. It's still uses the old navigation in many places. So I am going all in on URL navigation on this app

Speaker 1 (27:52):
distraction. Let me just interrupt. That's your abstraction. So don't feel bad about, Oh, my button on click handler has a open URL and it, because that open URL is the abstraction. It's just, yeah, you're not all going through the same view model, but even then you could, you could just put that URL into the view model or things like that. Yeah. So I navigation is hard. Don't, don't feel bad about yourself for breaking in architecture because it's going to make your app more usable, make your navigation good, make your UI good damned architecture.

Speaker 2 (28:25):
That's true. That's true. Yeah. And I, and I am going in on it. I think that one thing that I really, um, like about URL navigation is that it sort of mimics the web obviously. Um, the, the, the pro is that it is an abstraction. So you just say, Hey, go do this thing and magically resolve it for me. Which I like. It's kind of like, um, asp.net, right. It just, here's some routes and go figure out where to go. Um, one thing that I really like about, I would say Xamarin forms is URL navigation, is that they have these things called query parameters. Um, and I'll pose this in our Zencaster of, of how I do it here for you to look at basically line 10 and 11. I'll put this in the upper at the handsome handsome in, um, poor requested in the show notes.

Speaker 2 (29:16):
But what it's doing is it's, it's gonna say I'm gonna pass a URL with a few identifiers and in this case I have ID and series ID and then it sort of does a binding to say resolve and then set those properties in my view model or in the code behind the page. Um, and it just as URI S, you know, escaping and on escaping of the data string, um, and sets those properties. So that's a nice way of saying no, only navigate to this page, but pass a little bit of data. Now that is good and bad because the good part is that I can pass data. The problem that I have is that on the previous page, I already had that data. So how do I pass the entire data object to the other page? And in this form it's like, well don't unless you serialize the entire thing, but that would be silly.

Speaker 2 (30:05):
Don't do that. Um, but um, it actually leads to good practices, which is now this page can easily navigate via this URL with an identifier and then it can resolve itself naturally. So the negative, like I said, is I can no longer pass the Pogo or the poco or the whatever the object is, um, to it, the object in memory. But the positive is that when I rearchitected the page to use URL navigation and the query parameters is I rearchitected my caching layer so I could easily grab in, query this information from my cash service that I had my data service. So instead of having to pass things around like, Oh, don't worry, it's up there and it's in my cash and if it's not in the cash, then go get it. You know what I mean? So that's what I sort of done.

Speaker 1 (31:00):
[inaudible] you are basically a web developer. Yeah. The HTTP is stateless. All you ever get are query parameters. They're just stupid strings. They can't be anything but stupid strings. So you have to go query the database. Scoring the database is expensive. So you have a global cache that you hit first. I was gonna say, um, I, I actually, I really like this approach. I don't use it very much in my apps, but I really liked the concept of deep linking and having the UIs kind of separate like that. The downside of it, you already said it eloquently, but I'm going to say it differently. Um, you have to by definition now have a global data source and that always kinda hurt my soul a tiny bit. I like my apps. You know, if someone opens two different files in my app, I would like the, those two bits of data to be very, as separate from each other as I can.

Speaker 1 (31:54):
Two different data sources, two different backings, whatever, two different databases. Who knows? It doesn't matter, but different things. But kind of by definition, if you have to be able to hydrate or load any object given just it's identifier or whatever, you have to have a global data source. All of that said, James, all my apps have a global data source, so I should just get over myself and just, just start using URLs for things. Um, it's funny that we got so far into navigation coming from procedural programming, but I think we're just addressing kind of the same thing. These are the cracks and um, the UI architecture and these are how you're filling the cracks. And I, I like shell. I like it a lot.

Speaker 2 (32:41):
Yeah. I like the idea of it. It brings me back to thinking about my data source a little bit more because in, in the world in which I don't have to do that, it means my app isn't deep linkable. It means that I'm doing a little bit of shortcuts because I can pass the object around and could I, you know, deep link into this correctly or do other things when I think about the long term of my application to say, okay, it's a, it's okay that I'm, you know, taking a little bit more time to think about that intermediate caching layer. And you're right, it sort of reminds me of a website and a little bit more, which are funnily enough, how Google thinks about your Android applications, which are deep links into your applications via their app indexing because the index your application like a,

Speaker 1 (33:26):
um, like a website. Same with them. Um, what's the lowest Siri Siri search, right? They index your gift cup Siri thing. Siri, Siri, Siri thing. In fact, I was going to bring that up. Um, everything that you were describing sounded so much like Android activities to me because I remember back in the day before fragments, um, you couldn't guarantee that, um, the process for one page would be the same process for the next, uh, page or activity, whatever they're called. And so you had to serialize your identifiers, have global data sources, do all those little tricks so that you could survive being on multiple activities. Especially cause I think what just kill activities and then bring them right back up and all those terrible things. It's funny, it's just a big circle comes back around, you know,

Speaker 2 (34:17):
actually, yeah, I should give this feedback to the team now that I think about it is I actually really liked how Google did activities because it, they, they sort of did them as URLs because you would sort of say navigate to this activity, but it was a type of, it was like this type system, which is a string. Um, but um, what was cool about it is that you could attach, um, properties to the intents. So you'd have an intent to go here. And then you had a big dictionary, which was, I'm going to pass around a bucket of data, which might be like a string or an integer or a Boolean. And then on the other side, I'm going to pull what I need out of that bucket. So instead of, um, putting it into a big huge query string, you can just give these buckets of information.

Speaker 2 (35:05):
I always thought that was kind of cool. Um, they've kind of gone against that and they've added this app indexing thing on top of it. But I sort of like that where it's like, here's a bucket of data that might be a relevance to you, but again, how do you then put a bucket of data into a string URL? And that's the problem they ran into. But I like that model, which is a, I might be navigating to and from different pieces with different bits of information. I'm going to pass some of this data along with you, but the downside is that people will abuse that and then say, okay, well serialize the entire object and pass it along as a, as a big blob. You know? So yeah.

Speaker 1 (35:41):
I mean we do it on the web all the time. There's actually an encoding for how to convert Jason onto friendly URL query strings. It's a, it's a whole thing. I honestly don't see a big difference between, uh, the Android activity system. And what we're describing, you know, a property bag versus a query string. They're basically the same thing I know on Android. Um, any objects you put into that property bag had to be serialized double by whatever their Java definition of what that was. And so you were in all intents and purposes converting it to a string anyway. So you know, they were hiding it a little and query strings are making Omar public and in your face it's really just levels of abstraction though they feel very similar, very similar to each other. Uh, navigation is hard. Just write single page apps, just hi ha, hide, watch ever parts of your app you don't need at the time.

Speaker 2 (36:37):
I like that. That's good. Good, good approach for, for life. Basically just single page, your app in your life. That's all I want. We keep it simple. Keep it simple, keep email. Here's what they used to tell me a, use the telling me to keep it simple. Back when I worked at Canon and then we used to write about 5 billion interfaces and then you change one and then everything falls over. So, yeah,

Speaker 1 (37:01):
it depends on your definition. A simple, someone was optimizing something and probably not what they should have been optimizing. You know, all this is just making me wish though that I had a more blended style because when I am doing like MVVM data binding things using MVC, it's a pain. It's just so much, you know, stupid typing that really isn't necessary in a good data binding system. So I kind of wish we had more gray middle grounds.

Speaker 2 (37:30):
Well Frank, that could be something that you create because apparently you just create everything in a weekend. So I already wrote it. Oh, it's my, it's my bind to library. Oh, that's right. That's right. When you want to bind some things, but not everything. Funnily enough, I S before we get out of here, funnily enough, I was chatting with Luce, uh, recently and uh, she's doing this session on, uh, Xamarin development for asp.net developers at the Donnette focus on Xamarin event on the 23rd, which everyone should tune into. Um, cool. And she was like, Oh, do you have any good diagrams of MVVM? She's like, I've Googled around, but you know, I just started to do this and I, and I, I, I, I dug deep into my treasure trove, um, PowerPoint presentations. I, I have an archive of every single presentation I've ever given since I started at Xamarin, which is now six and a half years old.

Speaker 1 (38:24):
Was going to say that must be a really big directory with a lot of images. I've seen your presentations, you have a lot of pictures.

Speaker 2 (38:32):
Oh, they are so organized. So there's, each of them have, and then every presentation has a folder with the year, month day on it. So it's every single one in order by the year, which is great. And then stuff inside of that folder, it's spectacular. Um, and I, I dove deep into my 2014, 2014, um, talk that I gave on MVVM and this is before Xamarin forms, before all this stuff. And there's all this stuff I gave it that I don't know, VSI or user group or MVP max or something like that. And, um, I kid you not, I had a MVC versus MVVM how it works, what data binding is. And then I said well you know, there is no data binding in iOS and Android what to do. And then I said well don't worry cause there's MVVM cross and a little library called

Speaker 1 (39:21):
bind [inaudible] you knew about bind. Oh yeah. Back in 2014 shock. Yeah. Cool. Uh, yeah that's, that is super cool. What a trip. I wonder if it'll make it onto the new slide now. I hope so. Um, bind was super cool. I my my ambitions were right. I messed up the syntax a little bit and it has a few little bugs that are frustrating and that's why I don't use it a lot right now. But the idea is still right. Really need to write a bind version to yeah. Actually a Clancy and I have talked about it from time to time cause I think we all have settled on how we want it to actually work. Yeah. That was my small attempt to bridge these two worlds. Pretty good. I like it. I'm going to put a link to it in the shown us. But don't forget people, UI is messy and it's okay to keep it messy. It's okay. You can always clean it up later. That's what I'm thinking. Or just put a region around it and never opened that region.

Speaker 2 (40:15):
Ooh, I like that. And with that, that's going to bring us to our end of the pod and we'll put a region around this ends and go to town. So you can always hit us up anywhere on the internet at merge conflict, FM Patrion, the Twitters, the YouTubes, the twitches, all the things Frank is streaming on occasion at twitch.tv/frank Kruger and I of course, stream at twitch.tv/james Monta Magno. So you can follow us, yell at us and tell us how much we're wrong or right. So please do that. And that's going to do it for this week's merge conflicts. So until next time, I'm Jason,

Speaker 4 (40:51):
Martha Magno and God ranker. Thanks for listening.