Jon (00:19.726)
You're listening to Gone Mobile, your input and output for all things.NET, mobile and Maui.

Jon (00:37.29)
Welcome back to Gone Mobile. It's a new year, Alan, and I think we should start out the new year by tackling some of the toughest topics known to mobile developers. What do you think?

Allan Ritchie (00:50.591)
I'm not sure if push is the most... oh did I announce it too soon? But I'm not sure if this is the most complicated topic or...

Jon (00:53.758)
Oh, you gave a- yeah. Spoiler alert.

I said one of, one of the most. It's in there, right?

Allan Ritchie (01:02.211)
Eh, fair. It's certainly got the most boilerplate for sure. Lots of stuff you have to do from both the server and the client side.

Jon (01:09.126)
Another spoiler alert for everyone listening. Um, we're talking about the topics that seem to be the things that you try to tackle and shiny as well. Why, why is it that you, you know, we gravitate towards tackling these really hard problems? Is it because they're hard problems?

Allan Ritchie (01:26.031)
Uh, maybe. I think technically we live in two different worlds, right? Like I have to deal with all the stuff outside of UI. Um, whereas obviously you're dealing with the UI. Well, I guess essentials tends to tackle a lot of these things, but

Jon (01:40.618)
Essentials does it. And I've had like a weird, um, love hate relationship with some of these things too over the years. Like I made a library, I don't know if you ever stumbled across it called push sharp. Uh, and actually, yeah, no, it was, it did, you know, it, it quote unquote did super well. And I say that because it was like not, it was not a great library in terms of the implementation of it in many ways. But when, when Apple first, you know, we'll talk about the history of these things a little bit when Apple first made

Allan Ritchie (01:51.884)
Yep, everybody's used it.

Jon (02:08.822)
this idea of notifications, like they had a protocol that you had to talk to them with that was just, it was a binary protocol. It was horrible. And it, yeah, it was the worst thing ever. And somehow that, like, that was a glutton for punishment and I had to make a library for it and I, I really wanted just to make it work and I don't know why I gravitate towards these harder things, but I feel like you're in the same boat with shiny a lot, um, maybe not for the same reasons, but.

Allan Ritchie (02:34.091)
Yep. Your library wasn't the only library at the time though that I remember doing it for both, right? For the Android side, the Apple side. Like it was the only one. I think you even did Windows which I was like...

Jon (02:42.998)
Yeah.

Jon (02:48.118)
Well, and fun fact, when I made that, I wasn't part of Microsoft at the time. I probably was part of, no, I wasn't part of Xamarin technically either. It was before those days too. And I made it and at some point I remember somebody from a Microsoft Azure team got in touch with me too. And they're like, how are you doing this? Like, can we learn something from you? Cause talking to Apple is really hard and there's all these challenges in how you do it. And it was kind of like.

Yeah, this is what I do, but there's not really an easy answer to it. And that's kind of unfortunate, but, and it's evolved since then, right? We can talk about that a little bit more too. Um,

Allan Ritchie (03:23.491)
Yeah, Apple's evolved to a lot. Like that binary protocol, I think they finally turned that off, what, just a year ago or something.

Jon (03:25.911)
Yeah.

Jon (03:30.766)
Yeah, yeah. So it's all like HTTP based and we'll get into like talking to the different servers and stuff. But I kind of wanted to dig a little bit in first into the history of this to an extent. Uh, I don't know what your first interaction was with push notifications, but I, uh, way back in the day before mono touch was really taking off yet, I think maybe it was like announced or in its infancy. Um, but Apple, like they kind of invented the space, right? And at first they didn't have push notifications on their platform. There was no concept of that.

Uh, they ha well, they had some kind of concept of it with email and they made their own email system, their iCloud email work with like the whole Blackberry idea of pushing data to you when it arrived. Now I didn't use iCloud email when I got my first iPhone and I was really jealous cause I use Gmail and I really wanted that like instant information kind of a la Blackberry world.

And so I actually set out to make an app in objective C even. This is my first iPhone app at the time that did the whole push notification thing for Google Gmail accounts. And so I made this whole server side setup that, you know, you'd, I would log into your account that you gave me your credentials for, which is, oh my goodness. Uh, I didn't do anything nefarious. I swear.

And I would use like the IMAP idle extension and I would listen for changes and I would push those up to Apple and make that come down through the app and everything. But I think that was iOS, was it three or four that they introduced notifications?

Allan Ritchie (05:01.42)
It would have been probably three if I remember correctly because the first time I started doing dev was on an iPhone 3 iPhone 3s was it the 3s?

Jon (05:07.646)
Yeah. Well, and they didn't, yeah, 3G. Yeah. And they didn't have like an App Store at first either on iPhone, right? So it wasn't, that was still fairly, you know, new I think even for the iOS 3. Like that came out very, very shortly after they announced the 2G or whatever the first one was.

Allan Ritchie (05:12.655)
3G, there we go, that's the one I was looking for.

Allan Ritchie (05:29.047)
back in history. I thought for sure they had the App Store with it but you could be right.

Jon (05:30.206)
Oh yeah. I don't think it was right off the bat. I think it was like, they were like, you can write these web apps and pin them to the home screen. And then the app store came out, you know, shortly after that. Anyway, we're getting into the weeds with it a little bit. Yeah.

Allan Ritchie (05:40.443)
Okay, yeah and without the App Store, without the App Store there is definitely no push notification. So somewhere in there I know I remember doing it on the 3G and I also did it with Objective-C but I was when 3G came out it wasn't long after that Miguel started putting out Mono Touch. So I was experimenting that right from the beginning because we were doing a lot of testing for the company I worked for and it was fun. It was very

Jon (05:58.498)
Yeah.

Jon (06:03.883)
Yeah.

Jon (06:08.11)
Thanks for watching!

Allan Ritchie (06:09.091)
feature deficient at the time.

Jon (06:10.814)
Yeah. Well, and one of the things was, you know, the lack of push notifications, right? And so if anyone's not familiar with the concept, like when you would make an app, you know, you might want your app to learn about things that are happening outside of the context of the phone of the app and maybe from a server, some other service, et cetera. And so Apple kind of decided, Hey, you know, we don't really want every app.

Well, first of all, you couldn't run your app in the background at all at first. Like there's just no concept of that. So even if I wanted to, I think maybe they made exceptions for VoIP apps or the certain categories, like they kind of still do at the time. I don't know if that was, yeah, maybe it was just GPS. So first of all, like you, you kind of couldn't do it. And then even if you could, Apple's kind of like, well, we don't want every app.

Allan Ritchie (06:47.043)
GPS at first. Let's get location.

Jon (06:57.258)
maintaining a socket connection to some server on their own. And so they obviously at some point the idea was, hey, let's make one in the OS and we'll connect to our own servers and we'll keep that one connection open and optimize it and everything. And then we'll have the different apps talk to us and we will relay those notifications on to the app itself. Kind of an ingenious idea, given the constraints of hardware and bandwidth at the time too, I think.

But it is an interesting situation to then start to tap into that ecosystem, right? And of course like Android they came out with something not too far after Apple cloud to device messaging right C2dm Which became Google Cloud messaging GCM, which is kind of still a thing I think but they wrap it on Firebase now Yeah So there's been an evolution of it all right

Allan Ritchie (07:43.111)
No, they've definitely, you can't use it anymore. You have to be on Firebase now. So, but yeah, they've, Android kept changing the game on us. It was fun.

