Jon (00:08.222) Welcome back to another Gone Mobile. We're here, we're back again. And if you remember from our previous episode, Alan was about to try my virtual list view. And I kind of said, well, if it goes horribly, there might not be another episode, but we're back. So it must not have gone too bad. Allan Ritchie (00:24.364) You opened with that, huh? I guess that was a good thing to start with. But yeah, it did. It ended up fixing my problem. It was an interesting problem. It was only, it was like dynamic sizing with the collection view, but only on the phone tablets and more specifically the iPhone 15 Pro Max. Is that what it is? Jon (00:44.566) It's a massive phone. Allan Ritchie (00:46.882) I don't know. I don't know how people use it, man. It's too big. Jon (00:49.098) You need like bigger pockets. Like, I don't, yeah. Where do you put it? Allan Ritchie (00:52.928) Is that, what do you have? Jon (00:55.206) I have a 15 Pro, just the normal Pro. Like that's fine. No, no, it's the smaller of the Pros, right? Like it's decent sized. It fits in my pocket. Allan Ritchie (00:58.016) Isn't that a huge phone? Or is that in between? Allan Ritchie (01:03.728) Okay. I don't bother getting it because it's only the camera that upgrades, right, from the regular iPhone? And it's green size. Jon (01:11.048) Yeah, I don't even remember anymore. I just was like, oh yeah, new shiny thing. I'll, I'll go grab it and see what it's like, but it's, it's. Allan Ritchie (01:18.348) I never get them because the camera just like I take crappy pictures anyways. Why do I need a better camera for? But yes, it solved it a hundred percent. Um, I used it on a customer project and they're quite happy. So good job, John, your, uh, your controls, uh, getting some sweet love. Jon (01:22.239) Yeah, I don't I don't know how to make use of that Jon (01:38.126) So let's maybe cautiously, optimistically suggest that somebody could go out and try it. We'll start with that. See if there's more bugs. I do want more people using it because that'll help me figure out if there's things missing or scenarios that I haven't tested. So please check it out. Allan Ritchie (01:53.964) You know what I'm thinking? I might, I might use it for a few scenarios because just like that's usually the first thing that comes up is, and you need a simple list. This is simple list. It just works. I didn't have any issues. I think it took me, I think between the time we ended our last episode, it probably took me five minutes to, to convert the code that was there to work with your adapter. Um, that was it. It was up and running. It was great. Jon (02:17.994) Nice. So I see you've preceded the show notes with a question that you didn't, uh, you know, clear by me first. Allan Ritchie (02:27.145) This is my question of the week because I've never asked it. I've never asked it and I'm like, I said it at the end of the last episode. It was like you're going to have to explain this red to me at some point because like I'm not really sure how you got that as a nickname. But yeah, do fill me in here. Jon (02:44.158) You know, I debated because I've held this secret fairly close to, you know, my chest over the years. And probably only mostly because it's like a really silly story. A few people know a few people do know already, and they've probably told others. I think I think like David's probably told others or something. He probably forgets when I told him anyway. However, OK, here's I'm willing to do it. This is the big reveal. Allan Ritchie (03:10.212) Uh oh. Jon (03:11.402) This was, this has been many years, many years. This goes back to when I was, I don't know how old I was. I couldn't have been more than like 12. And back in the day, I played some MS Flight Simulator 90, I don't know, was it, was 95 a thing with them or 97 maybe? Allan Ritchie (03:34.737) I never played the flight sims, that's all you my friend. Jon (03:37.542) So I played MS Flight Simulator and I needed to find a online handle that I could use to play multiplayer. I don't know why I even played multiplayer. I think it was flight sim. It was some kind of flying game. And, you know, finding a name that wasn't used because like John, you know, was clearly taken. And then it's like, well, why don't you use like John 78, 34, 23? Right. It's like, no, I'm not doing that. That's silly. I don't want a number in my name. So I. Kind of was just looking around and I thought, you know, I just watched some, you know, probably Tom Cruise. It was probably top gun or something. And all of the pilots have these call signs, right? Like, um, I can't even think of one off the top of my head, but they're all like, yeah, exactly. And so I started looking around and I came up with red thunder and red thunder was taken. But then it was like, I think it suggested it's like, well, why don't you just use the RADTH? I'm like, Allan Ritchie (04:19.448) Maverick. Jon (04:36.506) Okay. And then what I found was over the years, like if I was looking to use a, a handle on something, like nobody ever chose that. So I'm like, I'm rolling with this because it's fairly unique. It's never taken on platforms, you know, new platforms. And, and so it just kind of stuck. Allan Ritchie (04:49.144) Hehehe Allan Ritchie (04:52.84) All right. Well, it works because it's hard as hell to pronounce, right? Because you've got to go red. And oh, yeah, I'm sure it is. And you use it for every everywhere. So that's how people know you a lot of the time. That's a red guy. Jon (04:56.298) Yeah, but it's pretty SEO friendly, so. Jon (05:04.938) Yeah, yeah, no, true, true story. That's that like conferences and stuff in the past. It's been like, you know, oh, hey, you're that guy. Then I tried to pronounce it and it's like, yep. It's always fun. Allan Ritchie (05:16.652) Well, that explains it. I've always wondered, I was like, you know, this doesn't match your name at all. Jon (05:22.066) No, no it doesn't. Allan Ritchie (05:24.49) All right, well. Jon (05:26.078) So what are we talking about today? Allan Ritchie (05:28.716) Oh, we're going to do one that's near and dear to my heart and backgrounding and all the fun it brings. I also have that in quotes. I can't, you can't see my air quotes, but fun. Jon (05:37.674) So backgrounding, that's just easy. You just use a thread, right? And you're good. Allan Ritchie (05:41.528) That's what everybody does and then they go, hey, this doesn't work, right? Must be Xamarin bug. A lot of people think that those async things, they just work. I don't know, what does it mean to you? You don't get to work with this area a lot. So that's. Jon (05:56.326) No, but I, you know, we, we talked about the, uh, like I think it was the push notification stuff, um, and, oh no, and then the list stuff too. And, and funny enough, so like, I wrote whatever the chapters were in that one book that we talked about, I actually went this morning and dug out the copy that I still have in the basement. And I looked back and funny enough is I actually did write some stuff on push notifications for that one that I completely forgot about did the list stuff. But then also I wrote a chapter on background. Allan Ritchie (06:02.455) That's true. Allan Ritchie (06:21.72) Yeah Jon (06:25.802) uh code you know basically encompassing everything android related at the time so like this was i there's like a footnote in there that's like if you're targeting less than android or api level five i'm like oh yeah well this is old right like api level five was a thing okay um so i know i you know a little bit biased in my understanding of what backgrounding means on mobile i knew a little bit about android uh but to me backgrounding Allan Ritchie (06:39.41) Oh wow, that is old. Jon (06:53.558) You know, from a mobile development perspective is really just like, how do I execute code when my app is not the thing that's in the foreground? My app is not the thing that's kind of like running quote unquote, you know, on the user's device, right? So that would be my simplest understanding and explanation of it. Allan Ritchie (07:09.612) Yeah. Allan Ritchie (07:14.256) And it's not, it's not far from the truth. That's for sure. I think people have different understandings of what background is. Cause there, you know, a lot of devs from web perspective, they're used to having just stuff run, right? Like if, if you're on a server side, stuff just runs, you can have scheduled jobs. If you're in like a WPF, if you're a windows dev, it's just kind of your app is always there or it's a window service. It's always there. Mobile is different, right? Mobile has that, uh, Jon (07:29.901) Yeah. Jon (07:40.267) Yeah. Allan Ritchie (07:43.904) Well, your users like their battery life, right? I like when my phone can make it through the day, right? So, you know, there's a whole bunch of things that it kind of stops your app from doing for good reason. Thankfully, because again, I want my phone to last the day, not, you know, 35 minutes. So some of the stuff I've seen people try and do over the years is like you said, that async task, you know, you run an async task to you to do something. Jon (07:48.131) Usually. Yeah. Jon (08:02.667) Yeah. Allan Ritchie (08:11.592) And let's say I just wipe my phone away. Well, Android generally tends to let those finish as long as they're not too long. Yeah, they do. They'll they'll start shutting it down if it wants the memory that they'll take it right. iOS is far less forgiving. Soon as that app goes away, it's got about four seconds before it's like, yeah, shut up. You're done. Right. Jon (08:19.427) Do they actually enforce things? Jon (08:24.663) Okay. Jon (08:38.61) So what are some of the things that you see people wanting to use background jobs to do? Can we break it down to a set of common scenarios on mobile? Allan Ritchie (08:50.32) Well, usually there's things like data synchronization, right? Like a lot of people want that offline. So they might use jobs for stuff like, you know, does my, you know, get me the, get me the all the data or all the work I've been assigned since the last time I asked, right? Jon (09:08.735) So network access is one obvious one that people want. Allan Ritchie (09:10.984) Yep. And same pushing my data back. So if I'm online, push my whatever work I've done since I came back into coverage. Maybe stuff like GPS. Where am I currently at or where have I walked? Right here it is. So my employer can sneakily track me, whatever. Stuff like that, right? So a lot of people, jobs don't really go too far. Jon (09:19.916) Mm-hmm. Allan Ritchie (09:40.02) in terms of a mobile background, right? Like they just, like I said, data synchronization. There's another one, image uploads. That's common. A lot of people try to say, oh, I'll just, you know, an image uploader should only take a second. Jon (09:48.44) Mm-hmm. Jon (09:52.926) Yeah, like you post a like if you're using like a good example, probably a social media app, right? Like I'm going to go post a video even right. And upload that to my account. And it's like, well, what from the app developers perspective, like fine, your user wants to do that, but what do you do to, to make sure that it still works once they just swipe the app closed right after they hit post. Allan Ritchie (09:58.125) Yep. Allan Ritchie (10:13.004) Right. And it gets worse because you don't even necessarily get the chance to trap an error. Right. So if I upload an image and the platform goes, yeah, you're done. Right. It just fails like silently. There's no, you can't track an error. You don't know that upload never hit your server does. It'll be like, Hey, you told me I was expecting like 12 megs and you gave me three. So what would you like me to do with this? Right. Jon (10:24.045) Yeah. Jon (10:40.446) Yeah. And the user doesn't know, right? Like so bad user experience. So they think everything's great and it's just failing. Allan Ritchie (10:42.805) Nope. Allan Ritchie (10:46.312) Right. And so you don't have that, right? It just kind of evaporates and your picture's gone and you see that a lot. Jon (10:54.942) And that's kind of, so like that's seems like one common scenario where you are initiating the background job as a result of doing something in the app. Right. Like is that, that's one way to do it. Are there other kind of categories of, you know, can I, we talked in push notifications, right? So like that's, that's another one, right? You could, you could tell the server to do, to tell the device to do something. Allan Ritchie (11:17.94) Right, but you only get so many of those. Like I said in that thing, like I've seen people abuse push notifications, so they try and send silent ones and then Android doesn't seem to stop those. Like it doesn't throttle them very much, but iOS sure does. Apple will start saying, yeah, you can't do this, man. You can't keep telling the device to wake up. The user likes their battery. So you don't even really get that. There's other push notification settings with Apple that you can use. They've got that activity one. Jon (11:31.465) Mm-hmm. Allan Ritchie (11:46.656) So if you want to keep real time sports scores, but it's not really your app running, it's. It's like some sort of pseudo Apple app that they say is approved because it, they know their code runs fast. Jon (11:58.226) Yeah, so it's a pretty constrained way to do something. Allan Ritchie (12:01.512) Right. So a lot of those things come up where you just push notifications, just don't do the job, right? You have to really use them for messaging and just bits of data. You can't use them to kick your Apple life. It's just not a good, it's not going to work out for you. Jon (12:18.606) And each platform also supports some idea of like schedule jobs, like something that happens on a recurring basis or something like that. Is that. Allan Ritchie (12:29.78) Oh, you use the bad word. I love that one. Well, a lot of people think jobs on these platforms, and I'm gonna cover this more when we get to each platform, is it's scheduled. Well, no, that means you could decide a time interval or like a date and time to run. Yeah, it doesn't quite work like that. It doesn't work like that at all. It's periodic. And what that means is that, you know, so Android has their... Jon (12:32.779) Recurring. Jon (12:52.738) Right. Allan Ritchie (12:58.264) their tools and iOS has their tools for how it runs, but they're very smart, right? If your battery is almost dead, they might say, yeah, guess what? We're not going to, we're not going to time slice this for you. You're not going to get any runtime. iOS is even smarter. You know, it'll, it'll say the user doesn't use this app in the middle of the night. We're not running it right. You don't need to sync data in the middle of the night. You can wait until about 20 minutes until they're about to run the app. Jon (13:20.619) Yeah, yeah. Allan Ritchie (13:27.678) So they're very intelligent about it. Jon (13:29.734) Yeah, so they're really protective of the user experience on the device, right? And you're just basically asking like, can I please do something sometime? And when I can just let me know. Allan Ritchie (13:39.864) Right and it's smart though right because again they're doing it proactively if you do need to send a message so like a chat app right that's a great one. I do want to know when a message comes in real time but I can do that with a push notification without my app ever opening right so it's those things that people like I said syncing data you can still use a push notification to say hey you need to get data right but you don't you don't want to do it all the time. Jon (13:50.84) Mm-hmm. Jon (13:54.847) Right. Jon (14:07.969) Yeah. Allan Ritchie (14:09.192) So the other ones that I tend to see, this is the big one usually is real time GPS. So I know Maui has started to do stuff with that. You guys are kind of looking at it. Jon (14:14.807) Okay. Jon (14:20.15) Yeah, we I mean we've been GPS location on Maui, especially from an Android perspective has been kind of interesting because we haven't yet taken a dependency on the place services implementation of location stuff. And we've talked about that back and forth quite a bit. It's probably overdue to do that at some point. But for now, we've just kind of said. Allan Ritchie (14:36.548) Yeah. Jon (14:47.262) Let's let's keep that simple. Let's not pull in that extra dependency. And let's that has implications for all sorts of stuff, right? To have that particular dependency there. But I think we're at the point now where it would be fine. It's just we haven't planned the work to do that yet. So. Allan Ritchie (14:57.752) For sure it does. Allan Ritchie (15:04.288) And it really, that's the thing you really need for Android. You really need their GPS library, like the Android X1, um, to do things properly. Right. Like the built-in one, I don't know why they just don't make it part of the OS, but it's, it's just. Jon (15:12.13) Yeah. Jon (15:18.526) Yeah, that was a funny one, right? Cause it's such a core function of devices that you would think they would just have said, okay, let's just make the core one work a little bit better too. Allan Ritchie (15:28.116) No, but it's got to be part of Google Play for whatever reason. So that, you know, okay. So we got to take. Jon (15:30.231) Yep. Jon (15:34.69) There, and there's still implications, I think, like, cause that, that particular one, I think does even need play services on the device, right? And I'm not sure if all of them do, but I think that one does, which is, was fine. If you're shipping to, you know, regions and stores that. And devices that have that, but that, like I said, that's a whole other kind of can of worms and we'd have to kind of. Allan Ritchie (15:42.728) Yep. No, it does. Why? Jon (15:57.442) figure out what our polyfill kind of story is around that for devices that don't support play services. And, and that's part of why we've just kind of said, you know what, let's not go there just yet. Allan Ritchie (16:07.884) You can just use shiny locations. I already have the fallback in there and it works. Jon (16:10.314) There you go. Yeah, and honestly, that's another reason. It's like if there's good implementations out in the ecosystem for some of these things, and I know we get requests all the time for this kind of stuff, we're like, well, this should be part of MAUI. It's like, maybe, but like, let's focus our attention on other things because this other thing exists like Shiny out there already that does the work for you. So just like go use that, that's fine. Allan Ritchie (16:34.288) And that's the funny thing too, right? Like people, people want that, that GPS stuff and they don't realize that there is a lot of work and that Maui isn't meant for the background. Like that's, that's a different part of an architecture, right? Um, Jon (16:44.087) Yeah. Allan Ritchie (16:48.404) So there's all those things to consider is like, you're going to take that hit on the, on the G on the Android X package. Are you really going to deal with the moving target that is Android in terms of permissions, how they background, because it changes a lot. Jon (17:02.187) Yeah. Yeah. And even for us, like, you know, just do we want to, is that the best place for us to spend our time that we have to spend on things, right? Like to duplicate efforts that are already out there from a number of reasons. Like one, I don't want to stomp on work that you do well, um, and say like, well, no, now we're going to do it right. That just stopped. That's not really an open source kind of friendly way to go about it. And in two just. Yeah, the, why, why duplicate the efforts in the, in the ecosystem? Like we all, we're all friends. Like let's all kind of work together and cover the whole spectrum of things, you know, in any way we can. Allan Ritchie (17:42.924) Well, think about the permissions, right? So Essentials does permissions and everybody uses them, except for me, I can't, I can't for Shiny because I tend to be a little bit different with the ecosystem. I have to work with the UNOs and the native and the non-MAUI. But if you think about it, right, like how Android changes, like your permissions are changing almost every Android release. So 14 introduced. Jon (17:47.352) Mm-hmm. Jon (17:55.938) Mm-hmm. Jon (18:08.022) Yeah. Allan Ritchie (18:10.644) Sorry, was it 30? Somewhat, sometime in the last API changes, they added like a background permission, right? Background location permission, which doesn't mean what people thinks it means, by the way. It's not quite, just because you have that permission doesn't mean that it's gonna do what you think it's gonna do, but it's there and you guys had to add it. Jon (18:16.501) Mm-hmm. Jon (18:22.019) Yeah. Jon (18:32.095) Yeah. Allan Ritchie (18:32.62) But if you want real time GPS, which is another thing that's quite common, right? Like people want the GPS coming in. So iOS, that just works. Android, well, it depends where you are in the ecosystem now, right? They've got, I don't know, if you go back to your Android 5, API 5 level, what'd you have? You had a service. That was it, right? I don't even think they had permissions yet. It was just like, sure, you can run this. Jon (18:39.127) Yep. Jon (18:46.29) Yeah. Jon (18:54.862) Yeah. No. Well, so yeah, like, you know, digging into the Android side of things a little bit, I went, like I said, I went back and read the chapter that I'd written again, because it's been so long, and I covered, you know, a basic service, and, you know, the basic service was like, you start it from your activity if you want, you know, you could start it from a broadcast receiver, you could start it from a few different places. And that service, like the simplest thing you managed yourself in terms of, if I'm going to keep it alive, like I'm going to start a new thread up and I'm, that thread is going to be the thing that kind of like does all the work. Um, but that service could just start, keep running right in early Android. You could just run services and, and I remember having Android devices and having apps that you'd go into like the app, the system settings and see, Oh, this app is running like three different background services. Allan Ritchie (19:47.576) Hahaha Jon (19:48.406) And like, do you want to stop them? Like, yeah, like quit wasting my battery. Uh, which is why I'll, you know, they've progressed more and more towards the, where we're at today. And, and so there was the, the normal services, there was a thing called an intent service, which I mean, these all still exist, but, um, which would kind of. Allan Ritchie (20:05.024) Was that Android 5? Okay, that was still there. Jon (20:06.89) Yeah, it would do the plumbing for you basically, right? Like you start the service, it's like, it's gonna give you the information you were passing over and you would run your code and then, you know, it would stop the service as it needed to, or as you were done and it could. And it even had the concept of foreground services back then. And so like... Allan Ritchie (20:25.44) No, foreground service is new. Yes. Jon (20:28.386) Uh, they had, they had, no, well they had, they had, um, there were things that you could return for what type of service you had. There was sticky. Yep. Allan Ritchie (20:36.98) Sticky, non-sticky, not quite the same thing though. Jon (20:39.934) Not quite the same, but, but now foreground services is the kind of newer thing, right? Like they're really discouraging you having services. It seems like on Android, because if you now correct me if I'm wrong, but my understanding is if I want to keep a service running in my app, it has to be a foreground service, which means basically I have a notification that is pinned for as long as my service is running that the users can see so that the user knows that I'm doing this. Allan Ritchie (21:06.156) Yep. And that's it exactly. Right. There is one other thing that they've added that's kind of newer is the foreground permissions. Right. So you have to say what that foreground service is doing. Like is it doing location. Is it doing some sort of data sync. They've got like I don't know. I want to say eight to ten categories and you have to Jon (21:15.797) Okay. Jon (21:22.586) Is that the user like user has to accept the permission before then it'll even run? Allan Ritchie (21:27.796) No, which is weird. It's more of a, it's more of the, not the runtime check, but the one that you have to put in the, the manifest. It has to be there so that it, you know, it, it knows that it can do it, but it's more, you still have to have like the location permission as well as the foreground location, foreground. Um, I'm struggling to get the word, whatever the permission is in the manifest. Jon (21:35.251) Okay. Jon (21:50.41) Yeah. And then there were, you know, at that point too, there were still originally, there was broadcast receivers and stuff too, where you could say like, Hey, when the phone boots up, you know, run my broadcast receiver. I don't think they had any restrictions on how long you ran code in those either. I could be wrong. Um, but you like, usually the pattern that you would use is to start your service from that broadcast receiver, I think. Allan Ritchie (22:07.584) No, I enter I never didn't care. Allan Ritchie (22:16.213) Yep. Jon (22:16.874) And then once your service is running, the other thing you could do is you could create a binder to it, right? So that you could, potentially from your activity, if you wanted to talk to that service back and forth, you would create this whole binder thing and it would, I forget the details completely. It was weird, yeah. Allan Ritchie (22:31.544) Those were odd. They were odd. We just returned null now in the Maui, the Maui ecosystem. I don't remember the last time I ran a binder was, but I'm pretty sure I've just got null set up for everything. Jon (22:38.207) Yeah. Jon (22:43.026) I think I always pretty much like did the bad thing if I was going to do something like that and had, um, you know, like a static event or something like that. Cause I, at that point, and maybe it's changed, like your app and like your activity, if you had one running and your services, they would still all be in the same process, right? Allan Ritchie (23:03.08) Yyyy Jon (23:04.194) That was the way, I think it's still the way. So while it was kind of not great form to do it, you could have your static and communicate back and forth between the things. Allan Ritchie (23:17.58) So, and all that still exists, but in the world of cross-platform, it's obviously changing, right? So we've got service, we've got broadcast receivers, we've got foreground services, and then we've got all these permissions that keep changing. So for Maui to do it, even essentials, is it really essential, right? And what does that mean? Like I said, background permissions on Android now, background location, whatever it's called. Jon (23:23.669) Right. Allan Ritchie (23:46.708) It's not really what people think it is. I mean, it's great for like geo-fencing. So we don't need real time, right? You can still start up a GPS like listener, but it doesn't really suit anybody's needs, right? So how often do you think it's going to ping on? How often would you want something to ping if you were running a service? Right. Fair. So on average, this is about maybe three to five times an hour. Jon (23:50.128) So what is it? Okay. Jon (24:07.618) Well, it depends what you're doing, right? Jon (24:15.91) Okay. Yeah, that's not super useful. Yeah. Allan Ritchie (24:16.94) I'm not really sure what that's going to do for you. So, but people use it and then they go, it doesn't work. It only responds. I'm like, yeah, that's unfortunate. If you weren't real time GPS, this is where the foreground service needs to come in, right? You need to tell the user. We're abusing you a little bit, but you're well, you're a willing participant. Jon (24:34.802) Yeah. Like I know there's a group around here that was developing for, I think they're still probably doing it. A like trucking, you know, man, fleet management app. Right. And so it's like, if you're, if you're using the app, you know, as a driver or something, there's like, well, yeah, you know, that this thing has to run. And so you just deal with it. Allan Ritchie (24:45.921) Yep. Allan Ritchie (24:56.628) And most of those scenarios, because I used to work for a fleet management company, so that's why this stuff is near and dear to my heart, is you could apply to say, like, look, we're going to abuse the living junk out of your phone, plug it in. Right. And we could send notifications. Right. Now, the cool thing when we talk about real-time GPS, the other one I like to mention is that people also want to keep their app hot, always running. So. Jon (25:10.25) Yeah. Allan Ritchie (25:22.432) Usually iOS is like, yeah, no, that doesn't happen here. Android still, like I said, foreground service, your app is hot all the time. But iOS, if you can sacrifice a pint of blood to Steve Jobs and Apple, they'll still let you run GPS. You just have to explain why, what your business case is. Jon (25:34.924) Yeah. Jon (25:41.757) Is that explaining why, like, just to the user with the permissions? Or is that like, you have to apply for an entitlement, get approval and... Allan Ritchie (25:45.996) No, you have to. So you don't have to do that yet. I imagine that'll come at some point. But you do have to have a good explanation because if it's going hot for that period of time, they will ask what are you doing and why. So not just your permission, they don't care so much about that. They care in the explanation of your app to say this is what we're doing and why. Use at your own risk. Jon (25:51.243) Yeah. Jon (26:01.395) Right. Jon (26:12.074) Yeah, they, they give you the ability to do some of these things. And like that, that happens a lot with Apple. Right. And like you said, not yet, but maybe soon. Um, I know in the past, well, you've, I think dealt with some of like the health kit approval stuff, um, when we were doing, um, for like the, the expo COVID exposure notifications, like we were trying to, to build that API out in a cross-platform thing for Maui and like being able to even get a entitlement to test that was way harder than you might expect it to be. Allan Ritchie (26:17.816) Yeah. Allan Ritchie (26:24.765) Yeah. Allan Ritchie (26:30.52) So that was. Allan Ritchie (26:42.004) It's absolutely annoying that they do that too. It's like, come on guys, you're really slowing down. Like just block at the point of entry maybe. I guess they don't want people going through all that just for them to turn around and say no. Jon (26:42.246) Ah. Jon (26:48.397) Yeah. Jon (26:53.066) Yeah. Allan Ritchie (26:53.676) But at some point you got to let users like that's the one thing I do like about the Android ecosystem is that it's like the user still has to accept the pain like you're doing this knowingly. So Apple being gatekeepers on this stuff is sometimes frustrating and that's why the web is so good for certain situations like this because you don't have those blockers. Right. Jon (27:03.467) Yeah. Jon (27:13.47) Yeah. So for Android, you know, we've talked a bit about the historic kind of stuff and like, yeah, those things still exist. But I think like most of that has moved to two different models, right? Like I remember. Binding some of the first versions of some of the support still, I think, still support libraries at the time for the work manager and the Firebase has some job dispatcher thing, I don't know if that's still what's in use. Like what are the newer things? Allan Ritchie (27:45.598) So in terms of jobs, Android X has their work run time. So that's what China uses in the background. It just feeds off of that. They've got some great set of filters, right? So if you want your job to kick off. Jon (27:50.903) Mm-hmm. Allan Ritchie (28:01.568) when the device gets plugged in or you have internet, right? So again, that connectivity scenario where it's on and off, this thing will kick in, right? You can apply filters like the battery level has to be greater than 20% or don't run, right? So it's pretty rich. It's a great API. It's a lot less handcuffed than Apple's, but again, I think Apple got this partially right as a user. Jon (28:15.117) Right. Jon (28:27.118) Mm-hmm. Allan Ritchie (28:27.884) Because they have the same thing. They have the battery filter. They have the internet filter They just don't run it because they run it when the user is going to step in. So that's fine Jon (28:36.242) Yeah, so, you know, in theory, like if you want to think of that from a really optimistic perspective is like they're kind of helping you to as a developer to do the right thing, right? Like, in a sense, it's like, they're gonna do it at the right time. They're gonna make sure that, you know, if your app, I'm assuming that nobody knows, I guess, exactly how they've implemented it. But I'm assuming that. You know, if your app is more used by a user or something like that, you're probably getting more, you know, scheduled time and stuff like that. So as much as it kind of sucks because you want the control as the developer, you know, you kind of have to look at it from the, the like, hey, at least they're kind of trying to help make the experience better for you, my users too. Allan Ritchie (29:06.231) right. Allan Ritchie (29:17.608) Right. Yeah. Protect me a little bit from my own kind of ignorance on what this app is doing. Right. Because a lot of people are just like, oh, it's one of those annoying dialogues. Yeah. Yes. Give my life away. So they still try and help. What else does it get? Jon (29:21.474) Yeah. Jon (29:29.57) Yeah. Jon (29:34.082) So what, like have we covered Android? Is there anything else that we're missing on kind of the newer way they do it? Allan Ritchie (29:40.628) Well, there's the downloads as well, the transfers. So it's kind of, if we go back to kind of the key scenarios for background when we talked about, we had real time GPS, we had scheduled, not scheduled jobs, I used my bad word, periodic jobs, push notifications, and kind of these HTTP transfers, right? Those kind of four, there's VPN as well. Jon (29:59.51) Yeah, so Android had its own thing like that too, like its own special, I vaguely recall it. Allan Ritchie (30:04.876) They do not have an upload service, but they do have a download service. Not really sure why, but, uh, it's a bit old. It's a bit clunky. It's existed since I'm pretty sure Android, like 13. So it's been around the block. It hasn't really evolved. It's got like a kind of this old little SQL light database. They have to query to see, you know, what's going on, what's done, what's not done, et cetera. So it's there. Jon (30:07.255) Okay. Jon (30:17.614) Mm-hmm. Jon (30:29.506) Yeah. Allan Ritchie (30:31.072) It doesn't, it works. It doesn't need a foreground service, but it's kind of clunky. Um, so what a lot of people are switching off to is again, just your old foreground service where you can do an HTTP client and manage it all yourself. Right. So, and then you can do uploads or downloads pretty much the same thing. Jon (30:44.631) Yeah. Jon (30:50.006) Can you not do some of that in periodic jobs? I guess it's not the right, you know, fit, depending on what you're doing. If you're trying to post a video to social, you know, a media account, right? Like. Allan Ritchie (31:00.448) So I had thought about doing jobs when I was writing the open source version of it. And it just, you want it to start uploading right away. Like if I've got connection, just, just go, don't wait. Don't don't do any of that stuff. So the way I, and you, a job may not necessarily wake up right away when it has internet. So it says, oh, I've got internet. It's still going to time slice you in at some point. So it made more sense. Jon (31:08.098) Mm-hmm. Jon (31:24.499) Right. Allan Ritchie (31:27.008) kind of from a user perspective to just say like look this thing is running the second we see internet we're going to start uploading contract the progress and just let them know that this thing is there and waiting. So that tends that's worked for kind of the use cases that I have. Some people might not like it but it does its job. Now kind of hopping over the fence to the iOS side for the transfers they have the Jon (31:37.921) Mm-hmm. Jon (31:55.7) Right. Allan Ritchie (31:55.956) Now, the funny thing is, is that most people don't tend to know what that is in kind of the Maui ecosystem. Jon (32:01.974) Wasn't that like the kind of first foray that they made into background and stuff in a sense? Like, I don't think they had background tasks as soon as they had the NSURL session stuff. Allan Ritchie (32:12.692) Yeah, they had a they had a fetch mechanism, but it wasn't the same. This is more like. They'll manage it for you. You're almost handing over. Here's a URL. Here's some stuff I want to upload or download. Do your thing right. And it'll notify you. It's all great. Like if your app is in the foreground, it'll tell you the progress. But if, if your app goes to the background, it kind of just manages it. And if it. Jon (32:15.68) Yeah. Jon (32:26.507) Yeah. Jon (32:35.958) But that's pretty restrictive though, isn't it? Like you can only do HTTP based operations then with this. Allan Ritchie (32:42.956) Yeah, that's all it's meant for, right? So you're like I said, you're uploading like a like a big image or database or you're downloading something. It'll still tell you, hey, this download error or this download or this transfer past you get, you know, your usual, which is the other thing within with iOS. It gives you about four seconds to respond to that event. So it's basically come in and go set a flag that transfer is good. Jon (32:48.75) Mm-hmm. Jon (33:05.963) Yeah. Allan Ritchie (33:10.612) And then when they come back into the app, you could be like, yeah, transfer is good. Right. Jon (33:14.238) Yeah, so hopefully you have a fast enough device and like that this kind of stuff I think was much more You know prone to be like Finicky with dotnet or with mono back in the day right with slower devices slower mono Allan Ritchie (33:27.863) Yep. Jon (33:29.022) Now I mean, am I kind of right in saying that it's probably much less of a concern? Like, wait, you know, would it be like, Oh, is the runtime going to spool up enough? And am I going to be fast enough? And I would, you know, going to be able to do this thing in those seconds. Like, is that less of a problem now? Allan Ritchie (33:45.04) It definitely is. Now people still tend to do certain things like jobs. So we used to have a background fetch. So iOS started with this background fetch thing. That was so you could get data. So that was iOS 9 or 10 somewhere in there and you could go off and people would ask for data. Right. And they tend to give you. Jon (33:57.238) Right. Jon (34:03.115) Mm-hmm. Allan Ritchie (34:09.044) I think anywhere between four to 10 seconds there. But if your API is slower, you've got a bad connection or you're one of those APIs that tends to suck in the world. Right. These things would again fail. The OS would trim it down. Um, so iOS introduced this thing that you could ask for a little bit more time. They've got this thing that you can say, Oh, it's going over time. Let's ask for it, which is complicated to do. I mean, you're like, okay, well it's not done. So yes, ask for more time. It's like, why don't you just either give me the time or don't. Jon (34:18.935) Yeah. Jon (34:28.342) That's right. Yeah, like, yeah. Jon (34:35.265) Right. Allan Ritchie (34:38.552) You know what I mean? Jon (34:38.754) Yeah, like if I'm still executing and not telling you I'm done, then like I want the time yet. Allan Ritchie (34:42.468) Then I'm not done. It's like they were like, if you're going to abuse the user, then we're going to abuse you or so. I don't know what their thinking was, but that's what they did. So then lo and behold, they introduced these things called BG tasks and that was iOS 13. And this was a better, this was a better attempt because now they give you 30 seconds. You don't get more time. You can ask for it, but they don't give you more time. You got that 30 second window. I mean Jon (34:48.938) Yeah. I'm gonna make it painful to take too long. Jon (35:04.043) Right. Allan Ritchie (35:10.72) Crepes, what do you need? What more could you need to do on a mobile phone in 30 seconds? Jon (35:14.838) Hopefully not. I mean, the only thing I could maybe see is if you're in a weird state where like connectivity is not great and you're trying to do a bunch of, operations like syncing data. Like, I don't know, I've had requests and it is. I mean, I'm just thinking like I've had requests even like if you load a browser page or something and like stuff is weird with your connection. Like sometimes that can take a while, but yeah, 30 seconds is actually long if you count it out. Allan Ritchie (35:29.196) 30 seconds is a long time. Allan Ritchie (35:45.112) And again, they're really good with these. I don't know. iOS is a different beast in terms of quality. Like if they know that. So I used to take the train to downtown Toronto most days. And I swear to God that thing was stupid smart. It would just go. It's not going to run here. But as soon as I would come into it, like areas of great coverage, it's like all of a sudden my notifications would just be like bing, bing. And I started running those tests. And sure enough, it was smart enough to know, OK, yes, you've got signal. But. Jon (35:50.344) Mm-hmm. Jon (35:54.264) Mm-hmm. Jon (36:07.564) Yeah. Allan Ritchie (36:14.204) you know what we're gonna wait till this end and it did it was it was actually pretty cool that they did it by location and just knowing the coverage that they were hitting maybe it's just me being way too optimistic and a fanboy of apple but they really seem to have that down Jon (36:23.906) Yeah. Jon (36:30.814) Yeah, no, that's why I kind of always think, yeah, there's probably more heuristics at play for these kinds of things than we really understand or give credit for. And yeah, it's all kind of meant to just make things work. In theory, everything is supposed to be easier as a developer because of it. Allan Ritchie (36:46.18) True. And honestly, BG Tasks did solve kind of a gap. So you can do these data syncs now. Jon (36:53.302) So are these like the same idea? Like these are kind of periodic more than anything. So you can say, I wanna do this thing when I have, you know, network and I have power and that's it. They kind of decide and they decide the, are these like one off? Like, can you schedule another one right after because you wanna like keep sinking in the background every once in a while? Allan Ritchie (37:05.524) And that's it. That's their only filters. Allan Ritchie (37:18.08) You said the bad word again. There's no scheduling. Heh heh. Jon (37:19.71) Yeah, I know. Well, can you can you request a future occurrence? Allan Ritchie (37:25.512) So you can request a one-off, right? Both platforms, so both the worker runtime on Android and iOS have that one-off request, right? So you can say, just run this whenever. They also have scope of, if you're in the app, just in case you're about to go to the background, this is a task that we really want to finish. So you can say it's... Jon (37:27.363) Mm-hmm. Jon (37:34.652) Mm-hmm. Jon (37:45.462) Yeah, there's like a like it's like a continuation almost right or like a I know which one you mean Allan Ritchie (37:48.632) Yeah, I'm trying to think of the words. See, this is why I write libraries, because I don't remember what the actual things are I use underneath the hood. I gotta go look. But they had this thing, so if you were doing any async tasks, you could say, look, just give me like 20 more seconds to finish it and then trim, right? Which is also a good option if you're doing small images, but still use NSURLSession, you don't have to worry. So. Jon (37:57.417) yet. Jon (38:05.794) Yep. Allan Ritchie (38:19.912) I totally lost my train of thought on this, but really it's, you got that 30 seconds now on BG tasks. You don't have to worry. You just play by the rules and do your thing. And if it falls out of scope, you had 30 seconds, man. Jon (38:34.23) Does Shiny, so Shiny uses BG tasks, is that true? Is that true? And does Shiny, it kind of sounded like when we were talking about the work manager stuff, like you don't use that in Shiny on Android? Okay, you do. Allan Ritchie (38:38.241) Yep. Allan Ritchie (38:47.008) Yeah, I do. Yep. I use the worker runtime. That's that's the way to do it on Android. Jon (38:51.922) So I'm curious then, like when I, back in the day, remember looking at some of this, because I think, I don't know if you hadn't made the shiny stuff already or not, I can't recall, but I remember looking at this problem space at one time a while back. And I think it was when the work runtimes, you know, stuff first came out for Android and iOS had the tasks at some point. Allan Ritchie (39:09.581) Yep. Jon (39:12.766) And I thought, you know, I started kind of building this, um, you know, kind of what you were, you've done now with shiny. And one of the challenging things was sharing state between those, those jobs and your app, like what, what do you do there in shiny? Cause I know what I was going to try and do, but like, you're not, it is well, two questions, like one. Allan Ritchie (39:24.056) Ah. Jon (39:33.522) On Android, I think those probably still run in the one kind of process of your app. So in theory, if your app was still running, but that's not a safe way to try and share state between, you know, an activity that might have been killed. Um, but on iOS, is it, is it the same process as I, as the UI? Allan Ritchie (39:52.388) Uh, no, because it doesn't matter. It's not really intent. Like if your app's running. So shiny has the concept of like a foreground job. So I just spin off a thread and keep running. So I'm kind of emulating the worker. Um, but in terms of like that BG task firing, it's not really, it's not really meant to be UI, um, responsive. Like it, this is, this is a chunk of work you're going to do. Jon (39:53.854) Or it may be, maybe, or maybe not. And it kind of doesn't matter, I guess. Jon (40:00.376) Yeah. Jon (40:04.619) Mm-hmm. Jon (40:16.212) Right. Allan Ritchie (40:20.072) Whatever that case is in the background if you want to notify now, this is cool thing if you want to notify your app There's obviously messaging frameworks like there's you guys still have messaging center week messaging. That's in community Jon (40:32.366) Uh, there is something in yeah, there is something in Maui. We've kind of, I think even changed that up lately, but yeah. Allan Ritchie (40:37.5) Yeah, I don't use messages. I don't like them, but like. Jon (40:40.83) So yeah, you could do it that way, I guess, but that would depend on both ends being up and running for it to have an effect. Allan Ritchie (40:48.444) Exactly. But most of the time these jobs, when they're really truly running, they're not running within scope of your UI. So it's not really like Shiny doesn't have the concept of progress. It's like do whatever you're going to do. If you need to do something with the UI, because you think that that's going to happen, then you know. Jon (40:56.128) Right. Mm-hmm. Jon (41:05.81) send a notification, like do a local notification or something if you wanted. Allan Ritchie (41:08.416) You could, and that's another reason why local notifications is part of the OSS offering, because you often do those. But the key is that who knows what you're going to do in your job. So if you want to notify the UI, I don't have anything out of the box. But events are so easy to write, right? Like or a weak referenced message or whatever. Or an RX. RX subject. Future topic coming. Future topic. Jon (41:24.338) Mm-hmm. Yeah. Jon (41:36.492) So for the background periodic jobs, when I request that a periodic job be eventually executed, what are my options for passing state into there? Let's say I'm going to sync data. I want to know. I want to tell that job that, you know, here's some identifier or something to use or whatever. Like, what do we do? Allan Ritchie (42:04.204) You can pass state, Chinese lets you pass state, the worker manager lets you pass state, BG tasks doesn't, you have to store that somewhere and deal with it yourself. Just because it's like, again, if you're doing a job, most of the time, at least in the use cases I use it for, it's like, when was the last time you ran? So if it's a data sync, I'm gonna say, give me all the data from this Delta date, right? So last time you ran. Jon (42:12.096) Okay. Jon (42:27.838) Yeah, yeah. So you'll like open up and like, I like something, I haven't done this in, in pool math yet, um, maybe I should, that'd be a fun experiment to actually use shiny myself a bit, but I, I do, uh, this, this might be a good example though. I'll, I'll try this one. Uh, but what, like how I deal with my, my data in pool math is because like you can, you can have the app running on multiple devices, I can like, you know, create logs and stuff for my pool. Allan Ritchie (42:38.904) He doesn't use it. He writes his own stuff. It's frustrating. He has to write everything from scratch. Hehehehe Jon (42:56.506) on one app and that gets sent up to the database. I don't do like super rich offline data. I don't do offline data at this point. I just kind of say like, if you're gonna create a record or change a record, it has to go up to the server and then it comes back down and I update the local database based on it. But the way I do that is basically saying, okay, like here's the newest record for this type in my local database. Like... go get me anything, like you're saying, the delta between, you know, after that date, and what's happened after that date, go bring those down. So I would maybe wanna do that in the background, but that's like, I have access to connect to that database when my job runs at that point, right? Like it's just, it's my app, it's my code. So I can go say, hey, let's look at the state of things. So like worst case, I could manage my own state passing even on iOS by... writing, serializing something to some place, whether it's a JSON file or a database or whatever. Yeah. Allan Ritchie (43:55.884) Yeah, settings, preferences, there's so many ways to do it. And like I said, in OSS and Shiny, there's so many ways to maintain state and it does it for you. So jobs get bound. Like if you have like a notify property change, I remember all those for you, I put it into preferences. So there's so many ways to remember that state of where you were. Obviously you're not memorizing huge chunks of data, right? Like you still need a database for that. Jon (44:08.567) Mm-hmm. Jon (44:18.562) Right. Allan Ritchie (44:22.424) But there's so many ways to manage state. That's why you don't necessarily need to build it in. And data syncs are notoriously hard, right? That's why I don't have one, because there's no one way that's correct. Like what happens if somebody else updated the record? Who wins? Jon (44:29.174) Yes. Jon (44:38.558) Yeah. And that's, yeah, that exactly. That's why I haven't ever done like the full offline and the app yet. I'm like, you know what? Like, yes, no, thank you. Like that's just, if you want to make a change, you have to have network connectivity and that's the way to do it. So. Allan Ritchie (44:45.528) conflict resolution is hard. Allan Ritchie (44:56.028) Or you have to manage some sort of queue that says this failed because, which I have done, but it's hard. So don't just think you're going to get jobs, periodic jobs for data sync. And it's going to be great. It's not status data synchronization. If it's just push and pull, you're great. If there's other people involved in touch and that data is in motion, it's anything but great. Have fun. Jon (45:00.351) Yeah. Jon (45:16.798) Yeah. There's, yeah, there's lots of products that have, you know, popped up or, you know, failed or whatever because of that problem being very difficult to solve. Um, we, we touched on GPS a little bit, like there, there are, it occurs to me that there's, you know, some cases and scenarios here that you might like, it's not good enough to ask for a periodic task to happen. And I, I need to know. Allan Ritchie (45:27.392) Great. Jon (45:45.454) Android Fine foreground services. What do we do on iOS for that? Allan Ritchie (45:51.36) So iOS is pretty good in this regard, right? This is the one, they're consistent, right? You either, it's either a yes or it's a no. There's no gray area. They don't really change the way it works. It's just, this is the way it works. So GPS is kind of cool because when you say, look, we want, they actually have a flag that says we're like background, background. I forget what the actual flag is again. That's why I write libraries, but they actually have a boolean that says, you want this to run in the background. It'll ask the user for permission. They get kind of funky with that. Now they say, yes, I'll give it well in the app. It'll keep running in the background. And then later it'll say, this is still running. Do you want to switch it to always, or do you want to turn it off? Now they change that like iOS 13. It was like, really? So you're going to shut me down now. It's frustrating, but it just works. Right. Jon (46:36.778) Yeah. Allan Ritchie (46:41.436) So other than them kind of changing the game a little bit on us, the overall architecture of saying I want to work in the background just works and it keeps the app hot. So that's one of the things that users want. If generally if you're writing a GPS app like a map or I don't know, fleet tracking, that's a great one. Right. They want to know every, you know, Jon (47:01.294) Mm-hmm. Allan Ritchie (47:04.192) 30 seconds or every minute. Where is my driver? How fast are they going? You know, where am I going? Right. Maybe you want to track distance. Who knows, right? There's so many reasons for what, for why you might want to do it, but you've got to keep it hot. So iOS, it just stays hot, which is great. Um, now leading the witness here, I think I know where you're going with this question. Jon (47:24.73) Yeah, I mean, like, okay, let's, let's say I've got my app running then, and I want to put data back and forth like that. Like, does that finally give me the opportunity to do something like open a web, a web socket and keep that running and communicate back and forth. Allan Ritchie (47:39.472) Yes, and there is a lot of people that you've seen in Maui. Everybody asks for SignalR, right? They're all the web devs come over. They wanna do SignalR. Yes, you can do it. Should you? It's one of those things you really wanna know. Should you do it? Probably not. I mean, I can. Jon (47:46.731) Yeah. Allan Ritchie (48:01.984) The fleet app maybe could have had signal R because it's sending data constantly and resolving to pings. Um, but the app was always pretty much on the screen anyways, so it's a bit different. Um, but for your general users, just don't do it. And the reason is, is that not only do you have the GPS running hot processing cycles, which is going to, it's not as bad on the battery as people think, as long as you're not doing a lot of processing. Jon (48:04.447) Yeah. Jon (48:12.919) Yeah. Jon (48:21.404) Mm-hmm. Allan Ritchie (48:27.64) but enter signal R and now you've got the cell radio hot all the time that is doing processing all the time. You just going to murder your, your user's battery. They're going to hate you. They're going to cook. They're going to spew venom at you. Jon (48:32.375) Yeah. Jon (48:40.342) What? And this is, I think, another case of where, like, maybe we don't understand all of the effort that has probably gone into Apple's, like, implementations of these networking stacks and stuff, right? To be super optimized for dealing with. you know, cellular connectivity and being easy on the battery and kind of back to talking about push notifications where it's like, yeah, they don't want everybody opening up and keeping a socket open because they've probably done a lot of work to optimize, you know, the cases that they think there should always be a, you know, connection open, right? Allan Ritchie (49:03.491) Right. Allan Ritchie (49:15.176) Right. And so just because you can doesn't mean you should. Like I said, I've got an example actually that I'm going to Jon (49:19.822) Mm-hmm. Allan Ritchie (49:23.344) finish at some point. I've got like this GPS sync that keeps jobs running every 30 seconds. GPS is hot. So just blowing up everything. But there are apps, there are business cases where you need this. I just question SignalR unless you've got a power source, right? Like a truck, like you mentioned, you're plugging it into power. Then SignalR might matter. But for the most part, yes, I'm going to release the sample, but there's going to be a big caveat warning. Just don't. Jon (49:40.952) Yeah. Jon (49:51.038) Yeah, so it's kind of like if unless you if you don't really know exactly why and have a really good explanation of you know Why you want to do this? The answer is you shouldn't Allan Ritchie (50:04.576) Right. And I don't think people are really prepared for how often like GPS, you've got to set a throttle on it. Like iOS just keeps pumping the data. They used to have these filters, but now they're just like, too bad you requested full time. Here it comes. Right. So you have to actually process and go, have they moved 50 meters? Have they has it been 10 minutes since the last ping? You have to do all that on your own. Their filters just don't work anymore. They've deprecated them. Jon (50:12.301) Yep. Jon (50:22.19) Mm-hmm. Allan Ritchie (50:32.284) Apple's weird about deprecation. They just kind of they keep it there. It just doesn't work But it doesn't work it doesn't do anything So they've done that with GPS now So if you don't throttle it and you got that signal are open man Is it gonna push a lot of data to your service like just? You'll know that every step they take basically Jon (50:36.566) Yeah, the API is there kind of forever. Yeah. Jon (50:51.435) Yeah. Jon (50:56.682) Yeah, and that and like, you know, sell cellular data plans and stuff certainly aren't where they were like a decade ago or anything, but at the same time, it's like, I don't know if everyone, again, if it's like a business case and you know, the phone is, you know, paid for by the fleet management company, then okay, fine, but like, you know, other than that, it's like, you don't also wanna do that to just all of your users and assume that, you know, their data is free basically to use as you wish. Allan Ritchie (51:22.556) Right. And you know how hot that phone can get doing all that processing too. Like you notice it. So I run this GPS with the signal our test. Again, it's a test. Don't, don't copy it. Just don't do it. But it runs hot. It runs hot. And I do have processing again in shiny. I have that. So don't tell me unless it's been 50 meters or 30 seconds, but I have to process that. So just don't do it. Jon (51:25.524) Yeah. Jon (51:33.758) Yeah. Just because you can. Yeah. Jon (51:48.653) Yeah. Allan Ritchie (51:51.258) Show some love to users too. Jon (51:53.635) So have we missed anything on background tasks and jobs and code execution? Allan Ritchie (51:59.7) And then we talked about GPS. We talked about pretty much the four areas. There are other ones like VPN, which I don't cover. That's like a whole business case on its own. For the main stuff like sending and receiving images or files, we've got that covered. Periodic jobs, I almost said scheduled again. We got that covered. Cross platform. Jon (52:05.71) Mm-hmm. Jon (52:23.999) We didn't talk about windows yet. Allan Ritchie (52:26.924) Oh, you're not allowed to go there. If I'm not allowed to bash windows, then you're not allowed to pull it. Ha ha ha. Jon (52:27.586) Hahaha Jon (52:31.286) No, no. I mean, Windows, obviously, like if you're in a desktop environment, you know, the game is different for sure. Cause your one, your app is probably still running, but, and I don't actually know if in WinUI, so in UWP, there were some APIs around like periodic or background jobs of some kind. I... Allan Ritchie (52:36.068) It doesn't make sense. Right. Allan Ritchie (52:50.304) Yep, they still have them. It's called WinRT anyways, right? That's the confusion. Like WinRT is still the driver of UWP and it's still a driver on WinUI. Like it's there. Those APIs actually haven't changed. Jon (52:59.754) Yeah. And I don't know that they, you know, if they're fully implemented on WinUI or not, like maybe they still work the same. Hopefully this, they still work the same. And I think that the idea there was always like not for the, the desktop scenario as much as, you know, a tablet kind of form factor or like, you know, lightweight laptop kind of thing where Allan Ritchie (53:10.212) as far as I know. Allan Ritchie (53:21.677) Right. Jon (53:22.25) You might want to consider your user's environment more like a mobile app, but that seems to be less and less important for those types of scenarios. Yeah. Allan Ritchie (53:29.852) Yeah, the tough remember the Toughbook era, right? Where they had those indestructible laptops and stuff. Now I am I'm not a Windows lover personally. I just believe it's web Android and iOS. Those are what exists in my world. But I will say this win RT and I'm not going to talk much about win UI, but win RT. minus the Bluetooth API which is horrendous but the GPS one is fantastic. They really some of the WinRT APIs that the Windows team wrote is just clean. It's exactly what I think GPS should be. Whereas the Android is like some hodgepodge of junk that they've assembled over the years. The Windows RT stuff is solid. I don't support it because my business, my customers don't need it. So I don't do it in Shiny. Jon (53:53.772) Mm-hmm. Jon (54:05.539) Yeah. Jon (54:15.223) Mm-hmm. Allan Ritchie (54:16.908) That's not to say I won't. I mean, Dan Siegel, who's a good friend of mine, is a good friend of ours. He does prism. He's asked me for some Windows love. So of course I'll do it for you, Dan. But for the most part, I don't get like you said, it doesn't those kind of APIs are the background ones. You just don't need them on like a Windows. I mean, you could run a Windows service or, you know, generally you just minimize your app if it's on desktop and it could keep running away. Anyways, so. Jon (54:33.931) Yeah. Jon (54:43.582) Right. Yeah. And like GPS stuff too, like a windows device usually isn't one that's, you know, in, in motion as much as a phone. Right. So it's like. Allan Ritchie (54:52.084) No, that's it. I think the surface had a GPS in it, but it was a weird one. Jon (54:56.426) Yeah, I think a lot of the devices do now, but it's yeah, again, it's like, those are more special use cases. And at the end of the day to write, you know, if you're targeting windows to like write a little bit of code, to get the location updating constantly, like go do the platform code. Allan Ritchie (55:12.24) Exactly. Now we didn't cover this and I don't plan on covering this today but the other background scenarios and this is kind of what I think will eliminate Windows from the motion kind of backgrounding scenario is the CarPlay and the Android Auto. So John and I have toyed around with that a little bit. It's kind of cool. You can pretty much do whatever the heck you want there. So that'll probably be something we'll talk about in the future. We haven't played around with it enough yet. Jon (55:24.671) Mmm. Mm-hmm. Jon (55:34.838) Yeah, yeah, that would make a good episode. Right, yeah, we'd be more learning as we're talking about it, but it is an interesting area. Allan Ritchie (55:42.112) And to be fair, you only got you only got car play this year in your car, right? Where's the last year? Jon (55:46.582) I don't have CarPlay. There's no CarPlay. Allan Ritchie (55:49.797) You don't have it? I thought they gave it to you. Jon (55:52.05) No, no, no. So Tesla, they don't want you using those things. And actually, neither does GM, I think, now, right? They're going to drop it from their cars. Allan Ritchie (56:00.704) Okay, so keep using background services in your phone. I thought for sure you got CardPlay. Oh, who? Jon (56:04.342) Yeah, no, they have there's Apple Music and Apple podcasts now. Like there's the apps that are built specifically for the OS, right? So. Allan Ritchie (56:11.416) Okay, so you can't even help me test CarPlay, that's why. Okay. Jon (56:15.57) No, I can't. I mean there's solutions. Lots of people have like little carplay external screens and stuff that are hooked up if they really like it. Yeah. Allan Ritchie (56:22.376) Oh yeah, I've seen those on Amazon now. Anyhow, that's a new backgrounding scenario that we haven't explored yet, but I think that one's pretty cool. So it's coming. Jon (56:27.967) Oh yeah. Yeah. All right. Well, I think the obvious, I think we'll get episodes where, you know, the plugin package and product picks are not from one of us, but I mean, of course we have to pick shiny, you know, shiny jobs and shiny, uh, net HTTP transfer stuff. Um, yeah, naming this, I mean, it's descriptive, tells you what it's going to do. I think. Allan Ritchie (56:47.672) That's the transfers. Naming is hard. Hehehe Jon (56:54.546) So yeah, go check those out. We'll link to them, of course. And like always, if you like the show, please subscribe. Please leave us a review. Nice review on Apple podcasts generally is a really great thing for podcasts. So if you're looking to help out, support us, that's where you want to go. I can do that from my car now. So that's great. If you have ideas for a topic, another show episode, you have questions, you wanna recommend a plugin package or product that we haven't talked about, let us know, visit our website, drop us a line on SpeakPipe, on all of the social media things, using your phone that is now posting those in the background with background transfers, or send us an email, showetgonmobile.io, but I think that'll do it for this episode. Thanks, Alan, we'll talk to you later. See y'all. Allan Ritchie (57:44.548) Thanks, John.