Re: Assuring KVO compliance.
Re: Assuring KVO compliance.
- Subject: Re: Assuring KVO compliance.
- From: Alex Zavatone <email@hidden>
- Date: Tue, 07 Apr 2015 12:05:38 -0400
Thanks Roland.
Yeah, me neither, but this is inherited code where the previous guys obviously come from a java background and have done things in a manner I'm not accustomed to. In this project, refactoring properties and methods in many classes actually causes Xcode to tell me I'd be better off handling it manually. Never seen that before.
What doesn't sit right on this BAD_ACCESS problem is "why did adding an observer cause other code to cause an exception" and "OK, the exception is gone, but do I really understand why it's gone and should this change have actually fixed it"?
I'm assuming that the bad access is on the setting of the property within another class. I'm assuming that the way the enum is declared and exposed is where the problem is and that is causing the exception. Where its value is being set is where the debugger stops and tells me the exception is coming from.
What felt really odd to me was that simply adding an observer to a property in one class caused other code which set the property to trigger the exception to be thrown.
However…
all of the classes in this iOS project have their ivars defined in their interfaces and then properties created for all of them and occasionally synthesizing the properties manually.
I think we all stopped doing this in 2012 and I'm not going to address all of this until I know the product better.
What this leads to though is a case of "OK, I'm going to believe the debugger and try to make sure I address KVO/KVC compliance on the observed and make sure that the property is about to be observed and changed by multiple sources".
So, I tried what I thought would be good practices. Make sure the enum is backed by modern and KVC compliant approaches even though properties exposed through @synthesize should be KVO compliant, in case the way this property is exposed isn't. For example, due to the way the code is set up, what if the property being changed isn't the property I think it is, but the ivar instead?
I didn't change the way the property is @synthesized (still manually), I did change the property's atomicity to atomic without affecting the error, the only changes I did make were to use NS_Enum and declare the enum type as NSInteger.
In fact, a quick test changing the type of the NS_ENUM from NSInteger back to int doesn't cause the BAD_ACCESS to reappear.
I hate to mark something this core as "I don't know why but it works", but I don't know but it works.
Gremlins, I think.
Thanks for taking the time to eyeball this.
Alex Zavatone
On Apr 7, 2015, at 11:32 AM, Roland King wrote:
>
>> On 7 Apr 2015, at 23:12, Alex Zavatone <email@hidden> wrote:
>>
>> To answer my own question, changing the enum to an NSInteger backed NS_Enum resulted in no more bad access exceptions from other chunks of code attempting to change the APP_State property.
>>
>> typedef NS_ENUM(NSInteger, APP_State) {
>> APP_State_Normal = 0,
>> APP_State_Expired = 1,
>> APP_State_Waiting = 2
>> };
>>
>> Changing the atomicity of the exposed property had no effect on whether the exception was issued or not.
>>
>> Hope this helps someone.
>>
>> Alex Zavatone
>>
>
> I was just looking at some of my own code because I’m pretty sure I use enums all the time in properties which are KVO and observe them and update them, and I’ve never once had to mess around with NS_ENUM to make them work.
>
> And indeed I found 4 examples quite quickly, all of which look very much like your original code, a typedef’ed enum used as a property.
>
> So I really don’t know where your bad accesses were coming from.
>
> This was all ObjC right ?
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden