I can pair the phone with tv by url paremeter setting.
example:
https://www.youtube.com/tv?pairingCode=xxxxx
However, when I launch cobalt first, and then pairing by pushing the cast icon on phone.
It can not paring tv and phone.
Can the smooth-pairing worked on Cobalt?
Smooth pairing doesn't work yet due to Cobalt's security model. This should be fixed by the end of Q1, in the next several weeks.
Related
I am looking for a simple app (preferably for iPhone, but if not then for Android), which pops up a message when it receives a signal from a beacon.
The beacon is a Sensoro 4AA, we only purchased it for demonstration purposes.
The idea is: once we turn the smartphone's bluetooth on, the beacon is detected and the message just pops up.
Is there such an app (as simple as can be), where I can just insert the beacon's details (uuid, addtess, or whatever is needed) and maybe some text or link, in order to achieve that?
Thanks
You can use Beacon Simulator for Creating, broadcasting and Scanning Beacons as per your needs and testing.
For Android: https://play.google.com/store/apps/details?id=net.alea.beaconsimulator
For iOS: https://itunes.apple.com/us/app/noteacons-beacon-simulator/id1136196655?mt=8 or https://itunes.apple.com/us/app/dropbeacon-a-beacon-simulator-for-development-purposes/id866760594?mt=8
I hope this helps!!!
I have had a pack of four jaalee beacon stickers delivered and I'm having a problem getting them 'woken up'.
According to the website, you have to tap the beacons two or three times. I've tried this a few times but still no cigar, I can't detect them using various bluetooth sniffers.
I'm wondering if I'm tapping them too hard, too soft.
Also found a Jalee app which asks me to press a button on the stickers, no button is visible but I pressed for a few seconds and one of the four stickers 'beeped' once... but the app failed to pair with it. I couldn't get the sticker to beep again.
This was a cheap alternative to Estimote stickers I ordered but which never arrived. So far, beacon sticker technology doesn't seem to be 'there'.
The beacon stickers I have need a few things to happen to be enabled.
1) Download the Jaalee app, I'm not sure it was available when my stickers first arrived. This is the correct app for iPhone for the kind of stickers I have.
App store link for Jaalee thinnest smart tracker... app
2) Open the app and select a kind of activity to which the beacon is to be enabled (they are trying to ape Estimote I believe). I chose the magnifying glass.
3) On the following dialog select + to add a new sticker.
4) Squeeze the beacon sticker firmly in the centre for several seconds until it beeps.
5) Hold it close enough to the phone/mobile device running the app to enable the app to pair with the beacon and enable it.
At this point the Jaalee beacon should be detectable with a standard Bluetooth sniffer app such as 'LightBlue'
Firmly tap the beacon on a table and it should beep. You may need to turn it over a tap the other side. They need a firm tap.
Once woken up it will be available to connect to and reconfigure. If left it will go back to sleep after about a minute.
I've seen claims on the net that the newly released iOS 7.1's iBeacon support.
Specifically:
The system is supposed to still notify your app about
didEnterRegion/didExitRegion events, even if the user explicitly
kills your app.
didEnterRegion/didExitRegion notifications are
supposed to be faster from the background and/or with the device
locked.
I have not been able to confirm either of these claims with my own testing. In fact, I seem to be less likely to get didEnterRegion/didExitRegion notifications from a locked device. (more accurately I seem to get didEnterRegion notices, but not didExitRegion notices). That could be because Apple made me remove my BLE background mode entries in my info.plist - I'm not completely sure. I'm still trying to sort this out.
I had trouble setting up my tests at first, but I have witnessed background region entry callbacks after killing an app in iOS 7.1 on both iPhone 4s and iPhone 5s models. See comments below for testing details and instructions to reproduce.
I have also done tests on background detection times on an iPhone 4S, and I still see delays of 15 minutes on iOS 7.1. My full test results and methodology are described here.
Finally, I have also done some tests on the fluctuations on the "accuracy" (distance in meters) measurement on the same device before and after the upgrade to iOS 7.1. I do not see an obvious difference in the noise on the estimate. The graphs below show results before and after the upgrade, with an iBeacon 0.5 meters away for 60 seconds then moved to 3 meters away for 60 seconds. In both cases, the transmitter was a properly calibrated iPhone 4S w/ iOS 7.1 and the receiver was an iPhone 5S.
iOS 7.0.6 Estimated distance
iOS 7.1 Estimated distance
As has been mentioned in several articles circulating around the internet, beacon sensing is available even when you swipe your app away from the multi-tasking view. However in my experiments, a region enter/exit event doesn't call the didDetermineState: directly (Probably because I hadn't been using the AppDelegate to initiate any beacon sensing but instead triggering monitoring based on UI events). Instead if you have registered for Background Location Updates, your AppDelegate's didFinishLaunchingWithOptions: method would get called with the value for key UIApplicationLaunchOptionsLocationKey in the parameter launchOptions set.
You can do a simple check like this to test if this is indeed a location update that has bought your app into the background to perform some task.
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
You can then either register your monitored regions again or start ranging immediately.
P.S. CLLocationManager retains your previously monitoredRegions on app restore but without starting monitoring again using the same UUID and identity, you would not get the enter/exit region event in CLLocationManagerDelegate (which had brought your back up to life)
David has done some wonderful work on this, so I'm writing this cautiously... but I'm seeing something quite different from him in my tests.
I'm using two phones: an iPhone 4S running iOS 7.1 (11D167) and an iPhone 5S running iOS 7.0.6 (11B651). My iBeacons are manufactured and sold by Bluecats (www.bluecats.com), although I'm not yet using their SDK (ie. I'm just using CoreLocation) and I don't think the manufacturer makes much difference.
I'm getting response times of around 1-2 seconds on both devices when the app is running in the foreground and also when running in the background. The only difference is when I remove the app from the app switcher: iOS 7.0.6 never responds (or perhaps will do in 15 minutes), but iOS 7.1 responds in roughly the same time. When I say "respond", I mean that the CLLocationManager's locationManager:didDetermineState:forRegion: delegate is called by iOS.
I'm testing by actually wandering around my office with phones in hand, so I'm physically moving in and out of range. Strangely (?), in my early testing, where I was sitting at my desk and simulating moving in and out of range by removing and reinserting batteries, I was seeing much slower response times. Perhaps this is part of the difference?
In my testing I have seen the presence of a beacon go un-noticed by an app for up to 15 minutes, but I found something that's interesting. I'm using RedBearLabs mini BTLE sensors as ibeacons and their app to program the beacons, http://redbearlab.com/ibeacon/ (http://redbearlab.com/s/MiniBeacon_v1.zip), seems to have an something in it that immediately starts a scan / update of beacons. If I start a beacon up, and in my app it goes unnoticed, by starting then quitting the MiniBeacon app my app immediately notifies me that there are new beacons. This is the same result when entering or exiting. Their app uses CBCentralManager, which my app doesn't, so maybe a mixture between CBCentralManager and CLBeaconRegion is the way to go? I imagine CLBeaconRegion starts / restarts the bluetooth radio, so maybe that is the reason for this. Just taking a stab at it in hopes that someone with a more complete understanding can help resolve this.
Thanks
My testing also reproduces 15 mins to start scanning when my app is in background mode on iOS7.1.1. Just a bit curious, I have seen quite many youtube videos from different companies showing the app has been waken from background mode as soon as they approach their beacons. Is it sales trick?
I did everything verbatim on this sample (How do I discover a Chromecast device using Android?).
The chromecast icon turns to white on indicating there are devices available.
When I pressed it, the application unfortunately stops.
What can be going wrong? The only step so far I want to achieve is list all available devices.
Cheers!
I've been working on a Windows Phone 7 app for a few months now and have a collection of useful detection flags that are used to test for things like if the code is running in the emulator, on a background/foreground thread, or at design time. (see full list here)
I now want to add a new flag that will check if the phone is connected to a desktop using a USB cable to prevent issues that users are reporting. There are certain operations that are blocked while the phone is connected to the Zune software, for example you cannot use the camera (it will just open and then immediately close with e.TaskResult == Microsoft.Phone.Tasks.TaskResult.Cancel). This causes my app to think that the user canceled the photo, which the user miss-interprets as the app not working correctly.
I'd like to detect when the phone is connected to the Zune software and provide a message saying the camera will not work until they disconnect it. Is there any way to do this?
Gabor Dolhai has a full blog post on Zune Detection and Network Awareness, which uses a combiantion of NetworkInterfaceType detection and the NetworkAddressChangeed event.
Testing for NetworkInterfaceType being Ethernet gets you close, but not quite there - as this isn't sensitive to the status of Zune vs WPConnect for the connection. Also, reading NetworkInterfaceType also can prove to be less than a walk in the park.
Handling the resulting exception seems to be the reliable method, however the exception does appear to vary between some media APIs, so keep an eye out for that.
After reviewing the answers from Mike and Derek, I Decided to go with a simple timer to detect when the CameraCaptureTask returns faster than expected. This is done by adding the following right before the call to start the capture task:
State["CameraCaptureStart"] = DateTime.Now;//Save start time to detect fast cancel from zune software
Then when the capture finishes you can detect if it returned too fast:
//Detect if task returned too fast
if (State.ContainsKey("CameraCaptureStart"))
{
DateTime dtStart = (DateTime)State["CameraCaptureStart"];
TimeSpan ts = DateTime.Now - dtStart;
if (ts < TimeSpan.FromSeconds(3))
{
MessageBox.Show("Error: Camera does not work while phone is connected to the Zune software.");
}
}
In my testing the fastest I could load the camera, take a picure, and push the accept button was around 5-6 seconds, where as the Zune software would automatic cancel and return in around 2.5 seconds.
This approach is simple and works well for my situation, however you should be aware that the error message will also be displayed if the user presses the back button before the 3 second timeout has elapsed.