Greetings all seers! My PeerGroupManager based iOS app keeps a reference to a remote object around for the duration that the app is running. Frequently, the remote object will stop responding at which point, i'll nil it out and create a new one via:
self.myRemoteProxy = nil; self.myRemoteProxy = [self.peerGroupManager getRemoteObjectWithClassName:className forPeer:peerID inGroup:groupName onPath:objectPath];
This usually reestablishes the connection but we often have to quit the local or remote app in order to get them communicating again (the use case for our app makes it more convenient to force quit on the remote device.) Even though the remote object does not respond to method calls (they time out) both the local and remote devices still receive signals broadcast by a third device.
My questions are:
- Am i doing this wrong by keeping the remote proxy around or should i call getRemoteObjectWithClassName: every time i want to call a method on a remote object?
- Are broadcasted signals somehow more robust than point-to-point method calls? Should i implement this communication as a signal?
- I shouldn't have to tear down the entire alljoyn stack on the local device, should i?
Thanks so much.
[Updating the original question as opposed to commenting on @bspencer's answer since comments are limited to 300 characters]
Thanks so much for your answer @bspencer, your support of the community is greatly appreciated! Earlier in our development cycle we found the didLoseAdvertisedName and didFindAdvertisedName PGMPeerGroupManager callbacks to be unreliable. If i recall correctly, we would only receive didFindAdvertisedName the first time that the device encountered the name. If the remote advertising device disappeared and came back, the didFindAdvertisedName notification would not fire. Instead we rely on manually reconnecting to the remote device (via the snippet included above) whenever a message to the remote device fails to send. I should note that the above snippet does not include where the peerID comes from. The remote peer advertises a name via PGMPeerGroupManager's createGroupWithName. This lets us look up the peerID for the remote device via PGMPeerGroupManager's getHostPeerIdOfGroup (we don't use the group for anything else and no one joins it.) Thus, even when our proxy object isn't valid anymore, we should be able to get a new proxy object pointing to the correct device.
I think that what we've implemented is equivalent to your suggestion with the exception that we create our new proxy object on demand, not in response to the session lifecycle callbacks. Do you think this should work such that we should always be able to reestablish communication with the remote device after recreating our proxy object? If not, would you recommend trying the lifecycle callbacks again? Do you have any other recommendations for how to make this communication more reliable or see any problems with our approach? Our fallback right now is to literally kill the app on either the local or remote device so that they will reestablish communication when the app returns.