Zebra DEVTALK – How Xamarin Will Help You Build Enterprise Apps Using C#

, , 2 Comments


My name’s Rob Galvin. Thanks for joining us today. I am very excited to be your host for today’s session in a new series that we have dedicated just for developers. It’s called DevTalks. This is our first edition. We only announced a few weeks ago. We weren’t quite sure what to expect. We weren’t sure if you have the time for this. We weren’t sure if this concept was even important, and we were pleasantly surprised. We had close to 400 developers sign up to be notified that we’re actually doing these sessions, and for today we had almost 200 people register so we have a big crowd. Thanks for letting us know that these DevTalks are important to you. Thanks for taking the time out of your busy day to attend today, and before we jump into the topic for today, just as our first session I just wanted to spend a few moments talking about some of the things that you can expect from attending the sessions. Alright so this is a Developer Talk Honestly, we will be talking all about developer-related topics. You’ll see a lot of code, walk-throughs, and us demonstrating content and tools that will help make your life easier. Anything to do with developers, particularly around our products and SDKs, we will spend a lot of time, but also it could be third-party SDKs that we work with. It could be general topics or developer-related things that are going on an industry that we need to cover. So it’s really anything about developers. So what we will not cover is- This session will have no selling, no marketing. We’re not going to try to sell you any of our products. This is really just for development-related topics. In fact for today we didn’t even invite the product manager on some of the topics that we’re talking about. So this is really about developers. Also, we’re looking to present topics that are fresh. We’re not looking to re-present things that you may have heard many different times about our strategy and things like that. We only have twelve or so a year that we’re going to cover, so we want to make sure that the important topics bubble up to the top. Most importantly this session is really about you. It’s about you as a developer and what is important to you. That’s why we asked you when you registered to let us know about the topics that you’d like to hear. We are really going to be driven by the community on the presentations and the sessions so we cover. In fact, we didn’t even pick a session for next month. It’s really important that you give us that feedback, and make sure that since are only doing so many of these that we cover the most important topics. Please let us know. When you leave the session today, let us know what you want to hear. When you’re online in our developer community, let us know as well, and we’ll be sure to cover the topics that are important. So a few housekeeping notes before we
jump in today’s topic: first of all, we have a space on our developer community that’s dedicated just for these developer events. This is where you will see: one place to go to for all of our events. We’ll start putting in some physical events that we’ll be attending here as well. For these DevTalks, this is where we will be posting new DevTalks: what the topics will be, how you can register for them. After the presentation, we’ll put the recording here as well, and we ask you to please carry on the conversation even after today’s session. If you have other questions about what we covered today, it’ll be there, and in the unfortunate event that you have to leave this exciting topic today, the recording will be here as well. We are recording this session, and we’ll post it here to the developer events page. If you haven’t signed up for the notifications, you can do so on the page as well. Then you’ll be notified when we do new
Developer Talks. We’ll just send you a casual reminder a few weeks before the session that’s coming up. So, before we get into the topic today, let me just introduce it. Today, we’re here to talk about Xamarin. We have several SDKs that are available. Some are available now, some will be available soon. Today’s session, we’re going to basically cover the solutions we have for the Xamarin platform. We know a lot of you come from a development background and that you want to continue to use your skills and build applications
for our devices. We know Xamarin and C# and .net programming is important. We’re going to cover both the printer side and the Enterprise device side for our Xamarin SDKs, and what we’re going to do is we’re going to walk you through, making sure you’re up and running with that. That you’re set up with that, you understand the APIs that you need to use to build your applications. Although, we know how entertaining it is for you to watch somebody else code, what we decided to do today was show you a lot of code and concepts, but it’s not going to be a follow along. It’s not going to something where you need to code as we go. We’ll have some of those sessions in the future, but today we want to make sure that you have the constructs for building applications using our SDKs. You have a lot of tutorials and samples online where you can actually walk through the process. That’s what we’re going to cover today. Let me just introduce the presenters. We have two speakers. We have Bill Hecox from the Enterprise side. He’s responsible for our developer community and documentation for Enterprise, and then Quagliana, who is the ISV engineering manager for the printer SDKs. So, Dan and Bill, welcome. Dan, I’m going to actually turn it over to you now. Alright, thanks a lot, Rob, really appreciate that introduction. So again thanks everyone for joining. My name’s Dan Quagliana. I work with ISVs, as Rob said, on the printer side of Zebra’s business, and, to kick things off, we picked this Xamarin topic, because the Xamarin Evolve show is coming up next month, and Zebra’s going to be a Silver Sponsor there. We wanted to let you all know that we really do value this partnership with Xamarin, and we have a lot of developers currently working on Xamarin. As Rob said, as developers work with some legacy Zebra products, C# developers are now transitioning to other operating systems. Xamarin’s been a really good platform, for them to be able to move their apps forward. If you guys are planning on going to the event we would love to meet you in person. Attending the show will be myself and Bill, who is presenting today, and then we also have Robin West who is the main developer of the Link-OS Xamarin SDK that I’ll be going through. She’ll be there, and we have some other resources on the Enterprise side of the business, too. So we’d love to see you there. Please stop by our booth if you attend. So I’m going to dive into this new upcoming Xamarin SDK. It’s for the Link-OS framework. First, when we look at how people interface with the printers, we wanted to identify with Xamarin, what are the big operating systems, what’s the main usage. Based on that what, what we decided to do was to build a portable plug-in. That’s a type of component. A plug-in allows you to create either Android, iOS, or do a Forms app. A Forms app is one where you write it once and then you can deploy across both Android and iOS. The way that we did this, we tried to make it work with as many Zebra printers as possible, and so this will go across the Link-OS line, which is the newest printing line. It covers all of the mobile printers and a good portion of the desktop and industrial printers as well, but then we also have support for ZebraLink, which is the legacy printers. There’s a few printers that don’t fall into this category. There are some kiosk printers and a few exceptions, but really this is 99% of the printer portfolios Zebra has. Another thing that we wanted to point out here Zebra’s printer SDK philosophy had been to create a multi-platform SDK. We know that people write apps across multiple devices, and so we tried to have the APIs as similar across those platforms as possible. That allowed this project to work with Xamarin, to actually do true cross-platform development. It made it much easier. What we were able to do was all the common functions we had between our Windows Mobile, which was our base C# SDK, iOS, and Android, we’ve rolled into this Xamarin SDK. There are a couple of features in our Android SDK that were more advanced and we didn’t have in the others, and those aren’t in this, but they’re really much more advanced functionality. The basics of what you want to do and even some advanced features are rolled over here. The last thing here is this is not released yet. We’re targeting mid-April so we will have this released before we hit that Xamarin Evolve event. If you don’t want to wait the extra month and you want to get access to this, you can go onto LaunchPad or you can email the email that’s up there, [email protected], but I’m going to show you guys on LaunchPad, developer.zebra.com. This is where we try to drive and build our developer community. If you want access to this SDK or just to get other information, please go here. I’m now showing one of the printing pages. This is our “Label and Receipt” page. You can see there’s a button here “Sign up for Beta Releases.” Just send us a note there. We can work with you to get you access. We frequently update blogs and answer the discussion questions here, and there are links to getting started in API documentation, but that’s just a little plug. We do want you to go there. We try to make that your one-stop shop. In terms of the Xamarin SDK, there’s a few things you need to make sure on your system. Visual Studio is the base platform that Xamarin wants to build off of, so make sure you have that. Then you need to have Xamarin, and to be able to compile you need a license. Lastly, NuGet, which comes with Visual Studio, but we want to call that out because that’s how you’re able to pull in the Zebra Link-OS plug-in. Before we really dive into the code, I wanted to point out a few things we’re really trying to promote around Best Practices when you’re making
a printing application. My team, we have been engaging with software developers for the last 6 years, and we’ve seen a lot of common issues and how we recommend people build their applications out. We want to make sure we share these with everyone. One of the first things is when a customer gets a new printer, they want it to work with your application immediately. If there’s a whole bunch of settings or you want people to do different set-up things, see how much of that you can pull into your application so that can just be done programmatically so customers, who don’t always have as much knowledge about the products, don’t have to do that. We also recommend when you’re doing testing, you look at some really common error cases, like when the printer’s unreachable, either not connected or it’s off, or when the printer’s out of media or the media door’s open, just to see what kind of behavior you’re getting back. To kind of add on to that, it’s really nice for you to show the user of your application whether their printer is available and if it’s in those error states. That’s doing statusing. We’re going to go through some of the code on how to do that. We’ve seen from both developers and from customers that this has huge value. From the developer perspective, by putting that status in, you’re really able to differentiate your application. You provide more value to that customer as they’re trying to improve their processes and drive efficiency. That’s another thing: customers, if they see if they try to print and it doesn’t come out, they want to know why and what’s going on. One other one is checking the printer formatting language. Link-OS is our common operating system we have across the products. All Link-OS products accept the ZPL language, but that doesn’t mean all of our printers are set to ZPL by default. If you’re writing an app that’s going to interface with multiple printers, we really recommend checking what language that printer is in first and setting the language. That’s another thing, you can do that programmatically. We have the code here. We’re going to go through showing you how to do that. Those are the key things I really wanted to highlight there, and now we’re going to go through. Rather than just show some APIs, I thought it would be best to show you the guts of when you’re actually building an app that can print, what the main components of that are. Then we’re going to walk through the code of how to actually do this. Right here, we have ten steps of what we do through this printing process, but we really summarize it in the communication. How do you find what printer you want to connect to and then how do you actually establish that connection? How do you verify the settings and the actual format? We say format, that’s the layout of what you want your printed output to look like. How do you establish that? Making sure that the data you want to print is being put into your code and sent down to the printer properly. We’re actually going to go through a method that we call template-based printing. I’m going to touch on that a little as we’re going through, but that’s an optimized way to do printing. You can see, these are the core components of what we’re going to be covering. One big caveat here when working with Xamarin, if you are deploying across these different operating systems, you really need to make sure that this essentially ends up being a native application. There’s different operating system-specific things you need to make sure that your account for. Bluetooth is one that really has a few things you need to highlight. As we’ve written here, the Android manifest needs to be updated. Apple, when you’re dealing with Bluetooth, can be a little trickier. There’s a Made for iPhone requirement for establishing a Bluetooth connection. The majority of Zebra’s Link-OS products are Made for iPhone, but there’s also rules. You must pair that printer in the iOS settings first. You can’t do all of this programmatically in your application. Unfortunately that’s an Apple restriction, but that’s something as you’re building these apps out across operating systems, make sure you’re aware of those differences in how your users need to interface. First, we’re going to dive in to printer discovery: how you know what’s available and establishing that connection. The discovery is finding what is on the network. We’re going to focus on network discovery here rather than Bluetooth because, as I put it out on the previous slide, there are some differences with Bluetooth, We will, within our SDK, have developer demos that show both network and Bluetooth. What we’re trying to do here in our network discovery is, in the first section here, we’re really establishing a few variables so that we can identify what types of status we’re seeing as we’re doing this discovery. Is there an error, have we finished, have we found the printers yet? That’s what our first section is doing. Then, we are actually running this. The next section, we’re going through identifying what the discovered printer is, and if we see errors, we’re making sure those are brought back so that the user can see that. Next, we need to make sure that we actually connect to the printer. Because we’re just kind of going through a limited amount of code here, we haven’t done this, but we do want to make sure that you’re doing any of this connection on a separate thread. That way it doesn’t impact the performance of the rest of the application. Also, if the printer is unreachable because the printer is a peripheral device, we don’t want that to be impacting the performance of the app. This is pretty basic here what we’re doing. We’re identifying the printer that we found in the discovery. We did think it’s important to point out here that this is not the only way to do a connection. Discovery is a nice way to find what’s available, but you also can write code where you would just be directly connecting to a printer. We have that code there at the bottom so that, if you know that MAC address, serial number, or IP address, you can just put that address directly in and do that connection directly. Next, we’re doing this check and set printer language. This is what I talked about in the best practices. I didn’t say this before, but part of the reason we see a lot of value in doing this is that last year we evaluated over a hundred applications, testing them, and this was an issue that came up 55% of the time. People failed this test because they were trying to work with printers that had different default languages and that out of the box test failed. They wouldn’t actually print if they had the wrong language. This is something, as I said before, we really do strongly recommend. A key piece to note here of what we’re doing: in this first line, we’re writing. But what you’ll notice here, we’re doing a specific command that we have called “setvar”. This is part of a command set we have. We call them our set, get, do commands. We have over 700 of these that really let you control almost every component within the printer. This specific one is around device languages, but you really can use these right commands to focus on any of the set and the get commands. This is really something to open up the printer. You have access to all these settings. What we’re doing here is we’re setting the language to the ZPL, and then we’re getting the value. You see that there’s a “getvar,” and that’s to verify that the change went through. Then at the bottom what we’re doing is we’re doing a check. This error is not necessarily saying that the language wasn’t set, but it’s saying that any Link-OS or ZebraLink printer should be able to be set. This is another way we can check. You could be working with a printer that doesn’t work with this SDK. That was just a way that we built out to verify that. The next thing that we’re going to do is we’re going to focus on some of the actual printing here. I wanted to point one thing out to you which is a method that we call template-based printing. I have the print format, so this is the ZPL, Zebra Printing Language that’s sent to the printer to do the printing. What we’re doing here is we’re actually making a template. If you look at the printed label here, the way we have this setup is the word “Visitor” will always print. We’ll call that static text. Then we have two field boxes, the “Zebra” and “Technologies” that we’ll call dynamic. It’s a variable that’s in our ZPL. Then we’re taking this and we’re going to store it on the printer on the E drive. What this allows us to do is, in many of our customers use cases, we have these common label templates. Rather than having to send everything down, you can just send the variable text. If you’re planning a shipping label and you’re going to have 80% of your labels the same every time but you’re changing the recipient, so a name, an address, and a barcode, you can just send that dynamic data. It saves you time, bandwidth, and it’s more efficient. Another thing you can also do is if you have an image that you’re printing on your label, you can store that on the printer as well. That’s where you can really see some throughput increases by not having to send that image. You can recall that in just the same way we’re going to go through with this label. That’s kind of the overview of template-based printing. What we’re doing in this code is we’re assuming that this label format has already been sent to the printer. It’s sitting on the printer. Now in our code, what we’re doing is we are retrieving that format from the printer so that we can understand what they have and what these fields are. We’re retrieving the format from the printer. We’re calling it based on the drive and the file name. Then what we’re going to do is we’re going to be prompting the user to fill in this dynamic data. This is something maybe you’ll have a scanner set up, where you’re scanning this data and it will fill it in. You may not always have this where the user is inputting it. This may be something that’s tied into a backend system and ERP system or something like that, some kind of database and you can automatically fill that out, but we do see a lot of scanning applications where people will scan information and fill it in these forms. All we’re doing here is we’re identifying what are the fields, what is the data that is going to go in there, and then we have the UI to reflect what we’re doing there. We also talked about status checking and the value for that. Status checking is something we built into the APIs. We really try to make this as simple as possible. We just have a function for current status,. Then we have the alert where we can fill in what the actual status is. We’re only doing this if the printer is not ready to print. Lastly, what we’re going to do is send our print job down. What we’re doing here is we are taking that dynamic information that we entered previously, the “Zebra” and “Technologies,” those two fields, and we are telling the printer to recall the stored format and to print it and fill in with those fields that we put in before. Ultimately that is going to actually trigger the print event, and you’ll get your printed label based on that. So this next section is something that
we wouldn’t require, but we do recommend. For a lot of people, the printing can be a critical part of their business operations. They really want to verify whether the printing actually occurred. What we’re trying to do here is we’re trying to look did the printer run into any errors as it was printing. We’re going to be checking the status. We’re going to give it time to make sure that it’s actually printing, that we’re running through the buffer. Then we’re telling people did any errors actually come up so that they can know whether that print job actually went through. All this is doing is, outside of the discovery session that we did of trying to find the printers on the network, it’s pulled everything together, so you can see how it all lays together. This isn’t very much code at all. What we’re trying to show you is even doing some of the things we would term “advanced” and show a lot of value to our customers, it’s still very easy to implement within the code. This is functionality that we are building developer demos that are part of our SDK, and we do know that a lot of you really just look at us for how to do these best practices and take things as is. That’s what we’re trying to do here: show exactly how to do the core functionality of working with a Zebra printer. That’s the end of my section on the printing, so thanks to you guys for your time. I’m going to turn this over to Bill. Let me ensure I can get this working right. I’m going to make Bill the presenter. So my name is Bill Hecox. Today, I’m going to walk you through the EMDK for Xamarin. What is the EMDK for Xamarin? It’s a set of tools that allow you to build applications that will configure Zebra’s Android devices or build barcode scanning applications and make use of Zebra’s barcode scanning hardware. It’s designed to work with Visual Studio and Xamarin Studio, along with a component we include, a graphic user interface called Profile Manager that allows you to build XML-based profiles that you can submit to the device for configuration. To install these tools, we’ve created IDE extensions for both, all the way back to Visual Studio 2013 and Xamarin Studio 594. To get started with the EMDK, we need to install one of those extensions for either one of the IDEs. Once installed, you’ll be presented with a new EMDK menu option to allow you to install the component. Once we’ve got the component installed, then you could open up an existing Xamarin Android project or create a new one and add that EMDK component to your project. The last set up step you would need to do is modify your manifest. To a walk through the setup steps to quickly in Visual Studio, you would need to go to the tools, extensions and updates, select the online section. Then in the Visual Studio gallery, search for the EMDK. Once the EMDK is found, just click the download button. Follow the on-screen instructions. Similarly for Xamarin Studio, you would launch the add-in manager. Go to the gallery tab, select IDE extensions, and search for EMDK. Select the EMDK once it’s found, click the Install button, and follow the on-screen instructions. At that point after install, you are presented with an EMDK menu. The EMDK menu gives you all these tools at your fingertips to where you could launch our Profile Manager, which again is a graphic user interface that allows you to build profiles and fill out form fields to do things, such as setting the date and time on a device or building a wifi profile or turning the Bluetooth radios on and off, a very powerful tool. The output of that Profile Manager is an XML file that you would then submit to the device for processing. In this menu, we give you the Add tool to install the component on your development
system. This makes it available to the IDE later on to add to your project. One other piece of the EMDK is a device run time and this is installed on all recent Zebra Android devices, but depending on the version you’re running on the device, it may need to
be updated. We give you a command in the menu to update that runtime. We also give you quick access to our documentation, our developer community, LaunchPad, and our sample projects in a GitHub repo. From this menu, we can add the component to our system. Once that component’s added to our system, we can either create a Xamarin Android project or open one you already have built. Once our project’s open, in our Solution Explorer, we can right-click on our components folder and select Edit Components. The resulting screen will pop up and show the list of all the components installed on your machine and allow you to add these to your projects. Just click Add to Project to incorporate it in. In the Android manifest, you’ll need to make sure to request permission to use the EMDK and tell Android that you want to make use of the EMDK library that’s installed on the device. Now, for EMDK usage, you’ve got about 6 steps here. The main thing to start off with is
to add reference to the EMDK library. We want to request an EMDKManager object, and this object is going to give us access to the lower-level API, so BarcodeManager and ProfileManager, which are the two APIs we exposed in the EMDK for Xamarin. Once we have an EMDKManager object, we can start making use of those of those APIs. There are a few things that we need to do. Because this is an Android application, we need to make sure we deal with these objects properly, and our Android lifecycle methods are onDestroy() or onCreate() or onPause(). When you add the Xamarin component to your project, it will automatically add reference to the
EMDK libraries for you. You can see that in your Reference section in the Solution Explorer, but you will also need to add to using directives to make use of the libraries you’re going to use. Now if you’re not going to use barcoding in your application, you’re only going to use ProfileManager or one of those that are exposed, VersionManager for instance, you’ll only need to make reference to XamarinEMDK. To step right into the code here, normally we suggest you do this in your onCreate(), the first thing we’re going to do is ask for an EMDKManager object. Again, this is going to give us access to the ProfileManager and BarcodeManager. You’ll notice here that when we call this method, GetEMDKManager, we’re passing in our application context and our activity context. You’ll notice that it doesn’t actually return as an EMDKManager object. It’s returning is this results, EMDKResults. This is happening again in our onCreate(), and we don’t want to block for any large period of time in fear of getting an application not responding message. What we do is block for a short period of time request the EMDKManager, and what’s happening in the background asynchronously is we’re binding to the EMDK service. It will asynchronously give us an EMDK object via a listener interface, but with this results object, it’s going to tell us right away that if the request for that EMDK object was successful. That way we caninspect the status codes and alert the user whether there was an issue or not. Again, our EMDKManager object is going to come back asynchronously through this listener interface so what we’ll need to do is implement EMDKManager/EMDKListener interface and implement its OnOpened and OnClosed methods. You’ll notice here that this is a global that I created at the top of my project that’s accessible from everywhere in the activity. We’lll notice that when the EMDKListener.OnOpened() fires, it passes us that EMDKManager object. That tells us that the EMDK is ready for use, and we can start making use of it in our code. The first thing I’ve done here is set our global EMDKManager to the instance that already existed. Then our OnClosed() method might happen if something goes wrong with the EMDK service in the background and for some reason has to close, this method will fire. This gives us the ability to clean up any references we have, release any resources we’ve made and clean up that object. Now that we’ve got an EMDKManager object, we can ask the EMDKManager for an instance of ProfileManager. Again, I’ve created a global at the top of our activity. Here, we’re asking asking EMDKManager to give us an instance of FEATURE_TYPE.Profile. Then it will return an EMDK base object, and we need to cast that to a ProfileManager object and set our global with that. Now that we’ve got a ProfileManager object, I’m not going to go into showing the ProfileManager here, but the ProfileManager graphic interface will allow you to build those XML profiles that it will exist in your assets folder once it’s built. You would give that profile a name, and in all of our samples we make a global call profileName that has the name of that profile that we’re wanting to pass. In this case we’re going to call the ProfileManager’s ProcessProfile method, passing in that that profileName. As a result, we’re going to use the EMDKResults object. Once it’s submitted and this returns we’re able to inspect that results’ STATUS_CODE to see whether we successfully sent the profile and processed it. Now as far as passing profiles goes, you’re rarely going to get the success. The only reason you’re going to get the success is when we’re using the data capture sections of ProfileManager. Basically, configuring data through a profile. Most other profile features will return to CheckXml, because it’s using our value MX tools to configure the device. This results object will also have a results stream it will allow you to inspect XML for any errors and be able to tell whether your process submission was successful. So the last things you need to do with ProfileManager is make sure, in our OnDestroy(), that we clean up any references to it. Make sure that we null out our ProfileManager object, release our EMDK resources, and null out our EMDKManager as well. The BarcodeManager, in a similar fashion, I’ve created a global variable. Again I’m asking EMDKManager for an instance of a barcode object, in this case FEATURE_TYPE.Barcode. The EMDK basis returns. I’m going to cast it to a BarcodeManager object and set our global. Now that we’ve got a BarcodeManager object, we can actually ask it for access to our scanner hardware. In this case, I’m going to run the barcodeManager GetDevice method, passing on a DeviceIdentifier. In this case, I’m going to use the default. If I asked BarcodeManager.DeviceIdentifier.Default, I’m going to ask for whatever’s default on that device. For instance, a TC55 with an imager built in is going to give me that as opposed to the camera. In this case, we could also cast .Camera here and it would give us the camera as our scanner. To get our standard data back once you’ve scanned, we’ll need to wire an event and handle that event. In this case, we’re calling it scanner_Data, the event handler. Through the event, it will pass a collection of scanner information back, so we can pick out our scanner data and present it to the user or process it some other way. Similarly, we’re going to want to know what state the scanner is in to either present to the user that we’re idle or that we’re scanning or if we want to make if-then-else decisions upon that, whether we want to start a new scan for instance if we’re doing it via software instead of a hardware trigger. Now we’ve got a scanner. We’ve got some events wired up so we can get our data back. Now we can actually start using that scanner. First, we’re going to need to enable the scanner. Then once it’s enabled, we can pull out the ScannerConfig, modify the scanner’s configuration options. For this case, we’re enabling the Ean8 decoder parameters. Then once we modified our ScannerConfig object, we can set the scanner’s config back to what we modified. With the scanner, we can also set its TriggerType, whether we want to actually use the hardware buttons on the side of the Android device or if we want to do this via software. We set it to the soft scan, and then we can call scanner.Read(), and in both of these cases, whether hardware or software,we’ll get our information back through that scanner_data event. In order for us to de-initialize the scanner when we’re done with it, of course this would happen in our OnPause() or OnDestroy(), we’re going to want to cancel any pending reads, disable the scanner, unhook all these event handlers, and release the scanner. Again, you would want to do that in our OnPause() and OnResume(). In the case of the BarcodeManager as opposed to ProfileManager, in ProfileManager we’re basically just going to clean up any references to it when our application’s destroyed, someone hits the back button, for instance. In this case, for BarcodeManager, we want to make sure that we release any of the barcode resources, the scanner, so that if your application pauses and goes to the background and another application comes to the foreground that also wants to use BarcodeManager that we aren’t tying up the scanner resources in our application still. Again, in OnPause(), we’re going to de-initialize the scanner, we’re going to null out the BarcodeManager, and release any resources. When our application resumes, it comes back to the foreground, we’re going to rebuild our BarcodeManager instance by requesting the BarcodeManager instance again and reinitializing the scanner. Again, in our OnDestroy(), we’ll want to, similar to ProfileManager, clean up our BarcodeManager reference and release any resources the EMDKManager has. A couple of gotchas to point out with the Xamarin component. With the Xamarin component, we included the barcode sample. When you include the component in your project, for instance, and you’re looking through the component in the Getting Started document, reading about what it can do, you can also launch that sample directly from the components page. What I found is that when you launch it from there, most times on Windows, you get a path too long exception. The reason being that depending on where your project’s stored, likely your project folder inside the Visual Studio folder, it copies the whole component into your project as well as the BarcodeManager sample, so it’s too far away from the root of your hard drive. The quickest way to fix that is to go ahead and grab that sample project folder out of the component and move it closer to the root of your hard drive, and then the sample should run correctly, or you can just pull down that sample directly from our GitHub repository and run from wherever you place it on your system. One other thing to point out is that if you are upgrading from 1.0 to the new upcoming 2.0 EMDK for Xamarin, when you change versions or you remove a Xamarin component via Solution Explorer, it doesn’t delete it from your project. You’ll need to go in and physically remove that from the folder structure in your project. To learn more about the EMDK for Xamarin, of course you can always go to LaunchPad here, but we’ve also got to our technical documentation on the EMDK for Xamarin and EMDK for Android at techdocs.zebra.com. With that, I’ll pass it back to Rob Galvin Alright. Thanks, Bill, and thanks, Dan, for presenting. We reached the end of the webinar, but we’re not done yet. First of all, thanks for attending, and before we get to some of the questions, I just wanted to find out what you’d like to hear next time, and this is a part of where I see who’s actually still with us at the end of the session. Sometime in the future, maybe you’ll get a prize for sticking around to the end, but anyway, we’d like to see what you would like to hear next time. Next time is about a month from now. Like I said before, we’re looking to do these once a month. We’re looking for feedback. Do you want to see us do something deeper on EMDK for Xamarin or Android, a feature deep dive, specifically going through a follow-along code example? Do you want to see us do something more about printer SDKs and some of the different ways you can use the different APIs? What about Enterprise browser? If you’re developing Enterprise browser applications, do you want to know how to deliver the best-performing Enterprise browser application that you can? Another concept we had was called rapid fire do’s and don’t’s. This is more of we’re going to pick an area, maybe across different products, and give you some of the things that we’ve seen come into support and help do this instead type of scenarios. Then there could be other things that are outside of our scope, which are more general in terms of what’s happening in the field. What are some of the things that we need to consider when building an application? One of them I put out there I’ve been looking a lot at recently is real-time databases. If you have data, which we all do in our applications, instead of coming up with a sync engine or sync solution, how can you use some of these real-time database services instead to give you better performance? Do me a favor and fill out the survey, especially since we still have a lot of people with us and responding. I appreciate that. Thank you very much. Now, let’s get to some questions. I’ll keep the poll open for a little while. When you’re in the discovery process, you mentioned that you can specify the Bluetooth address or the network address. I guess another possible best practice would be to maybe even to pair EMDK with the printer SDKs and scan a barcode that has that information on there. Then you could initiate the connection right away. Do you see that being used out in the field? We definitely see that being used. The discovery process does take some time, so if you know the device that you’re working with, we actually see some people on the bottom of the printer will have Bluetooth information that you can scan. We see a lot of people do that. That’s really one of the quickest ways to do it. Another method that you can use is something we call Print Touch. There’s a passive NFC tag in the printer that contains the MAC addresses, and so you can write code and pull in parts through all the data that’s in that NFC tag. You can get that MAC address, and you can use that through that alternate method as well, since you already know that address. We definitely see that used a lot of different ways. We didn’t highlight that as much here just because we were doing more network-based. I think more often than not with Bluetooth, someone will know the address or they will be doing scanning to fill that in. On the network side, we do see people use discovery a little more often Bill, question for you: does the EMDK work with the Mac version of Xamarin Studio? Yes, absolutely. We support both. Install method is similar. The place where the add-in manager is different whether you’re in Windows or Mac. For Mac, it’s actually clicking the Xamarin Studio on the bar. In Windows, you’re just clicking tools to get to add-in manager, but similar process. The add-in manager layout is exactly the same on both, and access to all those features is exactly the same. Ok, another question for you, Bill. When you were talking about the component installations, the first step was install the gallery extension, and then I think to install the component. Do I need to install a component every time I build a project? Can you just clarify that a bit? Yes, when you create your project and you include the component, you’ll need to do that for every project, but adding the component from the EMDK menu only has to be done once. For instance, if you’re running both Xamarin Studio and Visual Studio on a Windows machine, if you were to install the components from Xamarin Studio onto the development system and you were to open up Visual Studio, you would also see that component. It would be system-wide that the component’s installed, but yes, each time you create a project and you want to use the EMDK, you’ll need to include the components of that project. So Rob, I wanted to add something in real quick here. Bill did a real nice job going through that install process and the setup, and I didn’t cover that on the printer side. Just so people know, there will be a readme file that has step-by-step instructions with screenshots showing how to do that process for the printer side. I didn’t do it today, but we’ll have that documented for you. Thanks, Dan. Alright, let me look at the other questions here. Another question just came in. He’s a RhoMobile developer: should I switch to Xamarin? So let me sepend a minute talking about the choices. RhoMobile is a cross-platform framework. You’re using your web skills to develop your application. Your using Javascript, HTML, and you’re running in this hybrid container. Enterprise browsers are very similar to that. It really boils down to a choice of what programming language do you want to work in? Do you want to work in C#? Then, you’re going to use Xamarin. Do you want to use web skills? Then you could possibly use RhoMobile or Enterprise browser. Do you want to do native Android? We have a solution for you. The goal from Zebra is to provide solutions for all different types of developer personas. We know there’s choices. There’s different ways to build applications, and we’re looking to provide solutions for all of them that are needed. It’s really just a personal choice. Alright, let’s see. Any other questions? Alright, so again, this session has been recorded. It will be available on our developer community event’s page. We’ll probably have it up later today or tomorrow. We urge you to continue the conversation there. If there are questions that come up after the fact, you can look at some of the samples and tutorials. Please feel free to add a comment or start a discussion on LaunchPad. We’ll be looking for those and be responding. This way, the rest of the community can benefit from the discussion as well. Also, please let us know the topics you’d like to hear in the future. I’ll kind of give one last call for last-minute questions. I can’t really tell if you’re typing or not. If you are, type quickly. Dan, Bill, any other last-minute comments? No, thank you, everyone, for a great first DevTalk. We’re looking forward to having more of these, and connecting more with you, both on LaunchPad and hopefully at Xamarin Evolve. Alright, thanks everybody for joining.
We will see you next time.

 

2 Responses

  1. Habib Sabet

    January 17, 2018 6:27 am

    The connection to the printer is wrong. You have to instantiate myPrinter first and then get the connection from it.

    Reply

Leave a Reply