I am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
Related
I want to write a tracking application, which reacts/record when users get in a car and phone automatically pair with Bluetooth hands free. I need also Id of the hands free device.
On Android it is easy, using Broadcast Receiver your app listen to broadcasts that device had been paired with phone. It is working even after phone had been restarted and App did not run after restart.
Is it possible on iOS(7+) ?
You can do it by reading the "Performing Long-Term Actions in the Background" part of this docs
Essentially, using state restoration, the system takes note of what your app was doing when it was killed.
If the app is searching for a bluetooth device and is killed by the system, the system will take care of continuing this research and wake up the app again when the bt device has ben found.
Note that this will work only if the app is killed by the system, not by the user (using the multitask bar). This behavior has changed since iOS 7.
Alternatively, If your BT hardware can be programmed to send advertisements using the ibeacon protocol, your app can be "awakened" by the corelocation/ibeacon api. After that prompt then maybe the corebluetooth pairing code could be initiated.
I tried searching around, but couldn't come up with much on the topic of this.
Is there an API or code within various Security API's that would allow some sort of passcode locking mechanism to enable whenever a device is connected (by Bluetooth, etc) and disable whenever said device is paired with the phone? An interesting concept I had thought up earlier today but can't seem to determine a method available for this.
The concept is pretty much this: if the phone is close enough to be connected over Bluetooth to the device (would be something like a smartwatch or other wearable computing) then the phone is on you and passcode entry can be disabled. However, when the device is not found by the iPhone, there is a physical distance between the two devices and the phone should lock up and not allow entry. This could even be some form of superficial lock mechanism on some apps (which exists already) that could activate based on this proximity awareness. This method is meant to failsafe by being a "lock first, then check" mentality that is paired to a specific address of the wearable computing. This could, in theory, be hacked, yes, but for general usage allows a user to have a no-maintenance method that can save some passcode entries from time to time should one find it annoying, but still want it's security potential.
Again, this idea is based on the assumption that said device connecting to your iPhone that the phone itself is searching for is physically latched to you somehow.
Thanks and I appreciate any sort of input or direction.
I am new to iPhone/iPad development and I am close to finishing up my first app and I am looking for some general advice.
I know it is important to test on actual devices and not just the simulator. What are the types of things people generally encounter when testing on a deal device that they don't see in the simulator?
The app itself is mainly a way to track online deals and that type of thing. It doesn't need anything special in term of using things like the camera or GPS.
It's just general usage testing. The device performs in an entirely different environment than your computer, and it's the best way to make sure if you push your app out to devices, that nothing unexpected will happen. For example, the phone/pad may have limited data coverage, low memory situations, incoming calls etc.. These situations are a lot more common on devices, then when people emulate it though the simulator.
On a hardware point of view, the device uses a different processor architecture than your Mac, which also needs to be accounted for (not as much as other cases, but you need to cover your bases). The Mac also cannot reliably emulate RAM, Disc Space, Processor Speed etc...hence testing on the device is useful here also.
Obviously there are some features you can only test on devices, such as Camera, GPS (and not so obviously iPod library usage), and if your app uses them it'd be careless not to test on a device.
Overall if you're intending to release your application to the App Store, or to devices at least, it's worth testing on the device itself. Only then can you be sure that it will act and perform as expected on the platform you intend to target. The simulator is only a simulator after all, not the real thing!
First of all: the user experience is very different.
The mouse based interaction is very different from a touch interaction. focusing at a monitor feels very different then looking on a device on the palm of your hand.
Also the experience of animations running on the simulator and the real device can be very different.
And the usage in the simulator won't tell you anything about the battery consumptions to be witnessed on the real device.
My opinion: every app that will be shipped to the App Store or customer for testing should be tested several different real devices. No excuses.
Simulator runs a lot slower than the real device.
Real device could run out of memory when Simulator doesn't or vice versa.
In app purchases, if you have included them
Orientations (not that
they are unavailable on simulator, but it is easy to forget it
there!)
App life cycle testing - bringing your app to foreground and
background.
Network access - can matter when you access the network from device through wireless or cellular network vs LAN/wifi on your mac. There is a huge testing to be done under the umbrella called Reachability if your app uses any of the resources across the net. You are bound to provide an alert if network is unreachable before using any such resources, as per app store requirements.
I would like to build an IPhone app that should check the identity of a BT device, by name or MAC.
If the device is not part of the MFI programme what profiles should the device support in order for an IPhone app to connect to it and validate its MAC or name ?
Cheers,
Ionut
I'm not sure you need to connect to something to get a MAC address or a name. My coworker's iphone seems to see all other bluetooth devices in our work area and displays the names, it just won't connect to them. And I'm sure it gets the MAC before it gets the name, but avoids displaying it to the user because names are a lot more friendly.
I do know that with android and blackberry, you actually use MAC addreses as your basic internal identifier, and only pull out the name when you want to identify your remote devices to the user.
If you really do need to make a connection from iOS to non MFi bluetooth radio, the advanced audio distribution profile (A2DP) would do what you want. There's a product out there I've seen that is a bluetooth controlled power board, and it used audio pulses being transmitted over A2DP to get around MFi requirements. Though you should reconsider this approach because it's problematic for a non audio device to advertise an audio profile. And this fake audio device will get seen by by a lot more than your application.
If you're happy to only work with iphone 4s and above, I've also heard rumours that bluetooth LE(4.0?) devices are not required to have the apple verification chip... but haven't really looked into it
I'm in the process of getting hardware for an iPhone prototype, and I'm wondering if it's possible to access bluetooth (ExternalAccessory, Bonjour or GameKit) exposed by development box (eg. a macbook) using the SDK's simulator as of the latest version (3.1.3 at the time of writing)
Before I get any answers on the subject, I accept that I will need an iPhone for the actual development - this is simply a prototype.
I'm not sure I understand your question entirely.
I can state that in iOS (as of May 2011) the only access you have to bonjour is through the Gamekit functionality. That functionality is fairly robust, but (for instance) you will not be able to create a BT based bonjour service that other non-iOS BT enabled devices can find.
On the simulator, even if the underlying device HAS bluetooth capabilities, you will NOT be able to perform "real" bluetooth operations. Instead the simulator will simulate some capabilities, and ignore others. You really do need multiple devices to load your code onto and run, in order to test out BT code.
Bluetooth connectivity is inaccessible using the Simulator. If WiFi is good enough for you, that works with Bonjour and GameKit on the Simulator as well. Otherwise, just like for the accelerometer and several other components of the device, you will need an actual device.