Jon (07:55.55)
Yeah, yeah, I remember that. And there was some quirky things too. Like if you had your app identifier, I think for a while in Sanran, we had some people who had, you could create your package ID with like an uppercase character. We didn't like not allow that, but there was some weird thing where like C2DM wouldn't work properly if you did that. And it was, yeah, it was a bit of a mess. So, Oh, maybe you never ran into it. Yeah. So push notifications are obviously.

Allan Ritchie (08:17.087)
I don't remember, thankfully. So it didn't scare me. Never scared me.

Jon (08:25.01)
not that easy. But you know, like, why are they so hard?

Allan Ritchie (08:30.283)
I will honestly go just going back to that comment I just made about they keep changing the game ever so slightly. So when Apple started my challenges were like there was no multilingual. It was basically this small little I think they limited to what like 140 bytes. It was limited. It was very limited. So you had to work on trimming your message. You know you had to stay connected. They didn't like if you kind of do the traditional web like request response. You connect.

Jon (08:47.614)
Yeah.

Allan Ritchie (08:59.447)
send data disconnect. They hated that, right? They'd start throttling you. So certainly the server side started off complex for Apple. But as we look nowadays, it's you're right. It's such a it's still kind of complicated because there's still so much boilerplate. You know, you have to get a key from Apple. Thank God they've made that easier too. Like it's not you still check it by an app, but you don't have to create your certificate for dev your certificate for.

Jon (09:02.412)
Yeah.

Jon (09:22.23)
Yeah.

Allan Ritchie (09:28.435)
App Store and a certificate for push. Like you have just one key now that does push for all apps. You just have to see.

Jon (09:34.038)
But you still have to have like the entitlement in your app and everything. Right. So I guess part of this is, you know, the classic, like if you want to target every single platform with your app, like you've got to learn all the nuances of each individual platform and how it works differently and, and to an extent, you know, I think there's, there's been multiple attempts. I mean, push sharp was my attempt at. Abstracting that concept away a little bit in terms of the, of talking server to server, right. But like, yeah, for the client app part of it.

Allan Ritchie (09:37.944)
Well...

Allan Ritchie (09:57.663)
Oh, we haven't even talked about server.

Jon (10:03.264)
It's all shades of different between platforms. And so, I don't know, maybe we want to talk.

Allan Ritchie (10:06.219)
Well, we're just at the, we're just at the portals, right? We're not even at the apps. Like we're talking about just declaring, right? So we've covered Apple, right? So we've got these different certificates. We've got the provisioning profile and entitlements. I'm pretty sure everybody at this point has probably dealt with Apple entitlements. So it's not really unexpected. I mean, you still have to know when you could be in developer versus production, right? Like...

Jon (10:12.414)
Right, just the setup configuration.

Jon (10:27.966)
Not tooth foreign. Yeah.

Jon (10:34.738)
Right. Yeah. And so that was distinguished, you know, for like, they, they still distinguish that difference for push notifications. Is that true? Um, so you have like ad hoc and development or sorry, development is like its own thing. And then they're like, how did those tie back to the different provisioning profile types? Right. Like, cause can you send to, can you send production, push notifications on like an ad hoc provisioning profile? I think you can.

Allan Ritchie (10:36.281)
Um...

Allan Ritchie (10:42.987)
Yep.

Allan Ritchie (11:03.035)
I don't think so anymore. If I remember correctly, that used to start, stop, or it's used to fail during builds. Like it was like, Oh, you're trying to use developer, but you're on a production, like an app store center build. And they would be like, no. And if they don't block it on builds anymore, I'm pretty sure they still block it on the, the release to app store. When you, when you go to test flight.

Jon (11:12.924)
Okay.

Jon (11:23.554)
So what is that mapping then? Like when do I use production? What are the two types, I guess? Like there's two APNs types, they call them, right? Apple push notification service.

Allan Ritchie (11:32.075)
Yep, so they have developer and they have production. Basically, if you're debugging, you're using developer. If you're releasing, you're using production. They don't. I mean, I really wish they just do it by the provisioning profile that we're using or the release setup and change it for us. But I get.

Jon (11:34.976)
Okay.

Jon (11:49.846)
Yeah, because it feels kind of weird to try and like do the cognitive thing of mapping. Okay, which one am I using?

Allan Ritchie (11:55.719)
Right. But they don't. I guess because they want you to.

Jon (11:57.694)
And you have to specify that in the entitlement too, right? Like which one you're using when you build the app, is that still the case? Okay.

Allan Ritchie (12:03.431)
Yes, that and that's what we're talking about. Really. It's those keys that go into the entitlements, but it's I feel like it's something that they should remove. But maybe it's a case of legacy that's just been brought along and it's you having to knowingly do it. The cases. It's not always obvious you have, you know, your build starts failing when you switch to an ad hoc profile and you're like, why you have to go through the logs and go, oh, you don't like that entitlement. Thank you. That's great.

Jon (12:07.063)
Right.

Jon (12:19.437)
Yeah.

Jon (12:29.458)
Okay. So I have my, my provisioning profiles. I have my entitlement set up. Like, you know, what's the next thing for Apple that I do in my app?

Allan Ritchie (12:38.623)
Um, well, that's that there's a whole bunch of stuff in there, right? There's there's some hooks you got to get into your app delegate. Um, obviously you got to make sure your app IDs match up from, from the client side, actually on, on iOS, it's pretty easy once you've got those entitlements, right? Um, how you handle it's a big different story. We won't go into that just yet. Um, but for the most part, the boilerplate is what three or four methods you got to get.

Jon (13:02.954)
Yeah. So you call like register for, for receiving notifications, right? And then you can tell it what types of notifications, right? Cause there's different types of notifications, right? Ooh, there's so many different rabbit holes to hit.

Allan Ritchie (13:07.597)
Yep.

Allan Ritchie (13:12.523)
You're going down that rabbit hole, aren't you? There's a... and they keep changing that one too. I don't even think I know all of them anymore, but there is a ton. They've got like GPS requests. You could ping and ask for a GPS coordinates. I'm like, oh man, we are going down some wild rabbit holes there.

Jon (13:28.342)
And then, and then once you get that, like when you register for notifications, if that works, you get a token back. Right. And that's kind of the unique identifier or unique token for sending notifications to that device, that app instance on that device, I guess. Right.

Allan Ritchie (13:34.765)
Yep.

Allan Ritchie (13:44.047)
Correct. And the funny part about it is again, Apple does their own thing. So it comes in as this kind of byte array type thing that we have to encode special to send it back to our server. Right. So because we usually work with that as strings.

Jon (13:49.984)
Right.

Jon (13:55.134)
Right. And so that's the key when you talk to Apple server and say, deliver this message for me, and you say, deliver it to this token. Right. And so like.

Allan Ritchie (14:04.107)
Yep, yep. And then you also have to line it up with your key and the app, the bundle IDs and all that stuff. There's just so much information you have to give. It's good though, because you could really spam the spam your users if you do it wrong.

Jon (14:09.834)
Right.

Jon (14:17.31)
Yeah, no, definitely. And you want to make sure that, you know, you've got like, then it's up to you to kind of figure out how do I relate that back to, you know, a user account or something, right? So you have to start developing that relationship then, and presumably store that token on your own server somewhere so that you know how to look up, okay, when this, whatever happens, I can get this token and I know that, you know, I want to send a message to this user and this user has this set of tokens associated with it.

