-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Automatic Reference Counting #78
Comments
I want to remove iOS 4 compatibility as soon as iOS 6 is public, this will then also include switching the project to ARC. This means late summer, I guess. |
As far as I know you don't have to abandon iOS 4 support if you use |
Almost 30% of my application users are still using iOs 4.x, so I cannot drop yet the iOs 4.x |
I have pulled MapBox's SDK and converted to ARC in 5 minutes. It took only a few lines to comment out for the use of AutoRelease pool in the RMMapTiledLayerView and changes handled in a semi automated way to change retain to "strong" etc. When you get to it, it won't be all that bad. |
Have you looked over the subtleties of the map view retaining the tiled layers due to the odd cleanup behavior of CATiledLayer when on a memory-constrained device? It gets tricky. On Oct 5, 2012, at 8:19 PM, teacup775 [email protected] wrote:
|
Can you clarify? In particular, what is the nature of the retaining the layers and what is odd nature of CATileLayer cleanup? I tried googling around and didn't find any specifics. I've run profiling for leaks, smashed the simulate memory warnings on a simulator run and it remains clean. Running on hardware (a 3gs) doesn't show any leaks -- but I don't know any tricks to force a memory warning, unless playing InfinityBlade will do it. :) I've noticed several bits of async invocation in the code, in particular the before/after move and zoom code areas, and also spawning an async tile download in the tile code. Not having large experience with CATileLayer, which seems to be an underdocumented class from Googled comments,I can see it's a bit of a pleasure/pain class in the framework. On principal I can understand why a rendering class that invokes work in multiple threads could cause some headaches. Still, the point of ARC conversion is to remove hand coded retain/release and have the compiler manage it automagically. If the existing code doesn't have any bugs with regard to handling the references, introducing ARC probably won't add them (crossing fingers). I
|
What do you think about moving to ARC? More precisely, how about removing reference counting in single files and transfer the project step by step. Does anybody have any experience with a mixed ARC/non-ARC project? Are there any arguments against using ARC?
The text was updated successfully, but these errors were encountered: