I have been working extensively testing out the BLE capabilities of the iPhone 4s as well as the iPhone 5.
At the moment, all I have been accomplishing is pulling in the advertisement data from multiple TI BLE keyfobs and populating a UITableView with the kCBAdvDataLocalName, ManufacturingData, and ServiceUUIDs for each respective device.
Basically, as I pull in the advertisement data, I am also pulling in the peripheral's UUID and using this to populate the datasource array for the tableview. (i.e. if a new UUID is found and it is not in the datasource array, add it to the array and use that to retrieve the respective peripheral).
With the iPhone 5 this works flawlessly. However, when I test with an iPhone 4S (and I have tested with multiple) the BLE hardware pulls in NULL UUIDs therefore preventing me from adding any peripheral's info to the datasource array. In my console log, the phone does indeed discover each peripheral, and displays its localname, and manufacturing data, but every single device has a null UUID.
I have also ran my testing app on a 4S and a 5 simultaneously with the exact same code, and it will work on the 5 and not the 4S. So I was wondering if anyone has been having this same issue, whether it was a bug in the SDK or the hardware, or if there is a known workaround? Any feedback will be greatly appreciated, thanks.
The problem in iOS 6 is that the UUID's are not generated until you've actually connected to the device. UUID's are generated on the iOS side for each peripheral, so that's why you'll typically see a different UUID for the same peripheral when using different iOS devices. I usually check the UUID, and then if it is NULL, I will go off of the name. If the name is NULL however, then I do not populate it in the device list. Your other option is to quickly connect and then disconnect from the device. A big time hack, but it will generate the UUID and then be non-null from then on. Supposedly this problem will be fixed in the next version of iOS.
Related
Specifically for flutter apps,
One way is to get the device id and then for each analytics call check if it is a test device or not. Is there a better way or function to do this at app level?
What if my test devices keep on changing all the time?
I think I found a way to make that happen. Of course, you have to do the query about which device it is, depending on how you recognize a test device. Probably via packages like "imei_plugin". We recognize this by the APi the app is connected to.
If you know that the device is a test device, then all you have to do is the following:
FirebaseAnalytics.instance.setAnalyticsCollectionEnabled(false);
or true if you want to enable the collection of data.
I am developing an iPhone application and a Mac application that communicate with each other via Bluetooth LE. The iPhone is the central, and the Mac is the peripheral. I would like the iPhone application to be able to reconnect to the Mac application after a relaunch. Therefore, I save the UUID of the peripheral representing the Mac in NSUserDefaults, and then when the iPhone app launches, I call -[CBCentralManager retrievePeripheralsWithIdentifiers:], passing in the UUID. Although this method returns the peripheral, when I call -[CBCentralManager connectPeripheral:options:], the iPhone never reconnects to the Mac. According to this SO post, the problem is that the two devices need to be paired so that the UUID of the Mac is persistent. This brings me to my problem. I cannot for the life of me get the iPhone and the Mac to pair. According to this page of the Core Bluetooth Programming Guide, the way to require a paired connection is for the peripheral to set the characteristic's properties and permissions to the appropriate values. I quote:
You can ensure that only trusted devices have access to sensitive characteristic values by setting the appropriate characteristic properties and permissions. To continue the example above, to allow only trusted devices to retrieve a member’s email address, set the appropriate characteristic’s properties and permissions, like this:
emailCharacteristic = [[CBMutableCharacteristic alloc]
initWithType:emailCharacteristicUUID
properties:CBCharacteristicPropertyRead
| CBCharacteristicPropertyNotifyEncryptionRequired
value:nil permissions:CBAttributePermissionsReadEncryptionRequired];
However, this does not work. Even when I set the correct permissions and properties for the characteristic, the iPhone can still read/write to it without a pairing dialog being displayed. Elsewhere I am told that the way to initiate pairing is for the peripheral to reject a read/write request with an insufficient authentication error. According to this post,
To pair, you need to respond to a write request with an insufficient authentication error. For example, for an iOS peripheral you would write something like:
- (void)peripheralManager:(CBPeripheralManager *)peripheralManager didReceiveWriteRequests:(NSArray *)requests {
...
[peripheralManager respondToRequest:request withResult:CBATTErrorInsufficientAuthentication];
...
}
But this still doesn't work! When the Mac rejects the write request with an insufficient authentication error, the iPhone receives a -[CBPeripheralDelegate peripheral:didWriteValueForCharacteristic:error:] callback with an error that says, "Authentication is insufficient." No pairing dialog. I have no idea what to do and am considering dropping Core Bluetooth altogether if I cannot get this to work. If you have any idea how to get this to work, please let me know.
From Apple DTS:
"I have checked with other engineers here and we don’t believe that the pairing popup is possible between two iOS devices, but an iOS device and a BLE peripheral."
So, pairing popup happens only between a iOS/Mac app and a peripheral. rdar time.
I have an app that I have been working on and I am now at the point that I want to integrate some interaction with an external device via the dock connector. The device that I am using (the iDive 300) conforms to the Made For iPod program. I have written a separate simple app based on the EADemo code to gather information about the device. However, when I run this app the iDive reports nothing for the Name, Serial Number, Firmware, etc and also says that no protocols were found. I know this simple app is working correctly because I have connected to several other external devices and the Name, serial number, etc is populated for each device.
The other odd thing is that the iDive seems to work properly when plugged into my iPhone 4 (i.e. it will increase the volume and play songs and videos found on my iPhone via the buttons on the device). Shouldn't this mean that some protocol is in place for this device to communicate with the iPhone? Is it all possible for me to read data from this device (e.g. capture when the 'play','menu', or other buttons are pressed) if I don't know the protocol?
I am completely new to the External Accessories framework and any help is appreciated!
You should autopsy the app that is associated with iDive. In its info.plist, there should be a key:
UISupportedExternalAccessoryProtocols
whose value is an array(See this for the formal definition), and within it lies a string whose value looks like a reversed domain name, as the device protocol.
You should edit your Info.plist, add the key('Supported external accessory protocols' in plain English) for an array, put in the protocol as its item.
There's no guarantee that an accessory actually uses EA. It may communicate using the protocols defined by Apple.
EA is only necessary if you want to communicate using your own proprietary protocol.
Check the EADemo example from Apple... If it doesn't show up in the demo app, it's not EA.
I have developed a server based app for iPhone. But according to client requirements and to avoid overloading on server side, i am required to store data on local end. It is all text and typically 2-4 MB in size.
For this i'm using NSUserDefaults instead of sqlite or CoreData.
The app has been tested successfully for around 2-3 months during it's development as well as post development testing and never shown any type of inconsistency in data storage, updation or deletion on any sort of iphone device from iphone 3G - iphone 4S.
Now there is an incosistency issue in the live app, when user leave the app idle on a screen for around 15-20 minutes and doesn't press home button means app is not in the background.
In this case, data seems to be lost.
But as soon as refresh app, in that case data appears again & app starts functioning normal again.
Here lies the main problem that when i'm refreshing, i'm doing nothing but only fetching fresh data from the server it can be simply one to five records or nothing at all.
Then app is refreshed, all of the records are shown & it functions normally.
I have been trying to spot the issue for around 3 days, and it's not happening on my device (iPhone 4S). As far as i can think, it seems to be problem with the old devices.
Previously in testing, none of this happened on old or new devices.
My questions are -
a) Is this an incosistency in my coding?
b) Are NSUserDefaults not trustworthy for database management for live apps?
c) Is it a device version specific problem related to NSUserDefaults?
Anybody faced/facing the problem with NSUserDefaults??
Please suggest me something i can do for this or tell me i have to do all the database work again for the next version using sqlite or CoreData.
Anyhow this is critically important and needs to be fixed.
Any help is appreciated in advance.
As my suggestion for you please introduce the Sqlite database integration because of the when the short size of the data store and of cause it's good rather then the Sqlite but it's not working into large number of the data that time must use the Sqlite or coredata.
so i suggest to use the Sqlite data and coredata.
The function
[[UIDevice currentDevice] uniqueIdentifier]
Is deprecated in iOS 5 and I found the solution in this project using the MAC address: https://github.com/gekitz/UIDevice-with-UniqueIdentifier-for-iOS-5
Ok, it is solved. But now I discovery that iOS 5 CHANGED the format of code that uniqueIdentifier return.
In iOS 4.x it is in this format:
93F38DEB-3C0B-5C09-B746-0DFDFDDB297C
Now the iOS 5, the same function return in this format:
93f38deB3c0b5c09b7460dfdfddb297c
Anyone know if the code changed at all? It is different only is format or the code in really different for the same device?
A MAC Address is a (supposedly) globally unique identifier attached to a network interface, though they can be changed in many ways.
The uniqueidentifier that Apple used to provide access to was attached to the device hardware and not changeable, which made it excellent for tracking a user across apps and sessions. That's also the reason Apple is removing it, if I had to guess. Not having a way to track users across apps and sessions increases a user's privacy on their devices.
I wouldn't be surprised if Apple removes access to the MAC Address eventually for the same reasons, so it might benefit you to examine other options for tracking devices.
[[UIDevice currentDevice] uniqueIdentifier] will still give you the same result as before. The project that you link to is not a 1:1 replacement, it is an alternative that gives you a similar solution using a different implementation, thus the two string are different.
You shouldn't use unique identifier on iOS 5. That's all you need to know.
The unique identifier on iOS was always something redundant and a big security threat. Other operating systems don't have unique identifiers and they can live without them.
You can always generate unique identifiers on your server and send them to your device.
You can always generate them from some unique system property (e.g. MAC), using system functions. On iOS you can create a unique identifier using CFUUIDCreate. This identifier is unique across devices and across time (you'll get a different identifier every time you call it) but you can save them (e.g. into keychain).
The code CHANGED!!!!!
UniqueIdentifier is no more UNIQUE!!!
The first format have 36 hexa lenght
93F38DEB-3C0B-5C09-B746-0DFDFDDB297C
The second have 40 hexa!!!!!
Because this, it changed. I don't know if it append more hexa to identifier, but the bigger size changed al all.