Allan Ritchie (14:45.707)
Yep. Yeah. And that's another thing. Apple doesn't do tagging of a user. So we'll get into what that is. That's more on the Firebase side, but.

Jon (14:46.872)
Um.

Jon (14:55.286)
Yeah, and so with Apple, when you have notifications, like when I go to then send one, and we don't have to get into the details of server to server to see it, but when I do send one, like what's the life cycle that happens on iOS at that point? Like the notification goes to the device, and then what, do they still show the pop-up for you? Like, do you have to specify that in the notification payload?

Allan Ritchie (15:22.543)
Um, you said the Apple, no Apple side, you don't really get a say. Um, you can see if it's priority or not, which overrides a whole bunch of stuff. Um, if you're allowed to do that, right. So, um, that's a new permission set that you have to do with Apple and say, like. This, this app can, can take the real time, um, notifications, like a permission. Most of the time people turn that off. Like if they've got that new mode where you can say, I want complete silence, like don't bug me.

Jon (15:51.339)
Right.

Allan Ritchie (15:51.479)
but you still want certain apps to be able to override it. So you can set that up. But the general process when you send it to Apple is they'll stick it in a queue, right? Because my device may not have connectivity, maybe I've got it turned off, but what it'll do is, or if my battery's low, that's another big one. If my battery's low, it kind of waits until I wake up the phone and then pulls that queue in. And then Apple, I think, hangs onto those push notifications. I think 48 hours is the max now.

But again, that's kind of the game changing on us all the time.

Jon (16:24.522)
Yeah. And like that's a whole other thing too, right? You don't really have control ultimately of when those get delivered to the device. Like that you're kind of at the mercy of Apple just to do the thing as best as they can do.

Allan Ritchie (16:35.979)
Yep. And the fun part is too, is that Apple really kind of dictates how so many things on top of that, right? Like if you're doing we haven't gotten into the silent background, but that was when you were mentioning to me, if you want to push notification to kind of kick your app alive. So do something in the background without, I don't want to say without your user knowing, but certainly it's like go get data from the server.

Jon (16:47.733)
Right.

Jon (16:57.218)
Like not showing them a banner that says like, there's a thing, right? Like that's the standard, I think, notification, right? Where you send a notification, there's like a, you get to choose in the app, you know, as a user, how it displays, I think mostly, but you can have something pop up, you click the notification and opens your app. And at that point, your app's active anyway. And it can kind of gets that call in the app delegate that says, Hey, we were open from a notification or you can discern that anyway yourself, right. And see the data that came along with it.

Allan Ritchie (17:00.896)
Right.

Allan Ritchie (17:26.819)
But if you want to just to have silent data, like let's say, like you've got a sync system that says, hey user, you've got new data. I want you to pull it into your local database. So they've got this content available thing, right? So it's good for syncing your app up before the user opens their phone.

Jon (17:33.931)
Mm-hmm.

Jon (17:43.562)
Right, so it's all done and they open it up and everything's new and shiny there.

Allan Ritchie (17:47.827)
Right. Yeah. And they do that so that you can have like beyond the chat message. Right. So we think of push notifications. It's like a poor man's signal. It just minus the, you know, there's this data involved here. So content available is this thing Apple invented to say like, hey, we just want this, there's content you need to wake up the app as well. So it's not just the notification that the OS deals with now. It's wake the app up, give it a few seconds to do whatever the heck it's

Jon (17:57.037)
Yeah.

Allan Ritchie (18:17.111)
Now some people go crazy with this stuff. This is one I see continuously in Chinese people complaining, well, I'm sending these silent notifications and they stop getting them, right? So Apple likes it if you only do that a few times an hour. So on average, I've seen my testing, I usually get four, maybe five if I'm lucky, but if you're sending a lot of these silent notifications, maybe to keep your Apple live, Apple starts throttling you, right? Yeah.

Jon (18:41.11)
Yeah, they're like, we know what you're trying to do. Don't do that.

Allan Ritchie (18:44.047)
Yeah, don't murder the user's battery. They'll let you do notifications as much as you want mostly, right? Like you can just spam them. But if you're trying to keep that app alive with kind of silent notifications, they'll start throttling you, which means they just won't send the message. Like it's not like they delay it. It's just they stop sending and they don't really give you an error, right? It's like one of those things you have to read back later because Apple is good about that. It's asynchronous, right? So they'll be like, yeah, it's pending.

Jon (18:49.578)
Mm-hmm.

Jon (19:00.738)
Just gone.

Jon (19:04.715)
Hehehe

Allan Ritchie (19:11.727)
So when you send a notification like sure, the data is all good, but we'll tell you later if it's sent. So the server on the request response, like we're like a lot of dotnet developers are used to, it says, yeah, that's good. But really it's not. It silently fails. So that's a, that's a thing that people have to be aware of, right?

Jon (19:14.963)
Right. Yeah.

Jon (19:27.885)
and

And even when they get like, let you get through, right? Like you mentioned briefly, but I don't know if anybody would have really caught it, like you're given a limited kind of amount of time and, you know, resources, I guess, to, to say, to actually do any execution too. Right. And then if you're like being a really good citizen, you have to call back their, you have to invoke their call back and tell them, Oh, you used to, maybe this doesn't the case anymore. But it used to be that you would have to say like, yeah, I know I, I'm done what I'm doing.

Allan Ritchie (19:40.184)
Meh.

Jon (19:59.51)
but and I actually did something or nah, nothing was new anyway. So I didn't really do anything.

Allan Ritchie (20:05.859)
Oh yeah, from the client side, yeah, you have to say if new data was presented or not, right? I'm not really sure.

Jon (20:10.282)
Right, which is presumably they're trying to use that to help kind of throttle background. I might be conflating that a bit with just pure background, like scheduled background tasks or whatever. Okay.

Allan Ritchie (20:20.427)
No, it's still there. That parameter is still there. It's kind of like they're async. It's more about their async process, right? So you can see you're done, right? Because you're gonna go off to the server. Most people try and go off to the server and probably pull that data, right? Because you're sure as heck not gonna ship a lot of data in a push notification, even though you've got a lot of data to work with now. Most of the time you still have to pull, like you're gonna go out, make an HTTP request, pull that data back and then tell Apple, yeah, it's good, right?

Jon (20:27.703)
Mm-hmm.

Jon (20:33.911)
Right.

Jon (20:46.828)
Yeah.

Allan Ritchie (20:47.507)
For the most part, I think everybody cheats that and just goes, yeah, there was new data. Go away. There's new data. It's good. The challenge is that they only give you so much time to work. Like Apple's very harsh, right? That used to be four seconds and that's people think, oh yeah, I can make a server call in that time. But you got some, if your app just woke up, there's a DNS resolution. You might have to.

Jon (20:51.09)
Yeah, yeah, of course there was. I'm good. This was worth it. Don't, don't throttle me.

Jon (21:10.014)
Yeah. And maybe you're on some kind of not great signal cellular network where a request just takes time.

Allan Ritchie (21:17.343)
Yep, maybe because it's an authenticated request, you have to redo your GWT token. Then you have to get the data. If you're doing a sync process, sometimes there might be a lot of data. Like maybe my phone's been asleep for two weeks and all of a sudden it's like, hey, there's a lot of data and you start to pull it and you can't do it in that time frame. So it used to be about four seconds. I think they give you more closer to 10 now. So if you can't get that done in 10 seconds, there's probably a little bit of an architectural

Jon (21:22.784)
Right.

