-
Hi!
I have an iOS application that’s working OK with the new 1.17.00 firmware readers and SDK 2.3. I do also have some issues though, that I don’t know how to address.- When re-loading the GUI (which is built in React Native), I can’t get my FmSessionManager so recognise that there’s a reader connected. E.g. [flomioMW startReaders] won’t work.
- When disabling Bluetooth, the device connected still appears to be “online”.
- When switching readers (e.g. when one runs low on batteries), I don’t understand how to initialise a session with the new one, without restarting the application or setting configuration.allowMultiConnect = @YES.
- Sometimes, the session seems to have been lost, and I don’t understand how to check and eventually re-initialise a session for any reader connected.
What the above examples all have in common, the way I see it, is the difficulties in checking the connectivity status, active sessions etcetera, and ultimately re-initialize whatever’s needed. How do you propose I should go about managing these things?
On a side note: When calling [flomioMW sleepReaders] I get a message saying that it’s not possible with firmware below a certain version, but I’m already on a higher version, so that seems odd.
Also, there are some typos and inconsistencies in the demo-code provided at the docs pages, that should probably be taken care of.
Thanks beforehand!
-
This topic was modified 7 years, 1 month ago by
Oskar.
Hi Scott, and thanks for answering!
Regarding React Native, yes, we’re exposing your API:s event handlers through the React bridge usingRCT_EXPORT_MODULE(). All events are wrapped inRCT_EXPORT_METHOD()statements, like so:RCT_EXPORT_METHOD(didFindTag:(FmTag *)tag fromDevice:(NSString *)deviceUuid) { NSObject *eventBody = @{ @"uuid": tag.uuid, @"deviceId": deviceUuid, @"attribute": tag.atr }; [self sendEventWithName:@"didFindTag" body:eventBody]; }We’re implementing and exposing
didChangeStatus,didChangeCardStatus,didFindTag,didReceiveReaderErroranddidGetLicenseInfo.I’m not following what you mean by using the “delegate which returns device info”. Can you provide an example, or just expand on what you mean by that?
We do implement the
didChangeStatushook, like I sad, but it doesn’t seem to trigger under these circumstances, and it wouldn’t be practical to use an event to check the status of a device, so I gather you mean something else. When we initialise the manager, we set theflomioMW.delegateto point toself, but I haven’t found a method or whatever on that which answers my questions. It might just be though that I’m looking in the wrong place. I’m really more of a C# guy 😉Regarding the lost sessions, I’m sorry, but I can’t give you a good example. Users have reported a behaviour where the application and reader just seem to stop cooperating, and I’ve been trying to reproduce something similar in debugging. This led to the discoveries reported above, e.g. that when re-loading the GUI the session is lost, and doing things like
[FmSessionManager flomioMW] initWithConfigurationand[flomioMW startReaders]does not mend it.I thought that if I could get to the bottom of that issue, and also like I mentioned understand why it would seem as if the reader is still available though Bluetooth was turned off, I could also fix or at least mitigate the risk of whatever it is that the end users are experiencing.
You must be logged in to reply to this topic.
