Search Results

Search found 61 results on 3 pages for 'dontwatchmyprofile'.

Page 2/3 | < Previous Page | 1 2 3  | Next Page >

  • How does a custom accessor method implementation in Core Data look like?

    - by dontWatchMyProfile
    The documentation is pretty confusing on this one: The implementation of accessor methods you write for subclasses of NSManagedObject is typically different from those you write for other classes. If you do not provide custom instance variables, you retrieve property values from and save values into the internal store using primitive accessor methods. You must ensure that you invoke the relevant access and change notification methods (willAccessValueForKey:, didAccessValueForKey:, willChangeValueForKey:, didChangeValueForKey:, willChangeValueForKey:withSetMutation:usingObjects:, and didChangeValueForKey:withSetMutation:usingObjects:). NSManagedObject disables automatic key-value observing (KVO, see Key-Value Observing Programming Guide) change notifications, and the primitive accessor methods do not invoke the access and change notification methods. In accessor methods for properties that are not defined in the entity model, you can either enable automatic change notifications or invoke the appropriate change notification methods. Are there any examples that show how these look like?

    Read the article

  • What's the point of having to provide a cacheName for NSFetchedResultsController?

    - by dontWatchMyProfile
    NSFetchedResultsController *frc = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:moc sectionNameKeyPath:nil cacheName:@"Root"]; Why do we have to think about a cacheName? How important is this decision? What would happen if there are two NSFetchedResultsController instances using the exact same cacheName? Does that matter? Is that some kind of singleton stuff? Thinking about Core Animation, there's also this strange animationID parameter, but setting it to the exact same thing for dozens of simultaneous animations doesn't hurt the animations at all. So I guess it's probably the same thing here...or not?

    Read the article

  • When does the DENY delete rule in Core Data actually deny deletion of an object?

    - by dontWatchMyProfile
    An Employee has an inverse relationship to it's Department and vice versa. The Employee entity has an Relationship called department, and it has a DENY delete rule. Employee shall be deleted. Now: Does DENY actually deny deletion of employee, because department is still referencing a Department? Or does it mean that a Department can't be deleted because an Employee is referencing it?

    Read the article

  • What exactly is the Nullify delete rule doing?

    - by dontWatchMyProfile
    Does that mean that if I delete an managed object which has references (relationship) to some others, the relationships are removed to those others? Example: objectA references objectB and objectC. objectA gets deleted, it's relationship to objectB and objectC is set to the Nullify rule. What happens in detail?

    Read the article

  • Couldn't I just pass an copied string to an Core Data property?

    - by dontWatchMyProfile
    The docs say: The default implementation does not copy attribute values. If the attribute value may be mutable and implements the NSCopying protocol (as is the case with NSString, for example), you can copy the value in a custom accessor to help preserve encapsulation (for example, in the case where an instance of NSMutableString is passed as a value). So instead of getting into trouble and inconvenience with overwriting accessors in my NSManagedObject subclass, couldn't I simply do something like this? myManagedObject.firstName = [[firstNameMutableStr copy] autorelease]; This would have the exact same effect, or not? The dynamic implementation would retain that anyways ... so.... why not the easy way?

    Read the article

  • What exactly is a memory page fault?

    - by dontWatchMyProfile
    From the docs: Note: Core Data avoids the term unfaulting because it is confusing. There's no “unfaulting” a virtual memory page fault. Page faults are triggered, caused, fired, or encountered. Of course, you can release memory back to the kernel in a variety of ways (using the functions vm_deallocate, munmap, or sbrk). Core Data describes this as “turning an object into a fault”. Is a Fault in Core Data essentially a memory page fault? I have only a slight idea about what a memory page is. I believe it's a kind of "piece of code in memory" which is needed to execute procedures and stuff like that, and as the app is runing, pieces of code are sucked into memory as "pages" and thrown away as they're not needed anymore. Probably 99% wrong ;) Anyone?

    Read the article

  • What's does "cardinality of an relationship" mean in Core Data?

    - by dontWatchMyProfile
    From the docs: If all of a managed object's relationship delete rules are Nullify, then for that object at least there is no additional work to do (you may have to consider other objects that were at the destination of the relationship—if the inverse relationship was either mandatory or had a lower limit on cardinality, then the destination object or objects might be in an invalid state). Does someone have an example of this cardinality thing? What's this good for and what's important to know about this? (sounds very important...)

    Read the article

  • So where is this calling super?

    - by dontWatchMyProfile
    From the Core Data docs: Inheritance If you have two subclasses of NSManagedObject where the parent class implements a dynamic property and its subclass (the grandchild of NSManagedObject) overrides the methods for the property, those overrides cannot call super. @interface Parent : NSManagedObject @property(nonatomic, retain) NSString* parentString; @end @implementation Parent @dynamic parentString; @end @interface Child : Parent @end @implementation Child - (NSString *)parentString { // this throws a "selector not found" exception return parentString.foo; } @end very, very funny, because: I see nobody calling super. Or are they? Wait... parentString.foo results in ... a crash ??? it's a string. How can that thing have a .foo suffixed to it? Just another documentation bug?

    Read the article

  • Quick way to get an NSDictionary from an XML NSData representation?

    - by dontWatchMyProfile
    I've loaded an XML file as NSData into memory and parse over the elements using NSXMLParser. Although it works, it's a very ugly and hard to maintain code since there are about 150 different elements to parse. I know there are nice third-party solutions, but I want to keep it with the iPhone SDK for purpose of practice and fun. So I thought: Why not convert that XML file into an NSDictionary? Having this, I could use fast enumeration to go over the elements. Or is it just the same amount of ugly code needed to parse and process an XML right away with NSXMLParser? Would I build up an NSDictionary for every found node in the XML and create a huge one, containing the whole structure and data? Or is there an even simpler way?

    Read the article

  • Why would I want to have a non-standard attribute?

    - by dontWatchMyProfile
    The documentation on Core Data entities says: You might implement a custom class, for example, to provide custom accessor or validation methods, to use non-standard attributes, to specify dependent keys, to calculate derived values, or to implement any other custom logic. I stumbled over the non-standard attributes claim. It's just a guess: If my attribute is anything other than NSString, NSNumber or NSDate I will want to have a non-standard Attribute with special setter and getter methods? So, for example, if I wanted to store an image, this would be a non-standard Attribute with type NSData and a special method, say -(void)setImageWithFileURL:(NSURL*)url which then pulls the image data from the file, puts in in an NSData and assigns it to core data? Or did I get that wrong?

    Read the article

  • Does this singleton pattern make sense?

    - by dontWatchMyProfile
    @implementation MySingletonClass static MySingletonClass *sharedInstance = nil; + (MySingletonClass*)sharedInstance { @synchronized(self) { if (sharedInstance == nil) { sharedInstance = [[self alloc] init]; } } return sharedInstance; } + (id)alloc { @synchronized(self) { if (sharedInstance == nil) { sharedInstance = [super alloc]; return sharedInstance; } } return nil; } + (id)allocWithZone:(NSZone *)zone { @synchronized(self) { if (sharedInstance == nil) { sharedInstance = [super allocWithZone:zone]; return sharedInstance; } } return nil; } -(id)init { self = [super init]; if (self != nil) { // initialize stuff here } return self; } @end Not sure if it's ok to overwrite both alloc and allocWithZone: like this...?

    Read the article

  • Most performant way to check how many objects are referenced by an to-many relationship in Core Data

    - by dontWatchMyProfile
    Lets say I have an employees relationship in an Company entity, and it's to-many. And they're really many. Apple in 100 years, with 1.258.500.073 employees. Could I simply do something like NSInteger numEmployees = [apple.employees count]; without firing 1.258.500.073 faults? (Well, in 100 years, the iPhone will easily handle so many objects, for sure...but anyways)

    Read the article

  • What happens inside the try block?

    - by dontWatchMyProfile
    Example: @try { // 1) do bad stuff that can throw an exception... // 2) do some more stuff // 3) ...and more... } @catch (NSException *e) { NSLog(@"Error: %@: %@", [e name], [e reason]); } If 1) throws an exception, is the block immediately canceled like a return in a function or a break in a loop? Or will 2) and 3) be processed no matter what happens in 1)?

    Read the article

  • Which kind of changes can't I do with lightweight migration in Core Data?

    - by dontWatchMyProfile
    I recently tried a lot of different stuff with lightweight migration. These all work: 1) Rename attributes (with renaming identifier specified) 2) Add attributes 3) Add new entity + new attribute + inverse relationship to an already existing entity 4) remove existing entity + relationships to that entity = It almost looks like just about anything can be handled with LM. Did I miss something? In which cases am I getting into trouble and need an some more complex approach?

    Read the article

  • What happens if a user jumps over 10 versions before updating, and every version had a new data mode

    - by dontWatchMyProfile
    Example: User installs app v.1.0, adds data. Then the dev submits 10 updates in 10 weeks. After 11 weeks, the user wants v.11.0 and grabs a copy from the app store. Assuming that the app has got 11 .xcdatamodel versions inside, where ***11.xcdatamodel is the current one, what would happen now since the persistent store of the user is ages old? would the migration happen 10 times, step-by-step through every migration iteration? Or does the actual migration of data (lets assume gigabytes of data) happen exactly once, after Core Data (or the persistent store coordinator) has figured out precisely what to do to go from v.1.0 to v.11.0?

    Read the article

  • Will the next iPhone Simulator be able to simulate the high resolution of iPhone 4?

    - by dontWatchMyProfile
    As a follow-up to this question, the next one is: Will we be able to simulate our interfaces how they look on the new high resolution display, even without owning an iPhone 4? I guess that there is a formula that we can use to calculate the exact needed distance between our monitors and our eyes, to achieve the exact same visual effect of the Retina Display. This would help a lot to get things right. The first thing we need is an high resolution iPhone Simulator. I can't get any sleep until I know.

    Read the article

  • Would a pointer to a pointer to nil match against NULL?

    - by dontWatchMyProfile
    Example: A validation method contains this check to see if an NSError object shall be created or not: - (BOOL)validateCompanyName:(NSString *)newName error:(NSError **)outError { if (outError != NULL) { // do it... Now I pass an NSError object, like this: NSError *error = nil; BOOL ok = [self validateCompanyName:@"Apple" error:&error]; I'm not sure if this matches the check for not NULL. I think it's not NULL, since I believe NULL is not nil. Maybe someone can clear this up?

    Read the article

  • What does -setPropagatesDeletesAtEndOfEvent: actually do?

    - by dontWatchMyProfile
    Let me try it: If I don't set this, then the default value is YES. So when I delete an managed object from the context, the context propagates this immediately to the persistent store so the object is gone? And when I set this to NO, then objects are deleted from the persistent store only when calling -save? Is that really true? I mean: If it was true, then the default behavior is that once you call the context to delete an object, the object is gone. Lets assume you're not using an undo manager. So... gone. Right? No rollback possible? Or can it still be recovered with a rollback?

    Read the article

< Previous Page | 1 2 3  | Next Page >