Jon (21:46.208)
Yeah.

Allan Ritchie (21:46.275)
Still, something to consider. I tend to push it off to like a background job now because background jobs application like 30 seconds up to a minute and 30 if you wanna request more time. So the push notification is more, you need to do something. So I'll flag it, I need to do something and then come back later with a background job.

Jon (22:01.741)
Yeah.

Jon (22:06.094)
And that, like, I think, you know, as we unfold some of this, like that's where a lot of the complexity just starts to come in, right? Because on, we've only talked about iOS so far, right? And, and already we're talking about, okay, there's a special notification. And if it comes in, you know, you have some time to do something, but maybe you actually want to do a whole background task. And that's a whole other very platform specific mechanism that we're talking about doing. And so suddenly you've, you're B you're way beyond the, you know, cross platform.

Allan Ritchie (22:15.392)
Yeah.

Jon (22:35.926)
you know, happy place of coding at this point, right? And so, you know, we'll have more conversations I think of other parts of Shiny too when we get into background tasks and services and things. But, you know, even push notifications, there's some commonalities between platforms, but like there's a lot that just isn't quite one-to-one mapped the same, which I think also makes it challenging.

from an implementation standpoint. And it certainly makes it challenging for something like Shiny to even try to implement in a cross-platform way.

Allan Ritchie (23:00.911)
Correct.

Allan Ritchie (23:09.131)
I mean, we'll get into what Shiny does. I feel, not to kick Shiny or anything, but I feel it's minor and we'll talk about what it does specifically that helps people. But for the most part, I think it's the small part of the overall picture. It's really these nuances about the platforms that really tend to cause the most issues for people. And I know as we talk about, so there's a lot of third parties like Azure notification hubs and...

Jon (23:28.863)
Yeah.

Jon (23:34.488)
Mm-hmm.

Allan Ritchie (23:36.239)
Oh, craps, there's been tons of them over the years. I can't even count. Did HockeyApp have push?

Jon (23:41.634)
They might have at one point. Yeah. There, yeah. I can't even remember all the other ones that, yeah, there was quite a few that this was like their business, right? Because, and because it was so challenging to talk to the different services, you know, they made businesses out of it.

Allan Ritchie (23:53.907)
Right, maybe we'll get to that after we talk to Android as we'll talk about what those services are actually doing for people, because they do a lot and you don't quite realize it, but it's mostly server. Like I said, the client side is a little bit easier other than the one thing that Shiny does to you, which we'll cover at the end of this.

Jon (23:58.519)
Yeah.

Mm-hmm.

Jon (24:12.27)
OK, so I think we've done a decent job of the iOS, at least the client side kind of part of it and configuration. So Android, what does that look like?

Allan Ritchie (24:19.771)
Android. Well, first of all, I want to say John and I generally tend to have a love-hate relation. Well, I do with iOS too, just more with Android. Android infuriates me.

Jon (24:30.038)
Yeah, they each kind of do some things better, right? And then the other, and you're just like, why can't you be more like your sibling Android or why can't you be more like iOS?

Allan Ritchie (24:39.991)
Well, the trick with Android is you don't know if it's a service or a broadcast receiver or a foreground service these days. They just keep changing that one. And then I swear to God, every release they do a new permission, right? So the trick, let's start, I guess, with the portal on the Android side because that's the first one is. Android has what? Three portals that you need to deal with for the most part. You have to deal with the Google Play Store console.

Jon (24:54.272)
Yeah.

Jon (25:00.801)
Yeah.

Jon (25:08.757)
Mm-hmm.

Allan Ritchie (25:08.867)
right to just release an app you have to deal and I guess Apple has that too. Fine. You have to deal with the Google developer portal and then

Jon (25:19.134)
Right to set up like your server key and stuff for, you know, application. Yeah. The API. Yeah.

Allan Ritchie (25:22.091)
the API. And then you have to deal with the Google Firebase console, which is yet another thing. And it's for me even today, it's still chaos, right? So you're still flipping. So not only is Android change the game between what was it called before Google Cloud Messaging? GCD. Yeah. So, oh wow, you got that one.

Jon (25:42.542)
Cloud to device messaging, C2DM.

Allan Ritchie (25:48.771)
right off the top of your head, man. I can't even remember it anymore. So they've changed the picture on us three times. And I've heard Firebase, there's rumblings that they might yet still change that again in the near future, which I sure as heck hope they don't.

Jon (25:49.834)
Oh, yeah.

Jon (25:59.056)
No.

And to be clear as well, Firebase almost adds another level of, if you're dealing with cross-platform, if you're also dealing with iOS, I also see a lot of confusion between, I want to do notifications to iOS, therefore I must need to use Firebase Cloud Messaging to do that, and it's like, well, you can, but it's another, it's more like a provider, like we'll talk about Azure.

or something right at that point. And you would think that maybe using Firebase both places would get you more consistency between things, but I don't think that's the case either. So when you get into Firebase console, developer console, don't be fooled by, oh, there's the iOS part of it. You can certainly use that, but that's a different thing too.

Allan Ritchie (26:37.253)
No, it doesn't really.

Allan Ritchie (26:50.539)
Yeah, and I think that that's one of the big confusions that still happens, right? These providers, you don't really need them on the client, right? So we'll speak to that, that's for sure. So the other thing about Android, their notifications are far, far richer in terms of kind of what they do. My phone's beeping, let me get rid of that. Sorry, that'll be an edit.

Jon (26:58.199)
Yeah.

Jon (27:11.106)
Mm-hmm.

Allan Ritchie (27:18.303)
So the Android notification is super rich in what it can do, but you only get a subset of that for your push notification payload, right? You can't really do, I think they let you do most of it, but certainly far from all of it nowadays. And then the other thing is the raw amount of boilerplate, right? Like you still need the, you still need access to an activity at some point, you still need, you still need to wire in Firebase. And they've got like that JSON file that you have to download.

Jon (27:31.623)
Mm-hmm.

Allan Ritchie (27:46.315)
You have to kind of specially build that in.

Jon (27:46.41)
Yeah, there's like the configuration file and you have to set, you know, every time you're, you're going not like the native platform language and tool tooling for development, you know, it adds kind of a bit more, I want to say complexity, but it's not always the easiest to understand. Like, okay, now I download this Google services, JSON file. Like what do I do with it? Right. And in terms of a Maui app or a Xamarin app. And we do, we, you know, we built.

Allan Ritchie (28:08.46)
Right.

Jon (28:14.006)
like the build actions or whatever for this forever ago. So you can include it in your project that way, but it's maybe not obvious always to everyone because there's not a ton of tutorials or whatever. I guess they just have to follow the shiny one and it'll tell them to do it.

Allan Ritchie (28:27.767)
Well, and that's the cool thing too, is you don't really need that complicated build step either. You can pass Firebase the variables. It's just, you have to go into that JSON file, pull out. And then their terminology doesn't always match to one-to-one between the JSON file and what their API is defined as. So it's a bit of trickery, but it does work, right? So there's just all this stuff that you have to set up in Android. And then there's how it deals with intents, right? So when you press on the...

Jon (28:35.886)
You have to get it.

Allan Ritchie (28:57.539)
notification. It's not as intuitive as the Apple SDK. You have to mark your activity, that it's going to receive that intent. You had to broadcast that intent from the server. It's just... I don't know man. I'm not sure what they were thinking when they made it to be honest.

Jon (29:06.082)
Mm-hmm.

Jon (29:11.571)
And

