Original article: http://blog.goosoftware.co.uk/2012/04/18/unique-identifier-no-warnings/
Postedby Simon Whitaker
APR 18th, 2012
If you are using the testflight SDK, you may find a slight but significant change in version 1.0 released a few weeks ago. As stated in this article, the reports returned by testflightsdk no longer contain the device's udid. In other words, in the testflight SDK console, session data and breakpoints are no longer related to a specified test device. This change is because the testflight SDK will be used in the test and production environments, and Apple now refuses to try to obtain the device's udid application.
Therefore, the testflight SDK now adds a new class method + setdeviceidentifier:. You can add the device udid to the ad-hoc release package generated by testflight, as shown in the following code (I add this line after + take: method call ):
1 |
[Testflight setdeviceidentifier: [[uidevice currentdevice] uniqueidentifier]; |
Note: You need to use a method similar to # ifdef macro to ensure that it can be compiled through test instead of just production.
This method is good, but the [uideviceuniqueidentifier] method has now been abandoned and a compilation warning will be generated:
/Users/Simon/dev/personal-Projects/apps/zippity/zpappdelegate. m: 70: 38: Warning: 'uniqueidentifier' is deprecated [-wdeprecated-declarations] [testflightsetdeviceidentifier: [[uidevice currentdevice] uniqueidentifier];
Aha!
I hate compilation warnings. If possible, I will try my best to eliminate them. The reason is simple. If I ignore the compilation warning, I may miss something important in my build log. If my build log keeps displaying 20 warnings, I am familiar with the warning content, so I usually ignore the past. When a new warning appears occasionally, can I capture it in time? This is obviously impossible. My code is always "clean" and new warnings are immediately captured.
Here, I can clear the warning by calling the delete-uniqueidentifier method, but obviously this is not my purpose. The best option is to ignore this warning. We already know the cause of this problem and do not need to ignore this warning. As mentioned above, it will mess up my build log.
The deprecated-declarations warning should be ignored. You can see the preceding clang error output.
([-Wdeprecated-declarations] indicates the error type because the deprecated-delcarations option is enabled ). In addition, you can know which class generates a warning-this is why I prefer clang more. If it is GCC, you will not get any useful messages.
By setting the-wno-deprecated-declarations compilation option of an incorrect file, you can let xcode ignore this error (select a target in xcode, click build phases, and expand compile source, double-click the file you want to add a flag ). But here, I just want to ignore this warning in a line of code. If the deprecated declaration error occurs in other codes, I still need to know.
This method uses the pargmas macro of clang. See:
# Ifdef Testing /* Disable deprecated-declarations warning. Refer Http://clang.llvm.org/docs/UsersManual.html#diagnostics_pragmas Basic Process: 1. Push the current warning to the stack 2. Ignore the warning we want to remove 3. Execute the code that generates a warning 4. Pop warning Stack -- restore the previous status */ # Pragma clang diagnostic push # Pragma clang diagnostic ignored "-wdeprecated-declarations" [testflight setdeviceidentifier: [[uidevice currentdevice] uniqueidentifier]; # Pragma clang diagnostic pop # Endif |