Hello Brock, How are you handling the EMDK objects in the lifecycle methods of your Activties?
Typically within the onCreate of the Main Activity I create an object to hold the EMDK objects. The on the OnDestroy I clean up. There is nothing within the OnResume/OnStop.
Reviewing a clients application, same setup, create EMDK objects within the OnCreate, clean up in the OnDestroy.
More information: I built and tested multiple EMDK sample applications, no problems. Switching back/forth between applications, no problems. But all the examples appear to supply the XML data within the processProfile method, like:
profileManager.processProfile(_profileName, ProfileManager.PROFILE_FLAG.SET, profileArgs);
The difference between the sample applications and my application:
1. The Sample Application builds the XML and sends to EMDK. My application is depending on EMDK pulling profile from EMDKConfig.xml
2. Within my Application is a launcher (not sure if it matters).
I will reboot the device, my application/launcher starts. EMDK profiles are set.
I start one of the Sample applications, it works.
I go back to my application and attempt something that invokes EMDK, those features fail.
Could you please change the code to get profile manager object when you need it and do the job, and release it. This will allow the apps to use their own config files. Same this should implement in both apps.
Get EMDK Manager Object in onCreate
Get Profile Manager object when needed, push the profile, release profile manager.
Release EMDK Manager in onDestory.
Otherwise accessing EMDK APIs from different threads/ apps simultaneously is not allowed.
Thanks for the pointers. Our code follows the sample applications where Profile Manager object is retrieved in the onOpened callback within the EMDKListener. I have attempted to update the code to grab the Profile Manager object in the worker thread, but this does not seem to help.
I did notice that the 3rd party application that has been causing me fits does not work in any callbacks, all calls are done with the UI Thread. I'm not sure if that is the culprit.
I do notice that once the 3rd party application loads, then any Zebra Sample applications fail.
Charitha and Bill,
After much research and testing, here are our steps to recreate the original error:
1. Build and install 3 Sample EMDK applications (clock, wifi, app mgr).
2. Run each application and invoke the appropriate functions that use the EMDK profile manager.
3. Bring up the running task list, and swipe one away. The swipe will cause the Activitiy onDestroy method to be invoked, thus causing the Emdk Manager release to be invoked. (when running adb shell ps, you will notice the process is gone for the swiped application).
You might have to swipe 2 applications away, but leave the 3rd running.
4. Bring up one of the remaining applications via task switcher and invoke the method. It will fail with the original error of "Caught exception : null".
At this point, EMDK is non-functional as long as ONE APK has access to the EMDK Manager.
The only way to get EMDK service working again is to Reboot Device or close ALL applications via Swipe, thus releasing all acquired instances of EMDK Manager.
This is using EMDK 18.104.22.168
It is almost as if the underlying EMDK service is releasing ALL instances to the manager/profiles when one application invokes the EMDK Manager release method.
Feel free to contact me offline to discuss this further.
As i mentioned earlier, EMDK is still not supported to be used from multiple threads/ apps same time.
As i suggested earlier, using EMDK APIs only when needed might solve this to a certain extent. Is it possible to send us (to Bill or to me) a code snippets from you apps, we may suggest a better way to workaround this.
Try to clear simultaneous calls from apps using something like:
Get EMDK Manager when needed, get Profile Manager, Push profile and release EMDK Manager when done.
Yes, I have modified my code to get the EMDK, use it, then release it. But, all the EMDK Samples that are provided do not follow that model, thus other developers will eventually fall into the same trap.
it is great to see that it is working for you. As it is not a supported scenario, it is not required to implement in samples. Proposed is just a workaround till we support it in near future.