I am trying to use a framework which does not use ARC and it seems that I have to turn this feature off before I can use it. My question is, what are the potential ramifications of doing so? If I turn this off, what will I have to do to my current code to make sure I don't have any memory leak or any other issues in general?
ARC works fine with static libraries that use manual reference counting. If you're copying a bunch of .m files into your project, though, that's a different story. Fortunately, it's pretty easy to turn off ARC for specific files; you should do that for the files in that framework and leave your own files using ARC.
Related
I am creating my first Swift framework and I notice there is a default .h file (Obj-C). What purpose does it serve in a Swift Framwork? Can it be removed without causing problems?
It is a bridging header to make sure everything plays nice with Obj-C frameworks. You may be okay deleting it depending on the intended use of your framework, but it won't hurt anything to leave it in so that's what I would recommend for best practice and to make sure you don't accidentally break anything in different contexts that you use the framework in.
I have an Iphone app that used the excellent ABContactHelper library origionally written for by Erica Sedun and released on github
Now with the release of XCode4 and Reference Counting support, it causes lots of errors. I have looked at the forks on github, but none seem to have updated to XCode 4 with Reference Counting. I am trying to update it myself but its slow and error prone. I have tried the automatic refactoring support, but to no avail.
Does anyone know of an alternative AddressBook wrapper that provides a simple interface for interacting with the IPhone AddressBook?
In your ARC-enabled project, you can selectively disable ARC for the AddressBook wrapper files by setting the -fno-objc-arc compiler flag for those files.
Add compiler flags in Targets -> Build Phases -> Compile Sources. Enter the compiler flag by double-clicking on the right column of the row under Compiler Flags.
Dealing with ARC/non-ARC issues is a pain in the butt, and I've found that letting CocoaPods handle these problems for me is the way to go. Simply list ABContactHelper as a pod dependency and you're done. Many of the most popular libraries are already there, but if yours isn't, it's really easy to add it.
http://cocoapods.org
I'm writing an app in an ARC environment, and I'm trying to use a 3rd party library that was written before ARC. I'm using the -fno-objc-arc flags on all the relevant files, so it's compiling, but the project uses #ifndef __OBJC_GC_ blocks to release memory, which is causing memory allocation errors. I'm trying to determine the right solution, and so far I have the following:
1.) find a different library or write my own - this is the only free library of it's kind, so this is obviously not ideal, and I'm new enough that I don't feel comfortable tackling that
2.) remove the #ifndef blocks and cross my fingers - not able to work on the project today, but that's my next plan
3.) refactor the code to be ARC compliant and remove the -fno-objc-arc flags
is #2 likely to work? How hard would #3 be, andwould it actually cause the compiler to define __OBJC_GC_? (there's about 4-5 classes that I'm planning on using, but they're pretty sizeable)
You say the allocation blocks are enclosed into #ifndef __OBJC_GC_.
Note it is #ifndef - "if not defined".
So it should work out of the box if the author maintains the non-GC version correctly.
There is no need for you to remove ifdefs or to forge them.
The compiler, even with ARC on, should not define this flag for iOS.
Just make sure the library itself does not set this flag explicitly..
I would suggest considering another option: Turn off ARC for the project.
When I'm using big frameworks like the Three20 Framework,
I always have the choice whether to #import the whole framework or to #import only the single file of it i'd need.
I guess there's a difference in compilation-overhead since it has to open all files of the framework, but is there also a run-time difference? like bigger memory-usage? Or does the compiler-optimization already remove everything that's not needed?
And if I use the same framework pretty much in every class I use, is it recommended to include the framework in the prefix file instead of every single class?
Greetings
Infinite :)
There will be a compilation difference, yes: including everything will take longer to compile. But there shouldn't be a run-time difference.
Your idea of including the framework in the prefix is a good one for frameworks you're going to be using throughout. However, there is a catch, which is that if you change something in that framework your entire codebase will have to be recompiled.
There is no performance hit in runtime. No matter how many frameworks or files you import, if you don't use whichever classes they won't affect the resultant bytecode when you compile. The compiler doesn't even optimize anything; unused classes just "aren't there" at all.
Include the framework in the precompiled header file if you're sure it's going to be necessary.
You footprint won't be any different unless you actually use the classes however I prefer to be more frugal with my headers, only including the ones I need. If I need a lot from the same library (like Three20) then you can add the whole reference.
Only include headers in the prefix that don't change much, but it will speed up compilation greatly.
Hi experts i have created a set of UItableviewcustom cell classes. Now can i group those classes to an static library so that i can include that library in whichever project i want and i can use it.
You can, but it really isn't worth the trouble... with the rate that they keep on releasing new SDKs, and considering that you'd have to make it a Universal binary supporting both the simulator and the iPhone device, it really isn't worth the effort... I'd just save the ".h" and ".m" files and drop them in a new project.
However, if you are absolutely determined to go that route... I do have some articles on creating iPhone frameworks: here. Note that they are somewhat outdated (circa iPhoneOS3.1), so I don't know how much has changed, and I've since converted to the Android camp... but you still might find the info there useful.