mergeconflict282 === [00:00:00] James: Frank Krueger. The number one way to get people into your apps is to just direct them directly to your application. Whenever they type in a URL into the browser, like don't even open the webpage and just go right to the app. I mean, that's pretty much a full strategy. [00:00:26] Frank: No, no. Hi everyone. I am going to complain about the hubbub. Now. It's funny, right? We've had URL, uh, support and apps, I think since the beginning and then deep linking, I think deep Lincoln's kind of what you want, but then something terrible happened. And also on HDP requests started getting routed to apps. And I think that that was the last straw. Bad, but overall it's really cool that we can deep link into apps. It's a technology I've been trying to take advantage of at my apps for years. I don't think I've done a great job, but I've at least done a little bit of a job and it's, it's powerful, but no, don't, don't do what you just said. [00:01:07] James: Yeah. Yeah. You know, and, and we've talked about, we've talked about these things for a long time because, you know, um, I, back in the day it was just URL schemes, like you're talking about, and that's what I use in Ireland. Because it makes it easier to just have a direct URL scheme. So a scheme you can think of HTTP or HTTPS as a scheme, it's the things before the semi colon slash slash. So those are the schemes and you can define it for your app and say, Hey, like, you know, this is my scheme that I'm going to use. And it's island tracker, colon dash dash, and Hey apple, like, you know, when someone taps on this link or does this thing, Hey, Google, like, it'd be pretty cool if you just open my app, you know, and I use it. Yeah. For my stream timer too. I'm a big fan of your L schemes, but the problem Frank is that anyone can register your El scheme. [00:01:58] Frank: That's not so bad. It's not so bad. Um, I like it. It's like making an API for your app almost. We don't have command line apps on iOS, but we have this terrible thing called, uh, what's it called? No, I was going to say I'm the user programmable script editor. Um, Oh, gosh. Well, how bad? Yeah, automator on Mac, but on iOS, it's not called scripts while totally blanking. Anyway. Um, the only way you can actually really apps can really communicate with each other. There's like audio channels. You could do some networking tricks, but the proper way for apps to talk to each other is through these URLs. So I think of them as APIs. So whenever you want to have an app, Uh, get data from it. Another app open another app. They were really useful to the point where, um, it's kind of the wild, wild west, because they're just URLs. And in the past, we did have some attempt at people, standardizing them. They're like, okay, this will be the format. If you want to do a query, this is what a query should look like. If you want to open a page, this is what a page should look like, but those efforts have kind of fallen through. So we're still back to the wild, wild west days, but still being able to provide. Apps to each other that provide data, like for instance, Coca Kamika and its most basic dumbest mode is a calculator. So I created a URL. Um, I, sorry. I'm, it's actually in the documentation, so I might get it wrong, just doing it from the top of my head, but something like Calca colon slash slash X callback URL slash Q equals two plus two. And that would be calculate the value of two plus two returning. And you can put that into your little scripts. Once I remember the name of the app that you're supposed to write scripts with on iOS, what is that stupid thing? It's not called shortcuts. It's not called Siri. It's an automator. It's automator on the Mac and on iOS, it has a different name. I was not sure. Shortcuts once I write their first time. Okay. Let's go with [00:04:01] James: shortcuts for now. I think so. I think so. I think shortcuts, I want to say shortcuts, but I'm not a hundred percent sure. So [00:04:07] Frank: yeah. So shortcuts are nice because they have a little card and you just say, if you can put in the URL, it'll call that URL and get back whatever data, and then you can start building up larger and larger scripts. So. I always recommend to people that problem. It's a, it's a feature you can't really sell. I mean, there, there definitely is a dev community out there and there's definitely people who are specializing in shortcuts. You do need utilities like this, like small unit C would have programs that do one thing and do it well and do a quickly. Um, but it's a hard feature to sell, but I still recommend everyone. If your app has any concept of here is a kind of a batch operation I can do or something that would be useful in a script. Like if you have a weather app, you absolutely should have, um, a URL registered so that people can just get the temperature or whatever from your weather app, that's kind of the most basic. [00:05:00] James: Yeah, I'm both. I know at least on iOS and Mac, you can also detect if and on and on Android as well and windows on all of them, but basically you can detect if an app is installed, that can handle it. So, for example, in the, in the back of the day, the Xamarin evolve conference app, this was before like Twitter became like the only Twitter client, you know, and then there's a lot more out there. But what I would do is, is say, Hey, listen, the worst experience. You know, tapping on the tweet and opening it in the browser because the user, if they have Twitter or have tweet bot or have some other, you know, Twitter client, it'd be great to just open their app direct. Now on Android, uh, you can do this very nicely because Android handles, um, you know, these URL schemes and multiple ways. Basically what can happen is anybody could register like Twitter, colon slash slash, and, and then you would get a pop-up basically you'd get a little pop-up that says, Hey, what app do you want to use? iOS still doesn't have that. So if everybody registers Twitter, colon slash slash. I think he just picks the first one you hadn't solved. The last one is, I don't know how it works magic, but [00:06:13] Frank: it's at that permanent. That's sad because I remember apple was popping up dialogues for a few things, but maybe that was only like Malin browser. That's the yes. [00:06:21] James: Today. It's a great point while Frank Kruger great point. Um, today in iOS 14, I want to say. 13 14, 13. They, they allow you to pick the default browser and also the default mail client. And maybe one other thing that you can toggle. So, but Andrew had had. Everything like, yeah, everything right. Which is good and bad. Uh, you know, because most likely you're you're if you tap on a tweet, the developers and to do anything, like they can just, you know, send it off and it would, it would go off and handle it. Automagically basically there were on, on iOS. What I'd have to do is I'd have to register and they got more strict about it too. Right. Cause I have to register all the URLs that you'd like to launch. And then. Or handled too, and then you'd have to check all of them. So I go, his Twitter kink and someone handled the Twitter URLs came out. No. Okay. How about the tweet bot? How about the whatever Twitter thing? And then if not then, okay. Just launch the browser who cares at this point, but it was just this, you know, step through process and you're right. There was a website out there we probably talked about in the podcast before. So there's people that are like, James Frank is talking about this a hundred times. Uh, yeah. You know, you can do that. And, uh, I thought that was a really cool that, that, that someone was trying to get these altogether. But the problem is there's too many apps, too many things, and you would need everyone to go on. Now, if somebody had a directory of every app that was, you know, put on the app store, right. And they could just generate some, you know, directory per se from, from it. I don't know a company has that. Apple Google, apple, yourself album. Then you could do that. Yes. [00:08:01] Frank: Yeah, it's funny because yeah, you're saying an app, you have to declare the schemes that you're going to probe or attempt to open, but you don't have to give any more details. You don't have to describe the URL structure or anything like that. So there's no great way to scan an app to do all that. Cause it's technically just code running. So it's yeah. We're we're like I said, wild, wild west. It's. I was always jealous of Android's kind of URL based navigation thing. It was annoying with activities and all that, but I got it. It was an architecture, it was kind of a clever architecture kind of annoying and practice, but still you had to hand it to them still somewhat clever. And then, um, Zimmerman forums adopted URLs for navigation. That made deep linking with these S URLs pretty darn easy. Did you ever kind of take advantage of that? Like just allow deep linking via Xamarin forms, navigation or anything like that? I never did, but I always thought that was just the gosh darn easiest way to do, um, uh, deep linking [00:09:11] James: from, oh yeah. Oh yeah. Island tracker does that specifically, so. When it was just tricky because you want to like, get the link. Correct. And you need to like, not change it in the future. Um, uh, but island tracker doesn't do that because when you send a friend request or, um, except a friend, basically what will happen is it comes into the application. And what it does is it looks at the URL scheme. Uh, and tries to open that URL. And that URL scheme actually is pretty long because it goes to like AC island tracker, and then. Like home slash friend slash friend code and then passes in a query as well to it. So I was like this very long URL that you'd actually be pasting to your friend, uh, over there. And, uh, to me, I thought that was, that was really cool that you could just extend this huge URL. And then when you tell just, just, you know, the Xamarin forms to navigate say, Hey, It just automatically goes there as long as everything is correct. You know what I mean? That's probably the, the biggest thing is make sure it's all correct. And it doesn't get messed up at all, but yeah, that's what I used to do. It's this huge, crazy path, uh, which is really cool. [00:10:26] Frank: I like it. Yeah. Um, definitely not like you said, not typeable, but that's the different use case you have kind of like the API use case, and then you have the deep linking use case. And then it's kind of funny that they're all through the same thing, but they're definitely pretty different from each other. And I definitely just stuck to the API kind of route. I haven't done the deep linking. Yeah. The only thing I do. Um, I have a lot of file-based apps, so those ones are pretty easy because you'll get an open URL, but it won't be your scheme. It'll just be like a file colon slash slash your out or something like that. And then a document based app. That's the idea is very easy. Yes. Open that file show it. It's like the dumbest form of deeply. So we started, uh, the show because I ran into an interesting blog posts to make testing these things easier. It's it's an old blog post I have to admit, but it was just making its round on Twitters. And I felt, um, because I've always had trouble testing these URL schemes. Um, I think what I did one time was I created like a hidden screen in my app that just had a million buttons on it. You know, it was almost like unit tests and I would just put like a URL behind one of those buttons and, you know, open it itself. It was a terrible way to test it. A I hated creating that hidden UI kind of thing, just for testing and B. It's not a good practical test because you're opening your app from within your app. And chances are things are going to work out really well in that case, because you haven't been put into the background, you haven't been put resident in memory, you haven't been, you know, all sorts of state changes have not occurred. Um, Uh, just, just this morning, hot off the presses. I'll make sure to get this URL too, but it'll be in the show notes a quick way to open custom URL schemes and iOS simulator. Are you interested at James'? [00:12:31] James: You know, cause I agree with you that the issue I had was that I had the same issue now. Now we also remember that the Google wanted to index every app, which is why HTTP. Schemes became the default. And I said, well, only one person in the Napal followed on, you know, one company can verify a URL. So that's the default way of doing this, where they really push on is saying, Hey, like register your domain. And then the idea was, Hey, your apps on two different from your website. So then they could deep link and all this stuff. I don't think it really took off very much, but URL, HTTP schemes came thing. Now, regardless of what you're using, you still need to like handle, like does my app. Actually open the specific HTTPS or the custom schemes here and there. So what I did, funnily enough is exactly what you said, Frank is I, your own app can open your own app. I'm pretty sure, but ideally you want to test it if other apps open your app. So I would create a test. Uh, and all it did was have like, you know, here's a bunch of not buttons. There was buy-ins, but then also like, you know, just a text fields that I could, you know, make sure that I could put in anything I want. And it became the tester app. Now, of course, an iOS 13 or 15, they changed this. And so did, uh, Android, where if you want to launch a URL, you have to, um, now if you have to accept the URL, if you accept a URL, you got to make sure that you're. I think Parson, maybe if you launch the URL, I don't know. Anyways, both. [00:14:00] Frank: So that both apps. Yeah. You have one app says, I'm going to try to open this URL. The other app has to say, I'm going to accept these URL. So yeah, definitely. I do it both places. [00:14:09] James: So anyways, so I basically create that little test or application, but that was always a pain because it. It, it was real world, but not exactly real world. Like ideally I would want to, like, I would end up how I would test it is I would get the URL and email it to myself, or I would like text it to myself. I would open up, you know, IMS or email. And again, you'd have to do that on a device because you don't have that on the simulator over there. Uh, so iOS to me was always a pain. And also, I will say also just testing on windows and Mac are always a little bit tricky for URL schemes because. I felt as though on windows, you can just go into run and just give it a protocol. They call it protocols. And in fact, if you go into windows defaults like default apps, you can also go to, um, protocols and you can, you know, I can be like, oh, what is my everything's there? So there's like search, read podcasts, like I'll outlook HTTP, because I had a, I had that issue, which was for some reason, edge was my default for all HTTP, even though my default browser was. Um, funny was edge dev or edge Bader or whatever I'm on. So actually had to change the HTTP. So how other apps are calling it, right. They might be using a different API. I had to change that, so to move it over. So anyways, back to back to what I'm saying over on the Mac, I always felt like I should just be able to open terminal, pop something in there, and it should be. And I feel like that mostly kind of worked, but how I honestly tested a lot of my apps was I opened up the browser and then I put the URL with the scheme in and then type it in. Uh, and again, that's not really real world. Um, but I always, I always had issues with this just in general. Frank, is there a better [00:15:50] Frank: way? Yes, there is whole podcasts. Um, yeah, I, I D I tried that browser approach. It's terrible text entry on the simulator is just bad and kind of even worse on the device because it's not in the clipboard or you don't have it anywhere, but yeah, I've definitely done the browser approach to no, James, there is a command line solution, which, you know, Which probably means I should make an extension for visual studio, put a bunch of these little things in it, but, um, I always forget this, but X code has a command line interface to it. It's, it's a little tool called XC run and I forget about it. I just forget. I, you know what the problem is. I have scripts that use it. So I use it all the time, but I've forget that I use it, but this little XC run thing can also control the iOS simulators and the command is ECC run space, SIM control S I M C. And then after that you have even more options. It's like, yeah, you can just keep straining, chaining these things together. And what you can say is open URL. It's so simple. Of course they have this, it just never occurred to me until I read this blog post. But what you can say is, uh, actually run SIM control, open URL, uh, this booted thing on another command line to just say, uh, what the state of the app should be. And then you can just give it the URL. Jane. Wonderful. I can't believe I never looked this up before. I should have read the manual. Where have you been my whole life? I've been doing 10 years of opening URLs without knowing about this thing. Uh, so at the command line, you can start doing your tests in some ways. I kinda like your second app, but if you're not willing to put the effort into writing that second app with the forms and all that kind of stuff, this is the approach I'm going to use from now on. I'm going to be doing. Yeah, just, and we can, I want to discuss other ideas building on top of this, but already. I just, I feel silly for not realizing this was a thing. And now I'm so happy that this is a thing I'm going to go test all my URLs. Cause I promise I have not been testing them very thoroughly and make sure everything's working. [00:18:07] James: Correct. I mean, this makes sense that this would be built in because I I'm wondering on Android, there's gotta be something on ADB that allows you to do. Probably something that we can do everything at this very, we can conquer the world. That's true. Truth, David. Um, it makes sense that, that there would be something built in because obviously I often look of how, you know, how, how do you even launch a simulator? How do you debug a thing? Like I'm assuming X code and visual studio for Mac and other ideas, or just using a bunch of these X code automation things. Because when you install X. And you install a visual city for maca. You need to go open excode and you need to install the command line tools. You have to have them. And if you don't, it gets. [00:18:51] Frank: Yeah. Very mad at you. Yeah. Um, I, I don't know all the internal details of anything, but, um, the last time I looked at, they definitely were using all these tools and it's really powerful for developer developers to, um, you know, I, I can never remember the exact incantation, but you can definitely look it up on Google, how to run the simulator from the command. It's not hard. You just have to know the XC, run some control, command pointed at your app and it'll launch the simulator. Why would you ever want to do that outside the IDE? It's rare, but it comes up for me. I just, you know, I don't want to deal with the ID right now, or I don't want to even chance the idea of it rebuilding the app or something, or maybe I have an archived version of the app. I want to try running that one. You can just point it. The.app and do that. So yeah, you nailed it. I'm pretty sure a pretty, all the tools out there are just calling out to XC run at some point. And that includes to deploy your app, uh, to the simulator. Start the simulator up, pick the right, um, device on the simulator. These are all command line arguments to these XC runs, SIM control tools. So. [00:20:03] James: Yeah. In fact, you know, I'm pretty sure that when the very first previews of Don and Mallory were coming out and still to this day, you know, if you just, if you just run the app and you say, oh, the iOS app, you say, run the app. I think it just will pick whatever default, you know, simulators, there tries to be smart about it, but you can pass it the grid. So every, every simulator has a grid basically associated. And you can pass some additional information into it, to like, say, Hey, target this one, but I'm pretty sure that in the documentation they gave you a, one of these XC, whatever commands to use inquiry, you know, you got a query it because like, how do you think visual studio populates a list of the simulators? It's a magically knows it's calling one of these API APIs, which is very. [00:20:50] Frank: Yeah. Yeah. Uh, wow. So, um, I'm starting to, you brought up ADB, which is the Android debugger. Um, but it's so much more than an ad. It's a device manager. Uh, you're making me realize they're basically the same thing at this point. So we got to learn two sets of command line tools, but it's super powerful. I feel like I'm even forgetting things you have deploying. I'm pretty sure you can deploy the devices and all that signing is still. I think he's still used like the code sign tool instead of all of this. But man, this is going to save me a lot of time. Just being able to open URLs, especially because this opens the gateway to a lot of other potential things. I'm going to say unit testing, but please understand I'm a terrible unit tester and I don't do good UI tests. I tend to do manual tests for all that kind of stuff. But even with manual tests, wouldn't it be nice to have a bunch of deep linked URLs that I cycle through? I could have a tiny little bash script or something, or even a little C-sharp script that just calls out to this XC run SIM control register a bunch of either deep link or API APIs or things like that. That I want my app to accept and start to automate the simulator. Bring up this. Have it bring up that part of my app. You could even go really crazy and, um, passing some URL parameters and tell it like where to report the results to. So open up a little TCP port and then start running this and have it start posting results back. And you have a very clever way. Very simple way, very elegant way. I think it's not hacky at all to start. Automating act, uh, uh, bringing up different parts of your UI, calling into different functional parts and even getting some data back. If you just pass to those URLs, how it should, um, what it should connect to or whatever, to send data back to you. So my mind's just kind of racing of just what are all of the different automations I can do by, uh, using these URLs. [00:22:55] James: So can you, you call a URL. Scheme, how does it, how does it pass data back to your app? [00:23:00] Frank: There's no good way. So there, there's no way in the API for the past data back. As far as I understand the Apotex full control, it's a UI app. It's now waiting for user input, but what you could do is pass a query argument with a URL to your store. And, uh, when, whenever the app's done doing its thing, computing, whatever results you want, it can just HDP post to that. You know, it's, it's the classic. How do you get data off of iOS? The easiest way is usually just post to an HTTP server somewhere. So, um, create like a little app that has an HTTP listener. Um, Open a port than, uh, use the process object to call out to ECC runs and control, open URL booted and give it your URL. Pass the query of your port of your server. And then the app can post. To that server. I, it, it sounds, I know it sounds a little bit like a Rube Goldberg device, but I've done way worse than that. That is actually pretty darn elegant for automatically opening a bit of your app and getting some data out of it. Obviously you can do unit test frameworks they're out there and all that, but for the manual testers like me, I'm kind of loving this idea because [00:24:20] James: I'm pretty sure that. You know, actual UI automation, things probably use something similar to that, right? Like they actually have to inject some sort of server that is listening and communicating back and executing. [00:24:33] Frank: Yeah. It's it's, it's how to get data off of iOS 1 0 1. You always have to put up some little server like that. You're making me actually really curious. I wonder if any of those automation commands are in here? I don't know how to the automation API works cause that one's very sophisticated where you can say like hover over a button, press a button and that kind of stuff. That's proper testing everyone. If you've got the time, go do that. Um, I've supported apps for 10 years and. By far regressions are your biggest concern. No other bug matters other than regression bugs. So you can deal with anything else, really trivially. Uh, and if you have UI tests that makes regression bugs so much easier to deal with that said, I never write you this, do you, James? I, I should, I should. I should. [00:25:21] James: I should. Um, I don't, I. Manual testing. And that's sort of my jam in general. I have in the past probably functional testing probably makes the most sense. I think if I'm doing web stuff, there's a lot of really powerful web frameworks, like, like playwright and selenium and a few other ones out there that really make it easy to just kind of like run the recorder and bop around and do stuff as a full-time job. You know what I mean? It's not necessarily a full-time job, but it's full time job to get it up and running. And then it's a full-time job. [00:25:53] Frank: You're definitely writing the app twice, which is fine. Um, because we've made this argument before your time on an app is not how long it takes you to type the code. It just isn't that almost has nothing to do with it. So it's okay to have twice that amount of time. The question is, can you keep it up? Can you keep doing that? Are you willing to devote that level of quality to it? Me, um, and also my UIs tend to be harder to, um, Automation test. They, they, so I have like a lot of multi-touch events, you know, you gotta use fingers and you got to select this and then use a finger over here and do this and then drag this over there. And those are just a little bit tricky to UI test. Whereas I know a bunch of little manual tests. So when. What I've done in the past and what I'm definitely going to do more of now that I know how easy it is to bring up these URLs is just have those deep links into the app. So I can get straight to the thing that I want to test out to make sure I haven't regressed on that. And then, you know, document these things and, uh, maybe users can use them in a, a weird shortcut script or something like that. [00:27:00] James: Yeah, totally. I think that the thing with, with testing is that, is that yeah, you have. Think about that a little bit when you're building the application and going around it. Um, I, I think that it's always best to think about automation and testing of just major flows. So you're not rewriting your app multiple times. Like that's definitely problematic, uh, because you really want to. You know, you only want to maybe automate the major flows, like, Hey, does my sign in thing work or does this other thing work? Or, you know, I mean, so I think those are the hardest parts of it in general. So it's trying to figure out what's the balance between the two. Um, yeah. [00:27:42] Frank: Yeah. So. And those won't help you with the API version of these URLs either because those are UI tests and you can definitely write unit tests. I, I, everyone, I do unit test my code. I just don't UI test my code. Um, Unit tests are great for testing the API side, but you always have that one little last bit that never gets test, which is the app delegate open URL. You know, that nasty function. That's just every code base I've ever seen in my life has the most nasty open URL. And it's, it's partly Apple's fault because that function does so many different things and the app delegate, but that. It's always spaghetti code. Every app I've seen that bit is spaghetti code and it's good to get that really thoroughly tested. Oh, I should just speak for myself. Every app I've ever written that spaghetti code in that. [00:28:33] James: There you go. Yeah, actually mine does too. So don't worry. It's not just you Frank. It's not just you. Yeah. Yeah. I think these things are super harmful and that's how I would like to talk about them. And sometimes, you know, we've done 282 podcasts, so sometimes we retouch on a topic that we touched on before and that's okay. I think because we're always learning. I think that's the best part of being a developer is that you're always learning something new. Even if you read a blog post from, you know, 20 years ago, did you ever send me this blog post? There it is. Yeah, got it. I'll put it in the show notes [00:29:02] Frank: 10 years, man. Like these URLs have been around forever. I've been doing iOS development for forever and today I learned about this. So knowing, so I just wanted to make sure everyone knows there's a way to open URLs from the command line. [00:29:15] James: Yes. I can't believe we didn't know this. That's so good. Oh my goodness. Yeah. I liked this blog post because I don't know whoever wrote it, but they're like, you could go to a browser and type it in manually or. Run this command. Right. And then just copy and paste it in. That's a smart, so smart. Uh, I love these little, like little code hacks, you know? [00:29:36] Frank: Yeah. I'm just going to have. That's a script called test a bunch dot S H and it's going to be open URL, sleep, open URL, sleep, open yard sleep, and it's gonna be amazing. I'm going to love it. And it's going to auto test my app. [00:29:50] James: All right, well, that's going to wrap up this week's merge conflict. It's a nice short one this week. Cause we are on the run. Well, not really, but I'm going to go hop in a car and then go drive. So anyways, um, Frank, actually, I'm going to write, I'm going to do a video on this. I want to get back. Cause I think this is really. I think I'm going to do one of those YouTube shorts. That's what I've got YouTube short [00:30:09] Frank: people do like those short videos. How short your short [00:30:12] James: video? Well, they can only be up to 60 seconds, so, whoa, that's real short. Yeah. They're real short. The default is 15 seconds technically on YouTube, but you can just, YouTube trolls are kind of interesting because all you need is a portrait mode square or a portrait, as long as it's the, as long as. The height is equal or greater than the width, then you're totally good to make it a short and it has to be under 60 seconds. Uh, so I'm going to be doing one every week of just new C-sharp features, just like, and here it is here, it is in here. Nice and short, and then to compliment my existing long form content, but, you know, Take talks and the snap who's and the what's and all this stuff. They're all the same at the end of the day. [00:30:53] Frank: They're all the 60 seconds. If you can't make your point in 60 seconds, that's just not, [00:30:58] James: I guess, apparently I am. I did one on file, escape, scope. Namespaces and I thought that was pretty good. So, uh, I'll do it on this though. Cause I think this is, this would make a perfect. Video short thing. Yeah. [00:31:12] Frank: So everyone will be happy. You did it. So I will be. [00:31:16] James: Yeah. All right, man. Well, have a great week wherever you're at in the world. It is almost December. Oh my goodness. That is crazy. It's almost 20, 22. Um, but I hope everyone had a great holiday. If you're hearing in the states, if you're not here in the states, I would just have a great weekend. And then you have a great week going forward and we'll talk to you next week. So until next time I'm James Monson. And I'm [00:31:37] Frank: Frank Krueger. Thanks for listening.