Jon (29:15.178)
Do you still need to, like, I know, um, not that long ago, and I've obviously forgotten all the stuff that I did with it when I was kind of playing around with Maui apps and getting Android notifications working and just kind of proving out that, you know, I think we had somebody concerned that, Hey, I'm not getting, you know, when I killed the app and this is another thing too, right, like I'm not getting the notifications.

Allan Ritchie (29:35.352)
Yep.

Jon (29:39.062)
Um, but then even when they're like, when the activity goes to the background, I'm also not getting the notifications. So like, you have to do some special things depending on how you want to be able to receive those is that, you know, that the case still.

Allan Ritchie (29:51.071)
If you swipe it away, it's a service, right? And so services in, especially the Firebase one, cause they control that. I think the Firebase stuff is still improving too. But when you swipe it away, it does take time before it either wakes up. You usually have to open the app again yourself. There's certain things you can do, like receive boot intent to get it wound back up. So if the phone reboots or you can kind of get it going again, but for the most part, if you usually swipes it away, you know.

Jon (29:59.319)
Mm-hmm.

Allan Ritchie (30:20.131)
Tough luck, you're gonna have to, you just have to deal with it. It's basically like they silenced it.

Jon (30:25.106)
Well, yeah, I was going to say, I think that at some point, you know, I remember going to like a Google IO and sitting in some session about push notifications and Firebase and like them talking about that being rather intentional too, like if a user is forced killing your app, it's like, well, I don't want this. So go away.

Allan Ritchie (30:37.623)
Yeah.

Yep. Apple does that to an intent to, but they'll eventually wake it back up. Right. So if you, if you're sending enough notifications, eventually they'll say, like, listen, either silence it in the notification settings or we're waking it back up. So I think when the swipe away, it usually goes away for an hour or two. Um, but then it'll kind of get itself going again by Apple's will, not yours.

Jon (30:53.666)
Right.

Jon (31:05.194)
Yeah. And I seem to recall on Android as part of looking at this, um, there were differences in, you know, how the notification was received depending on the activity state as well. Like if your activity was in the foreground, I forget the path, but they didn't show like the pop-up notification in the system at that point. If I remember correctly.

Allan Ritchie (31:29.792)
Yeah, that's still, you have to include the notification payload and kind of say how it's gonna work. So I think that's what you were asking for the Apple side of things. It is still a thing for Android, but for the most part, you can do it in the notification payload. You just have to be very intentful on what you're doing.

Jon (31:38.775)
Yeah.

Jon (31:50.322)
Intentful. Nice pun. Android intense.

Allan Ritchie (31:51.571)
And well, yeah, it sticks with you, unfortunately. That's like the biggest hang up is trying to remember all the stuff and like the intent filters and how you broadcast. It's just I don't know what they were thinking with Android some days. It's like, how did we get here?

that can definitely use a re-haul.

Jon (32:11.158)
So what other complications haven't we touched on with Android? I think permissions was something we started talking about.

Allan Ritchie (32:19.599)
So, oh, the permissions is a good one. Like I said, Android 13, they added like this post notifications. So they finally made it so you had to ask your user permission first to be able to do notifications. Right. Right, and it makes sense. I was like, why wouldn't you ask that on both? But it was always like, there was a flag on Android that you could say, are notifications enabled? Right, so they were, it was more of a white listing than a black listing, and now it's like, you asked permission.

Jon (32:29.826)
to actually register to receive them yet, which has been, iOS has been like that forever, right?

Jon (32:43.97)
Yeah.

Allan Ritchie (32:49.931)
right? So it's, I don't know why they didn't do it from the start, but it created a bit of a havoc play because now all of a sudden you're like, okay, uh, what changed? So I feel like when we do iOS releases, I know you tend to freak out a lot more about the big releases, rightfully so, right? Cause UI always seems to be where they, the native controls start to kick. So I feel like Android's probably not as bad there because of Android X. Is that fair?

Jon (32:50.582)
Yeah.

Jon (33:09.3)
Yeah.

Jon (33:16.266)
Yeah, that's probably partially true. Yeah. Permissions has been the big one, right? And that bit us, even recently with Maui, I actually like that the Maui service release that's coming out has some fixes specifically for some permission changes that happened on the newest version of Android, right? And it's like, you used to be able to like call the connectivity APIs a certain way. Maybe it wasn't permissions specifically, but it was like broadcast receiver.

Allan Ritchie (33:19.648)
Right. So the.

Allan Ritchie (33:34.988)
Yep.

Allan Ritchie (33:45.185)
Yeah.

Jon (33:45.914)
type stuff and it's just like every release there's something that changes there.

Allan Ritchie (33:50.475)
And the thing is, is that the call is not, it's deprecated, but it's not removed. So you don't actually know what fails until you test it. And you're like, oh, okay. Well that, that's helpful. So I almost feel like the iOS doesn't break you, you want, the iOS breaks the UI more than Android, but Android breaks the backend more than iOS. So it's like.

Jon (33:55.328)
Right.

Jon (34:07.127)
Yeah.

Jon (34:11.198)
And this seems to be like, and I think I said this on our last episode or maybe the first one, just about how like they kind of are like working towards the middle ground of being, you know, the same to an extent, right? Like Android keeps adding more permissions where we just talked about iOS already had permissions for those types of situations. And so they're making things more and more restrictive as they go on to kind of match up.

Allan Ritchie (34:31.662)
rate.

Allan Ritchie (34:36.231)
I will say this though that the one thing Android has going for it is it's still a lot easier to... once you get all that boilerplate which you can usually document, it's so much easier to set up for push, believe it or not. Once you get through the three portals and all that stuff and all the API keys and all that crap, once you get that out of the way, it's generally easier. It just works. Whereas iOS, you've got to scratch your head and go, oh, I have the wrong key or oh, I'm passing the wrong bundle and oh, my app is signed with...

Jon (34:49.005)
Yeah.

Allan Ritchie (35:04.899)
production, right? Like, and they don't really give you failures because like I said, it's asynchronous, right? You don't know that it fails and you have to go in and read logs. And so I will say that, that it's easier to set up iOS but it's a lot harder to tell the problems. Once you're through Android, it just kind of works. And that's the nice part. So.

Jon (35:10.933)
Yeah.

Jon (35:27.254)
So with Android 2, I know we talked a little bit about services and activities. What is the setup there? When the notification comes in, can you choose if you want it to route directly to an activity? Like, can you put your, I don't know, are you registering an intent filter? How does that all get set up?

Allan Ritchie (35:48.175)
So you do that from the server, right, if you want it to open, because a lot of the cases it's done from the notification payload. So the notification payload, if your app is in the background, you have no control over it. It's just going to flow, right? So the OS is going to take care of it.

Jon (35:54.114)
Mm-hmm.

Jon (36:01.715)
And is the OS by default then just going to open up your main launcher activity?

Allan Ritchie (36:06.781)
If you don't specify an intent from the server, so that's the one

Jon (36:09.278)
Okay, so you can put an intent in the notification payload to tell it what to do actually. Okay.

Allan Ritchie (36:13.215)
Right. Yeah. So it's, you have to have that relationship between your app and your backend. So Shiny, I have like a forced one that this is the key you have to use. I might open that up in the future, but right now it's like, this is the constant, put this everywhere, put it on your server. If you want to use it, you got to do it for both ends. Right. And then that way I can register and kind of deal with the cross-platform there. But we'll get into that. But yeah, the intent has to come from your server, which means it has to have knowledge of your app.

