 Thank you. Yeah You're not all the issues maybe we also responsible some of the issues gets closed and not responding to sorry for that Yeah We're gonna talk about the life cycle of an APM command So I'm sure like everyone in the room has been working on APM nor at least would have done some sort of spike Or you've been working on your projects and stuff, right? So we're gonna talk about what exactly happens behind the hood For the specific commands which you actually run, right? To get started a very quick introduction about me is I'm Sai Krishna I work for ThoughtWorks, and I'm a ThoughtWorks for about four years now And I maintain and also contribute actively to the APM repo and open source Yeah, just learn and give back to the community Myself Srinivasan Shekhar APM member, maintainer, APM's Java client and open source contributor in various open source repository. I also work for ThoughtWorks So Agenda for the day enough for the day for the session So we're gonna talk about the session creation. So I'm sure everyone should be familiar about The new Android driver the new iOS driver command. So that's exactly what you you know That's that's like your first line after you key in your capabilities So we're gonna talk you through what exactly happens when a new Android driver or and a new iOS driver actually is Exegguted and another one what we want to cover today is about find element So I know most of your client all the client code say that driver dot find element by ID expat or whatever that could be So we're gonna talk about how exactly that command gets executed and and what exactly happens What are the node modules called and stuff Problem statement, I always like to start something with a problem statement because I like problems So yesterday when we are when we were part of the workshop. So we had a advanced APM workshop We had a awesome bunch of people in the room anyone from the workshop in the room Wow, yeah, so and Some of them actually bumped at this crazy Error saying socket exception and even people who were not there in the room How many of you are bummed at this exception when you're working in your projects, you know You try to execute and nothing happens and all that you see is a socket exception, right? Right, and how many of you feel that the issues just closed. It's just ignored and no one's fixed it Yeah, let's be frank about it, right? Yeah, so I've picked one of those Crazy exceptions why we close that and and basically let's try to debug as a part of the lifecycle to see When exactly this exception actually happens so that when you go back, it's you know great that even you know understand What's happening? You know where which node module you need to look into where exactly is the problem and stuff? It remembers kind of remembers me a fun fact if you type Who broke the build in selenium say as a channel it bumps up. Yeah Simon's name. Yeah Anyone on the selenium IRC channel in the room? Oh, yeah Yeah, so you know that right? Yeah, similar way if something's actually Broken on the espresso driver Probably should be Daniel is Daniel in the room here No, it's not around you folks need to catch a lot. Yeah, you should catch a lot of Daniel He's gonna be around somewhere. So he's one of the person who's very actively contributing to the espresso Module so if something is broken and I'm sure it's him because whenever I go back in he says yeah I know I broke this. I'm gonna fix this. Yeah, so Quickly on the Android architecture, right? I'm gonna briefly talk about the Android architecture Basically, what do you see on the left corner is the client? So your client could be either it's your Java client or your Ruby client or your C sharp Python JavaScript like web drive. I oh, I love the driver. I oh, yeah And so typically what happened? What do you do in your client? You try to create a session then you say driver dot find element by ID by X path You give some locator to it and you try to do a click send keys Scroll and all of this stuff. So you do typically on your client, right? so When you when you actually do that and when you run your test what happens? So that goes into the APM server on our W3C protocol and the APM server gets the request from the client and APM server smart enough to understand whether it's a iOS request or an Android request and it's going to send it to the respective drivers in this case We're looking at Android. So let's talk about Espresso driver. I mean, why did we actually pick Espresso driver? is UI automated to so APM also has got another driver module call UI automated to and you also have another module call APM Android driver So let's not talk about APM Android driver because that was UI automated one Which is completely like old old old. I don't know if I've started my automation at that point of time With UI automated to is officially deprecated by Google and they actually very actively maintain Espresso driver But it is not deprecated by the APM community. We still maintain it We still have users using it the whole reason being we just moved into Espresso driver and we are actively Building staffs contributing and just trying to make it more stable But down the lane at some point of frame APM would actually deprecate UI automated to as well when Espresso driver gets into a stable state So start looking at Espresso driver play around with it report bugs contribute to the community. So That's the sole reason why we wanted to actually pick Espresso driver and take you guys through what exactly is happening on Espresso driver And if you want to know more on UI automated to driver, please attend Shravan stock Which is bootstrapping on Android easier easier. Yeah, so attendance talk to know what are the internals of UI automated to driver So we are going to talk the internals of Espresso driver today Yeah, and you have a server. So basically the server is installed into your real devices or your emulators So any request which comes from the server to the Espresso driver that is sent into The server which is residing inside your device and that server is your Espresso server So we have a driver. We have a server. Okay, so that's basically how each and every command just flows through internally inside your driver So let's go through to a bird's-eye and see what happens into all of that So Coming into the APM base driver, right? So Actually APM the three different drivers actually extend APM base driver like the Android driver Espresso driver UI automated to So you're gonna talk about APM's Espresso driver So we also see like other two modules, which is called APM ADB and APM's support So basically APM's ADB is a wrapper around ADB So I think most of you know the Android debug bridge, right? So we typically try to do ADB devices. You do your ADB Dump dump system and all of that stuff So all those ADB commands have wrapped into that specific module and the ADB support is more a utility function Module there basically if I have to give you an example So it's got some functions like you know if can tell me if it's a Mac machine Mac OS if it's a Windows or Something related to your file systems and file utils. So all of those stuffs will actually find inside the APM support So going forward we're gonna see how Espresso driver, you know takes help from APM's ADB and Android driver as I said Android drivers like got more score of UI automated one But still there are some helper methods where we actually still using that because we have a lot of helper methods regards to the old ADB debug bridges Okay, so let's look at The APM's Android life cycle on a bird's eye view is the typical four stages Which I want to take you through today is I've just broken it down so that it could be easy for us to understand What exactly happens on the initialization phase and then we create so what exactly happens in initialization is about your Driver creation and stuff and in the creation when our drivers getting created what is happening inside that an instrumentation We'll talk about what is instrumentation Why we need to instrument your APKs in Espresso and how do we do it and things and then finally is the execution So how does your commands actually execute on your real devices or your emulators? So as a part of your initialization, I'm sure everyone in the room who's at least looked at the read me of APM should be familiar with this piece of code so basically what we're doing is we're just creating an object of desired capabilities and We just giving some basic capabilities like a device name and you know app package and your app path and app activity And you also see an automation name that has Espresso, right? so If you want to choose a UI automated to driver you actually give your automation name as UI automated to if you want to choose the Espresso driver you basically give your Automation name as Espresso driver and Yeah, that's a very common line where you want to create an object like new Android driver in the mobile world for Selenium folks It's going to be new Firefox driver new Chrome driver and stuff, right? So that's basically where your driver gets created this piece of code is the one which creates the driver. So Let's go Deep dive into it and see I mean what happens underneath, right? What exactly goes through what are the things that the more different node modules actually pick things how they move forward what they do and things and So we're falling back to the main APM base driver. So basically Appium's base driver this module actually has got all the W3C protocol proxies and And also it validates all your given capabilities So like when you give a capability you could also give an invalid capability, right? Which does not exist at all so it actually validates and checks if this is a valid capability so that the whole thing is we want to fail fast So we just want to you know fail fast and tell the user something's not right so probably you need to go fix these things right and When we talk about W3C protocol, right? Is it the client or the server which sends an understand? So it's typically the client which actually sends the request so when we send the request from the client Either it's your Java client or Ruby client or any of those clients which you use It's the client which actually sends the WC 3 request to the server and when the server looks at it Okay, I'm getting a W3C request. So which means I'm going to create a W3C session now Okay, and with selenium 3 dot x we have we have support to both W3C protocol as well as your json white protocol and what APM that was we actually exposed a Capability where you can actually force sending a backward compatible of mobile json protocol as well But once we migrate to selenium 4, which means it is default to W3C So which you you cannot go back to the old protocol. Okay, so going forward once it's selenium 4 The clients will always send a W3C protocol to the server and Once the server gets that it knows it's a W3C request and it's just gonna go ahead and take things up And app launch date, right? So what happens in your app launch date with your desired capabilities? Basically, it's gonna decide how what should be the app launch date. So there could be Capability like no reset. So which means you're saying APM that do not do anything to my app state Just go ahead and execute only the test let the app be in whatever state that could be right So we have a lot of these Capabilities so basically depends on those capabilities it decides what should be your app launch date And if you want to know more on capabilities, you should definitely attend John's talk He said that there are about 180 capabilities That's a good stuff for you to go through is John is in the room anyway. Yeah, there he is Yeah, so probably attend this talk if you want to like know more on what are the different capabilities That we have in APM around iOS Android and how that could actually Help you in your test execution. Yeah, you should definitely do that And and once we actually decide on the app launch date and that's when comes your automation name So in your capabilities you provided automation name as espresso driver or you I automated to write and and What the base driver does at that point is it goes through your capabilities it takes your automation name and That's when it actually pulls that node module so it says, okay I'm getting an espresso session to be created. So let me require the espresso module Let me import the espresso driver model now So at this point of time the base driver actually imports the espresso driver module now So which means all your navigations are moved into the espresso driver not to the UI automated route and Once the espresso Driver is being imported. It just returns the driver from the base driver saying, okay It's gonna be an espresso driver going forward. So we'll just return that and espresso driver actually extends base driver and What happens after that, right? So we actually inside an espresso driver module now So keep that in mind just try to imagine you that you're debugging flow so you come into an espresso driver module now and We basically as a user view would have given certain capabilities, right? Because when we saw in the the previous slides you say desired capabilities of new capabilities you gave some capabilities so that's something which is You know Flexible to the user what you want to give apart from the mandatory ones. So there are some mandatory capabilities as well which apium actually needs as a part of the espresso driver is Something like a tick screenshot, right? So if you say driver dot capture screenshot So which means you need to actually enable that should be a default stuff Which is set so we don't tell the user. I mean just go ahead and give it a true so we are setting some of the default stuff so we here and We try to merge both the capabilities together So which means whatever you have given as well as what are the default capabilities that the apium actually needs for the test Execution so which means we are still preparing for the state of our test execution over here and once we actually Merge into this that's when we actually Jump into the start server session now So so now you know the capabilities have been prepped for us, right? So what's the next that we actually need so you need to know where to execute your test, right? So to know where to execute your test you actually Need to know what devices are connected are their devices in my system are the emulators in my system So if not you need to fail fast, right? You need to come back and say user I can't find any devices connected could be you most of you might have seen that Throwing some errors saying that please set Android home. We can't find in things right that basically happens at this point of time, okay? and to get these device information we actually get into Appiim's Android driver as I said that module still holds a lot of Android helpers for us So we just jump into the driver Typically what you manually do like adb devices That's exactly what we tend to do there as well if we have multiple devices connected into your system All that we do is we take the first device because there are multiple ones We just say array of zero we pick that and we get it out from here, okay? So once you have the devices You have the device to execute now. So what's next that the espresso driver actually needs it needs an adb session, right? So when I say adb session so typically when adb devices don't deduct You know the common stack overflow. It says do adb kill server do start so basically you're playing around with adb over here, right? So similar way you need to create that adb session and give it so that you can go ahead play around a lot of things with adb which is required for us and and we actually create the adb session using the Appiim's adb module as I said that module is the one which is basically a node utility wrapper around all the adb commands for us, right? And what happens next now because you have you know the devices so you know this device We've already created your adb session so you can go forward and take control of adb That's the Android debug bridge to perform any other actions and installations and stuff, right? And then you basically get into Initializing the server over here. So what what exactly we do in the server initialization, right? So if you look at these in the server initialization of espresso So we have the devices we created the adb But the next is we're gonna now we're gonna prep the espresso runner So because that's the one that's gonna execute your test cases, right? So we're gonna prep the espresso runner out there and if you see some of the capabilities there You see anything with dot options o pts is something what you have provided Right if you have provided we're gonna actually take those capabilities because if you see there are capabilities Which is very specific to espresso if you look at one of the capabilities called force espresso rebuild That's just for espresso not for you. I automated it if such a capabilities actually set we are gonna actually get those capabilities and Prep so we're still prepping now. We have not just gone ahead. So we are prepping for the espresso runner session now and Once that's done and that's where you actually get into instrumentation Okay, what typically is an instrumentation, right? so basically when you say instrumentation you need to actually instrument your Your espresso server and your APK so basically both these APKs should be signed with a single signing certificate and What else does espresso driver actually do with as a part of the signing right? So it unpacks your app under test and it re-signs it with a certificate and then it unpacks your Server and servers got a manifest file Okay, so what expresso server the way it works is you need to take your app package That's your app under test package So every application you test will have an app package right something like comm dot qa dot whatever your company's Package that specific app has got so it's gonna just use adb modules Take the app package and it's gonna bundle the expresso server with that target app package Right and why it should do this because espresso needs to know which application that I need to communicate and I need to interact and do all my actions and that's the reason we actually as a part of instrumentation we take your APKs app path and and we try to dump it inside your espresso a manifest file and Appium expresso driver bundles it so which means your expresso server is ready And the server is service manifest file is got your test app under test package name So and and next is we go ahead and do a port forward over there. So you see this command called adb Forward TCP 8300 TCP 6791, right? Yeah, and just above that you see something called a system port and a device port so just to emphasize on system port like that's when We establish a communication between our Mac or Windows PC with the mobile application and the test which is residing under Our mobile device so system port is another capability that enables a port-to-port communication So if you give the unique port, that's when we start running our test parallel So in order to run your test parallely on Android using espresso or UI automata to Server you have to mention a unique system port. That's when communication between our mobile devices are unique to the system Yeah, so that the sessions won't collaborate So once we do the port forwards, which means 8300 is a port which is available Which is free in your machine or wherever your devices or emulators are connected and 6791 is the default device port When I say device port it's your either emulator or your real device where your Express of servers actually running okay, so express a server because when it's a server You basically need a port to communicate with it right that port is 6791 and you really can't communicate to a server Which is running somewhere like just in a device, right? So we try to do a port forward to it as which means you take control of that You can actually communicate to that specific device over HTTP when you look at the architecture It's all HTTP right the entire architecture is a no HTTP protocol there Yeah, and we as we saw we have instrumented the app. You're gonna install the app as well So express of drivers actually installing the modified Server as well as your re-signed app under test and once that is done So which means now because a port forward is already done So there's a communication channel open between your system and the device which could be either your emulator or your real devices Right, so even now we are still only at the installation process So you have the app ready you have the server ready. It's just about installations and stuff So what happens next right because now things are ready now. It's all available in your Devices and that's when the actual start session happens. So if you look at that command Which says shell a m instrument blah blah blah and it says test APK package and the android just J unit runner right so what typically that command would do is when you run that command even if you run it manually So that's what express or driver does there internally it triggers that command and that command would launch the express So APK that's the server inside your device So when the server gets triggered and now you know if you're configured a port forward stuff So which means the server is up and running and you can start communicating with that server now And that's what APM does there as well Okay, and once the communication is actually open and it's all good So which means it just triggered it ran the command But doesn't matter the servers immediately up and running right maybe the server takes time because could be for x number of reasons right and That's when What we do from the driver is we hit the status endpoint because the server is running you did a TCP port forward So you have access to that specific You know device through rest so through a HTTP you can actually communicate start communicating with that device and that's exactly how APM actually does there and what we tend to do is we do a slash status do a get and We do a retry because maybe take some time Maybe the device is slow network it could be x number of reasons So we try to pull for like 20 seconds with one second of interval and once we get a 200 boom We got a result of 200 so which means the server is up and running so which means we this app is still not launched So that launch is still up So we just have the servers ready where the server can accept any request from APM now Right and you see there There's if condition in the catch block which says has socket error So we'll fall back to the problem when we started off the socket exception So when people keep talking about socket exceptions So which typically means if the server inside your device does not respond in 20 seconds Right it's gonna throw a socket exception because your server is not responding there And that's why you actually see that error so there are two possibilities either you need to check What's actually happening because your system cannot communicate to the server or why the server cannot respond back to the You know the client in your machine or maybe you need to retry more number of times by setting some capabilities, right and Once it gets a 200 that's when us after that we do a slash session That's another endpoint in W3C. We do a post with the post we give the capabilities what you exactly gave right and we also merge certain capabilities And once that command is triggered and it gives a 200. That's exactly when app actually launch in your device So it was not even with the status. It's actually with a session. That's when your app actually launches out there for you and That's exactly the post called which would be made With a slash session and those are exactly the capabilities which you have provided at the start of your client, right? You say desired capabilities equal to new capabilities. That's exactly the capabilities which goes as a JSON into a post method there Cool. So let's see a very quick Interesting demo. I've whatever I explain now is all about the driver and the way we do ADB port forwards and stuff Right, so which means there's nothing to do with the app aims or mechanism and stuff It's just that we just we're just putting things together. So what we have done now is Show you a very quick demo on Whatever we spoke on the slides. I've just put all of that manually now. So which means I'm gonna Yeah, so if you see that we're doing the AM shell the same command which we saw inside App aims express a driver code. So we have done a port forward on a three double zero to the device And I've just opened postman now and as I said, it's just a HTTP stuff I'm hitting local host a three double zero because we did a TCP port forward to the emulator Which is running and I'm doing a slash status and you should get a response with 200 Okay, and a and a body there. You see there I got a 200 okay with an ID and it says session ID is null and value and stuff So let's try to open that app right what exactly the Espresso driver does is I'm doing a slash session And I'm just giving the object of the Capabilities and it's a post now So there's no Espresso server. There's nothing running now, right? So because a server just passed it out to the driver and it's the Espresso driver who's You know responsible for that So you see the app launched and the response you get a session ID and it says okay I actually launched the specific app activity and the package Cool, and that's where your new Android driver session creation actually takes place Sweet and I'm gonna let Sreeni talk about some of the crazy things of iOS on how the creation actually Happens. Thanks. I for picking the easy stuff and talking about now comes the painful part of our life So I always session creation I always session creation Yeah, so let's get into our problem statement I hope everyone has faced this problem. Yeah, anyone didn't face this problem Webriver agent as a Xcode build failure returning a status code of 65 Anyone didn't face this problem when you are executing for the first time in real iOS device Good only with less hands. So let's get on to Let's go on deep dive on APMs iOS architecture and see how we can deep up this problem and Where exactly this problem comes from which node module that returns this kind of error. So Quickly jump to APMs iOS architecture similar to APMs Android architecture. We have client libraries Where in you talk wherein we code about desired capabilities and driver dot find elements and Creating the sessions. So that talks to APM server through Jason Sorry, but Jason wire protocol and now it is web driver protocol. So APM has a backward compatibility now still and APM server talks to APMs iOS Xe way driver if we give a capability name as Xe way, that's when it picks up iOS Xe way driver And which internally talks to Facebook's web driver agent. Why Facebook's web driver agent? Let's go and deep day on Facebook's web driver agent in the upcoming slides So it kind of talks to sense the commands to Facebook web driver agent present in the mobile device That's when web driver agent talks to your application on the test present in our mobile device So if we go one step further and see where it exactly starts from when you send the command of desired capabilities and Try new iOS driver. It all starts with APMs base driver. So it has two automation drivers in it so which is it can talk to APMs Xe way driver or the APMs iOS driver APMs Xe way driver is the recent one, which is like Which internally talks to couple of other node modules that APM has one is APMs Xcode Wherein it's a wrapper around Xcode modules in order to get information around What kind of Xcode is installed? What version of Xcode is installed? What is the derived path where your applications are building in your mobile in your Mac PCs and we have another module called node sim ctl It's a node wrapper on top of a Apple simulator control library Which helps us to get how many number of simulators and what is the platform version of your simulator? What are all the UDIDs that the simulator has and all other informations about simulators and APM iOS simulator specific to a particular simulator if you wanted to know about Platform version of that particular simulator So that's when this node module comes into picture. So APM iOS simulator is a wrapper again It's a node module to get details about a particular simulator Whether it is of type iOS or it is of platform TV OS or it's a platform Watch OS so all this information can be Gathered through this node module APMs iOS simulator and we have another node module called remote debugger APMs remote debugger It helps us to communicate to web views or Safari When you give the browser name, this is one taking the control This is the node module that takes the control and passes or proxies the commands to the Safari Browser or the any of the web views when you have a hybrid app or automating an hybrid app in your Day-to-day life. Let's go for a bird's-eye view of how does iOS life cycle? looks at so similar to Android life cycle we have four stages over here one is initialization and next is Next is the creation phase and next comes the app installation Then web driver bundling and web driver installation then comes actual Execution so let's go into each and every step and do a deep day on it So coming to initialization phase wherein we have given all of our desired capabilities For example for a simulator to be in order to execute Your application under test on us in order to install on a simulator. We used to give two desired capabilities called Grow device name and platform version. There are two ways to Interact with the simulator one is by giving device name and platform version together and otherwise by giving the appropriate Ud ID of the simulator itself So either by giving a device name or platform version or by giving the Ud ID of that particular simulator So in order to talk to a real device or interact with the application under test on the real device we used to give We have to give Ud ID of the real device connected to that Mac host then APM sci-wise driver kind of takes the server URL where exactly server is running and then it sends the desired Capabilities that user as a user that we have paused on so that's when the initialization actually happens So coming to base driver the node module exactly takes care of a automation name So in case of ios automation name here is xe y when the user provides automation name as xe y It kinds of loads xe y driver module instead of a highway is driver module It kinds of loads xe y driver module and if you have any other Desi-8 capabilities like no reset full reset So we kind of give all these resets together and Bump at our code and make sure that now a script doesn't work right most of the times So doesn't give all the desi-8 capabilities try to give the appropriate desi-8 capabilities if you give no reset That's when it decides on it takes care of Taking a decision about whether the application launch date has to be clean or it has to be take the cache all together Yeah, so that's all the decision that it takes to so when it's the Xe y driver load module comes and loads into picture It kinds of extends the base driver again So if you imagine it starts with base driver, it goes to xe y driver now which merges the capabilities that Desi-8 capabilities that we provided with the default capabilities of the driver It started with client code went to base driver then it went to xe y driver now in the life cycle so it kind of merges the capabilities and let's If the capability is of type or device name and platform version, then it assumes. Okay, it's going to be a simulator So it uses a node module called node sim ctl to get all the existing simulator and figures out Whether the platform version has that simulator as well or not in uo pc if it doesn't it just throws an error so sometime back it used to create a simulator by itself and Some versions back in the mpm it used to create a simulator by itself and then launches our application and the test on it but now it's not the case and Now then it goes to another module node module called a pms ios simulator Wherein we got the simulator name for that corresponding platform version But I need to know the further details about the simulator simulator. So that's when it talks to a pms ios Simulator node module gets all the information about that particular simulator apart from the platform versions What does the u d id of the simulator and it gathers all the informations? so there are another way to Another way to interact with the simulator and which is by providing the u d id it checks It gets all the connected devices fast checks whether the u d id is present if it doesn't if it's not present It goes to simulator checks whether any other simulator has this u d id That's when it returns real device as false and the u d id if user has provided the real device u d id Then it gets the connected device match against and sense the real device as true That's what happens over here and just to add over here is Why we actually the first line of get devices still talk to id wise id and and after that We again check with id wise id the whole reason being is With simulators when you get when you give an u d id it gives you all the properties of it But whereas with a real device it only gives you a new d id So we first list the u d id take the u d id again go back to id wise with id wise info and get the properties of that specific Device so that's why we fall back with two different commands for real devices. So we did the initialization now Now let's go ahead and figure out. How does the installation happens? So in case of simulators as you all know, it's going to be an app file that we used to install in our simulators So it again uses node sim ctl library installs The application on the test in your simulator in case of real device if the application is already installed We give bundle id so it checks for the bundle id and launches at the latest stage. So if the application Package is given a pic sorry IP is given then it go ahead some installs the IPA into the real device using a node module Call ios deploy single library called ios deploy So let's get to the painful part of the session that is the WDA itself web driver agent Facebook officially Deplicated or I've got this web driver agent so they started this project when Xui API is were broken They rewrote rewrite those APIs and released it as Facebook's web driver agent couple of years back So APM kind of adopted that project and maintained that for a long time now and even APM internally uses web driver agent to talk to application on the test through the Xui commands. So Similar to system port we have a system WDA port here wherein a Mac host can talk to web driver server which is running in the Device so if the installation successful then that's when the communication and port forwarding happens between the two ports here web driver port and Default port that web driver agent is running on which is 8 1 double zero. So when it wants to start the execution Just to add a point over here on the way it communicates to the real devices Appium actually uses a bundle called I proxy if it's a real device so it goes through I proxy over the USB Macs so that's how it actually communicates from your device to your system and the port forward have actually done Coming to execution phase right so it kind of starts the web driver agent So if the web driver agent successfully started that's when So that there is another phase called signing phase that happens So in order for in case of a real device we have to give the signing authority so that Apple IPA can be installed in our real device So if the signing is successful then it successfully installs web driver agent in the real device if it doesn't that's when it throws The error just getting back to the problem statement where the export bill failure with the status code 65 So it comes from XU driver module which throws because the signing authority is different Or it couldn't sign the application with the signing authority given So coming to so if the web drivers agent is installed and started then comes the real face of hitting the API similar to Android it hits the API endpoint slash status if that if it is 200 just go ahead and start the Application and the test which is still stalled by APM server so now we have server is up and running then it starts a kind of does a post session that we have seen similar in Android It does a post to session with the desired capabilities. So application under test also gets launched. So communication happens So everything is successful there Cool, so we did see the creation of Android driver as well as iOS so which means your app is actually launched in your emulators simulators or your real real devices, right? So that's when the step execution from new Android driver just falls out It comes to your next line of code. So what exactly is then your next line of code, right? Everyone should be very very familiar or should be like super easy to read this So that's exactly what we do to interact with any element, right? You see Find an element either by the locator either one of the locators by accessibility ID expat iOS locators or whatever that locator strategy is right So you write this piece of code and you actually run so the client actually Converse this code into a rest like you see over there It's a HTTP and the method is a post in this case because you're trying to perform some action and it creates it sends a request because When you when we saw the demo we did see the session ID is actually created, right? So that's when your app gets lots of session ID is created So we send the session ID as a part of the URL So you see wd hub session and that's your ID of the session and you see slash elements So what is slash elements? That's an endpoint like any other API. That's an endpoint, okay? and For this you actually need to send a payload as well and what does the payload hold so the payload actually looks for two Arguments there once is using another one is a value. So what is using right? So using should always get what sort of locator strategy it is so in this case It's accessibility ID. It could be an ID. It could be an expat on stuff and your value should be Your ID so which means what exactly you're inspecting, right? So you use APM desktop to inspect certain elements you take your IDs and expats and stuff So that goes into the value args and stuff So this typically is just sent to the espresso Server and the server Exeggutes this and if this command goes at 200 it's going to give you a 200 if the element is not found Which means the espresso can't interact with that element. It can't find it It's going to give you a 404 and that's when we map it back saying that element no element found exception and stuff You would see on your client, right? Yeah, that's exactly what happens over there. So let's quickly Look at a demo out here for this I'm I'm again using postman and stuff to drive drive and show you how exactly this happens So because we already have the session created so I have the session ID with me So right now what we're doing is we're still doing the same local host a three double zero and I'm trying to get the element ID So basically, you know what the element is but you need the element ID to interact, right? So I'm just saying slash element and the value is accessibility with a login and that's going to give me an ID So that ID is the element ID Of login so I'm going to take this element ID and I'm going to give it to our next API, which is called slash click Right to the click command. I'm going to give this element ID and that's exactly what Appium from your client to the server to the espresso drivers actually do and I'm just trying to replicate that using postman so that it could be easy for us to understand and Now we're just going to do a click you see the click happened and I got a status 200 and It also returned me back the session ID and as well as the ID and this way we actually go forward with any sort of Commands, which gets executed This helps us to debug any issues that comes up during our Descripting or it can also help us to contribute back to the community as well And thank you so much Yeah And I just wanted to mention there is a special mention for couple of people one is Manoj and Another one is Kazoo. Yeah, these guys took a lot of time to help us You know put things together and and and you know run through what we have done and things Yeah, a big round of applause for them. Thank you so much if they're around anywhere Thank you. Thank you Srinni and Sai These guys deserve like huge round of applause making our life easy writing a boom test every day And thank you for coming and sharing the insights this maybe If we talk about like bringing contribution from outside people feel fear But now if I see this single command line just executed in postman it becomes easier and I can go in look at it So, yeah, thank you. Thank you. So we have two minutes for maybe we can take a couple of questions Anyone? Hi, this is Santosh. So I have a question like in comparing your automator and espresso driver So in your automator like we used to use same session To handle multiple bundle ID seven with the different apps. So you mentioned signing is required for espresso driver So does it mean like we are not a poorly testing with only single app? Yeah, the answer is yes So with you I automated to you can actually move between apps But with espresso driver you cannot so it's targeted to a specific app. So you can only interact with a specific app But there was a contribution by Rajdeep where you can actually use mobile colons Only for find elements for you I automated to but you can't switch between applications Thank you. So currently there is no authorization to be honest Yeah, so it's a simple server that just access a router Without any authorization Sigh, I have a question. So how it how it works in case of x path because in Expresso we do not have x path strategy. We usually have our dot ID or You know our dot class name, etc Because in espresso we used to find using on view on data and how it basically parts your expert to Corresponding express or component. Yeah, so very recently. There was another You know contribution or we did cover this as a part of yesterday's workshop, which is a new locator I don't know if it's in any of I think I'm sure it's in Java client But I don't know if it's Contributed of any of the other clients. So it's called a find element by data matcher So basically exactly what you said, right? So on anything that espresso driver does like on data or on views the child views and stuff You can basically use your hand cross assertions as well as a part of it and send to the locator, which is a find element by data matcher, okay, so in that case you are Ex-path won't work with espresso. We doing to explicitly you Okay, fine, and one more question. So how it works in case of a shared reference shall we do share preference because as Espresso give the liberty to you know, ingest value in your share preference. So using APM Xc you Espresso driver is it possible to do so? I don't know. Maybe I haven't tested it probably you have to test