currently I'm in the stage where I'll be integrating GameCenter into my games.
I saw these 2 authentication methods in the documentation
authenticateHandler
authenticateWithCompletionHandler: (Deprecated in iOS 6.0)
My question is, which one should I use?
Because my games will be supported by the minimum iOS which is 4.3 and up until 6.0
If I use authenticateWithCompletionHandler: , it says will be deprecated in iOS 6.0
If I use authenticateHandler property, I wonder does iOS 4.x and 5.x able to run it?
Hope someone can explain to me, I'm confused by the compatibility now :(
Usually it is safe to use deprecated methods if you want to support older devices or iOS versions. It does not mean that the function is removed anytime soon... It's just a hint that a better or newer version of the function is available.
If the new function offers something the old don't, you could check if the function is available at runtime (respondsToSelector) and if not use the old one.
Related
First of all, let me tell you that I'm using xcode 4.6.3 and iOS 6.1. I have been trying to build connection using AFNetworking or CocoaPods. it throws errors due to backward compatibility issues. Current error is xctest/xctest.h Is there any way out to this problem? I'm highly confused on this. Any help would be appreciated.
What version of AFNetworking you are using -
AFNetworking 3.0 is the latest major release of AFNetworking, a delightful networking library for iOS & Mac OS X. To keep this library maintainable moving forward, 3.0 removes all support for the now deprecated NSURLConnection based APIs.
https://github.com/AFNetworking/AFNetworking/wiki/AFNetworking-3.0-Migration-Guide
I hope this will help.
I'm playing around a little bit with a hooked DirectX 9 application. As you may know, the D3DX framework has been deprecated in Windows 8. Microsoft advises us to "investigate alternative solutions to working with the Direct3D API". What are alternative solutions to using the handy D3DXCreateFont in Windows 8? I am working with DirectX version 9. If I am still able to reference the D3DX framework somehow in Windows 8, this is my preferred solution.
Use D3DX.
In this particular case, because you are hooking an application already using DirectX 9, using the libraries and resources provided by that version of the API is your best solution. When working with D3D9, using D3DX for the utility functions is perfectly acceptable and recommended practice.
The recommendations apply to software designed for Windows 8. While your software may be intended to work on that platform, hooking into applications that was not imposes significant restrictions. You have to work with what's already in use, and in this case, D3DX is going to be far more compatible than trying to rope in new libraries. In fact, given how many D3D9 and earlier apps use D3DX, there's a good chance it's already in use, and you may be able to just reuse that.
Note that this does not mean the D3DX DLL(s) you need are present; depending on the application, there may only be a single version present, so you may need to provide the DLL(s) or installer.
I have developed an application using xcode 4.3.2 with ARC enabled ,my app users having ios3.2, ios4.0,ios5.0 devices how can I give support to lower version ios device uses .Should I need to do anything in code side . or Is there any way set ARC dynamically like.
Any have any idea regarding this plz share with me.
Thanks
ARC is not device- or OS-dependent (see note below). It is a LLVM compiler feature (which can be disabled using the -fno-objc-arc compiler flag). The compiler manages the memory instead of the programmer. The final executables will not be very different from one another and will work on the minimum OS specified for your project (if you are not using ARC-specific keywords, etc.).
Note:
According to Apple's Transitioning to ARC Release Notes from Apple, ARC-compiled executables will only run on iOS 4 and above. In addition, weak references are only supported on iOS 5.
Just set the target deployment to the lowest iOS version your users might be on.. AutoMatic Reference Counts only while compiling the app in Xcode. The memory of app enabled ARC is managed by compiler (Xcode). So you need not to worry about the target iOS version of the device. Just set the Target Deployment to 3.2 or 4 etc.
I think at least it is not guaranteed to work correctly on iOS 3.x. See Transitioning to ARC Release Notes from Apple:
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.
My app is fairly close to being submitted for approval. I would like to make sure I am using the most current version of Xcode that I can. My Mac's operation system is Mac OS X Version 10.6.8 and I am using Xcode Version 3.2.3. I have seen that there are Versions 4.0 and 4.1 for Xcode. Should I be using one of these, or am I good to go?
Both Xcode 3.2 and 4.0 are supported on Snow Leopard. You can use any of them. Since you already use 3.2 I would recommend that you keep using that version until you find a good time to update to the 4.x series.
It is however a good idea to update to the latest version of Xcode 3.2, which is currently 3.2.6. That way you get the latest bug fixes and updates while staying on the 3.2 branch.
I highly recommend Xcode 4. You'll want to upgrade to it eventually anyway. Also, it makes it much easier to package up an app and submit it to the App Store. Just make sure you keep your Xcode 3, in case you need it - see here: Can I run Xcode 3 and Xcode 4 at the same time?
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).