Jon (36:36.554)
Yeah.

Jon (36:43.55)
Mm-hmm. Which yeah, is always kind of that weird mixing of like, it's almost like mixing your UI and business logic, right? That's like.

Allan Ritchie (36:43.961)
Right?

Allan Ritchie (36:51.791)
to a degree.

Allan Ritchie (36:56.211)
Yeah, I don't want to get into the philosophicals of that one. It's hard to say. It kind of makes sense and it's kind of annoying at the same time, right? I don't know what the best way is to say it. It is annoying.

Jon (36:57.39)
Hehehe

Jon (37:08.675)
So does that mean that you can also then, if I can specify like the intent on the payload itself, can I also then send, you know, these kind of background silent notifications like we're talking about on iOS?

Allan Ritchie (37:20.643)
So iOS has that content available and then it has the data payload as well. With Android it's basically you can send both and if you negate one then the other one just is used. So if I send just data, it'll work. Now they don't tend to, I mean I've never broken it per se, they don't tend to throttle those silent notifications like Apple does. Don't quote me on that because that could start tomorrow. That's the challenge.

Jon (37:42.871)
Right.

Allan Ritchie (37:48.343)
They have that concept of silent notification that wakes up your app and says, here's the data, right? And as it is too, like I said, if you send notification data and data data, right? In your payload, if your app is in the background, they don't give you the notification payload to read, even though it's been sent. I know that's confusing. If your app's in the foreground, they give you both. Why? I don't know. They just decided that was a good idea, I guess. I don't know.

Jon (38:00.587)
Mm-hmm.

Jon (38:19.306)
Yeah, that's strange. But, but I can still build like my, you know, service or whatever that can receive those in the background and wake up and do whatever I need.

Allan Ritchie (38:24.321)
Right.

Allan Ritchie (38:28.251)
Right and usually for the most part that those data payloads are pretty small. It's more or less a kick to get your app going. That's why I think Apple just said content available is one and if you must put like maybe you want to pull a certain work order or something as an example right you could include the ID or a chat message or whatever. Normally I just don't. I say give me a delta of everything that's changed. It's usually the easiest but teach his own however you want to architect it I guess.

Jon (38:38.859)
Yeah.

Jon (38:56.278)
So does that cover the Android client side of things? Are we missing any kind of gotchas or info? I mean, we might be, but I think it's a pretty good, yeah.

Allan Ritchie (39:00.587)
No, we might be. Um, but for the most part, it's just boilerplate. It's just understanding the platforms and then the most, most of the work is done on the server, right? That's where all the complexity lies and certificates and all that stuff that you don't want to learn about. But you have to, you have to know the platform nuances. Like I said, the big gotchas, that's the stuff I like to cover. Cause that's where people always get.

Jon (39:11.704)
Mm-hmm.

Jon (39:28.01)
Yeah. Yep.

Allan Ritchie (39:28.759)
trip over, right? Like the iOS throttling. If you didn't know about it you'd be like it stopped working. It must be a bug in the library. No it's not. Oh I get it a lot for shiny people like it stopped working. No it's it worked in it. This is how Apple works and get used to it.

Jon (39:34.09)
Yeah, there's no indication, so how do you know? Yeah, exactly. It's a bug in the apple. It's a worm in the apple.

Jon (39:52.022)
So does Shiny handle any of the server to server aspect of notifications or do you just leave that up to, you know, the Azure's and Firebase providers of the world?

Allan Ritchie (40:03.431)
I do have a library that does it. Now it's based around kind of how I deal with it, like user registration and tagging, right? So it removes like the need for Azure notification hubs and Firebase to a degree. And it allows me, it's probably pretty complex for most, but it allows me to customize the notification per user. It allows me to kind of run it off in a background process so that, because sometimes you may have one message that triggers like a thousand notifications.

Jon (40:11.479)
Mm-hmm.

Allan Ritchie (40:33.259)
And that's the other thing a lot of people think, oh, well, I have to send one notification. I need it to be easy. But as your app starts to get bigger, you know, like I said, you might be sending that message to a thousand users. Right. So I tend to work with a lot of ambulatory services and hospitals, at least in my past. And they would send out notifications to like hundreds of ambulances within a, you know, a GPS set of coordinates and the device would respond. Yeah, I'm good. Or no, I'm not in that area. Right. So.

Jon (40:47.458)
Mm-hmm.

Allan Ritchie (41:02.499)
That doesn't happen in a three second window of an HTTP request, you have to kind of background it. And this is where a lot of services like Azure Notification Hubs and Firebase, those services kind of do it for you. So one of the things they also add is tagging. So you may wanna tag a certain groups on users and say, send it to all these tags. iOS doesn't have that concept. It's just, yes.

Jon (41:08.063)
Yeah.

Jon (41:25.622)
So does Android support that like, yeah, at the notification level? So I can send a notification to a tag and everything they never registered to that tag is gonna get it. So I don't have to send one to each person. Okay.

Allan Ritchie (41:34.931)
Exactly. So that's right. So that's like fire. Firebase has that and that's why a lot of people tend to use Firebase on iOS as well. But now we're talking at a provider level versus like a platform level. Right. So Firebase has moved to a

Jon (41:42.77)
iOS as well. Okay.

Jon (41:48.306)
Right, so Firebase for iOS is handling that for you on their servers. They're still sending all the notifications to Apple.

Allan Ritchie (41:52.693)
Exactly.

And you still need the native token from Apple to register. Like that's, that's the thing. All these providers, like there's, there's gotta be a hundred of them out there. They just keep coming and going. Right. Um, that's what they're doing. They're building an easy server layer. You still have to do the Apple and Firebase setups and give them the keys. You still are using.

Jon (42:13.062)
Right, but then you send them like, hey, here's my token, here's the tag I want you to associate it with, and then I can tell them server to server, you know, use the tag. So like in the past when I've done this, I've made like a user ID as a tag. Is that, you know, a reasonable thing to do with some of these providers? So like, I don't wanna track myself that the device is associated with it, so I'm just like, hey Azure.

Allan Ritchie (42:23.224)
Right.

Allan Ritchie (42:33.751)
You can.

Jon (42:40.114)
I have this device token, here's the user ID tag I want, and then I just kind of let them deal with it.

Allan Ritchie (42:45.451)
Absolutely you can. A lot of people do that and they might stick certain roles on it too, right? So to say, so for instance, I've done it like hospital and ambulance, so I'd say send it to all ambulances, send it to hospital, right? And then that's how you do your logical grouping. But again, that's at a provider level, right? So your Azure notification hubs has that, Firebase has that, it brings it across platform. So, you know, the tags is now built into Apple and to Android and you have that nice surface level.

Jon (42:50.463)
Mm-hmm.

Jon (43:01.632)
Mm-hmm.

Allan Ritchie (43:14.787)
kind of API and then these providers do lots of little extra neat stuff for you. Azure notifications has like a message template so you can do I think minor bits of logic in it with keys and I think it's

Jon (43:29.462)
So are they, they're kind of trying to abstract like how to present the notifications across platforms for you in that sense, is that what that's for?

Allan Ritchie (43:37.083)
Yeah, and you can do things like with multilingual there that makes it kind of nice. I don't tend to use them myself. I usually know the user's language so that I can tell. That's again one of those things why I have a library that goes through and decides kind of the left or right metrics and there's a lot to it. Keep in mind also that people might have multiple devices. So tags, even if you set a user ID, it might be multiplicity still. It's not like a

