As you can see in the example app and in the skeletons, enclosed with the AN, the library is initialized in onCreate() (like all other libraries would do it) and the library is located in the main activity, because only the main activity will receive NFC intents from Android. Of course, you can have more activities in your app, but only the main activity should be able to receive NFC intents
And that's a design flaw. You are forcing the users of the SDK to have only one activity capable of receiving NFC intents and then forcing to use some complicated methods to retrieve the data.
This also doesn't make to me sense because: (1). using different threads has nothing with the problem at hand since once an activity is paused you can't access its intents. (2). Inter-app-communication in this scenario tells me that the SDK wasn't thought to be used in more than one activity (and Android doesn't restrict you to only use NFC in one activity).
If you need processing of NFC data in other activities of your app, you should do it via separate threads or use other mechanisms of inter-app-communication.
I don't understand what you mean by this. Imagine this use case: The user will be presented with an UI screen in activity A, and in this activity A will be able to receive NFC intents. Then the user navigates to activity B, with a different UI, and will also receive NFC intents. Nowhere did I state that I wanted to receive intents simultaneously in various activities.
The attempt to try to get NFC intents to multiple activities of the same app makes no sense for me, because this opens synchronization troubles
Don't worry, it isn't customer code, it is the example app enclosed in the AN which only has one activity more (a very simple one in fact). But now I see it is unnecessary for you to download it since you already solved my issue which was: The library doesn't support more than one activity.
but I do not have time to download customer code and start investigations on this code.
+ 0 | - 0