But we're all going to really have to get used to everybody here. And maybe in the middle, maybe we'll have a break and we'll all stand up for something. But this talk is very easy. I don't have to keep a certain set of slides, or I don't have to stay on script or anything like that, because the whole point of this talk is just to go through all the desired capabilities for Africa. And I think we mentioned, some people mentioned that before this, no one knew how many there were, because nobody had made a list of all of them in one place before. So I said, okay, I'll do this talk with all the desired capabilities. And so I have to first, I have to figure out what are all the desired capabilities. And then I started telling everybody what I found. Some of the Appium Pro articles that I published in the last couple of months were just like, hey, I was writing this talk and I found a desired capability that nobody remembers, but it turns out it's really useful. So here you go. This, I guess, quick intro of myself. I'm Jonah. That's my GitHub picture from a long time ago, but I can't change it now, because then people won't recognize me. But you can also see how the styles have changed over time. Circle pictures are in. But that's even, that's probably a little bit old. So maybe we'll go back to squares next, or maybe we can have like hexagon photos. Anyway, I also want this talk to be kind of interactive. So if I need a view of anything, we'll get there in a second. So basically, the whole part of desired capabilities is that there's all these times when someone has a problem with their Appium script, something is breaking, they can't find an element, they can't tap an element, or the app just hangs, or the session never starts, so the driver doesn't work. And all the time, if you look on the Appium Discuss Forum, sometimes the answer is just use this desired capability. That's it. And so it really helps to know what all the desired capabilities are. And I don't think you should memorize them. I have not memorized them. Maybe today we'll find out that some of them I don't even know what they do. I tried to study, but you know. But I think it's very helpful to have heard of all of them. So that one day you're going to be having some problem with your script and you'll try everything and it won't work. And then you'll think like, oh, wasn't there like a desired capability, something related to the Wi-Fi or something. And then now you'll be able to go, you'll kind of, you'll have heard it here today. And so that'll remind you about it. And then you can go to the documentation and look up there. So as also part of this talk, I didn't spend any time on the slides, but because I was building this site, it's a new documentation site for the desired capabilities. So you can go here right now. I think the, and you can follow along in today's talk, because all I'm going to do is going to use that documentation site and we're going to go through all the desired capabilities. So let's look at them. So exiting from the PowerPoint. This is the site. Here we go. I am not a designer. This is after several people helped me out. But we do have all the desired capabilities. These are all of them. The green ones are our Android and the silver ones are iOS. And the yellow ones are all of them. And there's a couple of special ones that are only iOS and it's a nice crossfade here. I'm pretty part of that. So, but the useful things we added the, all these, so each of these capabilities, right? Here's all the information about it. And we have what drivers can it be used on? What are the valid values you can use? Or sometimes it includes example values. And then hopefully a description. Now, the descriptions, a lot of these I just took from our current documentation. Sometimes it was pretty not really that good at documenting. And some of them I rewrote for this presentation. And others, special ones, I didn't really know what they did. They just kind of improved the grammar a little bit or the spelling. But the whole thing here is actually backed by an error table spreadsheet. How do I switch tabs? So the entire Appium team and everybody online can help out from now on. Because this spreadsheet just automatically converts into this site and it reloads every five minutes. So this is really cool because it's almost like live documentation, oh boy. So I actually have a slightly, so we also have here, you can filter by your platforms. So if you only care about Android, now you only have the Android ones. If you only care about iOS, you only get that there. And then I also added a bunch of tagging. These tags didn't exist before. This part was actually really exciting because I was like, all this design capability, how many of them are just logging? So here we have all the Android logs. Here's all the logs, right? So these all control various logging things. Maybe we have timeouts. Here's all the timeouts. And so we can use these to sort of like get an idea for which ones there are and which ones there aren't. I also added what I call like levels. Some of these design capabilities you need to know in order to do good Appium testing. You'll need some of these on your first day. And others you will hopefully never use. So I kind of had this beginner, intermediate, advanced. And that's also the order it's sorted in. So if you want to learn all the design capabilities, I would pick your platform. And then I would just start from the top and sort of go down and familiarize yourself with them. So I made a slightly modified version of this. I made a slightly modified version of the site that I'm hosting locally. This just added these X's here where I can remove it from the list. So every time we go through one today, I'll remove it from the list and we'll see how far we get. Also, some of you might be a little bit bored. It's very long and there's many. You can tune out and tune back in when you get here. But I also create a worksheet to keep you busy. So if you can test these out. It's not enough for all of you. So you might have to share. But just for those of you who really need something to do, then this will keep you going. You don't have to take it a long. I haven't seen one of these in so long. It wasn't since I was in school. You'll see in the back where it comes to.  If any of the first person to complete it, you bring it to me and I'll check it and then you get a price. Okay, so now we can do the actual desired capabilities. So maybe we'll go through some of them really fast. I don't want to go all really slow. If we talk about anyone and you have any question about that desired capability or also if you have a story about that desired capability, maybe this one saved you one time or maybe one time you spent a whole day in a bug or a whole week in a bug and then this one fixed it or maybe this one that you hate and you can't figure it out and always just seems random. Bring it up. I want to hear desired capability stories. I'll just get started a little bit. We've got automation name that is picking your driver. There's even a little nice table here. On iOS, you've got XCY test. That's the one we like nowadays. You've got UI Automator 2. That's what we like. But for Android, there's UI Automator 1. There's Cylindroid. There's Espresso. On iOS, you can use the old instruments. So automation name is the way you pick your driver. If we could rename this, we would probably rename it like driver name, but it's automation name. That's what it is. So any questions on automation name? No? Any stories? No? Boom. That's it. That's our first desired capability. Great. Platform name. That one we should all know. There's a couple of the other ones. There's the Tizen driver. There's the Mac driver. There's the Window driver. So that can be your platform name, too. And this is common in all of them. And this one's required. And if you also notice I have fake here, there's actually a driver called the fake driver. The Appium developers use it for testing. So it's a driver that doesn't control anything. It just pretends to do the commands. But that's a driver, so it's included. Any questions on platform name? Yeah? All right. Here for that one, that's the version of the device that you're testing and the version of the coincidence system on the device that you're testing, Appium is a lot about versions. There's the version of Appium, that version of your client, the version of your computer that you're running on, the version of Node, the version of the device that you are on and the version of the app on the device that you are on. And I don't know, the more you spend time with Appium the time. Oh, there's also the Xcode version Android, you know, SDK version, so the more time you spend on Anthony and Maria with versions, so... Platinum version, yeah, very good. Anything else? No? Boom. Hi, Rory, like, look at this. 3 out of 180. It's pretty good so far, yeah. We're really starting to get in the role here. We've got device name, right? There we go, like iPhone similar, iPad similar. This one's kind of wonky, because this one's always like just picking sort of based on the name. And oftentimes, I don't really know where it gets that name from. It can sometimes be random. On iPhone, it's like the name of the simulator. And real devices, I don't even think it works that well. But for real devices, of course, you would use UDID, right? And that's where you can pick the actual ID of the device. And that one's really great, but it's never like, if I was running in cloud or something, I'd use that one. But when you're running on just, like, locally, you just want to pick the first one by default. That's fine. There's also the AVD. This one's Android only. That's where you're selecting the name of the AVD, of the emulator that you want to launch. And you can set that name, too, in the AVD manager. So that's a nice one there. Browser name, we're just getting all of these ones out of the way here. It's Phi Chrome Chromium. That's like, if you're automating the browser. And also, if you select browser name, then Appium is going to automatically go into the first web view available when it boots up the driver. Otherwise, for example, if you just started the Chrome app, instead of using browser name and you used bundle ID or app name, then you would be in the app. And you'd have to use set context to get into the web view. But if you put browser name, it starts the browser for you. And then it also goes straight into the web view. And there's also a desired capability for deciding whether or not you want that. That comes later. We got the app. And that's the app that you're uploading, the one that you're putting in. It can also, so there's a little trick here. You can put the URL of an app instead of just the path to your app. So it'll just download a random app off the internet. We use that for our example code in Appium Pro all the time just so that you don't have to already have the file. All right, yeah. OK, so that, we got rid of, those are all like the basic ones you see in every single test pretty much. Now we start getting a little bit more into stuff that goes on. So I might just pick here the beginner ones only. And so looks like we've got a bunch to work through here. New command timeout. I love this one. Everybody hates this one? This is like, I really don't know whether or not to decide whether or not this should be in it or not. Because the new command timeout is basically how long that Appium will sit there and wait for your next command before deciding that you've completely given up and you're switching jobs. And so it'll just sit there. And this is now very useful because a lot of the times your test script will crash. And so now you're waiting. And so Appium, if it just keeps going, if you're using a cloud device, it's going to waste your money. And if you're not using a cloud device, it's going to waste your time. And it's going to be confusing. And you won't know why the session's there or the session's not there and why is my phone not being used because you can't start a new session because it's already using the phone. So new client's good for that. But other times, the new command timeout, if it's set, let's see the default here it says is 60. So it's pretty long. But still, it happens to people that sometimes they have a command that takes 60 seconds. Or maybe some other part of your test script decided to load a file for 65 seconds while before the next command, suddenly your script crashes. What I've also noticed a lot of is let's say in the middle of your test, let's say the remote debugger for Safari breaks. So in your Appium logs, it'll look like some other bug happened or it just hangs. And if you go up 100 lines in the logs, you'll see new command timeout was hit, canceling session. And that happens all the time. So people will report their bug. I don't know what's happening. The logs don't show anything. But really, five minutes ago, Appium closed your session. And it's just a couple other things still happening. Oh, I also like new command timeout. You can set it to 0. And then it just waits forever. And I like that when I am programming locally in a REPL, I can just be typing some commands and then getting a copy and then type some more commands and write a test script and like that. So it always keeps it running for me. Anybody have anything to say about new command timeout? No? I've talked a lot. What's one of your favorite design capabilities? You can pick one from this list. You just want to be around. But no resets. Oh, man. So yeah, that's good. OK, so specifically for the reset ones, I made a tag here called session lifecycle. And session lifecycle, I tried to find all the desired capabilities that did something related to something it should do before your app runs the test or something it should do after the app runs the test. So this would be good to go through. So there's a couple here. So let's do it. We've got no reset. So don't reset app state before and after this session. More details here at this other file. That will talk a lot about it. It just confuses you. So no reset means don't do anything. But the default value is false. So by default, it does some reset. And no reset would be if you want it so that after the test runs, it leaves the app even like still sitting there. And that can be useful sometimes if you want to debug something else after that or maybe catch some debug information if your test failed or something. Or maybe if there's just a lot of startup time, you don't have to worry about it. So that's no reset.  After. Not before. All right, so for more details, see here. And so that's what's that. Do you have anything? We'll do more of the resets. But any more in that closure? Is that pretty good? Yeah? So notice that also full resets also false by default. So the default is it does something in between these two. I'll leave them there for a second because we might have to go back now. Don't stop at one reset. So this doesn't stop the process of the app on a test before starting the app using ADB. So if the app on a test is created by some other app and you set this to false, allows the process of the anchor app to still be alive during the start of the test app using ADBs. So if don't stop app on a reset is true, Ampium will not include, oh, that just talks about how Appium is actually starting this because all of these things actually involve the ADB command that Appium uses. So it's saying that this is similar to including the dash s command. And so the best thing to do for that, if you're confused by, would be to go to the Appium ADB, the Android ADB documentation, and read about what an ADB shell AM start what dash s does there. So I'm just going to run that. Boom. We've got auto grant permissions. That one's great. You'll automatically give permissions that your app needs. I think it does this. This is Android only if you notice. So I think it does this by reading your manifest file. So it'll give it. But if no reset capability is true, this capability doesn't work. So you have to pick what you want. We have skip unlock. And this just skips unlocking device when the session starts. And that is a great way. I think it was in the workshop that Siam Srini did that that's a good way to speed up your test because the actual unlocking is like uploading a special app. And then it has to like check, look for the lock screen and a couple of things like that. So if I skip unlock, if you set it to true, because the default is false, then you can speed up all of your Android tests a little bit. That's why I also gave it a increased test speed tag. And we can look at those later. Yeah, yeah. We have clear device logs on start. This was useful. It was in, I mentioned, Appium Pro article. So when the device starts, then Android, you have like the logcat logs. And if you are trying to get those logs, there's a command that's like get logs. And if you get those logs in the middle of your test, the logs are going to start with whenever the phone was turned on. So you're going to get like tons of logs, especially if this phone just ran 100 tests before yours. But if you do clear device logs on start, then when as soon as Appium starts your app and the session starts, then it truncates the logs there. So when you do get logs, you only get the logs that are relevant to your test. So like that's a great one. I would thumbs up that one. Reset on session start only. So, the docs here. Reset on session start only. Whether to perform a reset, what a session ends. So when set to true, a reset is not performed. Keeping this variable set to true and simulator running, oh, because this is on iOS, you can significantly shorten the duration of the test session initialization. So, yeah, reset on session start only. Yeah, so I guess that means if you have a simulator already running and you set this to true, it's just going to use that simulator. But the defaults, and that's the default actually. So I have no idea why you'd ever set this to false, but maybe if you wanted each time test run to have a brand new simulator come up, then you could set this to true. No sign, this is an Android, and it skipped signing your app with the debug keys because an Android actually like it will take your app and it will re-sign it with special keys that Appium has. So again, you want to like go through your process even faster or you have some issue with your signing. You can just set this and it'll skip that. That's probably a good way to make it faster. Skip device initialization Android. Oh, right, yeah, yeah, when you turn on. So by default, Appium will often like bring up the settings app and right before your test runs and it'll try to like give you a couple permissions and things like that. And so it might also like do the unlock stuff like that. So this just skips that. Again, you can just get some faster tests. Skip server installation. So, you know, the way Appium works, right? It's installing a special server onto the device and the server is running and your app is running and Appium talks to the server and the server controls your app. Is that clear? So every single time you run a test, it has to install that server and then it has to run the server and then it waits until can I talk to the server? Can I talk to the server? Can I talk to the server? Oh, there, server is spotted. Okay, session starts. And then at the end it like kills that. So if you set this one to true, then if you just ran an Android test and you now run another one again, it'll use that same server. It's okay if the, and so that actually speeds up UI Automator 2 tests by a lot like 30 to 60, even to 90 seconds.    Yeah, so this is on iOS now. So when it's set to true, then when it, what is it? Is it okay if it's set to true? It can device on a test on iOS 7? Apple, right. So Appian will just shut down all the other simulators except for the one that it's running the test on. And so if you were let's say running multiple concurrent simulators because you were running like multiple Appian tests concurrently on your machine, this would really mess you up if it was set to false. So you'd wanna set that to true if you're doing concurrent stuff. It used to be that actually the iOS simulator is only you can run one at a time, but it was really awesome when they let us have multiple. Any questions on that one? Okay. Clear system files. This is an iOS and Android.  So that's nice because it's kind of like most of the time every single time you have your test run you kind of want to have a fresh, the same environment. So this is just cleaning up stuff. But sometimes people are like, I want to have those things there so I can grab them later. And like if it was a failed test, like check what was there. Maybe they're like, oh, I want the user to have already like done stuff before. Like I want it to remember that I clicked okay on some button in the beginning. Took me through like my sign up flow or something. So default this is false actually. So, which is actually kind of odd. But you can set to true to clear more system files. Forced espresso rebuild for espresso only, obviously. If set to true, then a fresh espresso server AKK will be built. A lot of the desired capabilities like this. Sometimes this can be used to fix problems with starting a session. Doesn't say what problems. And that's like kind of case. If you ever like really curious like, so through this talk, I've gotten really good at figuring out like what a design capability does if no one knows and the documentation doesn't look good. The first thing I do is look at the code. But the other great thing to do is you go into GitHub and you go into the Appium like organization. And then you just search this and it'll give you all of the GitHub issues where the desired capability was mentioned. And so you always find the one where somebody had some problem. And then one of the app developers said, okay, we'll fix your problem with this new desired capability. And you're like, that's what it's for. Yeah? What? All right, there's one that was added last night. Was it, it's not published yet. You want me to add it? Okay, okay. We'll put it in. Okay. So what is it? What's the name of it? And which driver was it added to? So is it in the base? Like what actual code is it in the base driver? So that's how this knows like if it's iOS or Android or anything. And so what does it do? What would be your, what specific functionalities? Is this gonna help us in a week? Yeah. And what would be an example value? And what would be all the possible values? Okay, okay. That's good, because we need to know that what people can add. This is also an important part to see if we don't, if you don't add it on the day that the person adds it, then it'll be lost forever. No one will know, except yeah. And the negative ones, the negative flags are always like really tricky. But I am just recording, I'm just the documenter. I have not decided here. Would you say this is an advanced feature, an intermediate feature, advanced? And I wonder if I have a security tag. I can, well, do we want a security tag? Now we have one. Okay, I'll put draft here just because I don't know what that does if I don't. All right, what was the other one we have? I can guess what that was. URL, capital U, lowercase RL. And the D in Chrome drivers, that up. Okay, okay, great, great, great. And that's in the, I'm guessing that's in the Android driver. And I'm guessing supply a URL, which buy a URL for a executable file, which Appian will download and then use if clickable to your session. Yeah, cool. An example value would be like HTTP colon double slash size URL sum.url, cool. And would you say that's advanced, intermediate? Could be intermediate, man. Yeah, because people have to use it. Yeah, it's pretty common to get into that. And I have a bunch of tags for a Chrome driver related stuff. Chrome driver, I've got web. This is also related to web view. Cool, okay, wait, wait, wait. We're almost done with the lifecycle ones here. So we've got to keep keychains. This is iOS only. Whether to keep the similar keychains when after a full reset, the value is false. So even a full reset will not keep the keychains because it's a full reset. But if you set this to true, it'll be a full reset, but keep your keychains. Wait for App Script. This is the iOS Automation Script used to determine if app has been launched. So normally the system waits for the page source to not be empty. So when it starts your app, it tries to get the page source as soon as it gets it now it has that. And, or you can just pass in literally code that will run and as soon as that code returns true then the session starts. But notice not supported by XCUI test driver. This is just for the old instruments driver. Other apps, this is crazy. So for Android, you can add other apps that you want it to install before your test starts. Just for whatever reason, maybe your app has some companion app and you want that to be there or maybe there's just something else you want to have there. Maybe you're testing deep linking and you want to make sure that the other app you're deep linking into is there. There it is, yeah. Use new WDA. So now we're in iOS LAN. I'm gonna save that one for later actually. So keychains exclude patterns. Right, so before we saw that you could keep the keychains. Here, if we want, this can, you can define basically like a regular expression for which keychains are not restored when you have a full reset. So if let's say for somebody, obviously, whoever we added the other keychain capability for also then came back later and said, actually I want to be able to delete some of the keychains and not the rest. And so we had to add this for them. Cool, all right, 26 out of 180. It's like a little bit over a fifth way there. You can see the, yeah, we're getting somewhere. All right, anybody else favorite design capability? No stories yet? Who's your favorite one? Pop-ups, so I also made this nice search here. Safari allow pop-ups, that one? Yeah, so yeah, allow JavaScript to open new windows in Safari. Do you know anything about this one? Oh, you meant a different one? Yes, Safari pop-ups, yeah. Is this not the one you meant? Oh my gosh, you wanted to say, okay, yeah, all right. Let us figure out, Safari allow pop-ups. Yeah, I did, I did, this is good, this is good. This will be funny, because we'll really dig into it. That's what you wanted. So notice first of all, we have not supported on real devices, maybe we'll find out why. We all know that iOS is kind of strange about pop-ups, right, or any alert or anything like that. Sometimes you can get them, sometimes you can't. That is actually a bug in XCOI test itself. So we try to do things about it, sometimes we can, sometimes we can't. So allow JavaScript to open new windows in Safari. Yeah, so this would be like, normally a web app would not allow this behavior, because it'd be very insecure if I could put an ad on your page and that whenever your mouse just went over my ad, suddenly I could open a new window in your browser. So basically I guess the thing that normally Safari will not allow JavaScript code to open a new window. Normally you have to click on a link for that to happen. But if you want to, we can like really take a look at what's going on there. So what I would normally do if I'm trying to figure out like where desired capability comes from is I would go to my repository. So I happen to have all of the Appium, I have all of the Appium projects here. So this is all of Appium in one place, basically. And I would just search something like the exact desired capability. So it'd be like, Safari allow popups and it's just gonna search recursively. And so I'm looking and I'm like, okay. We've got, it's in the iOS driver, but we're just like, oh this is a test. So I usually just don't care about those. This is just saying declaring the desired capability. All the desired capabilities are declared in these desired caps.js files in each of the drivers. That way if you try to use the desired capability that the driver doesn't support, it'll like warn you in the logs like using unsupported unrecognized desired capability. So the way it recognizes them is we've hard-coded them all into those start caps.js files. Yeah, this looks pretty good like Safari allow popups. Yeah, okay.  And then we've got the XCOI test driver and that's a test and that's a test and that's a test. And then this is more documentation. And it's also in the Windows driver, which seems wrong. So that's that. Well, the best place that we have to look like looks like in the settings.js there of FBM iOS driver. Atom, FBM iOS driver. So we open editor, avoid. And I'm gonna search it again here. And so, what's that here? All right. So set, it looks like, so if you set it, we log a debug line that says setting JavaScript window opening two, and so that's just saying we're setting it. And then we have Safari settings that WebKit JavaScript can open windows automatically equals to a false web you put in. And Safari settings that JavaScript can open windows automatically equals to a false. So that, I'm wondering if that's like something that exists outside of Appium now, right? Cause in the end, everything you get outside of Appium at some point or another. So if I just go to a web browser somewhere, wait, where was my, oh here. If we just search this, let's see what we get. Yeah, so this is part of Safari. Determine the state of a menu. I'm sure that's a type of a state. Here we go, we have documentation for Safari. So allow pop-up windows. So it looks like literally this is just something that's built into Safari that it has these two commands that you can set to a false. And when it's true, it allows pop-up windows and when false, they're not allowed. And if you're seeing inconsistent behavior with your pop-up, then this would be the place to start digging in where you're just like, maybe it's a bug in Safari, maybe not. There's other times where you can have your app and you can have something that looks like a pop-up, but really it's just JavaScript putting a nice square in front of the screen, but you didn't really have a pop-up, so. Does that answer the question now? Yeah, all right, pretty good. That was a nice deep dive. Now 27 out of 180. So yes. Oh yeah. Right, so this would only be supported by the instruments automation. So basically, hopefully no one's still using that, so it's basically irrelevant. At a certain point, we'll probably deprecate those older drivers and then this one will just disappear. Still confused. If there isn't one for XUI test, I see. Oh, and you want to auto accept alerts. I think the reason we probably don't have that for XUI test is because as we've noticed, sometimes XUI tests literally just cannot access the alert, but if that was the case, we should probably do something like just do a tap on the screen where the alert would be, right, something like that. So yeah, I'd file a feature request. Yeah, thanks, that's a good one. But if you set this to true, it'll automatically try to accept the alerts. I think there's also a, isn't there also a auto dismiss alerts? That's the opposite, it'll just do. Every alert in iOS has a positive thing and negative thing, so accept, takes the positive one and dismiss, we'll take the negative one. Where'd it go? Now we're at 29. Anybody else have anybody? Otherwise just keep start going through the list. Would you rather focus just on Android or just on iOS, or would you rather, should we do all the easy ones, go from beginner, intermediate, advanced, or would you rather we start from advanced and then forget about the easy ones? Advanced, advanced, I'm hanging on to advanced, okay. So let's do the advanced ones. Also if you think it's not advanced, you can tell me and then we'll, I can just change the tags. Localizable strings directory, yeah. So for, I also by the way have an internationalization tag, that one's pretty good for all the different ways, you can deal with different languages and different locales. So iOS apps, they have their like strings, you know it's the same as in Android too, where they have a bunch of files that hold all the strings for your app. And you can have one file for each different locale or language. And then depending on what the user of the phone has set, it picks that file for all the strings, all the words that appear in your app. So for some reason, you might want to tell Appium that you want it to get those strings from some other file, like not the normal place where it would be in your app. I have no idea why, but maybe you want to test a translation that hasn't been built into the app yet, or maybe you want to say like, I don't care what the locale is, I'm just gonna have the same set of strings here. I'm really not sure, but it exists and so we have it. Oh, but it's not supporting the XCY test driver, so it's pretty much relevant. App weight duration. This goes along with app weight activity, but basically it's just one of our timeouts for how long we wait for the app weight activity to launch. So this has to do with, when you're first starting out your test in Android, and you can set a special activity that's waiting for before it says that okay, you're ready to automate, so you can set how long you want it to wait. All of the timeouts are things that like, we've set them to values that should work for most people, but we keep it in there because every now and then someone has a case where it doesn't. Sometimes it's because the phone itself is too slow or too fast, other times maybe it's newer or older, and other times it's your app is taking too long to do something or is too quick at something. Android coverage, yeah, this one's kind of interesting. You can do stuff to test like your code coverage. I would look at the documentation for Android for this, but if you look, it says in ADB you have a way of Android will catch all the code coverage for your app while you run your test. Afterwards it gives you this code coverage file and you can like check over which parts of your app or cover, which you know, code paths of your app are covered by your Appium test. It's pretty cool. Android coverage end intent. This is how you can tell the system. This is like you can specify a specific Android intent that tells the system when it should give you that coverage information. Android install path. Yeah, this is when Android, when Appium is installing your app on the device, it picks like where on the device it should install the actual physical file. Because first what you have to do is you have to do ADB push and that just puts the APK file on the device. Then you do like ADB install and it'll install it and you know, it puts it into your apps directory and it appears on your home screen and all that. So this would just be for some reason like our default value should be fine. It puts it in data local temp, but maybe for some reason you want Appium to upload all of your apps to a specific directory. Maybe you want them all to end up on your SD card on your physical device, something like that. So it'll put them there. Why? I'm not sure, that's just how Appium does it. Yeah, that's a good question. That's right, that's right. Jonathan's saying that it used to be, for those of you who know that it used to be that if you just told ADB install, it would take a long time, but if you do ADB push and then install from local in device, it'd be faster. ADB has a lot of things that don't make sense sometimes and Appium works around. Right, right, right, right, right. Jonathan's also saying if you run multiple tests, you know, Appium automatically checks to see if the app is already installed. So if you have the app already installed on the device from the beginning and you haven't cleared that out, then now when it installs, you don't have to take the time it takes to take your several megabyte app and push it over onto the device. Because if your app was like, you know, just half a gigabyte, it would still take like sometimes a minute to just put it onto the device. That was back in the day. If it, this is why, yeah. This is like a good house cleaning here. ADB port, yeah, yeah, you would be, it'd be pretty crazy to change this, but you can. People who do very specific things. So if you implemented your own ADB or maybe at one point Google had a super top secret, the Espresso team built their own version of ADB. That was 100 times faster and then they never released it to the public. But if you did have that, you could put it on a different port. Remote ADB host, that'd be the same. That'd be like, if your ADB server is actually like somewhere else, you can set an IP address for that. That's why these are under advanced. ADB exec timeout, that one seems actually pretty useful. Every time APM does one of the ADB commands, it has a timeout on that, right? Because if that hangs forever or let's say your device has been disconnected and ADB can't connect, then it'll timeout. So the default value looks like 20 seconds, but maybe for some reason you know that your phone is gonna take a really long time for this one ADB command, let's say pushing a big file, then you could change your ADB exec timeout and APM would wait longer. System port, yeah, this is the port. So like I said before, APM puts a special server, the UI Automator 2 server onto the phone, and then it talks to that. So this is, you could specify the port that they talk to each other on. I believe, it looks like, right, right. So UI Automator 2 and Espresso are actually pretty smart, where they'll just pick any open port. UI Automator 2 will pick a port from 8,200 to 8, 8,299, and then Espresso driver from 8,300 to 8,399, and you actually do need to use this when you're trying to run multiple tests in parallel, because for each one it's gonna have to be a different port. They pick them automatically, so you should be fine, but if you wanted to pick a specific port, that is how. Any questions so far, I'll just keep going. Wanna switch it up? Does anyone want to go to iOS? We've been doing Android for a while, or does the switching hurt your head? I was just going. Android Device Socket, DevTools Socket Name, man, needed only when app under test is a Chromium embedded browser. The socket is opened by the browser and Chrome driver connects to it. So this is only if your app is a browser, but not Chrome, and you're trying to connect to it, you can pick the socket. And that's why it's in advance, because I'm sure it's getting pretty in there, where you have a very specific kind of app, and you're trying to figure out why you can't connect. AVD Launch Timeout, that's pretty straightforward, it's just how long the app will wait before timing out while trying to launch one of your emulators. AVD Ready Timeout, so it's launched or still waiting for it to maybe for your emulator to boot and to go through spinning a bunch of Google stuff, and so that's just another timeout there. Uh, use key store?  If you look, the next three are all about key store. And actually, no, the next five are all about these Android key stores. So this all has to do, everything always gets confusing when it gets around to APKs and signing, but this is signing stuff here. So you use a special key store to sign your app. So this'll say, I wanna use these private keys to sign my app. This tells you where those keys are. The key can have a password on it. It can also have a name, and it also has the key itself. And notice there's actually, there's the key store, and the key store, once you've got through that password, you have the key itself that also has a password. So the signing stuff can be, who's been frustrated with signing stuff before? Nobody? You ever had a problem with signing? You're lucky. John, yeah, see? He knows. Chrome driver executable, which is not the same as the new one we just added, but this is if you're able to provide a local path to a Chrome driver executable file. You definitely, it's worth looking at these docs here that talk about why this is necessary. It's just that different versions of Android support different versions of the Chrome driver, so you always have to have some that match. Instead of just providing a single file, you can also, so Appium, finally, this became a big enough problem with the different versions of Chrome driver, and so we actually have inside of Appium, it has a special mapping, so Appium now internally has like for this version of Android, you can use these versions of Chrome driver, for this version of Android, you can use these versions of Chrome driver, and stuff like that, but maybe your version of Appium is old and we haven't updated that map to the latest stuff, so you can also provide a Chrome driver, a Chrome driver Chrome mapping file, and so that would be you give a file that says for this version of Android, I want to use this version of Chrome driver. We, like if you stay up to date on Appium, and please do, then we take care of that for you, but if you've fallen behind, now you have to take care of that yourself. And Chrome driver use system executable, this will just use the one that comes with Appium by default, if set to true, rather than using one that you install in your system. Chrome options, there's a bunch of random stuff that you can send into Chrome. There's a nice link here to the Chrome driver capabilities, basically there's extra options, you can send to Chrome, they do interesting things, it looks like there's even one to do disabled pop-up blocking which is related to the Safari one that we saw before. Recreate Chrome driver sessions, this one's weird, it's kind of like it's, so you know you can keep, basically Chrome driver is just like Appium, like it's also connecting, but instead of Appium connects to your phones and devices, Chrome driver connects to Chrome windows. So when you're running in a app that has web views, then when you say change context into the web view, now Appium uses Chrome driver and Chrome driver connects to that web view. If you now go back to your regular app native app context, the Chrome driver will actually keep the session going, so that when you go back into the context again, you can keep using that same session, because starting up that session takes a little bit of time, but sometimes for reasons nobody understands, the Chrome driver doesn't really like going back to that session. So if you have issues where you're going in and out of the context, and at one point in your test, suddenly the context can't connect anymore and Chrome driver isn't responding, then you could use this, set this to true, where every single time you go into the context, it'll start another Chrome driver session to connect specifically to that context. There's all over the place, Chrome driver args, this is different from the options, these are special arguments that can be passed to Chrome driver. Unicode keyboard, this enables the Univode keyboard. Reset keyboard, it puts it back after you enabled it. Disable Android Watchers, this one also came out in a Sai and Sweeney's workshop, but there's jobs that run in your Android phone that are always checking to see whether or not your app has crashed, and if your app has crashed, then they end the session and they give you an error, but that constant checking whether or not your app has crashed, that takes time, and so you can change this in order to disable that and then your app's gonna go faster, but you lose out on that chance to catch things when things go wrong. UI Automator 2 server launch timeout, that's just how long that app being will wait for that UI Automator server to come in, and it's got the same here, so it has to take that server and it has to install it, so we've got one timeout for that, and then the server has to start and it waits for it to connect, we have a timeout for that. Express the server launch timeout, same deal, but this time for Express. All right, we're doing pretty good. So if I want a, if I want a break or anything, are we doing good? How much time do we have? Okay, it's pretty good, we're about halfway through. We've done 58, that's actually pretty good. If we get to like 116, that's better than I expected. Native Instruments Lib, right, this is not for XC UI test driver, but if you were still using instruments, instruments back in the day had this issue where every single command we sent would take an extra second. So every single time you sent a command to Appium, and Appium sent it to iOS instruments and you're automating on your iOS, it would add a second between every command. This was especially frustrating when you were trying to do send keys because every single send one key would be, is actually one command. So if you did send keys like hello world, it would be like H, E, L, and that was taken forever. So somebody built a nice library called Instance Without Delay that sort of goes into the phone and changes and basically just removes the one second weight that we don't know why it was there. And so that's great, but it would also sometimes cause problems with people else apps or maybe the simulator would crash or something. So this is just a way of disabling the Instance Without Delay. Process arguments, again, this is only, oh no, this is for all of them. These are like environment variables that you can pass to your app. These is actually pretty convenient because a lot of the times you're doing some sort of testing and you have an app and you, let's say, want your app when you're testing to hit a specific backend server like your staging server or your development backend. And you don't want it to hit the production backend. So sometimes people build into their app different ways of setting the backend server with specific test server. I've seen a lot of manual testers will have a way where there's maybe like a secret gesture you can do when the app's starting and it brings up a menu to type it in. You don't even need a UI to do that. And so instead you could use these environment variables. So you'd have to have the developer of the app program this in that when the app starts it looks for these environment variables. But then it could just include those and connect to that server. And in that case, I would argue that you could even push that to your production app because it's not gonna bother the user experience and the worst that happens is somebody could maliciously try to run your app, find out what those parameters are and then oh no, they'd be able to access your like staging DB. So, but of course if you don't want that you can always not put that in. But that's just a really useful way of triggering specific test only things on your app. WebViewConnectViewTries again, this was ways of trying to figure out how to better connect to Chrome or WebViews in general. Safari is also tricky as Chrome can be. So sometimes the Safari like debug bridge just can't connect to a Safari view. So AppView will just keep on trying and this is the number of times that's gonna try. It looks like the default is eight, which is pretty, which is a lot. AppName, this is the name of the application under test. And it's only needed for backgrounding apps in iOS 9 or more on the old instance driver. So pretty much you already know about that. Custom SSL certificate. This is if you want to install a specific SSL certificate into your iOS simulator. Doesn't work in real devices. And this can be useful for when you're running a man in the middle proxy to capture network traffic during your test. And I wrote a great Appium Pro article about how to do that and it ends up using this desired capability. WebKit response timeout. This is again the amount of time that Appium is willing to wait for a response to come from a Safari WebView. And if it doesn't respond in time then you'll hit this timeout. Looks like the default value is about five seconds. Remote debug proxy. So normally Appium is connected through to the Safari. Like the Safari has like a special debugging port. If for some reason you wanted to create a proxy where it goes from Appium to your proxy to the Safari to the proxy to Appium you could put your own in there. Not exactly why exactly you want to do that. It used to be actually that we had a special Safari debug bridge and it'd be like a separate server we'd have to run in a separate process and you would use that proxy but now Appium does that by default. Yeah, we get to a bunch of web driver agent stuff now. So web driver agent is just the name for the server that Appium puts on the device in iOS. So it's a project built by Facebook. It's called web driver agent and it has a lot of desired capabilities. So we'll just start going through them here. You can set the port that it uses to talk over. Normally Appium sets this but if you wanted a specific port for web driver agent to connect to Appium you could use this. I'll just keep going to web driver agent stuff for a while. Every single time you run a test by default it takes the whole web driver agent project which is an Xcode project and it has to build it using Xcode build locally on your device. The reason it has to do that is that web driver agent has to be signed with your developer key because they put that as a security thing because they don't want, like if I go to a hotel and plug in my phone for a charger it shouldn't be able to use web driver agent. It should just be only something you've signed and you've already pre-authorized on your device and so it has to be signed locally on your machine. Facebook can't just publish it already signed because then it'd be signed by Facebook. You can only use it if you were Facebook. So whenever you install Appium you have this whole Xcode project, at least on Macs, this whole Xcode project and it has to build the whole project and compile a bunch of Objective-C and C++ and Swift and it puts all together and then it puts that onto the device and the whole process of signing it and getting your developer key and getting your signing profile and certificates, it's all pretty hectic and annoying and so it's a lot of design capabilities for changing every single part of that. So using pre-built WA skips all that assuming you already built a web driver agent like executable and you signed it and everything's all perfectly set up. You can use this as a capability instead of true and it skips that whole process and it'll just use the one you have on the file. And so that's a good way if you've already run a couple of successful iOS tests you can speed up your tests quite a bit, quite a bit, maybe even a minute or two per test and it's also used by the Appium developers when we're trying to work like debug and issue with web driver agent we can write code our own and then we tell Appium use the one I put in this file already. Right, yeah so this is just, this is a capability that I guess prevents the XT test framework from creating a lot of unnecessary files and it does it in a pretty extreme way. You can set the web driver agent URL that's just like where Appium is connecting to it. So normally it'd be a low-closed 8100 but I guess you could connect to a different one. Use new WA forces the uninstall of any existing web drive agent app on the device. If you want to change something about your web drive agent and start up options for different tests you'd want to set this. It says here, this capability is only guaranteed to work stably on simulators. Real devices require the web driver agent client to run for as long as possible without restalling or restarting to avoid issues. So and then it says, this is highly recommended for real device testing and to speed up suites multiple tests in general. So again it's kind of like if it's on you have problems if it's also you have problems so it's kind of just tune it to whichever problems you're having. Yeah so web driver agent itself has its own custom command timeout separate from the new command timeout. And so this interesting design capability even lets you, I could set let's say just wait six second timeout for all web driver agent commands. You can also set a specific timeout value for each specific command. If you need to use this I'd be very surprised but someone needed it so it's in here. Did anyone need it? Oh yeah? Oh which command did you want to set differently? Find elements, that's a good point yeah. So maybe finding elements is taking a long time because maybe you have to scroll through a long list or a lot of things but you don't want to have that long timeout on like take a screenshot or set a value. Yeah there we go. Thanks. We've got used cartage SSL so like I said like your computer is building web driver agent. Web driver agent is an Xcode project file but how does it get its dependencies? Well Xcode doesn't use NPM to get dependencies but one of their dependency managers is called cartage and so Ampium uses cartage to install the dependencies for web driver agent and then builds web driver agent. And so maybe you want to use SSL to download the dependencies because you want to maybe like get them securely. Probably your enterprise environment might require that or you have like a specific cartage server you're forced to use. So here you can enable us using SSL to get those dependencies. Oh few I think we got through all the web driver agents. All right scale factor, this one's nice and easy. The simulator can actually show like can zoom in to different amounts so you can actually set that here.  Yeah, oh this is another WDA one. So if you're using that use pre-built WDA capability this tells the system like where to search for the WDA app. Yeah, if not set then it goes to your preferences. Should use singleton test manager. Use default proxy for test management with moderate rate. Set this to false and it's home. Yeah exactly this is like, this is very typical of them or it's kind of like, yeah no idea what it does but setting this to false sometimes help with stock up hang up problems. Does anyone know what this does exactly? Webkit debug proxy port. The iOS webkit debug proxy is like I said that's what you use it talks from Appium to a Safari web view when you're in a web context but I guess only on real devices and this is the port to use. It has a default port so usually don't worry about it but you could set it. Use XC tester in file. So like the way XC UI test and XC test works is you have actually your app that's under test and you have another app that's not really an app. It's like a special app XC test bundle and it's kind of an app kind of not. I think the main difference is that it's an app that doesn't show up like on your home screen and it has the ability to start another app and whenever you write like your XC tests in Xcode it's gonna when you click run it takes those XC tests and it wraps them in a special XC test run app and then it puts that on the device and it puts your app in the device and it runs this one and that one runs the other one. So whenever you're running with web driver agent it takes web driver agent server and it puts it into this XC test run bundle and then it puts that on the phone and it puts your app on the phone and it starts that one and then web driver agent starts the other one. So this would be if for some reason you already built that whole bundle maybe you want to include something else besides web driver agent that you want web drive agent and some random XC test code file XC test code then you could build your own little file and then you could tell it to use that but then like things are really like you're on your own. This really just decides where on your screen it puts the simulator, the simulator always pops up and you can decide it's in the middle or the right or the left. We have a couple things related to iOS keychains this is just like the key stores on Android where it's saying like this is where you keep your like your private keys and stuff so that's what keychain path says where the keychain is keychain password is the password it uses to read the keychain and then it needs that in order to sign all those apps. Real device screenshotter, this one's weird. Normally the screenshots are taken using web driver agent in XC UI test apparently but if you're on a real device then it can use like another method of getting the screenshot. In this case it's iDeviceScreenshot which is just an executable you can use from the command line it's kind of like SIM control, simulator control where you can get a screenshot. So if for whatever reason whenever you try to get a screenshot with web drive agent it's not working the way you like you can say use iDeviceScreenshot instead. But then you're going to also have to follow some instructions to install iDeviceScreenshot to a computer. MJPEG's report gets so as of like this year it's pretty cool that you can stream video from your test to as a MJPEG file. So MJPEG is a movie format where it's a movie in each frame it's just a JPEG picture and so I believe. And so if you can set up MJPEG video recording and then Appium opens up a separate port on the Appium server and if you connect to that port it's just going to start sending you the video and you can open that port like in Chrome and just watch a video. You can open VLC too, watch a video or a quick turn. And that's pretty awesome. So this sets the port for that. And you can also use this one to send those videos to a specific URL. So maybe you just want to like stream them straight to Twitch. This could theoretically do that. Wait for quiescence is like very mysterious but it's iOS and XTUI test. And it's basically a way of saying web driver agent kind of uses its own way of deciding whether or not your app is ready for it to start testing. And I think what it does is it looks at like different elements and if they're moving or changing state it says you're not ready yet. I'm going to wait for whatever your animations are you're doing to finish before saying we can continue. But sometimes your app for whatever reason might like seem like it's still moving but the UI is responsive, it looks good, you should use it but for whatever reason web drive agent is like it's not ready yet. I'm going to wait. So you can disable this and set it to false and then web drive agent will no longer use that strange logic and it'll just go right away. Reduce motion, this will just sort of like reduce some of the animation in iOS and apparently it helps reduce flakiness during tests. Permissions, you can actually set different permissions only on simulators not real devices but you can just set the permissions that you want the phone to already have granted. So this is even better than saying like clicking on the pop-up for permissions. This will just basically what it does is it opens up the files for the simulator and it just changes the permissions like inside there and so now it'll automatically have these permissions. So for example like calendar permissions or photo permissions and stuff like that. This one's super weird but if set to true which is the default and every single time you set a command to a Safari web view then the Safari is going to automatically garbage collect the JavaScript VM heap. I don't know like why but I think someone was having some issues and this helped so it's set to true but if for whatever reason the garbage collection is gonna slow down your JavaScript execution in Safari so you could set this to false. This is another Safari one. Basically if you use a execute script command if you're trying to do something with HTTPS it has an issue unless you set this to true. I mean that's exactly one where like you're not even gonna know why it's not working but maybe you'll remember like isn't there some weird HTTPS execute a stink thing for iOS and there it is. Real device logger, so this is four real devices on iOS. You wanna get the logs. Then there's different ways of getting those logs so we have a couple different options we can pass in. The default is it uses iDevices log which again is another sort of like it's a C program that volunteers wrote that actually reverse engineers how iPhones work and just like that iDevice screenshotter this is iDevices log gets the log that way but there's other ways you can get it too. You can use device console which is going to just be another way of getting it. You can also set it to a path for these files so if these files are in a lot of different places you can tell it like look I installed iDevices log but I put it over here, use it there. Oh does it stream log? Yeah, yeah. Ignore about blank URL. This is like one of those weird tiny ones where it's like if you do driver.context it'll list all of the current web views, right? And maybe for some reason you have a web view that is not looking at any URL so then it's looking at about blank that's the default URL. So this one just if any of them are about blank it just won't include it. It just removes it from the list. I don't know why anybody cares so much. Did anybody use this for a specific reason? Show IWDP log. iOS webkit debug proxy, right, right. So we said before that there's logs, there's a separate proxy that iOS can use to talk to the Safari. And let's say we think there's a problem and a connection from Amplium to Safari you can actually enable the logs for that proxy and that'll be one of the logs available. When you're streaming logs in Amplium you do driver.like there's a way to like list all the logs available and it'll give you like six, seven different streams. So if you set this to true the webkit debug proxy logs will be one of your options to stream. It's interesting to bring up the streaming so by default you just get the logs and it returns all the ones up to that point but there's also a separate side capability for streaming the logs. Amplium opens up a web socket port and you connect to that and now you can get a stream. Let's do these other iOS ones first. Bootstrap path. This is right. It's used with the use XC test run file capability to specify the file path to search for a custom XC test run file. Again this is pretty much only used for development of Amplium when we're testing out different versions of WebDriverAgent. Agent path. Set the location of WebDriverAgent Xcode project file and exactly again this is for going through and finding and running your own version of WebDriverAgent. Use simple build test. Build WebDriverAgent with Xcode build. Run WebDriverAgent with Xcode test command see if it's set to true. So this has to do with exactly how you're doing your building of WebDriverAgent. If you're familiar with the internals of how Xcode build is used this is a way of setting slightly different options. That's all those advanced ones for iOS. I'm gonna get rid of these Mac ones real quick. There's the Mac driver. It's not super well supported. It does things a bit differently from the rest of Appian but it exists and it has a couple of desired capabilities like mouse move speed. That's just how quickly it moves the mouse. When you're typing or clicking on something or doing a touch action. We have the diagnostics directory location. It'll take performance information while you're running your test and this can tell it where to put that information at the end of the test. And SDB port that's just picking the port that it uses. Oh wait, no, that's for the Tizen driver. The Tizen driver is for automating apps made with the Tizen framework. I'm not super familiar with it but SDB is their version of ABB and so this is the port for that. We've got the Chrome driver port on Android and we've got the Chrome driver port. The difference between these two is that this one has a capital D and we were like, wait a minute, we wanted to be lowercase D like all of the other Chrome driver design capabilities. So this one is deprecated and this is the one you use to set the port. You can also give it a, you can also give it let's say multiple ports. So if you want it to like sort of choose which port it'll get, like Appian can pick just any one available. You can give it an array of specific ports. You can also in your array of specific ports give it another array that's specified a port range. Extract Chrome Android package from context name. This might be the longest one. But basically it, this will get the package name for, no, what is it? Use any package name in the name of the web context you're going to use. Any name. Right, right, right. So when you're connecting to web views you have to give Chrome driver your Android package name. And normally Appian automatically will get the package name from your desired capabilities. But if for some reason you wanted to use a different name this is how you would put it. Shared preferences in Android. So Android I guess has a shared preferences data store on your phone. Like these are your preferences for all users on your phone. You can just set random stuff in there but this is deprecated. Android natural orientation. This one's super funky but basically there's some device manufacturers where the like, so right now we say like this, you know this way is portrait and this way is landscape, right? So you can say set orientation portrait, set orientation landscape. Now there's some devices like a tablet maybe made by ASUS. Does that remember ASUS made like an Android tablet that was this big? It was like I saw it at a conference once. It looked like like an iMac computer, like a desktop and the guy in the sales guy, like I'm like using this desktop and he just like picks up this huge fine. He's like, oh, this is a tablet too. Like we can't even lift it. But anyways that thing is wider than it is tall but its normal orientation was like this. So portrait is this and landscape is this. This is the same for like whiteboards when they have like a smartboard. And so then someone made the natural orientation. So if you set that, then even though this is, you know, technically landscape mode, it still becomes the portrait mode because that's the way you're supposed to use it. And it just like reverberates, it just confuses you. But that's what that is. Honestly, if I ran into that problem, I would just be like, okay, so it's landscape like. User profile. So I guess Android phones can be multi-user. That's super cool. Like maybe we all share a phone in our family or I give you my phone and I want you to be like, just for a week and I want you to be a different user. Pretty cool and it supports that. I've never seen anybody actually use it. But if you did, this is how you could set the user profile ID number for the user that's starting your tests. Maybe there is a interesting use case here if you had like five different user profiles programmed into your real device already for different test case users, then you could actually switch between them like this. That'd be pretty interesting. That's all the advanced ones. 104 out of 180. It's pretty good. We have like 10 minutes, I think. Uh, anybody want any specific ones? Will you just grab one randomly here? Uh, native web tap. That's a great one. Hopefully you've all run into that before. That is basically when you're on a website, Jonathan wrote an acting pro article about this. When you're on a website and in the context of the web view and you do driver dot click element, the way it's going to click that is it uses JavaScript to simulate a click. Now a click is slightly different than a tap in JavaScript. And most frameworks, no problem. But in some specific ones, no matter how many times you call element dot click, nothing will happen. And what it really is waiting for is for a person to really tap the screen. And then the iOS or Android knows how to like signal that it was actually a tap. And so you set native web tap to true and then Appium, when you type click, what Appium will really do is it goes out into the native context, it finds your elements, you know, coordinates and then it does an actual tap in the native context onto those coordinates. And so that'll fix your click problems. That's a super important one. We've got show iOS log, that's known for our logs there. We've got unlock type and unlock key. That's for an Android. If you were like unlocking, it's not just sometimes it's just swipe. You know, sometimes it's a key code, sometimes it's pattern. So you can set the different types using unlock type here. We've got pin password, pattern fingerprint and then whatever that value would be, that's the unlock key. We've got intent action, intent category and intent flags. Those are just all different ways of starting your app. And I think they're all really cool ways because sometimes like it's crazy that you have to automate the first 10 steps of your app in every single test just to get to that part you care about. But if you have the developers install a deep link that takes you straight to the part of the app that you care about, you can skip the first 10 minutes of your test by deep linking straight and opening the exact category and activity that you want. And even if your developers don't do this for you, they actually, the way Android development works, every different like screen on the app is an activity. You could read the Android manifest file and you can see those different activities, you can skip straight to them. The developer can't stop you. There's an Appian Pro article about that. So it takes care of that, and that, and that, and that. The app we need activity, that's when the thing starts, the session starts, it picks an activity to the wait. We've got performance logging. Looks like just for web views and web browsers. So we've got Chrome, but I have a performance log in Android and Spark log in iOS, so that's pretty cool. Again, that would appear as just another login stream. App wait package, this is the, I just said wait. Allow test packages. This says that if for some reason the developer of the Android app specified in the manifest file, that this is a test only true. Normally that would prevent you from testing it, but if you set this to true, you can test it. Boom, right there, that's like, hey, I'm trying to use my app. Some reason it doesn't work. Set this to true, now it works. And reinstall timeout, and how long, and Appian will wait before deciding that your app is never gonna be installed. AVD args, these are arguments that you can specify directly, like send directly to the emulator. An important one to use is like.netfast, which will change like the network speed. So this is ways that you can test like a slow network or a bad network or like 2G or 3G as well as other things. Chrome driver executable directory, we've actually already talked about that. Show Xcode logs, we've got lots of logs. Network speed, that's Android only, but you can set the network speed, but it can't change the network latency. For that you have to use the other one. Is headless? That's actually kind of interesting. You wrote an app in your pro article about that one too, where you can basically, if that's set to true, then your iOS simulator or your Android emulator, it'll run the whole test and there's nothing visual, you won't see it. And that's kind of cool if you're just running them on your laptop and you don't need to have them constantly flying in your face while you're like trying to read the news while your tests are running. How do I put time? Oh, six minutes. Um, full context list, that one's kind of interesting. Like I said, you're getting like your context when you do driver.context to get all the web views. Normally it just lists like their names, but if you put this, it makes them objects and you can see the title of the page and the URL. So that's kind of useful. Show the Safari console log, like the JavaScript console, that's cool. Show the Safari networking log, that sounds great. Pre-build WDA, that's the web drive agent again. That's always true, but you could set it to false to skip that whole building process. Implicit timeout and loop delay, those are both for the Mac driver, just like it's controlling like how many times the button will, the timeout will happen and how many times the button will click in a row. Tizen drivers got another one here, Tizen install timeout. We've seen so many install timeouts, I think we know that for now. Android, you can disable window animation, that'll make things run faster, but again, now it's not quite exactly the way that most users are gonna use your app. Show Chrome driver log, that's more long. Safari initial URL, that's kind of neat. Like when Safari loads up instead of going to about blank, it'll go to the one that you set. Doesn't work on real devices. Location services authorized, location services enabled, that's bunch of permission stuff for iOS. Safari ignore fraud warning, if you use Safari and you're on a website where it doesn't recognize the SSL, then it's gonna put like a little bar at the top that gets in the way and a lot of your customers will be like, are people looking at the test? Oh, why does it have that bar? It looks like a bug, so this will just get rid of that. Safari open links in background instead of new windows, okay. Interkey delay, that's the time between keystrokes when you do send keys. So if for some reason you want someone to type slower or to type faster, you can send. Bundle ID, that's a right somewhere. Get in towards the end of the node, it's the bug, yeah. Oh, yeah, do I need extra time? No, I don't think so. I was gonna see how many I could get through, but I didn't want to like, you know, go through there. Oh, okay. Oh, okay, okay, we get five X-mits because the other session's running slow too, but I won't be offended if you just run out of here. Start IWDP, so this time before, that's the iOS WebKit debug proxy. Before this capability was introduced, the user was responsible for setting it up, so it's only for real devices, but in order for Appium to talk to Safari on a real device, you have to start this up. Used to be, you had to do it by hand yourself in a separate service, but now you can just set this to true and it'll start it. And that's the proxy where you can choose the port and you could also use your own custom proxy and you could also change the number of retries and you could also change, does it reconnect every time. We've got the WebDrive agent launch timeout. We've got the WebDrive agent bundle ID, oh, updated bundle ID, right. So when WebDrive agent is being rebuilt on your machine, you have to give it a different bundle ID because the bundle ID that comes with it by default is like facebook.com or something and you have your own .com U, so use that to set it. Xcode config file. I guess if, yeah, so if you wanted to set up like all this identity stuff about the code signing, you could use a config file and this is how you could set it up. The signing ID for Xcode. The org ID is also needed when you're signing. Cool. Here we have launch timeout for iOS and Android. That's just the amount of time it's gonna wait for it to launch. But for XCOI test, use WDA launch timeout. Probably already got that one. Another Mac driver one, let's get rid of that command delay. That's just like how long between commands. Screenshot on error, that sounds useful, but you should probably just do that yourself in the client when you get in there and take a screenshot. Max typing frequency, which is, oh, this one is only for clearing a text field in iOS. So iOS, there's a way to like clear the text field and so we had to work a lot of all the different ways of doing that. People are like, this is one day one would work, one day one next version, a different way to work. And so one way is you hold down backspace. Another way is you have to hit backspace a bunch. Another way is you select all and then backspace once. So whatever it is, if the way that it's currently using is to type backspace a lot, you can change how often that types, how quickly. Connect hardware keyboard. You can enable a hardware keyboard in the simulator. It's set to false by default because apparently that just works around some bugs. This is very good, ignore unimportant views. This is where an Android, when it gets the UI hierarchy inside of the app, that's the way it gets all of the elements as one big XML document and that's how it uses XPath. And also that's what you get when you do driver.getSource. And so it has Android built into it, has a compressed layout hierarchy where it'll just ignore a bunch of the container elements that are kind of, it thinks unimportant. And so you can use this to make your entire XML file smaller. So a lot of your XPath queries and getting the source will be much faster. But sometimes you might need some of those middle containers in order to use XPath to find your right element, in which case you wanna keep it. Chrome driver actually checks the build of itself. Oh, right, right, right, right, yeah, yeah. So Chrome driver, when you're running it, is gonna put a little banner that says like, Chrome is being controlled by an automatic thing. So if you set this to true, it removes that little banner. Except as cell search, it's set to true. The web browser is basically automatically except all SSL. So you don't have any like insecure issues if you're running against like a local site that doesn't have SSL set up. And you can use this if you don't want to actually install those specific SSL certificates. Print page source on find failure. Looks like this isn't all of them. So whenever find operation fails, it's gonna print the current page source. It probably makes your logs like very busy though. Event timings, this one's actually pretty cool. If set to true, it adds a bunch of timing information to Appian's logs. Looks like we have specific documents for that. But that can help with debugging or also making sure that your test is going the way you want it to. You can set the language of your device. You can set the locale of your device. Locale script is like if your language has multiple ways that can be written. I guess Cyrillic is a good example of this. I think in Japanese, there's different ways of writing. You can use like also in Chinese, you can have traditional versus simplified writing. Send key strategy, like I said, there's different ways that for iOS that we have for putting in the keys, but all that got fixed in X UI test. But for the old instruments, it looks like you could do like one by one keys or you set the keys all together. You try to set value rather than typing. Just once it works, sometimes they just won't work. Bundle ID, super simple though. It's just how to, which app to start. App package and app activity for Android. Which one's to start? Auto web view, that's what I was saying. It'll automatically go into the web view. So you can also set that on your app itself. Your app is like React Native. You, oh, sorry, if your app is React, not React Native, then you would, every single test would have to start with go into the web view. So you can set this to true when it does that automatically. Orientation, yep, landscape or portrait. That'd be for starting out. GPS enabled, you can set GPS enabled true or false. Native web screenshot, we talked about that for iOS. This is it for Android. So if your web context, if this is set to true, it uses ADB to get the screenshot. Otherwise, it uses Chrome driver to get the screenshot when you're in a web view. And I guess that would just be like, pick whichever one seems to work better for you. Android screenshot path, that's where it saves the screenshots to on the device, default data local temp. But you could put it in other places if you wanted. Calendar format for iOS is like, is this the Gregorian calendar or is it some other kind of calendar? Screenshot wait time, that's just a time for how long a wait before it decides that your screenshot's not gonna work. iOS install pause, time millsides pause between installing the application and starting the web-driver agent. I guess if you have a large application, you might wanna put this in. Default data is zero though, so it's usually not waiting. Oh my gosh, we're almost done. Page load strategy for Android. Pass to Chrome driver, this is our capability to tell Chrome driver when to return for command, navigate to new page. Right, so, right, right, right. So when you load a new page in Chrome, at what point is the page loaded? This is an age old question in Slendium and web development, is the page loaded when it downloaded HTML? Is the page loaded when all the JavaScript is finished loading? Is the page loaded when all the scripts have downloaded and the different assets? So this is a way of saying you can specify sort of your unique twist on when should you consider that the page is finished loading. Auto launch, this one was very confusing. Notice it's no description. As far as I can tell, it's basically no longer implemented anywhere, but it's still in there. And I couldn't confirm whether it did anything or didn't do anything. So I had to leave it in there. But I'm pretty sure auto launch does nothing and it's deprecated. There's the UI engine. Simon is here, he works for a company called UI TV and they have a framework that you can build apps and then deploy it to all sorts of different devices like Xbox and PlayStation and Sony TV and Samsung TV and stuff. And so there's a UI driver for Appium and this is just setting the address of the driver the same way it set a port and something else. Auto web view timeout, that's how long if you set auto web view to true they would wait for the web view. Did we already use up the extra five minutes? We still have, oh, I think we can finish. WebJoy connection timeout, that's how long to wait until you can connect to web driver agent. And then it's if web driver agent doesn't launch which I've seen happen all the time, it'll retry it, you can set the number of retries, defaults to, how long should it wait? In between those retries, default is 10 seconds, that's actually pretty long, but you can set it to whatever you want to. Simple is visible, I'm gonna save that one. Calendar access authorized again, that's just saying like whether or not the app has access to the calendar, you can set it. Absolute web locations. When you use the element location within web views, it'll return, oh okay, it'll return them relative to the origin page rather than the scroll offset. So if you have a page in a Safari web view and you're getting the element location, you can use this to choose, do I want the location of that element to be compared to the current screen or compared to the top of the page? Because you may have scrolled down. Use JSON source, web driver agent can get the source code. So we said before that it takes a while to generate the XML source code for your app and so that's why XPath is slow. If maybe your phone doesn't have as many resources, this will send the whole UI hierarchy from the phone, your web drive agent onto Appium is JSON and then Appium will write the XML file that it uses to parse the X code on your computer which has a faster processor. Screenshot quality is just how nice you want the screenshot to be. So zero is high quality and two is low quality. And simple is visible check. So web driver agent has different ways of deciding. So you can do element dot is visible and that tells you whether or not the element's visible on the screen. It's not always very reliable. But for some reason, sometimes the XCUI test would like hang for 60 seconds while trying to find out if the element's visible. So the web driver agent developers found a way to do it faster where they basically just like, they get the element's like location and they get the element's size and then they like find a certain point like the center and they say, is the center visible on the screen? And then if it is, they say true and not false. So this is, that's how it does it now by default and it seems fine for everybody. If for some reason you're having problems with checking what's visible or not, then you could use this and you could use the old way which has a high probability of hanging for 60 seconds and we made it. Yes, great. I didn't think we'd make it. All right, cool. Well, this site exists, caps.cloudgrade.io. You can use it from now on. If you want to change anything about it, I'll create a way of making pull requests so that we can update this documentation and maybe we might want to translate it too. If you wanna do that, I'll give you access to the repo and we could like do translations so we could get this into more languages than just English. And yes, pretty much please use it. It should be, you know, it doesn't look pretty. If you wanna make it look pretty, yeah. You can take that on. That's one way of continuing open source, right? Yeah, cool. Any questions? Any capabilities for mock the URL? What do you mean? You mean like the, you want the web view to go to another URL? You can just, yeah, so since you're in a web view, all the Selenium commands work. So you can do like driver dot, what's it, driver dot set URL or driver dot navigate? Yeah?  Is that what you meant? No. Right. You're saying if your app, if your app is connecting to a background set. So Appium can't control if your app is, which server your app is going to because every app does that differently. But if you were using a man in the middle proxy, network proxy, then you can actually take each of those requests that we're going to go to your production server and you can forward them to different server. And yeah, I have an Appium Pro article, like three Appium Pro articles about how to do that. But it's actually totally possible. Yeah. Cool. We're done. Great, thank you.


