I have since changed the UUIDS for my pimrary service, yet LightBlue refuses to acknowledge the change. If I use a new phone, I notice the UUID does change, however if I change it again, LightBlue the new phone is now stuck on the previous UUID. If I press "show" for advertisement data, I notice that the UUID is the correct value!
How do I make it "forget" the old UUIDs
Thanks
Thomas
What is happening is that the bluetooth on your phone has cached the old UUIDs.
To reset your phone's cache -
Turn off Bluetooth
Exit the app completely
Restart Bluetooth
Start your app again
If this does not help, delete and reinstall the app.
If that still does not help, you should Factory Reset your Phone.
Related
In my iPhone application I would like to communicate with a firmware device. During a connection they can to ask for a pairing key but they said they are not having provision to provide what is the key to enter.
In this situation USP(User Smart Phone) never knows the key to enter. What shall we do to communicate with device ?
they said they are not having provision to provide what is the key to enter
I'm not sure I completely understand this sentence but if the user is given a device that has a specific pin/key, then that has to be documented somewhere for them. This is the same situation as it is with a SIM card's PIN. That code is set by the manufacturer and the user gets to know it when she buys the card. If the code is the same for all devices, then you can add it to your application and show it to the user in some way.
The iPhone application cannot dismiss or enter any value in the pairing dialog, this is sure.
My application uses the core location also after the application terminates with the method startMonitoringSignificantLocationChanges in CLLocationManager class.
My application launches with a location key in iOS 5 and 6 in the method:
- (BOOL) application:application didFinishLaunchingWithOptions:launchOptions;
in AppDelegate class and everything works well.
But in iOS-7 betas the application doesn't launch with a location key after a significant location change.
Has anybody encountered this problem?
I tried it on a simulator and in the device.
Thanks for the help.
I have the same problem in my app, when the app was terminated by user from app switcher.
But it does launch with location key if it was terminated by OS for low memory or other reason.
It is the expected result from iOS7 unfortunately. An official apple response I got from one of their evangelists:
If a user swipes up in the app switcher then the OS will not launch
the app unless explicitly told to do so by the user. So no, SLC will
not be launching the app, nor will silent notifications. The only
thing that will launch the app at that point is the user tapping the
icon. The intention here is that the user has expressed their choice
of not having that app running any more for any reason, so we honor
that. In this situation, there's really nothing that you can do. The
next time the user launches the app you can let them know that some of
the data may be missing, although you really cannot tell whether
there's missing data or not (i.e. you might have been killed by the OS
in the background and the user may not have moved thereby not
triggering any SLC notifications). My suggestion would be to gather
the data you can within the policies of the OS and if the user has
manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in
behavior winds up causing problems for you or (especially) confusion
for your users.
Attach link to Apple DEV forums:
https://devforums.apple.com/message/882691#882691
My App can work with or without iCloud support.
If a user connects a device to iCloud and then wants to disconnect it, it's pretty easy for me to copy all data back to the local sandbox and stop using iCloud, and this device won't contribute anything new to iCloud anymore. However, changes from other devices will still be received (although not handled) on this device.
Is there a way to completely disconnect the device from iCloud, so that new changes won't be received?
iCloud stores data in a folder called "Mobile Documents." Your app's container resides in this folder. iOS devices know about new files and changes immediately. However, they do not actually download the file until the app specifically requests it. Here's an example scenario:
Someone is running your app on their iPhone and their iPad. They use iCloud on both. However, on their iPhone they disable your app's iCloud but leave their iCloud account active. This means that their device always knows about changes. But since your app never requests those documents, they are never downloaded to the device and therefore do not take up space. Also, iOS will automatically remove the local copy of an iCloud file to free up space if necessary.
For more information, see developer.apple.com/icloud, specifically the videos on how to use iCloud.
You can simply stop responding to the NSNotifications received by your app. You can either unregister your views from these notifications, or ignore them when they're received.
Switching to custom generated device UUID's is turning out to truly be a nightmare! I am hoping someone has come across this before and might know a way to deal with it.
Assume a user has an application with a data set of 500,000 (small) records, its not feasible to simply copy the entire db of a device and merge them. A user has this application installed on an:
iPhone,
MacBook
Android tablet.
When connected to the same physical network, each device can see each other and can initiate a synchronisation.
To achieve three way data synchronisation (that does not depend on a central server or an internet connection).
Each device keeps a list of timestamped changes.
Each device knows the last time it synchronised with each of the other two devices.
When a device sees another device, it sends through all known changes since the last time they spoke to that device.
If a new device is discovered, no problem just send through all data ever entered.
The problem comes along if a user backs up their iphone or ipad, and restores it onto another iphone or ipad. Under this scenario we are ending up with a user that has two devices on the local network with the same UUID. Updates end up (randomly) going to one or the other identically identified devices.
I know we can continue to use the device unique identifier for now, but I am worried whats going to happen once its gone!
On application start you search for a file in the applications documents folder called udid.txt. If this file is not available create it and generate your custom UDID, save it to this file. Use the following function to add a flag to this file, to exclude it from the backup and sync routines.
#include <sys/xattr.h>
- (void) AddSkipBackupAttributeToFile: (NSURL*) url
{
u_int8_t b = 1;
setxattr([[url path] fileSystemRepresentation], "com.apple.MobileBackup", &b, 1, 0, 0);
}
The problem with this solution is that a user might use iPhoneExplorer or something similar to change the UDID. Try to encrypt or hide the file to prevent him from doing this.
Note: Works only since iOS 5.0.1.
You can instead store your generated device UDID in a file in the Caches directory, where it will not be backed up. When a backup is restored onto a new device, the database will be present but there will be no UDID file. In this case create a new UDID; the other instances will see this as a new instance and can push any recent changes across. You might want to change the logic so the other instances will query the timestamp on a new UDID instead of assuming the new instance is totally empty.
Before iOS 5.0, your UDID file will not be automatically deleted by the system. However in iOS 5.0 you will need to put up with the fact that it may get purged in low disk space situations. If that happens, just follow the same procedure as when restored onto a new device: create a new UDID; the other instances will see this as a new instance and push recent changes across.
As Floix said, there is a new mechanism in iOS 5.0.1 (yet to be released) which will let you specify that the file should be neither backed up nor purged.
I'm developing an application that asks for a PIN when you start it. That's not great, but I can live with it. The problem is I'm being asked to ask for the PIN each time the phone wakes from sleep, too. Combined with the OS asking for its passcode, it's too much.
Is there any legitimate way to detect if the phone has a passcode required for waking, so I can skip requiring a PIN in this case? I don't want to know the PIN and I don't actually care if it was locked (for instance, if the phone was asleep very briefly), I just want to know that the data is in some way "protected."
For AppStore or not? If the former, no way.
In 3.x, the passcode is stored on the keychain, that means you have to get into the SpringBoard process to determine whether a passcode exists and nonempty. If you are in SpringBoard, calling -[SBAwayController isPasswordProtected] will determine if the device has passcode.
I created a very ugly workaround for this same issue.