Speaker 1: 00:09 [inaudible] James: 00:09 frank, it has already been over a week since we returned from the Dev summit a. And what'd you think? How'd it go? How was your trip to Houston Tech Frank: 00:19 says, Oh, I'm so glad I went. Um, wow. Houston, Texas is a very hot Texas city of Texas. But uh, aside from that I'm more of a cold weather person. But aside from that, it was super awesome to see all our online friends, everyone who made it there catch up with people, talk about open source projects, whine and complain about a few things, have a few too many drinks because none of us know when to stop talking at night. But yeah. Had a great time. And you were there, did you have fun? James: 00:48 I was there, yeah. You know, so we obviously tried to talk about it last week, but you know, we recorded before the show, so we couldn't really talk about us. And now it's Kinda like this retrospect have already being done for so long. But when I look back on another, we're kind of recording once it's all the dust, it says old and everything like that. Uh, yeah, I had a great time. I mean, I over committed to way too much. Uh, Frank: 01:12 all right. Yeah. You, you were always in the hallway. Someone was always talking to you. I felt a little bit bad, but it's a conference. We talk a lot, so. Yep. Good job though. You kept your energy levels up. I only saw you disappear a couple of times. James: 01:26 Yeah, I tried. I tried to keep going. I had the keynote, I had a session, the live stream now I'll tell you, doing live streaming for nine hours a day and working with captioning and doing everything. It was a lot of work, but totally worth it at the end of the day. And you're right. I mean, the most fun part of it was not only being able to watch a lot of the sessions, but the interactions with everybody was really, really fun. It reminded me of when we went to done it fringe so long. Frank: 01:52 Yeah, I remember. Yeah. These community events and I think that's how I differentiate them. We talk about the Microsoft events that usually we both attend. But these are the smaller community events where you'd still have your corporate sponsors because these stupid things cost a lot of money. But otherwise it's, um, I don't know what other word is there than community. I don't want to keep her using it. But yeah, these, it's all your online friends. That's what it is. The Twitter groups, it's a bunch of people from Twitter showing up in a hotel. James: 02:20 It was fun this year because I've been live streaming for a lot longer now and there was a lot of people that would come up and they're like, oh, I'm so and so and, and from, from twitch and like their user name and you know, you don't know people's names unless they're actually their who they are. And it was so cool to meet so many people in real life, uh, that have been, you know, I've been interacting with for so long, uh, in general. So it was super duper fun. Frank: 02:45 And there are a bunch of merge conflict listeners there and I super appreciated everyone who came up to me and said Hi. And we listened to the show. I kept trying to make the joke that James and I record this thing but we're all just into kind of a big black box. And then just hoping people listen and we know some people listen because of the Twitter. But to actually have someone come up to you and say, hey listen, that was super awesome. And I also learned that I need to update my Twitter picture because everyone's like, you look nothing like your Twitter picture. I'm like, Oh yeah, sorry about that. James: 03:19 And it's very, very true. In fact, I had to, I was doing some slides and I was like, I'm just going to grab some like people from Twitter and that's easier to get the profile photos all from Twitter cause they're all public domain. And just sitting there I was like man, that frank photo, Frank: 03:33 I don't know. Well at least I don't know. I either got to put a bearded picture up there or cut my beard off. So one or the other is going to happen. I have a couple of recent pictures taken of me that I don't hate. I was always afraid of 'em. I don't know. I don't know if you go on Twitter pleasurably anymore. Jane's, you always talk about how you go on professionally, but when I'm scrolling through Twitter, I know people by their icon, by their Twitter picture and so it's not so much like is it an accurate representation than me? It's an icon that represents me. It was me at one point. I've, I guess I don't look like that anymore, but uh, I was always afraid of changing, you know, branding I guess. But a WHO cares? Change it. They're already subscribed. They're stuck. Yeah. James: 04:19 People, no, I mean I, I agree with you. I definitely haven't changed your mind in a while, but it's more, it's definitely newer, that's for sure. But I think a lot of your photos from your campaign, it would be really, really good in general. Frank: 04:33 Ah, yeah, that's what I was thinking. I just need one really nerdy where I got my thumbs up or something. James: 04:39 Well, my favorite one is this on your Instagram, which is you zooming around on your one wheel with a bunch of trash picker. Uppers. That one's really good. Frank: 04:47 Okay. That one I like to a lot. I have a giant bag of trash picker uppers. Have you used a trash picker upper? It's such a stupid question to ask, but there are fon and they're affective and I really enjoy picking up trash with them. Do any parole duty. James: 05:02 I did on a, I did a community cleanup event in Seattle and yeah, they just like, do you feel like, just like you're in, you know, invincible at these things because they're so, they're just like a little, like as a kid you'd get those little like dinosaur things, you know? But yeah, they're super, super effective. Frank: 05:19 That's amazing. Yeah. I feel like I just want them in my normal life. I feel like they're just better hands than the hands we have. You don't have to bend over. You can do everything in a long distance. Wow. Okay. Sorry. Got Us onto that topic. Somehow. Back to the Xamarin Dev summit. Um, I thought the talks were pretty good too. I was really interested in everyone who showed up. It was a good set of speakers this year. I was talking to someone afterwards and they're like, how do you pick which talks to go to? I'm like, well I pick it by speaker. Unfortunately a, if I've seen him around on Twitter, I'm always excited to go to their talks. Yeah, James: 05:55 it was, it was super, super fun to watch all and they're all recorded so I, they'll roll out on there at some times. So once they're out, I'm sure people can go in and watch them Oswald, which would be cool. But uh, yeah, I mean I had a fun time. I hope you know that the team puts it on again next year. We'll definitely support them. I know it's a lot of people were asking cause it can happen again. You know, this, we had tons of people watching online. I mean it was a blast. I had fun. And you know, Houston, you know, July, it's fine. You're in a conference center the entire time. But we got a little tour of the town. But we never left the car because it was too hot outside to leave the car. That's true. That is true. Uh, all right, well frank nef Dev summit, we have a topic this week because I was just doing a little live coding with my good friend John Galloway and we were, you're Frank: 06:47 messing around with some razor html stuff and we'd be, you know, moving, suffer brown editing things going back and forth and all of a sudden something would go wrong, like the intellisense would mess up or just like we got herself into a state where I'm like, just go back. Right. And like just hold down control z. And there was two things that happen. Either everything worked gracefully or B, it did not work gracefully because John Sometimes closes the file. So the intellisense refreshes and then the back stack of your editing, you know, edit, undo, Redo, go away. And I thought that was really interesting that in 2019 we're struggling with copy, paste, undo, Redo. And in fact apple is trying to even solve this on the iPad with iPad s and all the new crazy gestures. So I thought I talked to the master of edit, undo, copy, paste, delete Mr. Frank Krueger. Frank: 07:46 Hi James. Nice, nice to be on your show. Uh, I've actually wanted to do this topic for a long time. There's a few things that I think way too much about as in I'm never happy with my solutions or I'm a worrier or it was a problem I had when I first started out programming and it feels to like just reoccur for the rest of my life. You know, that one weak spot that just no matter what you do or maybe it's like my Moby Dick, was that the name of the whale, whatever is the name of the way on that book, whatever. Yep. It's that. So for me, that's um, these very basic operations. So I think we all take for granted because, um, our, we encounter on most in text editors and they work very well. Cut, copy, paste, delete, undo. These are your basic editing commands. Frank: 08:34 But as mobile developers, I don't know about you James, but the majority of my mobile apps don't do anything like that. And they're not gooey apps. In the traditional sense that you can select something and cut it and then paste it into another something. It's really just not how mobile apps work. And even in the beginning there was no clipboard on Ios. So it's really not how mobile apps works. So I find it's not only something I think a lot about, but it's something I don't practice a lot and yet my apps need it. And so I'd love to talk to you about it. Let's talk about these basic apps. Yeah, and I never really thought too much about it when I was building apps cause I'm not really Speaker 4: 09:15 building apps in which you are building components on top of each other. Often the apps that I've built the ability to undo is a naturally UI experience. And what I mean by that is that when you take an action in the UI, the UI presents you with that visually Aka toggle switch, a check box, a some visual indicator in the UI stuff for, for instance, when I was working on the Media Player or the media center app, the Media Center app, you could record a show and how do you undo that? Well, you hit the Speaker 4: 09:52 record button, right? There's literally a record, don't record button there. So the act of undoing is the same action of doing and that isn't for all sorts of applications. The act of undoing when you type something, you type a bunch of code isn't necessarily the same action. Or for instance, um, when I'm inside of Gimp, which is one of my favorite free visual editors for a photography or just visual stuff, you may be, you may have copied something in, you might have modified it, you may have added an Alpha filter. You may have done 5 billion things where the Frank: 10:31 opposite, there's more than one opposite, right? Because if you do the opposite, then you want to go back to the other way. So the, the, the action here of having a problem Speaker 4: 10:44 [inaudible] copy, edit, undo, delete, is that there is more than just one thing that you can do, right? Uh, yeah, Frank: 10:52 general. Yeah. And so much so that you usually talk about it as the undo stack. And so every time you perform an operation, you can think about putting that operation on a stack, executing it. But then, uh, if someone hits Undo you pop that operation off the stack, do the inverse of it as you described, whatever you want to call it, the backwards version of it. I think of it as the inverse. And so for every operation in your app that you want to be undoable, you have to represent it, number one as a function. And number two, a second function that can do the opposite of it. And you know, that sounds roughly kind of easy until you actually start trying to implement this puppy. Because the truth is we don't abstract actions like that very much. We create functions all of our code and we mutate, stay all over our code. Frank: 11:44 And even though we might use the command, um, uh, you know, I command and all that pattern, we don't write opposite command. You know, what is the inverse of that command and we don't keep a log of which commands have executed or most apps I should say. And so you have that first step of a, how do I represent the actions and their inverses. Then you have maintenance of that stack and then you have to make sure that your UI updates, when that stack changes, you have to make sure that you save things at the right time. So if you're using our database, things become complicated again because you can't just save the database away. You got to restore different points in it. And I think for all of those reasons are by mobile developers do not implement undo. Speaker 4: 12:31 Yeah, you almost a meal, you only really have the built in whatever the editor or texts entry control does. All right, you're in control of that. You're often not the one writing your own entry box, for instance, that's provided by the UI. So you don't even think about it when you start to lay out because so much has done for you by the Ols. However, you're right. Uh, there are many times where you're building any applique application in which you have to worry about that, that stack. Uh, and I first, when I worked at cannon, right, I worked on a wizzy wiziwig or whizzy whip. Actually, it was what you see is what you print. So we worked on a, uh, an application in which it was sort of similar to an outlook where you, you know, for real progressers that would do blueprint blueprint printing and you could move around objects, you could do cutting, you could do, um, cutouts, you can move items around, you could increase different sizes of it. Speaker 4: 13:33 And you had to have this crazy back stack of commands. And I was lucky enough that I came into the project where I didn't have to worry about it. It was already done and completed for me. I just added onto the stacks in which w which are already was, uh, so, so it was done for me, but I don't even know how you would start to, to do this in modern times, I guess. Would you create the entire like action stack? Like there's every action is an easy nume and then you know, you have to replay or unplayed deep. Frank: 14:06 Yeah, I've read deeply undo, Redo it. Let's keep, let's keep that terminology. It's a little easier. Um, James, let's just say how many stars are in the sky. That's the number of architectures that I've written to solve the undue problem. But at the same time, uh, we're talking cut, copy, paste on delete because they're all kind of related because you're saving away some kind of state that you need to restore later. Something like that. And so the way I usually tackle this problem is I don't want to write those reverse functions. The inverse functions, they're too hard. Um, you know, you write a function. Let's not talk about a basic forms app. Let's talk about an that does a lot of work. Let's talk about something like a 3d editor. And let's say that there's an operation in that app that fundamentally distorts the geometry of the object. Frank: 15:01 You know, maybe it makes it bigger, smaller, squishes at something, you know, it does something very complicated. Well now you've got to write the inverse of that function. And that's hard. A lot of functions don't have inverses and so the trick that most people take is that they save a way, some kind of light copy of the document and save that to the undo stack. And so you could imagine in a mobile app, maybe you represent everything with view models or or your databases easily serialized bubble a. Then you could just keep copies of the document in a sack. You know, a literal, you know, system dot collections dot generic dot stack and have a copy of everything. That's the architecture that I circuit uses. Every time you do an operation and I circuit it serializes the whole document object, whatever that is, saves it to a little bit of text and puts it into a stack. How do you implement, Undo and Redo? Serialize, deserialize, Jason, whatever you feel like using and then you flush that into your app and uh, you know, uh, as long as you're using bindings and all that, your act react not so bad. Huh? Speaker 4: 16:16 Yeah. I mean I could imagine that that doesn't sound too bad. I have to imagine that there's several implications of size, speed performance with it. But maybe we should take a quick break and thank our sponsor this week. Our good friends at tellerik. Yes. You know and you love tellerik over at progress. They've been working on all sorts of amazing things for any of your applications and in fact they probably have things that do edit on, do copy, paste, delete all the things because they are working on so many UI controls for your applications, whether you're building Xamarin Apps, wet app web apps or blazer applications. They have a tellerik UI for you filled with tons of professional looking modern components that you can drag and drop easily into your application. They just released a new pdf, viewer control, new popup controls and even a new doc layout manager control for your Xamarin applications. It's all optimized and fully compatible with visual studio 2019 it just head over to telerik.com to learn more about all of the tellerik UI for any mobile application that you're building. Had to tell her rec.com and tell him that James and frank sent Ya. All right. Frank, what are the issues in this style? Because you're obviously I circuit is the most amazing application ever built so I can't be any issues, right? It has to be perfect. Frank: 17:36 Zero issues, zero issues changed. Well, you know, there is a few small flaws with ice circuits, something like you can't put images in a circuit and a few other things and maybe just maybe that's related to how quickly and I can serialize documents. So you're right, there is a fundamental flaw here and that this is definitely abusing memory and this technique is only good if you can shove your entire, um, data set into, you know, an immutable form either serialized into a string or binary data or just immutable, whatever it takes. Yeah. In fact, that's Kinda where, um, the functional style helps a lot because you're already dealing with immutable objects. So you don't need to serialize them to store them in the stack because you can't, by definition, you can't modify them. So they are perfect copies and that's actually more memory efficient. But we won't go into the functional world in this podcast. Frank: 18:32 We'll keep it clean. Well, I can imagine that you are building continuous your idea on the, on the iPad that you had to have run into a different type of vision because that is an f sharp application, functional style to it. Did you have to manage it or was that sort of built into the editor controls on what you were using? Oh, uh, you're doing all of this manually. Yeah. There aren't too many UI frameworks that help you with cut, copy, paste, delete, undo. I remember back in the day, um, MFC, remember MFC for c plus plus programming on windows. Yup. Yup, Yup. That actually had a, these concepts baked into it and they helped you architect your apps so that all of these things work correctly. And it was really cool cause if you just buy into their framework, you did get them for free. Frank: 19:22 But in modern, um, architects, uh, UI frameworks I should say, they don't force any architectures upon you. Uh, on Ios and UI Kit, we do have a thing called, uh, well UI document. Have you ever used that one? I've not used UI document. I know of a bit of the API's but I'm not super familiar using it at all. This is nice because this is trying to do what MFC did was help you architect apps. So this is architecture, this is not UI. So it's a little oddly named, it's the UI document but not really anything to do with the UI. But the neat thing is it contains another object called an undo manager. And this is Apple's prescribed way to do on do in Ios. This is how they want you to implement your architecture. So this is definitely pushing down a way to write your apps upon you. Frank: 20:19 Gotcha. Now the thing is James, I love apple and I love their APIs. We all go that right? I don't have to defend anything here. They are luxurious. Yes, I do like them very much. But I'm going to say that UI document undo, Redo is the worst thing on the planet. You don't want it. It is what they want you to do is, like I said before, like you said, is for every function, right? An inverse for it. And the truth is that's still very hard. So we have this world where apple is saying this is how you should write your undo, Redo and then, um, we have this other side saying, no way. That's way too hard. I'd rather just do this state saving. So what's left James, what do we do? Frank: 21:08 I Dunno. I have to write it all yourself, I guess and not do it. Yeah. Well I've tried a few architectures. A, the one that I have that I love the most is I did something a little crazy with, I notify property changed and uh, and an app that I have, I'm pretty proud of. It's undue architecture because as long as every object I create is, I notify property changed, then I can do tricks about monitoring properties and remembering them and let's say storing them in a replay buffer and an undo buffer and things like that. And so I think that, and I like this a lot because we, we all do, I notify property change already to do bindings to our user interfaces. And so I thought, why not just extend that and use that capability to automatically manage on do state within my apps? Frank: 22:06 Yeah. And now in that instance, I'm trying to remember back what we did at cannon. I am not 100% sure, but in that instance where you're controlling the stack, would it be that truly, maybe you have an entire list that you're building up. Okay, now you want to be able to undo and Redo, you know, and now once you make a change, you can't redo because there's nothing to read it. You can only undo. But it's almost like if I remember, you sort of have an int pointer, which is pointing to somewhere in your array. You know, and you're, this is a current state, so what you do is when you undo, you're not actually popping anything off the stack. You're just moving your pointer in it's time to say, I am currently here until you make another change, which then pops the entire top off the stack and then adds onto it again. Frank: 22:56 Is that an accurate thing of what you'd be doing over those property changes? Yeah, exactly. Well, it's almost two different topics. Everything that you described you absolutely have to do for an undue buffer. That's how an undue buffer works. So I kept calling it a stack, but let's think of it as an array. And every time you take an operation, you add on to the end of that array. Every time you undo, like you said, you move that pointer backwards. So you're not always looking at the end of the array for what values things should be. You look a little bit back into history, so that buffer is history. That's a, that is fundamental to how the undue systems work. Now, of course, I mean let's let's say 99% of all apps, that's how the under system works. There's always exceptions, right? Um, can you name what is a very large piece of software out there that sometimes breaks rules but other, none of the lessons always used by everyone. Frank: 23:53 Again, word, I don't know. Oh, that's a good one. But I think Microsoft adheres to their own standards of Photoshop. Photoshop nailed it on number two. You nailed that. Good job. Now, um, Photoshop is a famous notorious for having a much, they don't have normal undo. Technically they do, but it's not what happens when you hit control z. So normal and do like you said, it backs up point or off. Instead what they have is something more like get, so instead of thinking of a straight line, start thinking about branches. So if I'm at the end of something, undo, undo, undo. And now I take another action. On most apps you would pop off all the unused part of the stack. And now that new action becomes, you know, the current state instead create a branch James' branch, that puppy. Uh, so now you have multiple branches off of any, it's basically a back to the future. Frank: 24:55 You could impact one branch and time and then branch and then go back and then go on to another branch. Yeah. And it's, it's really good for apps to add this kind of get model into, and it doesn't have to be complicated. You can visualize it with a tree or something like that. But it allows people, I don't know if you've done this, but I do it all the time. You Undo, undo on, do make an edit and then are frustrated because you realize you just blew away all those previous edits that you had before. And people get whole clipboard apps and things like that to deal with this problem. So this is just a much safer way to present history to people. And in fact, you can take this model in so many different directions. Photoshop, I think even allows you to delete intermediate actions. Frank: 25:41 So imagine keeping the end of the list and the beginning of the list, but deleting something in the middle so you can say, Oh I turned that to blue but I want to undo the blue but keep everything else hit the lead on that history item a wow God. Right. That is good. And then I'm imagining what they have to do there is when you do something in probably, you know on doing a bunch of things then moving things back, right? Cause everything is just an action that brings you to your current point in time. So when you think about it, if it's just a list of actions and you remove one and you have some sort of function that says, Hey, at this point in time I need to rebuild the stack. Right? You can go back and then forward to delete a point in time in it. Frank: 26:23 That's that's really interesting. Isn't it beautiful. This is how all apps should be architected, but instead we'd never do it because in the end it's just undo. You know, that's the problem. We all think of it as a just undo, like how hard is that to implement? But when you think about there's so many nice features that you could give apps with this kind of thing. So I liked that branching. I liked that to leading. Here's another fun one that I circuited because I suck at use SQL light as it's undo buffer. So I have a giant database. I can store an infinite number of revisions of the document in that database. So my undo worked, whether you close the file or not, you brought the file backup. I still had an infinite history of that file. So to get back to your very beginning, this is within the capabilities of modern software. We know how to do it as long as you have architectures, but why not make undo work forever? I'm so frustrated by that paradigm that once you close a document, you've lost your own do history. James: 27:26 Yeah, I mean, I can imagine. Yeah, I can imagine. Yeah, I dunno. I mean, I guess you could close the entire ide technically in this, in this a foreign factor. I, because you have a snapshot in time to where it's at and that would be pretty nifty to be honest with you. That was one thing that sort of just, it's just bit as over and over again. I go, AH, why? Why is this so, you know, and the funny part is that you have the history because there's some sort of diff of the file so we know where it was and where it's at. We just don't know in between anymore. Frank: 27:59 Yeah. And you know, with a text editor, I think it's a pretty trivial problem to keep snapshots over history. Thank goodness. Most text editors, and it's even built into Macko s itself, uh, keeps copies of files for you automatically. You don't have to program any of this and it restores it, but might not the a hundred percent history of the file. Hard drives are free. Now text files are tiny, especially if you diff them. So it's just like, oh, come on software ketchup. We should just have infinite undo on everything. But there are problems. You either have to, you know, like I said, hey, you have to write, your code is action-based or you have to be able to serialize your data into a really small format or you have to use immutable objects. Those are the three big ones. There must be some thing with this though, because I'm looking now, I was like, I was like, I'm going to Google this. Frank: 28:49 Right. And I'm just kinda curious in, in vs code one of the top issues on there with, you know, 50 hearts and pluses is feature requests make possible to undo, redo changes in code after vs code has been restarted. Yeah, it's, you know, it's, it's not, I can understand why they don't want to do it because theoretically you have to save an infinite history of a file that, so this file can, you become infinitely large this history. But you know what people are really saying, they're saying, remember the last 500 versions, you don't need 10,000 versions ago. So it's just, you know, oops, I closed the file, I want undo to work again. It's okay if I don't have the 10000th Redo. Undo, put whatever you want to call it a, so I'm totally on the side of memory is free these days. Especially if you're talking about hard drive space and not real memory, just use a database. Frank: 29:43 It's easy. Huh? Yeah. I'm, I'm very intrigued by the idea of putting this into more applications that you're building. Cause you could be doing a whole bunch of different modifications to documents and even so like let's say you're filling out, um, let's say you're filling out a form, there's no reason that you couldn't even undo that. What do you have to do today? Is you either clear all and you clear stuff or what do you have to do is you have to go and select something, hit undo, right? It's not just filling it out. You might be down the farm. You're like, oh, I just want to undo the last five or something went wrong, you know? Uh, and then that sort of is a Gotcha. Um, I think view models in particular serialized very well because they're usually a very simple data. Just, you know, simple collections, a simple data, that kind of stuff. Frank: 30:32 And so you could take your view model through, analyze at the Jason and just keep a stack of those things and all of a sudden you have an undue buffer. This actually came up at the Xamarin Dev summit. Someone was asking the question, can you override the back button on android? So just for fun, James, can you, I don't even know. I don't know how to answer that question. Oh yeah, you can't. So there's an event a, there's an override that you can do, which allows you to intercept the back button and do whatever you want. And you can say if you handled it or not. Okay. Yeah. Okay. So I'm, I didn't know that. So I'm like, well maybe, maybe you should, maybe you shouldn't do that, but why don't what's, what's the real problem here? Like what issue are you really running into that you want to disable this back button? Frank: 31:18 Yeah, give me, give me the core problem here. He said what would happen is people would be filling out this pretty long form on phone. Unfortunately there's just a lot of fields to fill out on this one page. Accidentally hit the back button and then, oh yeah, bad stuff. Right? So I guess, yeah, your, your answers best do that override, do something else. But what I told them was, hey, until someone's bothered to hit the submit button, why don't you just keep a serialized copy of the view model around or even just in view model itself, who, you know, who cares? It's probably not that much memory. Keep that around. And then if they ever go to that form, just pre fill out the form with the last view model, you know, simply serialize it stored away. It's probably better for the UI in the first place because I imagine if it's a long form, people duplicate the fields anyway. So that was my solution to the problem was take your view model and serialize it. And then once you have that, you're just one step away from having an undo architecture. Yeah. You know, I was sitting in Shane Nouvel's xamarinforms shell presentation and he was going really heavy on the navigation and he, um, showed off a custom navigation, which kept an entire history of the back stack of the navigation. Maybe a little bit tricky, you know, as you're navigating Speaker 4: 32:40 through, but you could loop into all those events. So like some really, really good apps like that I've used, they don't always do it, but sometimes I'll, oh, reopen Gmail and it's like takes me exactly to where I was even after I forced closed it. It's like I open it and it's like, oh, you were on this email last time. You probably want to be on that email again. But most apps they just relaunched to the homescreen. Where is that the correct thing to do? Maybe you could, you know, rehydrate your entire application and tombstone it fully tombstone is kind of what it's called as a witness of whatever windows term from windows phone days. Frank: 33:16 Yeah, it's hydration. Dehydration on Mac usually, but or honestly just call it serialization DC realize that's all we're talking about. But in this case, it's your UI, not data. It's important. I mean, we've talked about iPad os coming out where we need to be able to restore scenes very easily based on, um, Geez, I already forgot it. UI, user activity, UI activity, whatever the activity thing. Speaker 4: 33:42 And that's, and it's user activity and a Caesar. Thank you. Frank: 33:46 Bring me, remember my favorite ols. Um, and that, that requires serializing data again. So we're, we're always back to that. Serializing DC realizing so, so many tricks you can do. Make sure your data works with jason.net. In other words, PSA, everything should be serialized. Double. That's why I'm so sad that they removed serialization from, um, originally, you know, Silverlight and then.net car and just no one cares about builtin sterilization. But these days we use Jason for everything and I'm okay with that. Yeah, but you know, they're bringing, they're bringing in a new Jason serializer to the system. Dot Text. Dot. Jason does it right now. Does it do all the, um, object modeling though? Because a lot of Jason dot nets power comes from your ability to override the serializers. Like jason.net gets you 80% there. But there's always a few objects that you need to kind of override and play games with. Speaker 4: 34:44 I think it does. I'm looking at it. There's you, yeah, you can do a Jason serializer like there's a serialized method I think. Yeah, you can do options. It's very similar to Jason de now you can say allow trailing commas don't allow stuffs. A lot of those Jason Ignores Jason Properties, things like that. I think that works. Frank: 35:02 Okay. Okay, cool. Yeah, and I know that one was optimized for speed. So if you do it the way I do I circuit where I'm literally just keeping serialized versions of the document around. Yeah, you need speed. But um, in my case, I'm also just throwing those into a database. And so SQL lite deals with all that garbage. I don't have to, that's what's, so databases, they good still, you should still use them. Speaker 4: 35:25 [inaudible] those databases use those databases and you can just timestamp them and then need you have an infinite, do you know Frank: 35:31 it was done [inaudible] and branching and deletion. Don't forget all those. So we just talked about undue forever. We didn't even get the co cut, copy paste elites like to hold all those other ones, but maybe we'll save those for another episode. I just enjoy talking undo. They are, they are part of it and they all sort of add onto it and you know, I think what needs to happen is a really good blog post on how to do this and your view models and keep your state, you know, through it and how you could have it autoregulate you inherit from something and it just magically does it right. That'd be a great library. That'd be a great little little note. I have it. It's only like 200 lines of code a complete on do system. So long as your object's obey. I notify property change. Frank: 36:19 I guess I should release it. It's very useful. It sounds useful. Frank c release it to the wild. Do it. Yay. Another o s library to support. Well maybe we can put it into MVVM helpers. Ah, that's Mar. It would fit well in there. Good Job James. Wait a pm good, good PME and yeah, we can make it so it doesn't like save two disc, you know what I mean? But you can make it so it's just in memory and people can figure out how to override it and do some things clear to, sorry, just real quick. Uh, this system, the, I notify property change one, it's much lighter in memory terms because it's only saving the old value of the property and which object in which property name. You know, it's only three little bits of data and so it's actually very memory efficient. Frank: 37:11 It's nice. It would fit into my little observable object. It's so cute. Got It. Just little observable object and it already does everything. You call it that property and it's, it does I quality compares value things so easy to put in. So maybe next week we'll have an update for our lightning talks, which you should totally go to merge conflict out of them and submit your lightning topics for us so we can pick it out. We try to cover six. Maybe we'll do it. We'll see if we get this puppy and I can release it to the wild. Truth be told, I'm pretty sure I just copied your observable object to start with, cause that's such boilerplate code I'd ever want to write. That's true. That's true. Yeah. So yeah. Cool. Sounds good to me, James. More work for us to do. Yeah, I love it. Frank: 37:55 That's what this podcast does. It gives us more and more work. Well yeah, there we go. All right. Not anything else from you from you on do I think, um, like I said, I really do think about this problem all the time. So anytime you want to talk about undue again, James, I'm here and what's, let's do a, let's do cut and delete next time. They're harder than they sound. They do sound harder than they sound. So. All right, cool. All right buddy. Well thanks for everyone that has tuned in. It's on all about those undies and Redos and if you have your own implementation, let us know how you're doing. Is Yours way better than frank? Probably. So let us know. Go to [inaudible] Dot FM and let us know or hit us up on Twitter at merge conflict FM. I was going to do it for this week's emerge merge conflict tanks to Tellerik Speaker 4: 38:36 for sponsoring this week's pod. So until next week, I'm James Monta Mag. Now Speaker 1: 38:42 I'm Frank Cruz. Thanks for listening. Ace. [inaudible].