Closed doctor3w closed 8 years ago
What if we were to run the process the other way around. I.e. the ipad on the presenter's desk is the official source of time, and the iphone is simply a device that controls it, and also asks for the current time.
The on desk ipad won't go to sleep.
On 7 June 2016 at 16:33, drewsdunne notifications@github.com wrote:
This is probably a huge problem if you wanted to do other things while the phone was timing.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Knowinnovation/bluetime/issues/9, or mute the thread https://github.com/notifications/unsubscribe/ABLk_mtIEfXOXLXfjZ5SUaIApna35o71ks5qJdWUgaJpZM4IwVNJ .
So right now, I have it so that each device has it's own "time". Like it's hosted on all devices. So the problem isn't much that the presenter's time would stop, it's more that once disconnected, in order to reconnect, the device needs to "accept" a connection from the controller.
I already have it set up so that if the timer app is open, it prevents sleep.
Ah, I see what you mean. Hmm I wonder why my car reconnects with my phone. Is there a more permanent form of pairing that we could use?
On 8 Jun 2016, at 16:34, drewsdunne notifications@github.com wrote:
So right now, I have it so that each device has it's own "time". Like it's hosted on all devices. So the problem isn't much that the presenter's time would stop, it's more that once disconnected, in order to reconnected the device needs to "accept" a connection from the controller.
I already have it set up so that if the timer app is open, it prevents sleep.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Well, so the way the MultipeerConnectivity framework that Apple offers does not reallypair two devices. If we wanted to pair two devices like your car does one would use the CoreBluetooth framework, but I don't believe this is allowed between two iPhones. That's why they created the MultipeerConnectivity framework, for connections for things such as games or sharing between apps. Sadly this framework is limited in it's capabilities as the sessions seem to disconnect upon exiting the app because the devices are not paired but really just have a knowledge of another device.
Another possible solution to this is:
We have the Presenter device (D1) and the controller device (D2). We could have it so the presenter device, when in fullscreen mode or maybe a presenter toggle, automatically accepts invitations and then outputs its data to any new connections. This would allow anyone who disconnected (D2) to reconnect by reopening their app, inviting D1 and then immediately being synced with D1's time and is now back in control.
Right now I have something like this implemented but it's backwards at the moment and doesn't automatically accept. But that would be an easy fix. This may be the only solution at the moment unless I can find a way to actually pair two devices with CoreBluetooth. But that would most definitely restrict the amount of timers to 2 devices.
I like that idea. And maybe we add a shared Pin? Just to stop anyone from pairing at will?
On 8 Jun 2016, 17:48 -0400, drewsdunnenotifications@github.com, wrote:
Another possible solution to this is:
We have the Presenter device (D1) and the controller device (D2). We could have it so the presenter device, when in fullscreen mode or maybe a presenter toggle, automatically accepts invitations and then outputs its data to any new connections. This would allow anyone who disconnected (D2) to reconnect by reopening their app, inviting D1 and then immediately being synced with D1's time and is now back in control.
Right now I have something like this implemented but it's backwards at the moment and doesn't automatically accept. But that would be an easy fix.
— You are receiving this because you commented. Reply to this email directly,view it on GitHub(https://github.com/Knowinnovation/bluetime/issues/9#issuecomment-224739842), ormute the thread(https://github.com/notifications/unsubscribe/ABLk_uq0ULjQCJP3a1Je0-FCVU4N8Z9cks5qJziqgaJpZM4IwVNJ).
Hmm we could add a pin, set in settings when you turn on automatic accept. But is it really that much of a security issue that people will try and connect willy-nilly? Definitely do-able though.
I think the risk is very low, and we can definitely make this a feature for a future release.
On 8 Jun 2016, 18:38 -0400, drewsdunnenotifications@github.com, wrote:
Hmm we could add a pin, set in settings when you turn on automatic accept. But is it really that much of a security issue that people will try and connect willy-nilly? Definitely do-able though.
— You are receiving this because you commented. Reply to this email directly,view it on GitHub(https://github.com/Knowinnovation/bluetime/issues/9#issuecomment-224752190), ormute the thread(https://github.com/notifications/unsubscribe/ABLk_rxvMqOtdw488CupwuKlggLptjo6ks5qJ0R7gaJpZM4IwVNJ).
Alright, well it wouldn't be hard at all to write so maybe we could add that before we push it out to the app store.
Drew Dunne drew@drewsdunne.com http://www.drewsdunne.com
On Wed, Jun 8, 2016 at 7:14 PM -0400, "andyburnett" notifications@github.com wrote:
I think the risk is very low, and we can definitely make this a feature for a future release.
On 8 Jun 2016, 18:38 -0400, drewsdunnenotifications@github.com, wrote:
Hmm we could add a pin, set in settings when you turn on automatic accept. But is it really that much of a security issue that people will try and connect willy-nilly? Definitely do-able though.
—
You are receiving this because you commented.
Reply to this email directly,view it on GitHub(https://github.com/Knowinnovation/bluetime/issues/9#issuecomment-224752190), ormute the thread(https://github.com/notifications/unsubscribe/ABLk_rxvMqOtdw488CupwuKlggLptjo6ks5qJ0R7gaJpZM4IwVNJ).
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.
This is probably a huge problem if you wanted to do other things while the phone was timing.