Now, outside Africa, four people were killed and another 17 wounded in a car-bomb attack on Thursday in the sprawling Sadir-Sisti district of Baghdad, according to Iraqi police and medical sources. The car was parked at a busy second-hand equipment market in the mainly Shi'ite Muslim district, the police said. An Iraqi military statement said a blast in an eastern Baghdad market killed one civilian, wounded 12 others and set several vehicles on fire.


Last week the U-Pike Bears put a W up on the board after defeating Livingstone University out of North Carolina. The Bears got moving early and often defeating the Blue Bears 52-23 with the offense putting up 28 unanswered points in the third and fourth quarters. We caught up with head coach Al Holland Jr. and receiver R T's Clark on their first victory of the season. Going back to the first game, we learned a lot of things about our football team and not being able to handle some adversity in that ball game so going into that second game we sort of put ourselves in the same situation at halftime and really talked to the guys about that. How are we going to handle this second half? You know, we've been here in this situation before. We're going to come out and we're going to regroup and come out and play with energy the second half and you know, go ahead and earn a win or we're going to just sort of let them hang around, hang around and I thought we had a big third quarter and that was a big difference in the ball game and sort of taking them out of their game plan and making them do things they didn't want to do. Just when we were making, just being prepared for what we're going to go our enemy, our team we were playing against, just being prepared for the first, second, and third, all the way to the fourth quarter. Not letting teams hang around with us a lot and going into halftime and finishing drives and getting first downs you can touch down so that's pretty much what we've been doing. The Bears now stand at one and one on this season as they gear up for Bethel University tonight from the Hambly Athletic Complex. The Bears lead the series with the Wildcats six to five although the two teams haven't met since 2016 where Bethel came out on top. The Wildcats coming off a big upsetting win over the number two team in the country, Reinhardt 31-21. Bethel is, you know, week one they played Reinhardt. Reinhardt's number two in the country. They had them at home and ended up knocking them off at home. So says a lot about their football program and their turn around with a new head coach and he's doing a great job. So we're going to have our hands full but we're going to play for 60 minutes and if it takes overtime we've been in that experience before. So we've got to be ready to go. We've got to, you know, be great in all three phases, offense, defense and special teams and, you know, take care of the football and create some turnovers defensively this week. Expectations on Bethel, you know, they're pretty physical. Some of the defense online and the DBs are pretty physical up front and they look pretty good, they look stock. But we're just making corrections in game. We just have to deal with them then.  So hopefully if we play sound that we can come out and win. They knocked out the number two team in the nation but I think if we just play that we can actually play it through in Bethel and upset a lot of people.