Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Instance Variables of NSManagedObject Subclasses
Dear cocoa-dev list,
I want my NSManagedObjects to retain a variable valid for the lifetime the
application instance but not between instances of the application. So I
have subclassed NSManagedObject and added an instance variable to the
NSManagedObject subclass and defined a property as follows:
from the NSManagedObject sublcass header file:
@interface KCBMergingManagedObject : NSManagedObject
{
NSNumber *mergeID;
}
@property(readwrite, retain) NSNumber *mergeID;
and the corresponding .m file contains
@synthesize mergeID;
Accessing that property has worked but now I have a case where it fails as
follows:
NSString *foo;
NSString *matchValueTemp;
foo= entityBTemp.mergeID;
matchValueTemp= [entityBTemp valueForKey: @userTypeName];
foo= entityBTemp.mergeID;
Here, userTypeName is a field of the entity defined in the core data model
and retain by the context. At line three of that that snippet the data of
entityBTemp is faulted. The fault is uniqued by accessing userTypeName in
the fourth line. In the fifth line, accessing entityBTemp.mergeID causes
the application to crash with EXC_BAD_ACCESS. The values returned in
variables foo and
matchValueTemp in lines 3 and 4 are correct.
Am I not supposed to add instance variables to NSManagedObject sublcasses?
It does seem like a poor idea from the standpoint that it would interfere
with faulting because the data held in the variable and perhaps then
also relationships could not be faulted. I can not find anything in Cocoa
documentation discussing instance variables in NSManagedObject subclasses.
Is it necessary to define transient attribute in the model to get a volatile
property in a managed object? Or I could define a new field in the model,
retained between app instances, and clear it at application launch. I
would like to understand what is going on here though.
Allen W. Ingling
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Changing classes
On Fri, Oct 1, 2010 at 4:19 AM, Remco Poelstra re...@beryllium.net wrote: I think I do not fully understand the difference you are trying to make between device and class behaviour. I think what he means is: use a single class for representing all of your amplifier types instead of one unique subclass per amplifier type. The type of amplifier which a particular instance of a class represents would be identified by an instance variable (an enumerated type would work here), instead of by the subclass. Whether this is a desirable solution or not would depend on what characteristics distinguish these amplifiers and their degrees of similarity. If it is that that some amplifiers have subsets of common functionality enabled then you are well off using that approach; Use the same class for all amplifiers and use instance variables to track which features are active on a particular amplifier. On the other hand, if the amplifiers have disparate architectures such that method foo for amplifier type X must do different work internally than method foo for amplifier type Y, then polymorphism is your friend; Use different subclasses for different amplifier types (or if very disparate, then different classes which conform to a common protocol). The design philosophy at work here is that when a method takes variant actions, it can be better to organize those variations by putting them in different subclasses, instead of by conditional branching from within the same class to different methods or by conditional branching within a method. I do not agree with my own earlier suggestion to consider class clusters. But here are some other alternatives: 1. Do a depth-first probe of your amplifiers instead of a breadth-first probe so that you can fully identify their characteristics before creating an objects to represent them. Are you in a catch-22 here because the object which probes the amplifier is the same as the object which represents it ? 2. Have the class which owns the amplifier object create and query a generic amplifier object which probes a particular amplifier, then the owner class releases that generic amplifier object and creates a more specific subclass to replace it according to results returned by the initial generic probe object. (same as Keary Suska's earlier suggestion) 3. Use a generic wrapper object which implements that probing functionality and which itself creates and owns an instance of a subclass implementing amplifier-type-specific methods. Clients of the amplifier object API treat the wrapper objects as amplifier objects and the generic wrapper objects forward calls to their amplifier-specific subclass. Essentially this is the same as 2 but with with better modularity because you tidily isolate the amplifier-specific object creation within the wrapper object. The messy business of choosing the subclass would be opaque to the clients of your amplifier object API. (See the Objective-C Runtime Programming Guide section on forwarding.) - Allen On Fri, Oct 1, 2010 at 4:19 AM, Remco Poelstra re...@beryllium.net wrote: Op 30-9-2010 21:58, Quincey Morris schreef: It's not at all obvious that having your class(es) represent your hardware is the right way to approach this. What are you actually trying to achieve? If the various kinds of hardware are differentiated by their properties, then a single class encapsulating the possible properties (including a specification of which properties are actually present for each device) may be all that you need. You would only use a class hierarchy if the class has significant shared *behavior*, plus behavior that is specific to each device type. Note that I'm talking about class behavior, not device behavior. The device behavior isn't relevant to the class behavior, unless the class is a software simulation of the device. Hi, Thanks for all answers! Seems there are a lot of possibilities solving such a simple thing :) I'm representing network enabled amplifiers, some of which have multiple inputs, some not. Other have surveillance features build in, which others might not have. I'm not trying to simulate them, just representing them so I can communicate with them. I think I do not fully understand the difference you are trying to make between device and class behaviour. The amplifiers do a lot the same, but some responses might need another interpretation. In the end, all communication is over a standard protocol for all amplifiers and I want the UITableview on my iPhone to show more or less (depending on capabilities of course) the same layout. Kind regards, Remco Poelstra ___ ___ 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:
Re: Changing classes
On Thu, Sep 30, 2010 at 2:28 PM, Remco Poelstra re...@beryllium.net wrote: Hi, I've a class that represents a general piece of hardware. Subclasses of that class represent more specific versions of that hardware. When I scan the network for hardware, I first only know some basic properties of the hardware and only after some more queries I'll know all details. I thought it would be a good thing to instantiate from the base class when I detect the hardware and then change the class to a more specific class as I find out more about the hardware. But how do I change a class? I know about the ISA pointer, but changing it doesn't allocate any additional variables. What would be a nice solution to this problem? Maybe a class cluster would be useful here? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: stringByReplacingCharactersInRange leading to bus error
On Tue, Aug 17, 2010 at 4:03 PM, James Miller jmiller3...@gmail.com wrote: Hello. I'm a little new to Objective-C / Cocoa so please don't shoot me, but I've been looking around for a few hours and can't seem to figure out what I'm doing wrong on my own and could use a second/third/fourth set of eyes. I have NSTimer that runs several times a second against an NSString called level, which is 190 characters long and previously initialized from: // NSString *level = [[NSString alloc] // initWithContentsOfFile:path // encoding:NSUTF8StringEncoding // error:error]; During the timer call, the level NSString is modified by the following line of code: level=[level stringByReplacingCharactersInRange:NSMakeRange(5,1) withString:@ ]; This operation appears to succeed as I print it via NSLog and it looks fine and the length checks out, but the next time through the NSTimer I get a bus error and the application dies. If I comment out the line above, the code continues to run fine. Am I doing something wrong in terms of how I am using this method or assigning it back to the NSString? The result of the stringByReplacingCharactersInRange: method call is not retained between NSTimer callback invocations. It will leak memory, but as a quick test of that diagnosis, replace this line: level=[level stringByReplacingCharactersInRange:NSMakeRange(5,1) withString:@ ] with level=[[level stringByReplacingCharactersInRange:NSMakeRange(5,1) withString:@ ] retain]; If that works, as a permanent fix declare the variable level a property of the class and use synthesized accessors to assign the value of level, which will retain/release it correctly: #1: add to your header file: @property(readwrite, retain) NSString *level; #2: you should already have the variable defined in your header: NSString *level; #3: Add to your .m file @synthesize level; #4: and replace your stringByReplacingCharactersInRange invocation line with this: self.level=[self.level stringByReplacingCharactersInRange:NSMakeRange(5,1) withString:@ ]; or if you prefer this style [self setLevel:[ [self level] stringByReplacingCharactersInRange:NSMakeRange(5,1) withString:@ ]]; - Allen ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: stringByReplacingCharactersInRange leading to bus error
On Wed, Aug 18, 2010 at 1:52 PM, Murat Konar mu...@pixar.com wrote: On Aug 18, 2010, at 11:06 AM, John C. Randolph wrote: -stringByReplacingCharactersInString: creates and returns a new string, which is autoreleased. Always? I recall running into a problem that was caused by -stringByReplacingCharactersInString: (or a method like it) simply returning self if no substitution occurred. _murat Even if it does do that, you should treat the returned result as if it were autoreleased. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
