Hi, everybody. This is Rob Galvin. Thanks for joining today for our second installment of the DevTalk webinar series. Just a couple of things before we get into the topic of today, I just wanted to remind everybody that if you’re interested in any previous DevTalks and actually other events that we have going on and participating in, We are constantly updating our developer events page on LaunchPad. You see the URL there, developer.zebra.com/community/developer-events In there, you’ll only see the next upcoming DevTalk listed there, and if you’re not signed up for our DevTalk notifications, you can also sign up with your email address. We’ll let you know what’s coming up next. In addition, we’ve also added the previous events that we’ve done. On the right-hand side, you’ll see a list of the past events that we covered. If you missed last month’s, this was about Xamarin. We covered both about Enterprise APIs as well as printer APIs and how to use those with the Xamarin platform. A great presentation last month that Bill and Dan had presented. It would be a good presentation. The recording’s up there as well. In addition, we’re also posting events that we’re attending in person. We have Xamarin Evolve coming up very soon, so there’s a few postings about what we’re doing there and who’s attending and all the great things that are going on at that event. You’ll also see other events listed there, local events that we may be attending. I think there was a recent one, Android DevCon, in Europe that we recently attended. We have some information there. We’ll continually post all of our event activities on this page. Last month, we asked you what you’d like to hear for the next topic, and one of the things that rose to the top was a deeper dive on some EMDK APIs. Today, we’re going to be covering one of those sets of APIs having to do with Bluetooth, and being able to use these APIs to more easily get Bluetooth capabilities in your application. Bill’s going to walk through, in very technical detail, all of the different steps that you will need. If you want to, you can try to follow along as well, but we’ll also post the contents of the presentation after the session. If anybody has any questions or comments throughout the session, please type them in the GoToWebinar question section. We’ll queue those up at the end. We appreciate your time, and thanks everybody. Bill? If you want to get started, that’d be great. Alright, Rob. As Rob said, we’re going to take a deep dive into the ScanAndPair APIs, which offer some simple methods to be able to scan a Bluetooth barcode containing a remote Bluetooth device’s MAC address or friendly device name and pair or unpair with that device. I’m going to go ahead and jump straight in. Those of you who are following along, I am using the latest Android Studio, 2.0, to showcase a couple of new features along with 2.0. One of the main ones is Instant Run, which is fantastic. It greatly reduces your development cycle of actually making changes and pushing to the device so I can focus on the code, the API itself, instead of building a bunch of UI code to exercise that API. I can make changes and run it really quickly. A couple of things to point out, what I’ve got for us today is a Zebra- This doesn’t look like my webcam is updating. Give me just a moment. Alright, having some issues with my webcam, but, as you can see from here, I’ve got a Zebra Bluetooth printer On the side of it, closest to the TC55, I’ve got a Bluetooth barcode with its MAC address on it. and a mobile-payment module below my TC55. I’m going to go ahead and jump straight into building an application here. For those of you that are following along, we’re just going to go ahead and create a new Android Studio application. Let’s call it DevTalks-ScanAndPair Leave everything else default here. In previous tutorials with the EMDK, we’ve directed you to choose the EMDK as your minimum SDK. In newer versions of Android Studio, that became an issue with how the project was scaffolded. In this case, we really just need to select APIs 19 or 16 as your minimum. Here, I’m just going to choose 19. Move on through the wizard. Create an empty activity. We’re going to use the default, MainActivity. Let Android Studio scaffold our application. Let’s see if we can get this to respond. Alright, good deal! So now we’re waiting for Android Studio to scaffold out our project. Looks like it’s still building here. Let’s give it just another moment. Gradle’s running… Alright, we’re ready to go. Now, one of the other features I’m going to make use of is a feature called Live Templates. It’ll allow me to build chunks of code and insert them into any one of the files that I’m working on. It makes it real simple. You can actually add in variables that allow you to tap through those templates if you want to add in code as you insert it. The first thing we want to do to make use of the EMDK is set up our project to make use of. Again, in older versions of Android Studio, you were able to select that when you’re creating a new project, or to simply go to the project structure and modify your app’s compile version. Here, we’re going to leave it to the default, the highest one you’ve got. Hopefully above 22. There are some things choices that Google’s made, and when you scaffold the application it caused issues if you choose a compile version below 21. We’ll just leave this at default, the highest that you’ve got. To actually make use of the EMDK, we’re going to modify our build.gradle file, and insert some values in there that point the build system to our EMDK jar files. I’m going to go ahead and push in here emdk_gradle_provided. So this line that I’ve added into our build.gradle for the app module. We’re just telling it that we want to include, for build purposes, our emdk.jar that’s on my file system in this case, buried in this Libs folder. It will be similar on your system, depending on whether you’re Windows or Mac. One other thing we need to point out here is even though we’re telling the build system where this jar is and that we want to use it during the build process, we want to tell it, in our exclude in the compile file tree, that we want to make sure it doesn’t get included in the resulting APK. That jar, this EMDK library already exists on the device or should. We’ve got a bunch of great tutorials online that walk you through the process of updating the library if it’s old, or doesn’t exist on, for instance, your Jellybean device. Newer Kit Kat devices will have that on them already. The next thing we need to do is go into our Android manifest and ask for permission to use the EMDK. As you can see here, we’re just asking for permission to use the EMDK. Then, we also need to tell Android that when our application is running, we want to use this library that exists in the system partition. Now, let’s see. We’ve got our build system set up, our manifest set up, and we can jump straight into plumbing everything that’s needed to make use of the ScanAndPair libraries. First thing I’m going to do is go ahead and import in all of the EMDK objects and fields that we’re going to need. This can happen on the fly. If you have Android Studio set up to automatically import those and organize your imports, it’s a pretty nice feature. But to save time here, I’m just going to go ahead and insert all of the imports we need. Ok, so we need to let Gradle sync here. Let’s go ahead and call Sync. Gradle’s going to go grab that jar file and satisfy all of these necessities. Usually, you would do that as soon as you start making modifications to this Gradle build file. You’ll usually get that banner saying it’s out of sync and you need to sync up. Again, it’s pulled in that jar file, and now we can see that all of our imports are satisfied here. The next thing I want to is pull in some globals that we’re going to use throughout the application. Let me go ahead and comment this one out. We’ll explain a little deeper later on what this StatusListener is for. But to point out the globals that we’re going to use throughout the application. Of course, there’s our emdkManager. If you were familiar at all with the EMDK APIs, this is our starting point to using any of the APIs. It deals with all the process of binding to the background EMDK library and providing us with instances of the APIs that are below it. I’m not going to spend a lot of time on building user interfaces: buttons, input fields and stuff. I really just want to focus on the API itself. So really, all I’m going to do at this point is have one TextView that’s basically a log of what’s going on and a StringBuilder to contain all the text. I’ll be inserting things at the top, and you’ll kind of see it scrolling on the screen. I think we need to go ahead in our layout, and do one thing, which is give our TextView an ID. Scroll down through here. Find our id, and I’m just going to call it tv1 for TextView one, and we should be able to close down just about everything else here and focus on our activity. Now, like I said, the emdkManager is our entry point to all the other APIs. The first thing we need to do is request that EMDKManager object. We’re going to do that in our OnCreate(). With this code, we’re going to ask our EMDKManager class to give us an EMDKManager object. You can see here that we’re passing in our application context and our activity context. You can also see here that Android Studio is not happy with this just yet. We need to make some modifications to our activity and implement a few listeners. This gripe is satisfied here. But one thing to point out, again, is that we’re requesting the EMDKManager object, but this call does not return the EMDKManager object. It only returns a results object, which basically explains whether we’ve successfully requested it or not. We’re going to be getting this EMDKManager object asynchronously, which is why we need to implement a couple of listeners to get that back A couple other things to point out here: again, in our results object that we get back, this process might take an unknown period of time, and because we’re doing this in our OnCreate(), we want to make sure we’re not blocking that in fear of giving the user an application not responding message. Again, we’re going to have our results object. This is going to block for a very short period of time. Return our results object, which will allow us to immediately inspect that results object and display to the user whether we were successfully able to request it. On other thing that Android Studio griping about here is that it’s looking for a method that doesn’t exist yet. I’m going to go ahead and add that in so we can satisfy that. In this method, I’m basically just taking in a string and finalizing that string and then calling this handy runOnUIThread method to modify our values on the UI thread, inserting a value, our text that we passed in, a line to separate stuff in the log. Then I’m setting our TextView’s value to the string value of that StringBuilder. Now, we’ve got an easy way to update our screen from asynchronous methods. In this case, I could’ve just done it directly, but I wanted to push all the messages that are going into my log into one method. It makes it a little bit easier. Let’s go back and satisfy this gripe here. It’s saying that we can’t pass out activity context here because it doesn’t implement a few listeners. Let’s jump in, and go ahead and implement those listeners. If you notice here, we’ve added in our EMDKListener, and something that our ScanAndPairManager is going to want as well, a StatusListener. The calls to StatusListener are synchronous, but the getting information back about the status of the process the ScanAndPairManager is in, for instance if we’re in the process of scanning or pairing or we’re paired, all that information will come back though this StatusListener asynchronously. We’ll tie up a handler for that. Here, you’ll notice that Android Studio gives us a nice tool that pops up here. It’s complaining that we’re not implementing these methods that both of these two require. So we’re going to go ahead and let Android Studio insert those for us. Here, I’m going to just click on Import Methods. It’s going to show us which methods it’s going to import: OnOpen and OnClose for our EMDKListener and OnStatus for our ScanAndPairManager listener I’m going to click ok. Let it stuff those values in. Alright, we’ve got our EMDKManager object requested, and, again, this is going to happen asynchronously. Once it’s done all the work in the background of binding to the service making sure everything’s up and ready to go, it’s going to call this OnOpen method passing us our EMDKManager object. Now we can take and set our emdkManager global to the value passed in so it can be used elsewhere in the application if we wish So here, all we’ve done is set our global to the one that was passed in. Then, we need to go ahead and also deal with what our OnStatus is going to pass back to us. Again, our OnStatus is coming from our ScanAndPair listener Again, this statusData is going to pass back information, status states, that will let us know what state the scanning or pairing process is in. Go ahead and add in a switch case here. Another handy thing inside Android Studio is some quick keys to organize your code when you’ve cut and pasted things in from elsewhere. On a Mac, it’s Alt-Command-L, and that’s going to push everything else and organize it properly. For our statusData that gets passed in, it has a method called getState to pull back an enum value that tells us what state we’re in. For instance, we’re waiting for someone to push the trigger, if we had told the ScanAndPair APIs to use a hard scan. And again, all these are giving us different states, and we’re going to be updating our user interface, the log, to explain what’s going on. Lastly, we’ve got an error message. If any of these fall through and an error comes through, we’re going to be able to push in our state, which we’re switching on here, into a string value as well as another method call, which is getting your result. It’s really just a string that gives us a better idea of what might have gone wrong. So now we’ve got our OnOpen method and our OnStatus that’ll deal with our asynchronous information coming back. Now, we can really start digging in and really making use of the ScanAndPair API. First of all, let’s go ahead and request an EMDK ScanAndPair object Let me organize my code So what we’re doing here is making sure our ScanAndPair object global from above hasn’t already been initialized. We’re going to take that global ScanAndPair object and ask our emdkManager to give us an instance of a FEATURE_TYPE.SCANANDPAIR. This getInstance is our method to gain access to multiple different APIs under the EMDK. By default, it returns an EMDK base, which all of those EMDK APIs are built on top of. We need to cast that ScanAndPair FEATURE_TYPE object to a ScanAndPairManager, and set our global with that. Because this is a blocking call, we’re pretty sure at this point that the ScanAndPairManager is initialized and not null, but it’s always better to be sure and check to make a sure it’s not null before you start trying to use it. The next thing we’re doing here, even though we’ve set our activity up as the listener for the ScanAndPairManager and we’ve implemented the method to do so, we also need to tell the ScanAndPairManager what is going to be handling the callbacks. Of course, Android Studio is griping here that we haven’t implemented this. It isn’t sure what it is, because I had, at the beginning, commented that out So now that we have everything set up, this allows us to go ahead and bring this up, and set our statusCallback to our activity, which again, implements the OnStatus call. So now we’ve got everything set up for receiving that information back. Let’s go and start making use of the APIs. One of the first things we want to do is go ahead and pair with this printer. Before I explain this, let me jump back over to my camera again. So I was pointing out that we’ve got a Zebra receipt printer here, Bluetooth enabled and on the side of it, we’ve got a barcode with the device’s Bluetooth MAC address in it. It’s kind of hard to see. It’s not focusing very well. Of course, we’ve got our TC55, and a nice tool here to be able to control and see what’s going on the screen a little better so we don’t have to try and see that through the camera. To break into the APIs here, one of the first things we want to do is set up the- ScanAndPairManager gives us a config object to manipulate how it’s going to function when you call its ScanAndPair method. One of the first thing I like to set up here is the NotificationType. One of the different NotificationType’s that is available is just a BEEPER, which is we’re going to play some tones on the device to tell us the state of pairing, whether there’s an error or whether it successfully happened. You can also shut this off by setting it to NONE so there are no beeps at all. The only notifications you’ll get are the Android system itself telling you it successfully paired or not. In this case, we are going to be using the barcode scanner. Let me back up a little bit, some of you may be asking why you would want to make use of this API as opposed to just using the standard Google Android APIs for Bluetooth pairing and then our BarcodeManager APIs, and marrying those together in your own code, which you can. This API basically simplifies that whole process. It’s making use of our APIs in the background as well as those Google Bluetooth APIs, marries them together to make it a really simple interface here for you to be able to configure and use the different use cases. Again, you’ll notice here if you’ve ever user our BarcodeManager APIs, our barcode APIs, there’s a whole bunch of other set up that you have to go through. This is giving you a quick interface to those things without really having to touch it. It’s dealing with all of your barcode scanning parameters for you One of the things that we’re going to do here is set up a scanInfo.scanTimeout field, which is basically saying that I want to wait for this period of time before timing out while trying to scan. Also, the next tier is our DeviceIdentifier, and what this is doing is it’s allowing us to choose which scanner we’re going to use on the device. Let’s see here. We’ve got DEFAULT chosen, and DEFAULT is going to default to whichever is the default scanner for the device. For instance, this TC55, I believe, has an internal imager. Some have an internal laser depending the device you have. It’s going to automatically use a Bluetooth scanner, if it’s attached, or you’re internal camera. In this case, I’m just going to stick with default. Also, we can set up the TriggerType for this scan Now, you really just have one or two choices. You can either do a SOFT trigger, which is going to do that with software. It’s going to kick off the scan as soon as we call ScanAndPair method and try to start scanning and wait for that five second timeout before it fails. You could also make your end user hit the scan button if you wish and then it would start the ScanAndPair process. In this case, I’m going to stick with SOFT One last thing, for configuration here, we’re going to tell it that we always want it to scan in this case. We want to make sure and do this because you can also pass in the MAC address. If you already have the MAC address of the device you’re wanting to pair with or it’s Bluetooth friendly name, you could just set a couple of variables here and completely skip the barcode scanning process. By default, I believe this is set to true, but we’re going to go ahead and set it to true. Later on I’ll show how to use the APIs if you already know that information, or, for instance, you want to allow your user to enter in that friendly name into a field, pass it off to these APIs and have it pair without having to do any scanning at all. The last thing I’m doing here before I actually go do my scan is setting it up to know what type of data this pairing barcode is, whether it’s actually the friendly name of the device or whether it’s a MAC address. So I’m setting the ScanDataType to MAC_ADDRESS. You can leave this to MAC_ADDRESS, DEVICE_NAME, and UNSPECIFIED. Now UNSPECIFIED is going to take a little longer. If you don’t really know and you’ve got a whole bunch of device’s, a mix of whether it’s a MAC address or a device name, If you set it to UNSPECIFIED, it’s going to scan the barcode and try to figure out if it is a MAC address or not, whether it has the correct number of characters and it’s in the correct format. If it is, it’s going to try to pair as if it was a MAC address. Otherwise, it’s going to assume it’s a name and go through the discovery process to find that device out there, find its MAC address, and then move on with the pairing process. It’s a lot quicker if you know what type of barcode you’re going to be scanning, but in this case, we’re going to leave it as MAC_ADDRESS. Lastly, here we’ve got some code to call the scanAndPairMgr’s scanAndPair method Older security methods in Bluetooth allowed you to pass in just you’re pin to pair with the device, Recent versions of the Bluetooth security standards force both devices to present a pairing pin and both agree with what’s going on. In this case, this is really just a dummy value. It is required. You can’t just pass in a null value. I’m just passing it a dummy string with a four pin value. It will basically throw this away when it goes through the pairing process. Much like the results object above with the EMDKManager, this is going to make the call and asynchronously we’re going to be getting values back about the pairing process and what state we need to be in and give us some information about what we need to do. This resultCode is going to immediately pass back and tell us whether we successfully attempted to do this process. Again, we’re just inspecting this results object and updating the UI if there were some errors for some reason. We’re not looking for it not to be a success, and if it isn’t a success, we can update the screen to tell the user that something went wrong. So let’s see. We’ve got everything wired up here. This first time here, I’m going to go ahead and build the application and push it to our device. There it is. Alright so, I’m going to go ahead and push this to our device. Wait for Android Studio to build our app. As I was talking about earlier, a new feature in Android Studio’s 2.0 is called Instant Run. So this first time building the application, it’s going to tack a bit, as usual. Those of you that have gone through this process before, you know that you build an application, you push it down to the device, make a simple mistake, so you name something incorrectly or use some value incorrectly, you would go back through this process every time of rebuilding the application after making maybe a one-line change. Instant Run is going to allow us to push this application down, and, while it’s still attached, if we make any simple modification, just by hitting the play button again, it’s going to look at the bi-code differences and push just those changes down to the device. So it looks like I’ve got an error. We need to dig in here and figure out what’s wrong. Oh, I know what it is. It was trying to set our TextView, and I forgot to bring our TextView to life. Let’s see. There it is. Ok. That should make it happy. Let’s see, so again, this live Instant Run is probably not going to work because it crashed. Let’s see. Yeah, it’s going to have to rebuild real quick. I was just going to say, Bill, you probably did that on purpose so you get them to straighten it out. What’s a good demo without an exception, right? Yeah, the demo gods are not exactly shining on me just yet. Ok, so now let’s see. This is probably going to time out because I took a little too long. Yeah, so basically what I did was I went ahead and pushed the application down. We got our EMDKManager object, turned on the beam so that it could start scanning, because we told it to soft scan, and it timed out because I didn’t do all this in five seconds. I’m going to go ahead and go back. One of the beauties, again, of Instant Run is I’m just going to make a simple change. It’s going to see that there’s really no changes. I don’t have anything to push to the device. I’m just going to fake it out real quick and put a space in there and push it again It should build the application. You could see that it flashed there. Our beam is on. It just scanned. It’s discovering the Bluetooth device. Oh, I know what else I did. You might want to turn the printer on for one thing. I’m going to cancel this Let our printer initialize here and get ready for pairing. Alright, it looks like it’s ready We’re going to go ahead and do that again, and we’re going to remove that space I added in there I’m going to push the Instant Run. Now what happened? I’ve seen the Vysor tool get in the way sometimes. It is beta. It somehow gets in the way It’s a great tool, until it’s not. Alright, so it errored out here. Let’s try this again. If we look at our printer, it printed out a pairing pin I’ve seen this also. It kind of depends sometimes, but I’ve also seen it go ahead and just present this PIN on the screen. I’m not really sure the sequence that allows you to do that, but here I’m just going to punch in what I see on the printer. That is paired, so let’s try this again. It did not pair with it, so we need to go back and try again Let’s kick this off one more time here. Let’s see, I’m not missing anything. I don’t see anything wrong here. We’ve successfully paired. To go back through that because it happened kind of quickly, it scanned that barcode, started the pairing process. Our printer kicked out another pairing PIN, and our device kicked a dialogue into the foreground saying that this is the pin that the remote device is wanting to pair with, do you agree? I hit yes. Now we’ve got this device paired with that printer just by scanning it and, or course, a little bit of user interaction to verify the PIN because of Bluetooth security To my knowledge, there is not a way to get past that. It’s required, and it will also be required to pair with our payment module in just a moment. We’ve got our device paired. Thinking about a use case for this, say we’ve got users in the field, a store associate, that picks up a printer out of a bank of printers at the start of their shift along with a device. They want to be able to pick those two things up, pair them together, and then, at the end of their shift, maybe they want to unpair them before putting them back on the shelf In our app, I’m going to just uncomment this line here. Again, we called our scanAndPair. The opposite of that, of course, is scanAndUnpair. We’re going to go ahead and call this, kick off our Instant Run again. We should be able to scan the barcode, which it did. You can see that it automatically unpaired for us. If we look in our Bluetooth settings, you’ll see the device is unpaired. Again, we’ve got all the necessities to scan a barcode and pair that with very minimal user input. That’s one of the last things last things I want to show off here in the API is say you’ve got a device. Its MAC address, for instance is not printed on the device anywhere. What I have is a mobile payment module. This device is just an engineering sample. The shippable products actually have our Bluetooth MAC in a barcode here on the back. In this case, I only have the device’s name. If that is the case and you know what the name of your device is going to be, you can use that in the API’s to go ahead and pair. I’m going to skip through a couple of menus here and get this thing ready to pair with. Alright, I don’t think you can really make out what’s on this screen, but it’s basically telling you is what its Bluetooth name is and telling me that it’s not connected. Now, I can go into my code and get rid of all this. Let’s go back through the code here real quick. Again, we’ve already set up our listener. We’ve told it we want to use the BEEPER. We’ve also told it that alwaysScan is false now. I’m going to tell it that we’re not going to use the scanner at all at this point. We’re just going to provide a device name. Again, this could have been passed in from some EditText field in your activity from the user or you can do what the name was of this remote device. You could pass it in. We’re telling it I don’t think this thing is necessary. I believe I can comment this out, because we’re not really setting up any scan info to tell it which type of device. I’m going to go ahead and comment that out. Same process here. We’re going to get a resultCode back. We could explain whether we had an issue or not. I’m going to go ahead and call this. What should happen is our device should automatically try to pair. Instant Run, just got to wait for the device. There’s our PIN. Now it’s wanting us to enter in this PIN. If I do it quickly enough… Device has successfully paired. So we’ve now got our payment module and our TC55 paired. We’ll be able to do payment transactions on it in our mobile payment application Again, just the opposite, we can go back into our code and when we’re done with it we could tell it to unpair. I’m going to kick off our Instant Run You should immediately see the changes take effect . It applied and automatically unpaired for our device. In a nutshell, that is the ScanAndPair APIs. Hoping for any questions. Rob, has anything rolled in yet? Yes, Bill, a couple of questions for you. That was really great. I mean, really only a few lines of code and you have all that functionality. Especially if you’re familiar with the EMDK. There is some overhead here and some set up necessary, but once you set this up, you can make use of all of the other EMDK APIs reusing this code here. Yeah, very little when it comes down to making use of the ScanAndPair APIs Right. Then you demonstrated using Zebra symbol devices, but this really applies to any Bluetooth device, right? Right, you could pair two Android devices together, for instance. Of course, they would have to be Zebra Android devices for this code to work. No, I take that back. One of them would have to be, the one that’s running this code, but you could pair to a Samsung device if you wish to. A couple of other questions came in. Can you use this API for pairing the ring scanner? No, I believe you’re talking about the RS507. In this case, that’s not what these APIs are designed for. The ring scanner is unique in that it is actually the master in this pairing process. In this case, because we’re initiating the Bluetooth pairing process from the TC55, it is the master in this pairing process. This being the slave. When it comes to the RS507, it’s the opposite. The RS507 is what’s initiating that pairing process, alerting the TC55 that it wants to pair. With the TC55, of course, you would present a barcode, the TC55’s MAC address, to the RS507. It would scan that and initiate the pairing process. These APIs do not handle that in any way. Alright, that kind of makes sense. It’s going the opposite direction Let’s see, a couple of questions. Is there a code sample for RAT Studio? I think he meant Android Studio? The best place to go is Delphi, I believe, and no, I don’t think we have any. In times past, I’ve seen code samples from both representative Java, representative RAT Studio. The functions are similar, but I don’t think we had any code examples of how to use the EMDK in Delphi. But we will post the code sample that we have with the recording, right? Yes. Alright, another question are these APIs available in the EMDK for Xamarin? Not yet. As of now and even the next release, 2.0, which is coming up soon, we don’t have pairing between the two yet. Only our ProfileManager APIs and our barcode scanning APIs are exposed in Xamarin. We are hoping to gain parody on the next release, but we can’t promise anything at this point, though. Alright. Can we use this ScanAndPair sample to pair our RF8500. That is the RFID tool. I’m not sure. I can’t answer that. I can find out, but I would imagine that you probably could, as long as it, again, does not expose the same function as the RS507. If it is the master in that pairing process, you’re probably going to get some of the same function. I did say that this could not be used for the RS507. In some cases, there are some hack-y ways to make it function, but I’m not going to say we support that. I think that once it’s paired with the RS507, you could go through that process and, with a sequence of buttons, you could make it function. I don’t think it’s a supported way, and, at this point, we don’t support that. But that RFID reader, I’m not sure to be honest with you. I would think it would, but I would actually have to try it myself and give some of that hardware a try. Going back to your code, could you show your code again? Not that one, you actually need the first example, where you were actually doing the ScanAndPair. You mentioned that some of these settings or configurations you’re setting have the default value that you could essentially use as well. Can you point out what is normally required here? To be completely honest with you, I’d have to dig in the APIs to figure out what the defaults are, but I’m pretty sure there’s a default timeout, which may or may not suite you. I believe that it defaults to, because these are namely ScanAndPair APIs, it would make sense that this would be set to true by default, but I’ll have to dig in the APIs to find that our for sure. Speaking of that, do you want to point out where the documentation is for that? If you go to techdocs.zebra.com or you can get to this through LaunchPad by going to LaunchPad and going to the Android section and choosing EMDK for Android or EMDK for Xamarin, you’ll initially get driven to this page. This is a high-level overview of all the different tools we have documentation for in this documentation system. For EMDK for Android for instance, if we were wanting to dig in and find out what those defaults were, we could go to our APIs link right here and scroll through our APIs. Let’s look for the S’s What was our question? Let’s see, our question was if config alwaysScan was necessary. Do have any idea which one that’s in, Rob? I don’t remember which one, but anyway this is where you would dig into the API listings and dig through and figure out which values would be default or not. I also think that this one may also be unnecessary, because it’s probably going to automatically default to this value Maybe you would just need to trigger whether you wanted a SOFT scan or a HARD scan. If you know the Mac address, you could probably set this to UNDEFINED as well, and it would go through the longer process of figuring out what it just tried to scan. Still pretty minimal in the configuration necessities. Alright, great. Let’s see, any other questions from anybody? Alright, I think we have all the questions answered. Do you have any questionnaires you wanted to throw up, Rob? I didn’t know if we had any polls. Yeah, when you guys exit the session, just you’ll be presented with a standard webinar survey. If you guys could fill that out, that would be great. We always look for suggestions for upcoming topics. We plan on doing these at least once a month. We may do it more. You may see other sessions pop up. We will always notify you via the DevTalk notification system. We’ll look to do another one in May, and we’ll look for your feedback to determine what the topic is. If you could kindly do that, that would be great. Since Dan or Robin may still be on the call, is there anything you want to mention from the printer point of view that may have come up in this demo? I know I’m putting you on the spot if you’re still on, Dan. Well, I think that Bill did an excellent job highlighting everything. The only thing that I would add is that we’ll be posting the recording and the presentation for this, so check back on LaunchPad to be able to find that. Bill, you did an excellent job. The demo gods were very kind to you, only a couple little issues, but you were able to work through them, so nicely done. Alright, Bill, thanks a lot. Thanks everybody for your time today and sticking through the webinar, and we’ll see you next time. Thanks, take care.