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 <z...@mac.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
