I am developing an iOS application with Chromecast. I would like to disconnect the Chromecast (stop playing the content) when the device that sent the content leaves the Wi-Fi network. Is it possible to do this? How would you implement it?
Thank you!
Are you sure you want to do this? This is against the Cast UX design, and frankly, provides a bad user experience. Also, consider a case where your connectivity to the wifi is dropped temporarily for whatever reason, do you really want to stop the playback? What if there is another sender connected at the same time, do you still want to stop it? Lets say your phone goes to sleep and loses connectivity, do you want to stop the playback?
As for the possibility of doing it, it obviously cannot be driven from the sender side since it has lost its connectivity. On the receiver side, you get a callback when senders get connected or disconnected, along with a "reason" so you need to implement your logic there.
Related
So I am building an IoT device and now I am working on battery optimizations. I am able to tell the device to connect to a central it has bonded to. This works(ish). You can observe the device connecting in bluetooth settings, but about 5 seconds later it disconnects. I would assume that since there is nothing happening and nothing asking for it, it drops the connection. I also assume that this is allowed for ANCS. What I want to know is can it be used for anything else? I would like to be able to shut off the device, not have to scan constantly in app, and have the system notify my central manager that the device has connected later (when a user wakes it up.
I know I can call
[_manager retrievePeripheralsWithIdentifiers:identifiers];
to get devices I have connected to before, but I am not seeing a way to attach unconnected ones to the manager so that when they do connect in the background, the app knows about it. Anyone have a solution for this?
Is it possible to create an app where the message is automatically sent from one device to another when both the devices are in the same geo-location in predefined range or in the wireless points like Bluetooth?
I think there must be some way to do this. Please let me know if you have any idea about the same.
In peer-peer connection, It is not possible. When the user terminates the app everything goes with it.
But if you connect it with server, you could try to implement the behavior you are looking for with a push notification with content available, which gives you some time awake to download content in the background.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
My app communicates with an external device via EA Framework. I would like to do a "soft disconnect", i.e. a software disconnect without actually physically disconnecting the device. The only way I see for a soft disconnect is to close the EASession's inputStream and outputStream. Question: Will the external device know I have closed the streams so it doesn't attempt to communicate further? Is there another way to do soft disconnect?
i think that actually is impossible to do a real soft disconnection.
i say 'think' cause you never stop learning on EA Framework (One week ago i found the showBluetoothAccessoryPickerWithNameFilter for example, maybe is useful for you for inApp-connection).
I use a EASession(s) manager to easily switch between connections. so forgot the word 'disconnection' and replace it with 'switch' :D
If you need disconnection, implements some function on btdevice-side and execute this to disconnect as soon as you receive a command from the iPhone.
I've got an iPhone, I've got a bluetooth low energy (aka Bluetooth 4.o) device. The two have connected in the past. But now they're apart. Something happened, words were said that couldn't be taken back, and now they've disconnected.
Now they're in the same room again. The BTLE device wants to connect again. It doesn't want to wait for the iPhone to call it. It's taking the initiative. It wants to talk to the iPhone, and get that app they used to share launched again.
How do I set up the iPhone code to support this?
(Wow, corny.)
You have to leave the app connecting to the device, so when the device becomes available the app will connect to it (so long as the app is alive). Just call [centralManager connectPeripheral] on the CMPeripheral, so the phone will keep listening for the device and connect immediately when it sees it. That doesn't time out, so you can just leave it running forever.
If no app is to connect to the peripheral, there's nothing the peripheral can do to change that.
This is a little late, but here's what I would do to accomplish this:
When your device wants to connect, have it advertise a special service.
Assuming the phone is already scanning for devices, it will see the service and you can auto-connect to it.
Now you can have the periphal trigger whatever you like on the central by updating a characteristic, etc.
Of course, this relies on the phone scanning at the time you need the action to trigger, but that is the nature of the beast.