Speaker 1: 00:07 [inaudible] Speaker 2: 00:08 frank. I was driving back from Portland today and Heather and I had this amazing conversation because we're listening to the tech meme ride home and about Google not making any more tablets like they're out of the tablet game there is done with it. And it sparked a whole conversation, but did you hear that Google's done with tablets? Speaker 3: 00:27 No. This is shocking news. Well, but now you have my mind wandering like it's a Google. Is it android who's not? Do they have a pixel tablet? What have, I don't know anything about Google, but it's a little scary to hear someone backing out a tablet, I guess. Speaker 2: 00:46 Yeah, so the Google specifically hardware division has canceled all tablets that they're ever going to meet. They had two in production. They had the Pixel C, which was there, cool tablet, and then they'd done Pitney on nexus nine nexus seven things like that. Speaker 3: 01:00 I had an excess, I should know this better. So all my nexuses, those were Google devices. I love my next PSI, whatever they are. Speaker 2: 01:08 Yeah, those are Google devices now they're, they're done now they're like, we're out of tablets. No one wants tablets anymore. We're focusing on phones and laptops, but don't worry, android will still support tablets. What do you have there in your hand? Speaker 3: 01:23 I have a kindle fire tablet and I wonder if there he got cut out of the market because it was hard for me to differentiate between the nexus and the fire. Um, and as far as we know, Amazon still going with the fire. Right. That's still a pretty big product for them. I have the cool kids' edition with a rubber covers so you can't hurt it. Speaker 2: 01:45 That's pretty good. I did. It was like what, $79 Speaker 3: 01:49 Shush. I think it was, I think I paid extra because I didn't want ads or something. I don't know how, how do Kendo fork? It's weird. Speaker 2: 01:55 I Dunno what I, here's to me about tablets. All right, so I am also not a tablet person. I think tablets are stupid, but I will say that I really enjoy a seven inch tablet. Like it's the perfect, it's the in between device. And Heather and I were talking about this because she has an extra seven and she loves it for travel and it's sort of like when you don't want to use your phone but you kind of don't want to use a television. It's the inbetween device and this is really starkly different than what apple seems to want people to use the iPad for because apple sort of wants it to, they're never going to say replace your laptop because they have a laptop line, but they will say that they really want it to be a productivity device. And this sort of had me thinking that while Google is getting out of the tablet game, but android will still support it at dub dub DC at the dub dub, uh, apple double down on Ipad oh ass. Which we all know is just ios. People don't freak out. We know it's just that it's just a bunch of new API APIs. But have me thinking if Google is getting out and Apple's double on it, like how does that work for us as developers to begin with? I know there's probably a longer conversation and we should probably talk about what iPad oh s is, but then what does that mean for cross platform development? Like do we care about tablets anymore? I don't know. It's kind of like what I'm thinking. Speaker 3: 03:14 It's the tap, what episode we're talking tablets if that's not clear yet. So this is going to be fun where wherever we go with this, that's going to be our route productivity apps. That's kind of my whole shtick. I'm pretty much all the APPS, everything. I make money off of our, this class of APP. And so it's, for me, this iPad ios things a really big deal. Um, but mostly because it's enabling Mac apps also. And because there's new API APIs to embrace that makes your apps more powerful, but it's changes and I'm going to have to make to my codes so we should talk through all that stuff. But, um, what does it mean for Google getting out of things? I don't know if I care to read into it that much just yet. Um, I don't know. This feels like Google just being Google with their business, deciding who they're buying. I mean did they by Motorola again, didn't they like sell them again? They could do that. Do they make it Speaker 2: 04:11 well they did. They did buy part of it. They did. They did buy part of HTC. I mean they did buy, yeah I guess motor oil and then sold Motorola. Yeah. I don't know. It's, it's hard because for me as an APP developer, I've never really focused on tablet. I focused on like windows eight type of Ui cause it was sort of desktop tablet in general built for that. But android, I mean you can really make really good android tablet apps just like you can make really good iPad tablet applications. But it takes a substantial amount of work to go into it. And for me that has always been a problem is like when I go into building a mobile application, I always kind of build phone first and then the tablet application just is a bigger version of it. And to me that's kind of why I'm assuming that Google's like, well, if developers aren't going to invest in this, then we don't care. But then apple is saying we want developers to develop in this so they so get in on it so they can create desktop apps. And then to me it's weird because Google android apps, they can run on Chromebooks like they can run like so it's a very confusing message in general. And you've now watched a lot of dub dub DC iPad. Oh s investing with good Tory videos. And does it seem like apple is really, really saying like, no, we're really serious. You should really care about iPad. Speaker 3: 05:31 Yeah, absolutely. Um, but first I want to start with how you were saying you start with the phone first. I start with the IPAD first, um, big screen first. And then honestly it's not so much that I start with the IPAD. I just assumed that an APP can be any size these days. So I come from the desktop background and, and desktops. You would resize windows all the time. So you always had to make your app work in a small mode, in a big mode. With the, it's a little bit different because you end up hiding a lot of Ui. You ended up changing like navigation hierarchies. So things like that become complicated. But in general, I start with an iPad first Ui because I think of my app is a big, big desktop apps though, you know, no matter, even if I'm deploying to Ios, only in my head that's what it is. Speaker 3: 06:17 And so even if it's an iPhone app, I'm just thinking how do I expose the parts of that bigger APP in, in this more constrained Ui. And so I just like thinking of it that way. And I almost, it's weird because every app I write, I write as a universal app. I think oftentimes it's because my test device is usually an iPad that's just sitting next to me. And therefore like if I run an iPhone APP on the IPAD, it's terrible. So immediately I start working on the iPad Ui and then when I'm done working, I switched to my phone so that the, it's always on my phone and that's when I like bang out the, the phone Ui. So with mobile apps I'm working on them simultaneously from the beginning. Speaker 2: 07:02 I see. So yeah. So this is very starkly different than how I work on applications because I'm literally polar opposite. But this does sort of make a little bit more sense. I mean I also started as a, every I ios app to me is a universal app because I don't want that stupid iPhone four blown up three x size or whatever, that it's terrible. I would rather, I'd rather just be bigger in general, everything gets bigger. But um, yeah, I mean how I look at it is always here's my phone and I will develop for that. And like the simulators are there because running an iPad simulators like huge and kind of complicated. But to me, I guess I never, I, I mean it's weird cause we both started mobile development around the same time you earlier than me, but both before tablets were a thing. Speaker 2: 07:46 And for me it's like I guess I just never graduated into caring and I believe that my problem is that I'm an android first developer and I think that's the problem is since Google didn't care, I mean am I going to say they didn't care, but since they never gave the priority are the priority to the tablet, it never really gave that umph to it. So to me that was always the problem that I had in general. I guess going into it because since Google didn't make it a priority, at least from a push from a pixel line or working with partners and making the ols different [inaudible] was there, I guess with apple, how I know Ios works, is it sort of built in that it knows if you're running on an iPad versus you know, a, um, iPhone and then literally they're different API is built into the, the, the API surface for it. Speaker 3: 08:37 I think a lot of it comes down to touch you. I too. I'm curious. Um, do you have a touchy why on the computer that you use the most? Like every day? No. Okay. Hmm. Speaker 2: 08:50 Not In the, on the computer now I don't touch screens. Oh, I guess I do have a touchscreen on my surface, but I'm on Speaker 3: 08:56 mouse and keyboard type of, yeah. So for touchy, why? Like I'm on a Mac and we don't have touch monitors. We don't have touched laptops or anything like that and touches just such a better Ui for a lot of things. Definitely for reading. But for drawing, I've been holding an apple pencil this entire podcast just because it's a comfortable thing to hold. Um, and I love using it on an iPad and I love scribbling away. So what do you call that? Productivity or just I want to have, um, something to do on this device, honestly, because it's a good device and I don't want to read Twitter all day. I get tired of Twitter and I want to do something more creative and interesting with it. Speaker 2: 09:39 So I have my surface go that I purchased and I doubled down on using a recently on some holidays when I was in Wisconsin. And um, the surface go, I took out of asthma, we have matching surface goes. And do you even have the I have the red cover or whatever. Yeah. So I, I bought this, the bigger one. I, I've installed visual studio 2019 on it and I'm doing mobile development on it and it works pretty good. Surprisingly. Actually. Um, Speaker 3: 10:10 not the worst. That's a little bit slow, but it's not the worst. Speaker 2: 10:14 But I can tell, I can tell by my monitor here that I use the touch because I want to touch on things. So yes, the touchy why on that I do want to use, cause it's, it's in the form factor where it's, it's in there, right. And, and you're kind of, you're hands are right there next to the keyboard and the, and the display. Speaker 3: 10:33 In fact, I wrote an entire IPAD APP, a one day APP, um, yesterday. And the whole purpose of the APP was to differentiate between touch gestures and pencil gestures. So it was a a noting a notation APP and I was just getting frustrated with everyone else's apps, the way that they recognize things and deal with things. So I was like, well this is a constraint problem. But it all came down to that's the environment that I wanted, I wanted a large surface to work on and it's a big virtual surface. I wasn't thinking of it as here's a laptop of some windows. I was, here's a big art project I'm trying to do and here's how I want to compose it together. And so I think it has those application areas that just keeps me excited about it forever. Speaker 2: 11:21 Hmm. Well, and so if your application start as an iPad tablet application and they're universal app, right? And you're focusing on that. There used to be a day when iPad first started where you had see flight simulator and flight simulator, iPad version. Right. And if we're about to double down, I want to get into the complexities of what's in Ipad OSCP, which was religious ios. Um, but before we even get there, I want to just talk about like if I'm building an application, am I now building two applications? Are My building or should I think about when I'm building an APP that know this is a phone app or like no, no, no, this is an iPad app or no, no, this is bull. Like when and how do I make those decisions? Speaker 3: 12:03 I'm not always on, if I'm honest with myself, I'm not the best one when it comes to marketing and business cause that's all that, that really is when it comes right down to it is Speaker 2: 12:14 hold on miss and Mister, Mister, I make all my entire income off of building applications. Speaker 3: 12:21 Yeah. But I don't optimize, you know, I don't Ab test, I don't do those kinds of things. So a lot of it's okay, whatever. Anyway, what was I saying? Chains. What was I saying? Whether you shipped two separate apps. Um, it has pros and cons. So I often ship Ios and Mac apps and from time to time I get emails saying, Hey, I paid for the Ios one, why can't I use it? On the Mac and so this has happened a lot or people will even jump the jump the whole barrier and say, I bought the Ios version, why can't I run the android version? And then I'm just like, well that's not how economics, that's not how the stories work unfortunately. But the truth is I'm certainly, when it comes to Ios versus Android, you're paying for that app twice because it consumes a lot of my time. Speaker 3: 13:11 The android code may be 20% the size of the Ios code because a lot of code is shared, et Cetera, et cetera. But the fact is code is shared because I designed it to be shared because I have, I have to abide by constraints. I have to use cross platform libraries. I would love to use, you know, the latest version of Ios and only ios life would be great. But if I'm shipping on multiple platforms, then I have some abstraction layers that I'm going to constantly be dealing with in my code. Now when it comes to, um, phone versus pad, I think that justification's a little harder to make just because you can share so much of the code with each other. And even nowadays Ipad apps that support side by side need to be able to go into a phone mode anyway. Speaker 2: 14:00 Mm that's right. Yeah cause they can actually split the Ui into several pieces. Yeah, that makes sense. Speaker 3: 14:06 Now that's an opt in feature. You could just not support that and then release two versions of the APP. But I think honestly you're making everyone's lives miserable. So I'd rather you just up your price a little bit on the Ios version. Speaker 2: 14:18 So if I am building this app that's going to support iPhone and I, I pad and potentially other platforms, which we'll talk about in the future, but does that mean that I'm going to be creating my UI twice in general now with iPad? Oh being really more almost at separate separate platform from just the core Ios bit, right? Like, is it still, with all of the knowledge that you know from the videos that you've watched and the documentation that you read, is there a way that you can still nearly, almost, or if not all of your Ui between iPhone and Ipad, because I know that let's say master detail of the master detail, um, controller for instance, that automatically has optimizations to work differently on the different devices. You do have to do some coding in there, right? You need to set that up, but it's basically for free. So with the new complexity of doubling down, is that nicety you still built into iPad class? Speaker 3: 15:21 Yes sir. Yes. Um, life is still pretty good. Um, the abstractions that we generally use an Ios, the view controller abstraction, which parallels nicely with Xamarin forms this page. So it's a chunk of code, a chunk of Ui. And generally you compose your app out of those. And so when I think about I circuit, I often have one large view that's the circuit editor. And then off to the side, I have a property editor, you know, two different views to different view controllers. And because they're separate interview controllers, I can pretty easily, um, on the IPAD, do this, present it here, presented in a pop over, do this or that with it or on Ios, put up a whole modal dial dialogue, take over the screen, that kind of thing. It's fine. Honestly, um, the changes that we're going to discuss are actually useful in some cases to phone apps also. Speaker 3: 16:19 So, yeah. So I think it's, um, I think apple did a good job here for, you know, bridging that gap especially we're going to talk about later, cause it can't be avoided but Macko s getting these apps running on Mac ios and so they're bridging between phone pad and desktop with these, um, iPad apps. And so I think it's worth time. It's definitely worth time if you're going to ship an iPad version of it. If you, you know, if you do a phone only version, don't bother. But the moment you click iPad, it's going to be, you want to invest in this, Speaker 2: 16:54 you want to invest in it. I mean you can obviously start with the quick win, which is check the iPad and just becomes bigger. Right? And just scales up but to invest on it. And I'm imagining it all begins at the starting place of all applications for Ios, which is the beautiful, the wonderful application. Delegate. Apt alligator definitely Speaker 3: 17:11 will apt. Delicate. I have to. Okay. I remember when I started ios programming, I can't, I had most recently come from windows forms and I was like what is this app dug it. We never had an APP class and farms. We had windows and that was it. We had a main, main, main, main, main, main. But what was this delegate thing and what was its role? Is it the APP? No, it's not the APP. It's elegant. Anyway, I think it's a big stumbling block when everyone's first learning, um, how to do ios programming. But it's the entry point of your app. Multiple entry points if you support background modes, um, mostly background modes. That's where it gets weird when you're opening URLs. Uh, when you open a file from a different APP, anytime you do cross application communications happens through the APP. Delegate Speaker 2: 17:58 notifications, push notifications, I'll go in there. Speaker 3: 18:01 Okay. Yup. Boy. Yeah, they pack a lot in. Speaker 2: 18:05 There's a lot and there's a lot of overrides. Yeah. I believe not only, and not only getting the the permission or getting the notification, but deep linking from like Siri search and everything sorted. That's the deeply needs of that all comes in the indexing, I believe. Also Google, if you're using Google APP indexing like that comes in through the APP delegate. Basically everything comes into the [inaudible] in general. Speaker 3: 18:32 Right. So yeah, that's a focal point and it's where we all kind of throw our global code. I don't know if you're a bad programmer like me, you tend to throw, at least in my early Apps, I've gotten better now a lot of code and the APP delegate cause they're like I need some global variables here. You know, database connection. Where else is it gonna go? Speaker 2: 18:52 You got one APP delegate and it's always going to be around because it's your application. Yeah. Speaker 3: 18:56 It's a guarantee location. That's not going away. It's, it's a wonderful, Speaker 2: 19:00 is it still guaranteed in the future? I'm a little worried. Nope. It's gone. Knows somebody save us APP delegate as God. No. Speaker 3: 19:12 After 13 versions they've decided, you know what time to change that whole gosh darn model. Yep. Speaker 2: 19:20 Do we still have an APP delegate? I don't quite understand. Where's it going? Speaker 3: 19:24 Yup. Okay. So we still have an apt elegant, but its responsibilities are much different now so it no longer gets application, resuming application going in the background, all that kind of stuff. I know there's this look on your face. I can imagine it. Imagine people across the podcast channels this inquisitive look on James's face. Speaker 2: 19:45 Uh, well, because if it, it's not in your Abdel get like where, where else does it go? Like I'm just, I mean there's a lot of people, there's some people that put a lot of logic into that APP. Delegate. Frank Dab delegates not going to tell me. I mean, even if I'm building a Xamarin forms APP, right. That has its own, it has deluge APP delegate at the hit. They put a lot, right? Speaker 3: 20:09 Yeah. Welcome James. Introducing the new scene. Delicate. Yes. And by your applause, I can tell you're very excited about this. Speaker 2: 20:20 Isn't every app now a seen Kit App? Is that what I'm hearing? No, no, don't confuse those two that it'll get very confusing the scene. So wait, so the show we have, okay. We, we look at all of our applications like a game and there's scenes, right? And now you're in this scene. So you're in chapter one, chapter two. No. Okay. Okay. Speaker 3: 20:39 It's completely different from that just to keep you on your toes. Yeah. The best way to think about a scene is that it's a window. And on the IPAD, that's exactly how it'll be represented are on Mac. That's exactly how it will be represented. But on Ipad it means that you can have say multiple documents open if it's a presentation or if it's the photos app, you could have a photo off in its own, what I would call a window. You know, it's own little thing in the task bar, but it's actually called the scene now. So as seen as how your APP can get split into multiple Uis Speaker 2: 21:16 is a scene then a grouping small piece of functionality of your apps. Cause I, when I think of an APP delegate as your whole app, but what is seen be for instance, here's my editor, here's my photo thing in general. Or is it just copies of like there's multiple scenes of your APP. Speaker 3: 21:36 So actually that's a question that apple was a little bit vague in their answer for. But the general rule of thumb is going to be that it's your full app in every one of these windows. And technically it's up to you. You're in control here. So when you create one of these scenes, you could put an image on there and nothing else, no other Ui, not even a way to close it. You know, you could be terrible like that. But what apple says is that you should be able to get back to any of the data or at least to be able to perform operations on whatever data you're presenting. So the better way to think about it maybe is that you want to deep link deep link into your app. So in a different scene show a different part of the Ui and another scene showing that other part of the Ui think yeah. Um, different data nodes of your APP. Speaker 2: 22:29 Got It. So you can create a scene into a specific area. So when I spin up a new scene, I'm going to say this scene is going to navigate down into the photo editor of it. And this one is the photo preview deep link into the scene. Speaker 3: 22:44 Is that an accurate representation? Yeah. Uh, but maybe before we get too much further ahead we should talk about how scenes are created because I think that's the most important thing. And Apple makes it pretty clear that scene's should only be created when the user does something. So something kind of physical and the one that they prefer is drag and drop. So say I'm in a photos APP, I long press on a photo, it picks up and now I move it to the right edge of the screen. It pops into a new window area, you let go, the APP should deep link into that photo itself. So think of it as a content level and that's the way apple wants you to think of it also is that you're dragging content around to create these new copies of your app. Speaker 2: 23:30 I see. So literally I drag and drop it over that kicks in. It's going to say, hey, I need a new scene. And and probably that drag and drop action is going to have some data associated with it to say, now I to start up, this scene started up and does that go through the APP delegate? Speaker 3: 23:50 It's also good for you think so? No. Oh, the APP delegate creates something like a scene controller, a scene manager, you know, one of those kinds of names. Uh Ooh, I see. And you're apt. I'll will be notified when a scene is created and want to seen as destroyed. But otherwise it's up to the scenes to know I'm activated, deactivated, not activated. So imagine this scenario, James, we let's do a photos app just because it's easiest to think about photos. Speaker 2: 24:18 I really think that the photo app that's easy to make the connection to and we've been using it throughout the entire podcast. Speaker 3: 24:25 Okay. Uh, so photos that, um, someone has dragged out 20 pictures and created all these virtual desktops on their iPad with all these different pictures with different things snap to them. But then 30 days go by and they haven't used our photos app because they didn't like it or I don't know, something, you know, basically though the OSDC has shut down the APP. It's no longer executing and memory. It's no longer frozen, nothing like that. So when your app starts up, it needs to restore not just its own Ui James, but like let's say 15 copies of its Ui. So it has kind of profound impacts on how you architect your app because at any point in time scenes can be created and destroyed. You need to make sure that your app is very flexible in that regard. It can bring up and tear down route based Uis with deep linking very quickly and not quickly, but you know, it can do it reliably and well. Speaker 2: 25:25 Got It. Got It. Well, I want to go deeper into this frank and learn about how things are handled from the user and how the activities work. Well, let's first hello guy, not tee that one up for you after the break. Let's thank our good sponsor and amazing sponsor this week. Our good friends at tellerik. Yes. You know tellerik the team over at progress had been working on all sorts of awesome things that we want to tell you about. First and foremost, blazers support. They totally got you covered. Every little bit of Web Ui component that you could possibly need for your blazer applications. They got you covered because Telerik they have all those different platforms already covered and now they got blazer, so if you're doing asp.net core type script, angular javascript blazer, they got you covered. They got everything that you could possibly want through building mobile apps. Speaker 2: 26:13 Don't worry, they got your cover there to Tellerik Ui for Xamarin offers one of the most beautiful toolkits and variety of controls for Ios, android and UWP. They just recently released their brand new pdf viewer control. I get this question all the time. How do I view a pdf? How do I edit a pdf? How do I get this thing? They got you covered. They got popups, they got charts, they got Groppe graphs, they got doc layout controls, all this stuff. And it's all built into vs 2019 you can it just go to [inaudible] dot com that's it. telerik.com check out all their beautiful controls and thanks to Tellerik for sponsoring this week's pod. Speaker 3: 26:52 Thank you. Tell her I'm just saying I need to use more controls, Speaker 2: 26:57 more controls. All right, so how do we get control and access of all these crazy scenes? Like how am I going to actually manage this shenanigans? I'm very worried, frank, about my app. All of a sudden. I don't know why we did this podcast. I'm just worried not gonna be able to sleep tonight and I'm gonna have to, I'm going to have to edit this podcast and be worried again by the way. Speaker 3: 27:17 Yeah, that's right. Cause it's been actually keeping me up at night and mine should actually be easy. But I've been a little worried because it's, yeah, it's never had two circuits open at once. That's crazy. Talk to so that, yeah. So, um, James, let me remind you of an old class, an old friend of ours called Ns user activity. This is a foundation class with a very innocuous name, Nsu orders or activity that can mean anything you say. And yes, James, it does mean literally anything. So before I said that, um, the normal user motion that you're going to do is drag and drop to create a new window. That's Apple's kind of preferred one though. Technically you could click a button and you could pop up your own thing. And you had mentioned there, I assume that there's some data that goes with the drag and drop to make this happen. Well James, that data is an nscs or activity. Speaker 2: 28:15 Of course. It is a, Oh gosh, yes. For, is it, are they just leveraging the handoff API to like hand off to the own yourself? Stupid. Speaker 3: 28:25 Yup. Okay. So you, you, you got to the end there. I was going to stretch this one out a little bit longer. Yeah. But if you've ever done any work to support handoff, then I think you already have a decent idea of how this is all gonna work. So Speaker 2: 28:38 yeah, now people probably don't know what hand off is because I'm assuming that nobody makes their APP eligible for handoff. I'm just saying, do you want to explain a shot? Uh, well, so how I understand it is let's say that you have your app on Ipad and iPhone. You can sort of synchronize the data between them working together and you make things hand off a fide. So you say this state is handed off from my iPhone to my iPad and it kind of sucks up the state over there. So if you're on a login page and you're filling off stuff, you can literally have a little popup dialog, um, that says, hey, I'm ready. Very similar basic use case. You open a website on your iPhone, on your Mac or on your iPad and says, Hey, do you want to open this tab also here? Because we noticed that you're also using this on your iPhone. Is that correct? Yeah, Speaker 3: 29:30 I don't, I do. Yup. Nailed it. Yep. I um, I kind of love the feature to be honest. Um, I do it for maps a lot. I'll be on a desktop, I'll find it on maps up my phone and just swipe up and there it is on maps, calendar, email. It makes sense. Um, definitely if you have, it's for crossing this boundary. Like if it, if it's only an iPhone APP, it doesn't make much sense to have hand off from iPhone, iPhone because when are you ever going to have an iPhone? But the moment you have a desktop or an iPad app, it makes sense to start thinking about it. And as you said, it also ties in to Siri things. So if you want to do Siri integration, then you also have to start labeling and let's get right down to it. It's the commands in your APP. Speaker 3: 30:18 It's the different areas in your app. You have to start labeling these things and telling the ols about these deep links is what they're often called. Is that the, in the android term, it might even be a, it might even be an ios term, but the concept is all there that you need to tell they, oh, s here is where the person is kind of in my app. Here's roughly what they're doing. And as long as you keep doing that, the [inaudible] can learn lots of interesting things. It can learn, um, some forms of automation because they can see, oh, we see you go to this map address all the time. Would you like to open that up? And they can suggest it. You can do manual Siri integration where people can assign commands to doing those kinds of things. And so I think it's kind of exciting actually, if you look at it from an architectural thing where we always talked about navigation in our apps, but that's almost a byproduct. But we should also, and more kind of importantly be thinking about what are the activities people can do in our apps and how do we want to break the APP down into those different areas. Speaker 2: 31:18 Yeah. I sort of, funnily enough think of what they just introduced with. I know we haven't talked about cross platform and we probably won't go into it cause it's a whole set of complexity. But that being said, with Xamarin forms for Oh, in Shell, which gives you an abstraction over your entire app sort of hierarchy. What would be interesting about that API is that they have a new navigation, Uri based structures. You pass it a string. So for instance, you start uh, start grouping these chunks of your app into URL schemes, which can take parameters. Guess what, those parameters could be good for hand off. Things like you're handing off the state of where you're at or what you want to do. So for instance, you might have slash picture pickers, slash editors slash ID and then or file name, and then that passes the file name in which you open up. I wonder if they thought about this when they built the API or if it's a byproduct. I'm so interested, by the way, I have no idea. No. Inside Baseball, Speaker 3: 32:19 I think that deep length have just been an issue. We've, we've all known that we need to support something like this. So if you're going to go through the effort of building a new navigation system in this modern era, it's just smart to make it something based. Url based nses are activity based, something you know, you gotta add some kind of high level organization to cause people don't want to start at the beginning of every APP. You know, you switch over to the Facebook APP, you want that post up, nothing else. Yeah. Yeah. Speaker 2: 32:47 And also for rehydration too, by the way, often you know apps, I don't see it all that often, but sometimes, especially on Andrew and some of the Google apps will do this is I may close G-mail, like swipe, get Outta here where I'm inside of an email and they open it again and literary rehydrates to that email. It's like here's where you just were because it saved out that state or that Ns user activity, if you will, of what I was doing. Speaker 3: 33:13 Yes. And so that's exactly what you're going to have to start doing on Ios. So any major areas of your app, you're going to have to create an nscs or activity to notify the oos that person's in that area right now. And then when you, um, create a new scene, you're going to pass in a new user activities saying where you want to take that person too. And then it's up to you in your Ui creation, seen creation code to restore the Ui to that state that it needs to be to show that deep link to people. So it's definitely more effort. Um, and it definitely exposes your app more because not many people design their apps to be multi window who's going to be in the person editor while they're also in the picture at it or whatever. So you're going to have to make sure you're using your observable objects and you heard observable collections because the same model objects can very easily now be on two different screens side by side. Speaker 2: 34:13 That's true. Yeah. You want to make sure that often before where you maybe weren't subscribing and notifications are there share, they may be updating and hydrating on both back and forth. So when are you saving the state and when does it get updated in general? That's a tricky to think about. I mean, it would be nice. I mean I think of a lot of different instances of browsing details going, going through you opening maps to a destination or multiple areas or multiple maps or um, multiple navigation routes or editing multiple photos or things like this where you'd have to build those separate, you'd almost have to build a Ui to be like, you can now edit three pictures, but now you're building one Ui that can just be open multiple times. Which, I mean, there's an operating system that does something like this. I'm not sure what it's called because it's kind of like your opening multiple windows. And normally you can have some windows open and the APP open, Speaker 3: 35:11 they probably call it doors. Doors would be a good game for that. Opening new doors. Yeah. But well, the difference here, yeah. Speaker 2: 35:21 I mean the thing is, but so now like is it just one app though? If you have multiple scenes open or is like a scene? It's own little APP. Speaker 3: 35:29 I'm so confused. Right? And that's where APP delegate got split up. So it's still just one app, still one process so your APP can still crash. Here's the interesting thing though. Instead of your APP crashing and making one window in the task thing, not work anymore, now you've just made all of those not work. So if I open one of these old scenes, it's got to start your app back up, give you that nscs or activity, and then you got a deep link into it. So your one app can have these multiple windows. Your APP can be shutdown because it's in the background. Your App could crash, but it's still just one APP and it'll get rehydrated. It'll get spun back up a lot of times now. Speaker 2: 36:12 So in contrary though, to chrome or edge for instance, or any browser, let's say a browser where a tab crashes or something like that, normally the process would be that you could bet that tablet close, but the browser would open, like the main APP opens. Um, in this case, because they're their own process, but they're not their own process, it's still a single process. That's hosting multiple things that's similar to let's say how, well, I mean it's similar to how, um, I'm trying to think of how that's similar. Okay. Speaker 3: 36:47 Look, it's, it's multiple windows. Just like you said, it's exactly like writing an old desktop out back in the day. It's like writing on modern madcap Mac apps behave this way. Did you come up with one? Speaker 2: 36:58 Yeah. If you open up visual studio and you open up some extension thing and that extension then crashes and they're in the same proc in Dev and V, uh, then it would crash, right? Yeah. Anything else? If I'm inside of stream labs, obs, which I'm in right now, and something else, another window crashes, the whole thing crashes in general because there's not sandbox unless they spun up a different process, which is kind of how proud was, are doing cause their own, like they're all mini apps with the big show, but if the shell crashes than everything, Speaker 3: 37:28 it's a little bit sad. All right. Back in the day, anytime the user would move away from your app, the Ostp took you down completely. Yeah. Yeah. So state restoration was a big deal back in the day. We were all super careful. This is exactly where you are in the APP. This is like we recorded scroll positions, everything because in an ideal world when they click the button and started your app up, it would come back exactly like what it looked like in, uh, in the past. Then apple enabled this, um, background saving and so it saves the ram, it says whatever. I can have your process and then just tries to spin your process back up again. And with increasing hardware, memory has gotten bigger. Everything's gotten faster. Our apps they running, running, you know, in a suspended state but running for quite a long time. Speaker 3: 38:20 And I think honestly, most of us have gotten pretty lazy about state restoration these days. Most of my apps, um, well mine are file based so it's a little weird, but I just remember what the last file was that you were looking at and try to pop that one up the last time. It's not the biggest state restoration tax task ever. But um, it means that if you're going to support all this fancy multisim stuff, then you're going to have to make sure your restoration game is on. It's good. Yeah. I have not worried about restoration for a long time. So Speaker 2: 38:57 Aye. Aye. Oh mean also the, the, the point is that the question is, do you, if someone swipes away, you're out. Do you care about your restoration at that time? Speaker 3: 39:07 Uh, well if they swipe you away, that closes a scene. So that is the signal for a scene closing that's not apple closing anymore. When they closed the last scene, then maybe your app will actually get close. So it's not even a reliable way to kill apps anymore because you never know. That APP might have had a different scene open Speaker 2: 39:27 like way over there, way over there, way over there somewhere. Exactly. Yeah. Cause I did notice that they were showing like the reminders at maybe that's what it was and they had like a 20 windows open or whatever, 20 scenes open. I guess we'll look at what we can do. [inaudible] all right. So people can drag and drop things. But I also noticed that is three d touch dead in iPad. Ios is yes, no iPad. I pad. Good. It should go away or is there another long, is there a fifth long press? Is there, is it, is it depth? It's like, you know, it's not, it's like when you go to delete intentions, not quite. It's intense. The face ID kicks in and it says, we know right now that face that you're making that looks like you want to open a pop. Yeah. Speaker 3: 40:18 Yeah. Okay. So iPad has never had um, three d touch because really they don't support it. What it has had is pressure on the um, a pen, pencil, pencil. Yeah. But it's never had that. So it was the reason why I never had my apps rely on it because well, a only some phones had it back in the day. Now most of them do. But you know, it was an unreliable feature but be, and I think the reason why I'm like kind of excited. I think you are. It's because it's a lot of undiscoverable features. I never, well it used to be called like forced touch so I still call it for touch. I never do that. Like who? Who's going to press hard on their screen? It's the pizza glass. I'm not going to like shove my finger into it. So I think they've decided as that just long process. Alright android does it. It's become, it's colloquialism, it's a language touches the language and long press means I'm interested in this thing. Tell me more. And so iPad has adopted that, thank goodness and I think it's going to spread all the phones too. Speaker 2: 41:25 I like that. That's a good idea. And I will say that with three d touch, there were a few things that you could do with it, like kind of transitioning into an activity but also the, the the icon which they introduce on android too that you can long press on and I can get more information. And that one is relatively useful when you want to delete an app because there's a little pop up that says like info, delete this app. And as a bunch of other stuff into it, but I don't ever use it for the other actions that are in it and because they're not really discoverable in general. But I do love for instance in pocket casts I can long press on a podcast and then it goes into an edit menu activity and different things happen cause I want to do more to this thing. You don't often want to do more to the things of an app because our brains are like I just want to launch the APP like gimme in the APP. Right. In general, but where the buttons, where are the buttons? Yeah. So so that's cool. Uh, that there's a now proper long press, long tap, long press is, is it a new gesture? Speaker 3: 42:30 Well it's kind of new just because we've always had the long gesture but what they've done is attached, like you were saying when you long press there was some builtin o s o s wide activity. You said here is another view controller when they press hard here, pop up this view controller. So you could kind of think of that as a context menu on a desktop. So on any object you can right click and you get a context menu. Yes. Things to do stuff, stuff to do. I like that. Yeah. And we haven't really had context menus. In ios we do have one kind and that's when, say you're in a text editor and you highlight some stuff and then you tap on it. Once a little black menu comes up with cut, copy, paste, look up, define it's um, I think it's called like Ui menu controller. Speaker 3: 43:22 It's not hard to add to your views. You should definitely look into it. But it's pretty limited. It's just a bunch of black buttons with some text on it and they're only ever able to fit like three or four of them on a screen at a time. So then you got to scroll or you've got to hit the Arrow. A lot of people don't know, but you can just scroll that thing. So don't use those arrows the really hard. But um, you want to do more. Uh, so on the iPad you would maybe do a pop up menu on the Iphone, you would do something else. Uh, you could do a modal controller or you could do that three d touch thing. And so they're just kind of unifying the space of what do you do on the iPad? What do you do on the phone to get a more of a context menu. But it's beyond just a bunch of commands. So you can put a picture in there, you can put some actions in there, you can put controls in there. It could be a whole different Ui and it's just unifying the experience. The cool thing is when you use, um, catalyst technology than it actually does, um, respond to right clicking. So that's how you create right click menus. Speaker 2: 44:27 Ah, so if you start to kind of opt into this, because what I've heard, frank, is that starting Speaker 3: 44:32 this fall, I can literally, no matter what, no matter what my application is, I can check a checkbox and then my app is now on the Mac. That's what I under this is my comprehension of of it, which is I no longer ever have to build a Mac app because my at Mac apps are been written for me for free no matter what. That's correct. That's absolutely correct. So long as you are a perfect coder and abided by all API documentation and even the documentation that wasn't written, you know that stuff you just should've known. As long as you abided by that too, then I think you'll just be fine. We'll be fine. Oh, perfect. Okay, cool. Well, I'm excited to run scoreboard and my scoreboard application. I'm excited to rebuild. Um, rebuild my countdown timer. Meetup manager can come to it. Yeah, I like that. Speaker 3: 45:24 Why not right do it everything. I'm super excited. We've already talked about catalyst, but a lot of the reasons that you're going to invest in all this new iPad scene stuff is because just like that other theoretical operating system called doors, Mack is able to show these things called windows. Wow. Crazy. Yeah. And your scenes become windows and it's kind of Nice because I'm Mac windows if they're the same type already have tabbing built into them. So you actually get free tabbing in your app if you're like a document based APP. But otherwise whenever you pop open a new scene or someone does a draggy and droppy operation, it creates a new window, which I think is super nice because macs are super drag and droppy. That's kind of what defines them. I like that. Yeah, it's, I'll be really intrigued to see how this applies longterm in some of my applications. Speaker 3: 46:20 Just what I have to do, how do I have to build it in, or if I don't decide to do anything and just click a checkbox to put my existing app on a Mac, will it function and be okay or will it actually start to make me build a better iPad application and we'll Apple's end all be all scheme to get better phone, tablet and Mac apps and will it all work? And will it be enough for you to not have to write a Mac application for ice circuit for Calca in general. That is the real test in general of catalyst, which is will you be able to take your existing iPad slash iPhone app, click publish, go. And now it's just on Mac. And like that's the question. Yeah. Um, I think you will be able to, but you're definitely gonna want to invest time in all of this stuff that we just talked about because otherwise you're just going to have, honestly, it'll be just like a lot like a web app honestly without a back button. Speaker 3: 47:19 No, it should have a back button as long as you put it back button. But it'll just be like a little web APP stuck in a little window to really make a few OSC. You got to put in this extra effort of um, creating these activities, handling multiple scenes and something we didn't get to because it's more just on the Mac side, but menu, menu bar, you can define menu bars and Ipad apps now, which is totally trippy because I pads don't have a menu bar. So why would you do that for the Mac or the Mac and they tried to make other reasons like Syria, etc. But Speaker 2: 47:53 yeah, now do I have to use the new stuff if I w if I don't want to do anything and I don't change my app, will it just magically knock at multi window? Like is basically what I'm saying is if I have my app and I'm like, I don't want to do any work, frank, because I'm just not about it and I want to not super about it. And if I don't do anything, nothing bad happens. Correct. Like all of a sudden, my app, does it become a multi window app magical thing or does it, you know, and I recompile against ios 13 Speaker 3: 48:25 as you were asking, I actually had to quickly search the documentation cause I wasn't sure what they had deprecated and not deprecated. But as far as I can see, they didn't, did not Speaker 2: 48:36 deprecate Eddie. Speaker 3: 48:38 Oh shoot. Well they didn't deprecate too many things. Okay. So you should be fine for now. Uh, the problem is these are parallel API APIs. The scene Api in the APP delegate Api Apis. So writing is on the wall. Uh, it's not that much extra code to support the CNA API. And if you're doing something like Xamarin forms, it'll really be up to Xamarin forms to support it. So hopefully just write to David and say, Hey David, listen to this podcast. When are you going to update for Ipad? Oos See Speaker 2: 49:12 what you're thing. Yeah. Wow. Okay. So go read some documentation. We'll link to some videos, APP, delegate nses or activity long tapping context menus, free Mac applications. I'm all in. I'm going to build all my iPad applications to be absolutely amazing. For iPad it was the best s that is just ios. I just don't believe, wait, does that also mean that truly then makeover is really just ios? No, don't, don't take that from what we just said. If I pad is just ios and you can take an iPad application and make it a macro ass transitive property, that must mean that a Macko HAZOP is just an ios app. Here's the real question, James. How many windows can you have in a scene? 51 50 as many as you want. As many as you want. All the windows. All right. All right, great. Well I'm over this. I've had stuff. I actually do have to go watch some videos and probably eat some dinner tonight at some point, but before we get out of here, there is one important question, not about iPad. It is about the Frank Krueger Iot effication challenge of your fan. Not a fan of the podcast, but a fan that blows air on you is thing magically Speaker 3: 50:28 Iot. I is it on the ground in a hundred pieces. What is the status of the challenge has been one week. Don't let me down. All right James. It was totally on the ground in a hundred pieces and I had that moment where I was like, what did I just do? No podcasts this worth this. That was a fully functioning fan and now it's not. It's on the ground, but I'm proud to say that a, I learned how it works and be figured out how I could iot a it, but more importantly see got it partially reassembled so it could send my function as a fan for the next day because it's really hot here in Seattle. So that is the say the operation is moving along nicely. I'll say it's 50% complete. I know how to, now I know what I needs to be done. I just need to be willing to start cutting wires on the fan. Speaker 3: 51:22 So stay tuned for update number two in a week. I'm excited about it. And please don't electrocute yourself, Sarah. Don't do it well. I've already shocked myself once, so I'll just try not to electrocute myself cause yeah, nothing wrong with a little shock. Okay. Nothing wrong with that. That just means you're experiencing something new. For the first day was it was reminding me that it was plugged in. I had forgotten that it was plugged in and how it's like, Hey, I'm plugged in. I'm like, Oh yeah, you were plugged in. Did I tell you the point? The part where I was disassembling my can parents, old computer and I shocked myself on the power supply built into the computer. Oh, that's DC too. That can be kind of rough. It was not pleasant. Now this was a old compact machine from 1998 but the power supply built into it was fully exposed like we did up in the case. Speaker 3: 52:18 Everything inside of it was fully exposed, so the big transformers, you've probably touched a transformer, maybe even a capacitor would had enough to get through your skin. I may have moved back a few inches that day in into an space like multiple dimensions and when I spa, when I touched it, I literally moved. I did not jump. It moved me back. I would say it was, I don't know how many, like what the wattage was on it, but like what's the wad, what's a low wattage that you could get electrocuted and not have to go to the hospital? So by a hundred instead of just 150 not trying to be pedantic but electrocuted literally means you died from an electrical shock. Okay. So once the, what is the, the, the amperage voltage or wattage, like what is the thing to be worried about in [inaudible] and in Europe? They'll wall cannot kill you. Speaker 3: 53:13 It will not kill you because that's why we have fuses in the walls. That's why homes get certified. There is no fuse that's going to let enough power through for you to die. That said, the fuses on your like washer and dryer and things like that are bigger and those ones might let you die. So hard to say. Um, you are going to need a lot of power going through. I don't want to give a number because someone's going to like try and that would be bad. Okay. But let's just say it's more than the wall. Definitely a lot more than the ball. How much power comes through my wall? It's it, you have to look at the RMS power, I guess because it's AC. So there's different, different amounts of power at different points. Speaker 2: 53:56 All right, so I have a, I have one of those APC big power things. It says it's 127 volts. Speaker 3: 54:03 Yeah. So call it 127 volts, then it's how many amps you multiply the voltage by the amps to get your power. So if it's 120 volts and one amp, it's 120 watts. Like a light bulb, like an old fashioned bad light bulb. Uh, you can handle that. You're hunting hundred watts. Yeah, Hunter Walk, you're fine. It's a load into it. You'll be fine. You can handle a hundred watts. Uh, the thing is that humans also act as an insulator. So you need a lot of voltage in order to get the current to go through us, you got to break down. So, um, you need, you need a high voltage. Both you want power and high voltage. Speaker 2: 54:45 And this has been a great way to have an in Florida, a formative and to the podcast, talking about ally extricating yourself. Well, that's going to do it for this week's podcast. I encourage everyone to not mess around with open electrical things without rubber gloves or without things that don't static shot, just a harmless little stash, don't we? We, we encourage you not to mess ever with electrical engineering unless you know what you're doing. Um, but also to subscribe to the podcast. You can go right now on your favorite podcast app or if you don't have a favorite podcast APP, go into the APP store and download a podcast APP. Or if you're on an ios device, it's literally built into the operating system. It says podcast. It's there. Just type merge conflict. Hit that subscribe button and also do it on all of your friends and your families devices. Speaker 2: 55:35 They will thank you for it and make sure that auto download of new episodes is checked. They will just be like, wow, what a wonderful morning. Every single Monday I can now drive to work and I'm so much happier now. Thank you. You are the best son and or daughter in the entire world. So boom, you're good to go. Additionally, you can check us out@mergeconflict.fm. You can write to us, tell us your story of being electrically electrocuted in the past. Just like me doing work on my computer, it was a lot of fun and now it's a great story that I can tell frank over and over again. Again, you should not do that. Don't do that, but you can write to us at merge conflict out of him or follow us on Twitter at merge conflict f m additionally, for the first time ever, frank and I twitch stream this on my twitch account. twitch.tv/james wants a Magno. Follow that jam, that follow button. You'll get notified when I go live coding, but also if we ever decided to do another podcast again, a lot of good people hung out with us and it was a lot of fun. So that's going to do it for this week's podcast. Until next time, I'm James Monson Magnum, I'm frank recurrence and thanks for listening. Piece.