Jon (43:46.743)
Mm-hmm.

Jon (43:58.828)
Right.

Allan Ritchie (44:04.327)
individual user, it's multiple. So that's another thing people don't understand, right?

Jon (44:09.346)
Yeah, I might have the app on my Android device and on my iPad, right? And I want to receive notifications to both. Or maybe I don't.

Allan Ritchie (44:13.665)
Right.

Well, and I know you have like a ton of phones, so you're going to be running Android nine, 10, 11, 12, 13, 14. Right. And you're going to have them all laid out in your desk, logged into the same account. I send a push and I want to see it on all those devices. Right.

Jon (44:25.046)
yet.

Jon (44:29.418)
I'll make my desk shake from all the phones, you know, vibrating at the same time.

Allan Ritchie (44:33.935)
But when you've got like QA testers, that's what they expect. They expect to see some sort of equivalent on them. So they will test it like that. So that's just another thing. Like these providers, they really do a good job of kind of flattening out that API and turning it into something that's kind of easier to use. It removes a lot of that pain that you would have to code yourself.

Jon (44:49.772)
Right.

Jon (44:56.766)
Well, and as, yeah, like, I mean, and this was ultimately, you know, where Push Sharp met its demise was that, you know, talking to these providers isn't easy. We talked about Apple having their binary protocol at first. That was a pain. And let me tell you, so what they would tell you, they would tell you like,

fire as many notifications on that one socket connection as you can back to back. And it wasn't like a fixed length or anything. It was I had to tell you the length of my payload. I sent it off. And then if I remember correctly, it was. And then they wouldn't really tell you when a message...

Allan Ritchie (45:33.199)
That was them framing the packet, right? That was how they did it.

Jon (45:41.198)
queued up failed for queuing up. Like we're not even talking about the delivery part of it, right? It's the sending it to Apple part. And they would just kind of like kill your connection. And I forget exactly the first iteration had no, like, you couldn't get the idea of the message that failed back or something. It was like the worst design ever. There was no confirmation that something worked. They basically said like, and what most libraries did was waited like three to 500 milliseconds.

Allan Ritchie (45:45.452)
Yeah.

Jon (46:10.358)
to see, you know, from the last sent notification to see if the connection got killed or not to Apple. And only then would you know that like one of the previous, however, many notifications went through. So what I ended up doing, I think I remember now as I would keep like a queue of things I had fired off and I would time those out of the queue. So like if 500 milliseconds happened and my connection still hadn't been broken, those ones were fine. I.

you know, quote unquote fine. And then if I got a connection killed, anything that was sitting in that kind of time queue, I would be like, yeah, those probably didn't send because they wouldn't tell you, you know, identifiers of messages that failed or whatever. I think eventually they enhanced that protocol to add something like that, to give you that information back. You do now.

Allan Ritchie (46:57.159)
You now know that it failed. If it's wrong, like if you sent data that doesn't match up or the device, you know. But you have to still follow up later to see if the message actually made it to the device. Or you have to have your.

Jon (47:03.934)
Right. Like a bad formatted message. Yeah.

Jon (47:10.45)
Oh yeah, yeah. This is just if it like entered Apple's own cube fine or not. Right. And so they

Allan Ritchie (47:15.807)
Right. Nowadays, people tend to act from the device, right?

Jon (47:19.71)
Yes, yeah. And so Apple, that was like their first iteration and that was a pain, but then they moved to an HTTP2 based protocol. And I tried my best to update Push Sharp to support this. But part of the challenge was like, there is no client library for HTTP2 in.NET at the time that just didn't exist. So I started writing my own and that's a pretty complicated spec.

Allan Ritchie (47:42.893)
Yep.

Jon (47:47.506)
I got it almost working, but then I ran into problems with SSL and secure socket connections and the way that you had to initiate the HTTP connection. And C Sharp just couldn't do what I needed to do to make this work. And so I'm like, OK, we're done. This is it. I'm finished. Push Sharp is no more. Go use Azure notification hubs because

Allan Ritchie (47:55.072)
Yeah.

Allan Ritchie (48:05.111)
You are ahead of your time.

Jon (48:15.274)
One, they're doing it for you. And two, like it's not that expensive to use. Like don't, this is something just don't roll your own. That's where we ended up eventually. And I would imagine if I tried to do it again today, it'd be more successful because hopefully C-sharp, you know.NET, the runtime would have the things I need. Like I think it would work on Windows at the time from a client library perspective, but the, you know.

SSL stuff just didn't work on like Linux or Mac and like there was just no plans to implement it at the time. So I'm like, well, I can't do anything more here.

Allan Ritchie (48:47.203)
So the funny part is too, is that even though Apple has modernized with HTTP and we now have that, like the HTTP client works on HTTP 2, I think it even works on the new 3 as well. Like it just works. Apple still has some funky HTTP stuff that they like to use. It's different from everybody else. You know, God forbid the rest of the world does rest and these kind of metrics with HTTP, but Apple has to do it just a touch different. So even though it's HTTP.

Jon (48:55.318)
Yep.

Jon (49:12.046)
Yep.

Allan Ritchie (49:15.083)
You still have to do some funky things with some weird encryption. Um, and you still have to do some kind of weirdo headers, um, with the Apple request, it's just great. I don't know why they do that, but they did.

Jon (49:27.778)
So are you, so Shiny, is it actually talking to Apple? Like, do you have that built in now where you act as the client and you can talk to their service?

Allan Ritchie (49:33.395)
Yeah, so, so shiny has its base kind of push library and what shiny does is tries to make that cross platform. So I try and get, you have a push manager that says, request me a token and it'll do stuff like the permission checks for both the Android and iOS. It'll ensure that the proper stuff is set off to the servers and that the token comes back kind of solidified. So you get a string from either Apple or Android and then you can do whatever the heck you want with it.

It also, it also kind of centralizes the events. This is what shiny really does anyways, it centralizes those events in a, in a, I call it a delegate because that's what Apple does. There's a reason I don't use.net events, but we don't need to go into that today. So it has this little delegate that says like on it, when you're entering a push notification, do this, right? Here's the data I give you do something with it. It has the background kind of data, the silent notification that we talked about.

Jon (50:11.458)
Mm-hmm.

Jon (50:29.367)
Mm-hmm.

Allan Ritchie (50:29.635)
It has an event for that in the delegate. So you can, you know, read your dictionary of whatever's in there, make an asynchronous call and do whatever. Right. And then last but not least, sometimes that token, now this doesn't really happen anymore, but it used to be as your app would wake up and you check for a notification token to see if it changed. Um, I think Firebase still does it rarely now and again.

So they'll say, okay, well, you know, you're a Firebase user for messaging. The token just changed. It's expired, right? Like a JWT, here's your new one. So I had to have an event for that too, because the thing with Shiny is I want to request access to the token when I usually, when I log in and I want to unregister when I log out, right? So after I've requested access to a token, I just want this just shiny deal with it. Every time if there's a token notification, I'm already logged in.

Jon (51:13.336)
Mm-hmm.

Allan Ritchie (51:24.491)
So I don't want to write startup checks. So every time I log in or my app starts, you already have a push notification token, make sure it's still the same. And if it's not fire, the delegate until the, tell the programmer has changed, call your server with your JWT, all your stuff and say, here's the new token. So that's one of the things that shiny does really well. It centralizes all that. The second thing is, is it, it makes it so you've got one interface to always work with. So.

