You may find it easier to export the DW configuration from a known working device and then place the configuration in the DW autoimport directory as part of device staging, as explained at DataWedge Settings - Zebra Technologies TechDocs, then you would not have to worry about doing this in your application. This sounds like the best solution here.
I do not have an example of using the DataWedge API via Xamarin I'm afraid but you would be using the Android.Content.Intent class, Intent Class - Xamarin . You would create the Intent with some bdf (basic data formatting rules) and there is a Java example showing this in the DW docs: Set Config - Zebra Technologies TechDocs (under 'Set BDF processing'). Once created, send the broadcast via SendBroadcast(Android.Content.Intent) - Xamarin
Hope that helps
Thank you for your response! I was a little leery of the autoimport solution for a few reasons:
1. Some of the research led me to people who had issues with their profile being overwritten by another app that used the same mechanism. It sounded like doing this import overwrote all profiles, so you effectively can't use two applications that use the scanner simultaneously.
2. The first item under "Notes" on the page you referenced says:
- For the best experience, Zebra strongly recommends that users be advised to exit DataWedge before new Config files are remotely deployed.
... which I am not going to do every time they bring up the application.
3. I also read somewhere that there's an amount of lag in loading the profile. Doing it once is no big deal, but causing that delay every time they bring up the app is not ok. Even if I used the autoimport mechanism, I'd prefer to have some way to check to see if it's necessary so I don't make the scanner unusable for up to several seconds each time the app is loaded.
4. Also on the page you linked is a section titled "Cross-device Import". I am developing on a TC51. I cannot guarantee that our customer will purchase TC51s. I can't have that helpful dialog pop up every time they bring up our app.
One of the difficulties in trying to figure this stuff out is that many things in forums, and documentation found by using Google are old and no longer correct. That may be the case for points 1 and 3.
To be perfectly frank, I'm surprised that you don't have a better solution for something this basic to the operation of your device. Aren't 3rd-party apps the primary use case for your scanners? The DataWedge interface is great for us application developers, except for this one point. I almost didn't have to write any custom code at all to make it work. Almost. That's awesome. I'm going to write a lot more code to tweak one little setting in DataWedge than I did to implement scanning. Jus' saying...
Yes, I see your points about having so many caveats in the documentation that it makes anybody question the robustness of the solution. There is another post where Dan lists his code to reliably import Packaging DataWedge Profile with Application . Regarding your other points, I will pass your feedback onto the development team to try and improve our process.