I am using Xcode 4.2 and building a game for iphone (from iOS 3.0 - 5.0). Does cocos2d support ARC? What modifications needs to be made to convert code written in previous versions?
If I use the strong and weak keywords for variables and set compiler to LLVM GCC 4.2, what will be the results? Is it a necessity to change compiler to 3.0 to support ARC?
Cocos2d v1.1 and v2.0 are compatible with ARC. However, the cocos2d code itself does not use ARC and there are no templates provided by cocos2d that you can use to start programming with ARC. You are required to add a seperate static library target for the cocos2d files yourself.
As Ankit pointed out, Tiny Tim Games made the necessary changes to a forked version of cocos2d-iphone to make it ARC compatible. These changes have been integrated into the development version and should be available in the cocos2d v2.x branch. I've since written a tutorial to enable ARC in a cocos2d (2.0) project.
It was said that cocos2d itself will be converted to use ARC internally in v2.1 or v2.2.
It's important to note that there are no plans to officially support ARC in the cocos2d v1.x branch because the v1.x line is supposed to remain backwards compatible with 1st generation devices and iOS 3.x. But general ARC compatibility has been added to v1.1.
Kobold2D fully supports ARC and has it enabled in all 15 template projects for almost two months now. Kobold2D uses the latest stable versions of cocos2d-iphone 1.x and 2.x. Just start a new Kobold2D project and you're set to work with cocos2d and ARC.
Even though Cocos2d does not support arc but there is way in which you can use both of them together, and that is by cross project referencing. You can learn how to do it by refering this.. cocos2d and ARC
Even easier, just get my cocos2d-ARC template here: https://github.com/Elland/Cocos2d-iphone-ARC-template hassle free, just rename the project to your desired name and you're set :)
Related
I'm aware that with Xcode now, it is recommended to use ARC, however I've read a bit about it not being compatible with iOS 4.x, at least when using __weak. When I create an IBOutlet it gives the choice of weak or strong as the storage type, does this mean my application is limited to iOS 5 or above, or will it still run on an older iOS?
Definitely just use ARC. As you point out, if you elect to provide iOS 4.3 compatibility, you don't enjoy that one little benefit feature of weak variables, where they'd be automatically nil-ed for you when they're deallocated (but you don't have that feature in non-ARC code, so it's not like you're losing anything). And, yes, when you control-drag from Interface Builder to the .h file, it says you have only the strong and weak options, but in the latest Xcode, at least, if you have iOS 4.3 as a target and you choose weak, it will automatically create it for you as a __unsafe_unretained, so all is good.
In short, use ARC, even if you're targetting support for iOS 4.3, and your coding life will be considerably better than if you didn't use ARC. Even in iOS 4.3, you get so many wonderful ARC benefits. And if you are willing to use iOS 5.0 as your target deployment, then you enjoy the full benefits of ARC.
If you use Xcode 4.5, you do, admittedly lose support for armv6, the processor for the iPhone 3G and earlier, so your app will only support the iPhone 3GS and later.
No, ARC is just compiler feature. It's per file, so it wouldn't impact your existing code at all.
iOS version support depends on your Xcode version.
With the last version of Xcode (4.5) you can create apps for iOS 4.3 and higher. If you need to create apps for earlier versions of iOS (prior that 4.3) you need to install Xcode 4.4.1.
What is the technical reason for ARC to be supported by iOS 4.0 and above only?
It is my understanding that it is a compiler feature, which merely inserts memory management related code automatically instead of requiring the developer to do so. From what I read the calls themselves remain the same - at least that's what Apples Transitioning to ARC Guide implies.
As such, it should not involve features that have not been present in previous versions of iOS, and indeed ARC does work with iOS 4.0 despite having been introduced later.
I'm asking this question out of curiosity and don't actually need to make ARC work with iOS 3.x.
It is for the same reason that automatic reference counting only supports 64-bit Snow Leopard as a minimum deployment target: ARC support requires certain features present only in a new enough version of the modern runtime. That modern runtime was introduced with iOS 4.0, so older iOS versions lack the runtime capable of handling some of the things required technically by ARC. If it were just keyed to OS versions, 32-bit Snow Leopard applications would be supported as well, but only the 64-bit runtime is the modern one there.
If you watch Apple's presentations from WWDC 2011, particularly the "Objective-C Advancements In-Depth," you'll see that a number of under-the-hood improvements have been made to speed up the retain / release process, as well as things like the faster #autoreleasepool. There's an entire section on runtime support in the LLVM ARC specification. These improvements require more than just compiler support.
We already had to use the modern runtime for features like automatic synthesis of instance variables (as explained in Apple's documentation), so this isn't a terrible surprise.
Even iOS 4.0 as a target lacks support for weak references, so there are clearly technical issues at play here. This isn't just a marketing strategy to drive developers to the newer versions, as has been asserted by others.
The docs of Apple states that the dealloc chaining to super is handled in runtime in the case of ARC.
The kind of a same question would be:
Why is NSRegularExpression only supported by iOS 4.0+ and Mac OS X 10.7(Lion)+?
You have fully working simulators of iOS 5.0(and 4.0 obviously) in Mac OS X 10.6.7(Snow Leopard) where you can easily use NSRegularExpression, but it's not supported by Mac OS X 10.6.7 itself.
And concerning your question: ARC was introduced with iOS 5.0. At that time there were not many iOS 3.x users anymore, so my opinion is that Apple was a bit too lazy to make ARC compatible with iOS 3.x.
My guess would be that the clang tool chain (required for ARC) does not build binaries compatible with iOS 3.x.
Also, there are a couple of C functions used in place of sending -retain and -release that might not be available in iOS 3.x
http://www.informit.com/articles/article.aspx?p=1745876
I am developing a cocos2d game, I tried to converted the code to Objective c ARC,
But it shows some issues in the cocos 2d library.
How can I convert a cocos2d application to Objective C ARc.
Is there any new release of cocos2d which is ARC compatible,
Thanks in advance
Cocos2d-iphone v1.1 (beta) and 2.0 (beta) are compatible with ARC - but only if you build cocos2d-iphone into a static library. There's no official instructions or template project yet.
Tiny Tim Games has a tutorial on that, and Ray Wenderlich has an alternative solution.
And Kobold2D gives you ARC for cocos2d-iphone out of the box, plus all the nitty-gritty information about ARC that'll help you with the follow-up questions you'll have sooner than later.
You can disable ARC on a file-by-file basis. For each element of the Cocos2D Library, apply the technique of How can I disable ARC for a single file in a project?
Hear a rumor that the new version of xcode is going to add the release statements for you.
So if I init something do I actually have to release it?
What you're referring to is called Automatic Reference Counting. ARC is a feature in recent versions of the LLVM compiler that will be included in a future version of Xcode. You have to specifically enable ARC to get the benefits from it, and it includes its own set of rules that you need to follow. Right now, unless you're compiling with a prerelease toolset, you need to do your own retains and releases. And even when the feature is released, you will need to specifically code for it — Xcode won't just helpfully correct your mistakes.
I'm completing a project for the iPhone entirely written in Objective-C. I'd like to port this for Android too.
While the user interface of the iPhone and the Android OS are very different and will need different code, can I some how import the core of my code (ie. the black box that does the thinking) as is to Android as part of some Java code?
I have no familiarity with bridging between Objective-C and Java even though I have written in both.
You got luck! Phil Hassey has recently ported his own game from iPhone to Android within a week and wrote up what he did steps by steps. Here is his journey: http://www.philhassey.com/blog/2010/08/03/porting-galcon-using-the-android-ndk/
You could have a look at Apportable which allows to generate an Android app from an existing Objective-C code base. See this article too.
there is a fork of the gcc that supports objective-c on the android by patching the NDK on
http://code.google.com/p/android-gcc-objc2-0/. But it's considered beta at the moment and i'm not sure if jni/java bridges are already implemented
I have been doing a lot of work on this front — for example by creating my own C++ base framework that does not depend on STL (called Platform Core) and writing the core of the next version of my iOS app with that, so that I can easily port it to Android and whatever else has a C++ compiler and strikes my fancy.
I suggest having a (ick, I can't believe I'm about to say this, but eh), ahem, having a C++ core (there, I said it!) so it can be easily ported.