Jon (51:26.487)
Yeah.

Allan Ritchie (51:52.723)
If you want to build Azure notification hubs or Firebase on the device, don't generally recommend. Um, you still can. And it's just another layer that sits on top, right? So regardless of, I think there's one signal and Azure and Firebase, they all still work on the native tokens. Like it's still Firebase. It's still APNs underneath. All I do is I say, okay, is there a provider registered? Okay, there is. Here's the tokens. Do as you will with them, right?

Jon (52:12.273)
Right.

Allan Ritchie (52:21.811)
If you're going to call off to Azure notification hubs, great. Um, but I I'm also able to do stuff like, do you support, does this provider support tags and all this other cool stuff? Okay. Here's tags for you to use as well. So definitely check it out. It is worth it. Um, if you've done one signal app center, that was actually shiny push started because of app center, um, my, my good friend, our good friend, Dan, uh, Segal. He was, he was like, dude, I have to keep changing this.

Jon (52:21.912)
Right.

Allan Ritchie (52:50.735)
and it's really hard to get these permissions and Android keeps changing on me. He's like, do you know anything to do with Shiny? And I was like, okay, Dan, I will try this. And it seems to be pretty popular. People like it and I use it everywhere. So Shiny just makes it all easier. It's one thing to deal with. Yes, there's boilerplate. I can't deal with all of it. I talk with John. John helps me sometimes in the Maui side, where you can.

Jon (53:13.874)
And there's the, you know, things that you've added here and there. And there's, there's always like kind of opportunities to try and make it easier. Right. Like I, I don't know. I haven't gone through the shiny, uh, tutorial or, you know, trying to use it at any time recently, um, probably should have done that for the show. But I, I'd imagine that. Yeah. I do it all myself.

Allan Ritchie (53:30.599)
John won't use any open source, he builds it all himself. Every time. He likes pain.

Jon (53:36.726)
But there's, you know, especially with stuff like newer stuff in.NET, like I don't know if you're doing any like source generator stuff for any of the boilerplate or if you just kind of have people, you know, go copy and paste. But there's always opportunities to make that kind of boilerplate set up a little bit easier. I know you've got your template, you know, master template of everything. So there's that, too.

Allan Ritchie (53:58.655)
Yeah, I do have on the shinylib.net site, there is like a, you pick the libraries you want, it generates all the boilerplate that you need so you can copy and paste from that, which helps so if you don't have an existing project, you can bring it in. Yes, the templates will obviously do all that. I was doing source generators. The problem is, is that it would conflict with like, like everybody was fighting for that base app delegate or that base Android activity or that base Android application.

Jon (54:08.345)
Okay, that's cool.

Jon (54:26.752)
Right.

Allan Ritchie (54:28.247)
So it was like, I couldn't figure out how to play nice with everybody. So at some point I was just like, you know what? I'm just going to tell people what they need. I'll document it the best way I can and have Adder. There's a sample app.

Jon (54:40.699)
Do we not expose enough of those at this point in Maui and like the lifecycle events to hook into?

Allan Ritchie (54:46.447)
Not yet and I don't think you ever will be able to because you have to register the intent filter right which is it's an attribute right and on the app delegate as soon as you expose those exports so um push the three push I can't remember the names of them then ios starts going wait you've got those so that means you need push and if you send that to app store connect it'll start going well you don't have a profile for this

Jon (54:51.671)
Yeah.

Jon (55:02.914)
Yeah.

Jon (55:12.566)
Right, so once you implement it, it's expecting that it's there. Now, we'll have to talk later. There's always ideas. I know there's some ways you can get around that with like overriding response to selector and stuff on your Apple types. But yeah, for now it sounds like, hey, I mean, go to the site and get your code generated and it's easy enough to copy and paste some stuff in. Definitely easier or no harder than doing the same natively, right?

Allan Ritchie (55:38.847)
Right. Well, and that's the thing. It's as good as source generators are when you try and do too much of the magic, good luck supporting that in open source. It's so hard. And source generators, I mean, John and I have worked on a couple of them together and it's so hard to tell what's going on or where the failures are going and how do you communicate that? So if it's a singular purpose, it's usually easy enough to describe, but like the first in version two of Shiny, I had a source generator that was doing the base application.

Jon (56:08.469)
Mm-hmm.

Allan Ritchie (56:08.835)
the activity, the app delegate, as well as like a startup. And there was just always something where people like, I don't want it to do this. And I was like, okay.

Jon (56:15.658)
Yeah. Fine. Just copy and paste it. Yeah. We, I had looked early on at, you know, source generating, like even for a Maui template app, right? The new, new Maui app, we include like an app delegate already. We include the main activity. And so we had talked about at one point.

Do we want to just source generate those in if you don't have them? But yeah, like you're saying, you run into all of these cases where like, okay, um, I guess we can try and do it only when, you know, you haven't implemented your own and try to detect that. And then, you know, what happens if you don't, uh, call the right methods in your own things and it's, yeah, it's all, all of these challenges to overcome. So maybe that's, uh, a little bit too extreme still to try and tackle, but.

Allan Ritchie (56:48.856)
It is partial.

Allan Ritchie (56:59.083)
I mean, you think about XAML is done through source generators and it works there because it's singular purpose, right? But you still have to deal with all those issues like why didn't the XAML generate properly or why wasn't there an error, right? That's an ongoing thing for you guys, right? So it just they solve problems, but they also create them as well. It's just never ending.

Jon (57:04.565)
Yep.

Jon (57:09.428)
Mm-hmm.

Yep.

Jon (57:17.446)
Exactly. Well, I think our plugin package and product of this episode is a pretty easy one that people might already have guessed. But I'm going to call out Shiny, particularly the Shiny push functionality as my pick this week, because that's what we've been talking about. And I think I've seen enough people starting to get into like, how do I add push to my apps?

One interesting thing I was talking with a friend in the area who is using Blazor and Maui, like a Maui Blazor hybrid app, where they're coming from the world of most of their stuff is Blazor and they're just sticking it in the app right now. And that's cool. It's a Maui app, but it's all Blazor content. But the next thing that they're looking at is starting to do stuff like, okay, I do want to add push notifications to my app. I want to add all this kind of stuff. And so

We're starting to see more people, you know, even if they're coming from that world of like, Hey, I have the blazer stuff that I'm just sticking in a Maui shell, um, but I start wanting to start adding these features in. And so I think it's, uh, you know, I think we'll see more and more of, and certainly anything that we can have people go, you know, try out and use to make their life easier and setting this all up is, is obviously going to put more people on the path to success. So, um, that is our plugin packaging product of the week.

Have we missed anything on notifications? Probably lots.

Allan Ritchie (58:43.667)
Oh, probably. It's like a three-episode talk, but I think we covered the big stuff.

Jon (58:49.218)
And I exactly, and I would say too, like if you're listening, if you have more questions, you know, reach out to us. Uh, if you go to gone mobile.io, you can hit us up on the various things that we have, you know, there's, there's threads, there's X there's speak pipe. You can leave us a voice message. There's our email address, uh, show at gone mobile.io send us a email and

We'll maybe do a follow-up episode if there's enough interest and stuff we haven't covered on more push notification stuff, or at least answer some questions there. And also, if you like the show, please subscribe to Apple Podcasts, leave us a review. We should be everywhere that you get your podcasts. And yeah, thanks for listening and we'll see you next time on the Gone Mobile I.O. Podcast.