Re: Detecting reading a key in KVC
Op 12-11-2010 2:26, Ken Thomases schreef:
On Nov 11, 2010, at 4:57 PM, Graham Cox wrote:
On 12/11/2010, at 3:30 AM, Ken Thomases wrote:
You should not override -setValue:forKey: or -valueForKey: if you can avoid it. Instead,
implement the methods -setValue:forUndefinedKey: and -valueForUndefinedKey:. They are
precisely for implementing dynamic properties in this manner.
Understood, but the OP's problem as I understand it is that it's not that the
key is undefined, but the value associated with it is uninitialized. So rather
than return nil, or zero, he wants to trigger a remote fetch of the value. KVC
doesn't appear to provide a mechanism for that out of the box.
He was using an NSMutableDictionary for his model, instead of a custom class.
The barrier to using a custom class was that he has many properties and didn't
want to implement them all. The suggestion was to make a class which wraps a
mutable dictionary and use the KVC methods to provide access to them and also
serve as the trigger for retrieving those which are not yet cached.
All fine so far.
The suggestion, though, was to implement the wrapper by overriding -setValue:forKey: and
-valueForKey:. You shouldn't override those, but rather override
-setValue:forUndefinedKey: and -valueForUndefinedKey:. The respective implementations
would be the same -- they would pass through to the mutable dictionary and initiate
fetches for absent values. -setValue:forKey: and -valueForKey: have some special
powers that you lose if you override them.
I think I don't get it. I now have to following:
@interface PropertiesController: NSObject {
NSMutableDictionary *properties;
}
-valueForKey:
-setValue:forKey:
@end
@implementation PropertiesController
valueForKey {
id retVal=[properties valueForKey:key];
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
@end
If I ommit the valueForKey method, how does the KVC logic now, that it
should check the properties variable?
Further more, NSDictionary seems to always return a value, so all keys
are defined, they just return nil sometimes. How can
valueForUndefinedKey: then ever be called?
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 12/11/2010, at 8:45 PM, Remco Poelstra wrote:
If I ommit the valueForKey method, how does the KVC logic now, that it should
check the properties variable?
Further more, NSDictionary seems to always return a value, so all keys are
defined, they just return nil sometimes. How can valueForUndefinedKey: then
ever be called?
nil from NSDictionary means no value associated with the key (dictionaries
cannot store 'nil' as a value) so this is your cue to go fetch. The problem is
that the object on which -valueForUndefinedKey: is invoked is the dictionary,
not your wrapper, and since you are not subclassing the dictionary, you won't
get that message (and the default will simply throw an exception). So instead,
the override to -valueForKey: in your wrapper is acceptable, in this case. But
instead of invoking -valueForKey: on the dictionary, use -objectForKey:
directly. That way, you get nil when there's no key instead of an exception.
If you have properties that can legally be nil, you'll need to treat those
differently, using some sort of marker object that means the property really
should return nil (and hence can be stored in a dictionary). For example
[NSNull null] is a valid object which means 'nil'. Basically, you can't use nil
itself to mean two different things, both uninitialized and a legal value, and
since NSDictionary reserves the use of nil to mean undefined, you have no
choice but to deal with that in some way.
@implementation MyWrapper
- (id) valueForKey:(NSString*) key
{
id value = [myDictionary objectForKey:key];
if( value )
return value;
[self beginFetchForKey:key];// assume starts a thread or
asynchronous task which calls -setValue:forKey: on completion
return nil; // OK, we have no value to return yet.
}
- (void) setNilValueForKey:(NSString*) key
{
[myDictionary setObject:[NSNull null] forKey:key]; // substitute a valid
object for nil values
}
Because this does not override -setValue:forKey: you get all the usual goodness
that gives you, such as KVO notifications. As your thread sets the value using
KVC any observers get notified of the value having been fetched automatically
(if you are using a thread take care to set the value on the main thread so
that all notifications take place on the main thread).
The override to -valueForKey: here does lose some of the 'special powers' that
Ken alluded to, one of them being the treatment of a leading '@' in the key. If
that matters, you need to emulate what NSDictionary's implementation does. But
since you are really replacing NSDictionary's version with your own, which has
already discarded the vast majority of NSObject's 'special powers' I can't see
you are losing much in this case. It has the advantage that subclassing
NS(Mutable)Dictionary is not required.
--Graham
___
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
Get Started with a webplugin
Hi, I have followed the rules written on the pdf doc WebKit Plug-In Programming Topics but I can't make Safari load my first webplugin yet. Does a webplugin require a signature, something not reported on the docs? I run MacOS X 10.6.5, Safari 5.0.2. I compile with Xcode 3.2.3, with SDK 10.6, target 10.6, 32 bit universal, i386. I create the plugin project with Xcode 3.2.3, which comes almost ready to use. Then I compile as Release i386 and copy the plugin within /Library/Internet Plug-Ins/ Then I launch Safari. I select the menu Help:Installed Plug-ins and my plugin is not there. What did I miss? Part of my Info.plist is - keyWebPluginDescription/key stringDisplay my own video type/string keyWebPluginMIMETypes/key dict keyvideo/x-myappmovie/key dict keyWebPluginExtensions/key array stringmox/string /array keyWebPluginTypeDescription/key stringMyApp Movie/string /dict /dict keyWebPluginName/key stringMyApp Plug-in/string This was ok keyCFBundlePackageType/key stringWBPL/string Regards Leonardo ___ 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: Detecting reading a key in KVC
Op 12-11-2010 12:13, Graham Cox schreef:
nil from NSDictionary means no value associated with the key
(dictionaries cannot store 'nil' as a value) so this is your cue to
go fetch. The problem is that the object on which
-valueForUndefinedKey: is invoked is the dictionary, not your
wrapper, and since you are not subclassing the dictionary, you won't
get that message (and the default will simply throw an exception). So
instead, the override to -valueForKey: in your wrapper is acceptable,
in this case. But instead of invoking -valueForKey: on the
dictionary, use -objectForKey: directly. That way, you get nil when
there's no key instead of an exception.
Unfortunatly this does not seem to be true. I use valueForKey on the
dictionary and for non-existing keys, nil is returned. No exception is
thrown. This is not a major problem I think, as I can just test for nil
as with objectForKey.
If you have properties that can legally be nil, you'll need to treat
those differently, using some sort of marker object that means the
property really should return nil (and hence can be stored in a
dictionary). For example [NSNull null] is a valid object which means
'nil'. Basically, you can't use nil itself to mean two different
things, both uninitialized and a legal value, and since NSDictionary
reserves the use of nil to mean undefined, you have no choice but to
deal with that in some way.
Fortunatly, this is not a problem, all my properties are non-nil.
@implementation MyWrapper
- (id) valueForKey:(NSString*) key { id value = [myDictionary
objectForKey:key];
if( value ) return value;
[self beginFetchForKey:key];// assume starts a thread or
asynchronous task which calls -setValue:forKey: on completion
return nil; // OK, we have no value to return yet. }
- (void) setNilValueForKey:(NSString*) key { [myDictionary
setObject:[NSNull null] forKey:key];// substitute a valid object for
nil values }
Because this does not override -setValue:forKey: you get all the
usual goodness that gives you, such as KVO notifications. As your
thread sets the value using KVC any observers get notified of the
value having been fetched automatically (if you are using a thread
take care to set the value on the main thread so that all
notifications take place on the main thread).
But if I do not override setValue:forKey: How does the KVC logic now
that it should not try to call setValue:forKey: on my wrapper object,
but on the enclosed dictionary instead? Do I not need to override
setValue:forKey: and call [myDictionary setValue:forKey] there? just as
with valueForKey:?
The override to -valueForKey: here does lose some of the 'special
powers' that Ken alluded to, one of them being the treatment of a
leading '@' in the key. If that matters, you need to emulate what
NSDictionary's implementation does. But since you are really
replacing NSDictionary's version with your own, which has already
discarded the vast majority of NSObject's 'special powers' I can't
see you are losing much in this case. It has the advantage that
subclassing NS(Mutable)Dictionary is not required.
Just out of curiosity, what is the use of the @ operator? I can't find
anything about it in the KVC Programming Guide.
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 12/11/2010, at 11:24 PM, Remco Poelstra wrote: But if I do not override setValue:forKey: How does the KVC logic now that it should not try to call setValue:forKey: on my wrapper object, but on the enclosed dictionary instead? Do I not need to override setValue:forKey: and call [myDictionary setValue:forKey] there? just as with valueForKey:? My apologies, yes, you do need to do this. Which means you'll also need to implement manual KVO notification using -willChangeValueForKey: and -didChangeValueForKey: since your object's clients will be observing it, not the internal dictionary. I'm not sure, but this could create a problem, in that -willChangeValueForKey: MIGHT invoke -valueForKey: in order to cache the old value that is about to be changed so it can pass it in the notification. That will trigger another fetch, because the new value has not yet been set. Result, an infinite cascade of fetches. This is easy to solve using a simple lock flag, but it may not be needed (just be aware of the possibility). --Graham ___ 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
How to remove 'not found in protocol' compiler warning
I'm getting a compiler warning message at the following line of code: NSArray *selectedObjects = [[secondTableView dataSource] selectedObjects ]; The warning message is 'selectedObjects' not found in protocol. Can someone suggest what I need to do to remove the warning? ___ 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: How to remove 'not found in protocol' compiler warning
On Fri, Nov 12, 2010 at 9:09 AM, Paul Johnson p...@askerko.net wrote: I'm getting a compiler warning message at the following line of code: NSArray *selectedObjects = [[secondTableView dataSource] selectedObjects]; The warning message is 'selectedObjects' not found in protocol. Note that NSTableView's -dataSource returns an object of type idNSTableViewDataSource. So, the compiler knows nothing about the object other than its protocol conformance. Since -selectedObjects isn't part of the protocol, it gives this warning. Can someone suggest what I need to do to remove the warning? Use a type cast to tell the compiler what class the data source really is: NSArray *selectedObjects = [(MyDataSourceClass*)[secondTableView dataSource] selectedObjects]; sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net ___ 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: How to remove 'not found in protocol' compiler warning
On 12 Nov 2010, at 14:17, Sherm Pendley wrote: On Fri, Nov 12, 2010 at 9:09 AM, Paul Johnson p...@askerko.net wrote: I'm getting a compiler warning message at the following line of code: NSArray *selectedObjects = [[secondTableView dataSource] selectedObjects]; The warning message is 'selectedObjects' not found in protocol. Note that NSTableView's -dataSource returns an object of type idNSTableViewDataSource. So, the compiler knows nothing about the object other than its protocol conformance. Since -selectedObjects isn't part of the protocol, it gives this warning. Can someone suggest what I need to do to remove the warning? Use a type cast to tell the compiler what class the data source really is: NSArray *selectedObjects = [(MyDataSourceClass*)[secondTableView dataSource] selectedObjects]; While this will work, I don't agree that it's the correct solution to the problem. The issue here is that you are making an assumption about the TV's data source that may not be true. Instead, what should be happening is that if you want to send messages to that particular object with the knowledge that it's the right type to receive those messages, you should maintain your own pointer to the object, and you should send messages there instead. This is roughly the same reason as why you shouldn't be sending messages to [NSApp delegate] – that's the app delegate, and the app is responsible for sending it messages, not you... if you want to send messages to a controller that just so happens to be the same object, maintain your own pointer to it with a more specific type. Bob___ 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: Detecting reading a key in KVC
Op 12 nov 2010, om 13:37 heeft Graham Cox het volgende geschreven: On 12/11/2010, at 11:24 PM, Remco Poelstra wrote: But if I do not override setValue:forKey: How does the KVC logic now that it should not try to call setValue:forKey: on my wrapper object, but on the enclosed dictionary instead? Do I not need to override setValue:forKey: and call [myDictionary setValue:forKey] there? just as with valueForKey:? My apologies, yes, you do need to do this. Which means you'll also need to implement manual KVO notification using -willChangeValueForKey: and -didChangeValueForKey: since your object's clients will be observing it, not the internal dictionary. Thanks. I hope overriding these methods will not destroy my performance too much. I'm not sure, but this could create a problem, in that -willChangeValueForKey: MIGHT invoke -valueForKey: in order to cache the old value that is about to be changed so it can pass it in the notification. That will trigger another fetch, because the new value has not yet been set. Result, an infinite cascade of fetches. This is easy to solve using a simple lock flag, but it may not be needed (just be aware of the possibility). Yes, that happens. Not an endless loop, but every property is indeed requested twice, once by me and once by the system. 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to remove 'not found in protocol' compiler warning
In the array controller I added an outlet for the data source of the second table view: IBOutlet ZZSecondArrayController *dataSource; and connected it to the Array Controller for the second table view. Then I changed the line that gave the compiler warning message to: NSArray *selectedObjects = [dataSource selectedObjects]; This removed the warning message. Thanks, Sherm. (If this doesn't look like proper implementation, let me know, because I'd want to do things correctly.) On Fri, Nov 12, 2010 at 8:35 AM, Thomas Davie tom.da...@gmail.com wrote: On 12 Nov 2010, at 14:17, Sherm Pendley wrote: On Fri, Nov 12, 2010 at 9:09 AM, Paul Johnson p...@askerko.net wrote: I'm getting a compiler warning message at the following line of code: NSArray *selectedObjects = [[secondTableView dataSource] selectedObjects]; The warning message is 'selectedObjects' not found in protocol. Note that NSTableView's -dataSource returns an object of type idNSTableViewDataSource. So, the compiler knows nothing about the object other than its protocol conformance. Since -selectedObjects isn't part of the protocol, it gives this warning. Can someone suggest what I need to do to remove the warning? Use a type cast to tell the compiler what class the data source really is: NSArray *selectedObjects = [(MyDataSourceClass*)[secondTableView dataSource] selectedObjects]; While this will work, I don't agree that it's the correct solution to the problem. The issue here is that you are making an assumption about the TV's data source that may not be true. Instead, what should be happening is that if you want to send messages to that particular object with the knowledge that it's the right type to receive those messages, you should maintain your own pointer to the object, and you should send messages there instead. This is roughly the same reason as why you shouldn't be sending messages to [NSApp delegate] – that's the app delegate, and the app is responsible for sending it messages, not you... if you want to send messages to a controller that just so happens to be the same object, maintain your own pointer to it with a more specific type. Bob ___ 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
Strange result with NSView's convertPoint:toView:
I have changed the contentView of my NSWindow to be a NSView which return YES for isFlipped. If I place a NSButton in the contentView of a window, I can do the following: NSRect r = [view frame]; NSPoint origin; origin = [view convertPoint:NSZeroPoint toView:[[view window] contentView]]; The r.origin will say something like ( 20, 14 ) and, when I convert the point, I get back what one would expect ( 20, 14 ). The problem comes when I try to place a NSImageView in that same content view. The r.origin will say something like ( 20, 14 ), but, when I convert the point, I get back ( 20, 78 ). (The NSImageView is 64x64) I am confused as to why this would be happening. Anyone have an idea? I should be able to easily provide some sample code if that is required in this case. ___ 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: Strange result with NSView's convertPoint:toView:
On Nov 12, 2010, at 11:47 AM, Eric Gorr wrote:
I have changed the contentView of my NSWindow to be a NSView which return YES
for isFlipped.
If I place a NSButton in the contentView of a window, I can do the following:
NSRect r = [view frame];
NSPointorigin;
origin = [view convertPoint:NSZeroPoint toView:[[view window]
contentView]];
The r.origin will say something like ( 20, 14 ) and, when I convert the
point, I get back what one would expect ( 20, 14 ).
The problem comes when I try to place a NSImageView in that same content view.
The r.origin will say something like ( 20, 14 ), but, when I convert the
point, I get back ( 20, 78 ). (The NSImageView is 64x64)
I am confused as to why this would be happening. Anyone have an idea?
I should be able to easily provide some sample code if that is required in
this case.
I have answered my own question. This solves the problem:
NSPoint originPoint = NSZeroPoint;
if ( ![view isFlipped] )
{
originPoint.y = NSHeight( r );
}
origin = [view convertPoint:originPoint toView:[[view window]
contentView]];
It looks like the NSButton picks up the isFlipped property of the contentView,
but the NSImageView does not.
So, I need to take this into account before attempting to convert the point.
___
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
[iPhone] Toolbar button and Touch Down
I'm doing an iPhone 4.1 app and I have a toolbar at the bottom with bar buttons. The problem is that I need to set one of the bar buttons to Touch Down instead of the default Touch Up Inside but IB doesn't show any touch options for toolbar buttons (it does for buttons not in the toolbar). Is there a programmatic way to set this? Thx ___ 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: Detecting reading a key in KVC
On Nov 12, 2010, at 01:45, Remco Poelstra wrote:
@interface PropertiesController: NSObject {
NSMutableDictionary *properties;
}
-valueForKey:
-setValue:forKey:
@end
@implementation PropertiesController
valueForKey {
id retVal=[properties valueForKey:key];
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
@end
If I ommit the valueForKey method, how does the KVC logic now, that it should
check the properties variable?
Further more, NSDictionary seems to always return a value, so all keys are
defined, they just return nil sometimes. How can valueForUndefinedKey: then
ever be called?
As as been said several times in this thread, you *shouldn't* override
'valueForKey:', but instead override 'valueForUndefinedKey:' like this:
@implementation PropertiesController
- (id) valueForUndefinedKey: (NSString*) key {
id retVal=[properties objectForKey:key]; // note: NOT 'valueForKey:'
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
@end
If you want to know how control reaches this method, read the documentation:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/SearchImplementation.html%23//apple_ref/doc/uid/2955-CJBBBFFA
The only restriction here is that none of your dictionary keys should be the
same as existing NSObject property names, because KVC references to those keys
will go to the existing methods instead of 'valueForUndefinedKey:'. For
example, a dictionary key class isn't going to work. If there's a chance the
dictionary keys will conflict with NSObject property names, you are going to
have to take steps to ensure the keys are made unique.
___
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: Detecting reading a key in KVC
On Nov 12, 2010, at 10:16, Quincey Morris wrote:
- (id) valueForUndefinedKey: (NSString*) key {
id retVal=[properties objectForKey:key]; // note: NOT 'valueForKey:'
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
Oops, sorry, I meant to suggest a slightly different implementation, but
forgot. Here's what I had in mind:
static NSSet* knownKeys = [NSSet setWithObjects: ... list of 82 keys your
dictionary is allowed to contain ..., nil];
- (id) valueForUndefinedKey: (NSString*) key {
if (![knownKeys containsObject: key])
return [super valueForUndefinedKey: key];
id retVal=[properties objectForKey:key]; // note: NOT 'valueForKey:'
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
Alternatively, you could prefill your dictionary with [NSNull null] values for
all keys, and test for that instead.
That way you can tell the difference between an invalid key and a key that
hasn't been fetched yet.
___
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
Core Data: During Migration, should use Primitive Accessors only?
When implementing this method: -createDestinationInstancesForSourceInstance:entityMapping:manager:error: in a subclass of NSEntityMigrationPolicy, one typically loops through attributes of the given source instance, does whatever migration logic is desired, and then sets the results as attributes of a new destination instance. Some time ago, I learned that one does not want to invoke the -foo and setFoo: accessors in this method, because, duh, the invoked methods may no longer exist in the current implementation of the managed object. Life has improved since I've been careful to leave the objects typed as unsubclassed NSManagedObject instances, which forces me to use -valueForKey: and -setValue:forKey:. But wait, there's more. Although these source objects log their type as Baz or whatever, they do not respond to Baz subclass methods, only NSManagedObject methods. They are like the proxy objects that are sometimes delivered by KVO. It's rather confusing to see an exception such as -[Baz foo]: unrecognized selector when your implementation of Baz clearly has a -foo, but it makes sense when you stop to consider what's going on. Migration is sandboxxed. The system only has the old store to work with; not the old class. Because the entity and apparently the class are stored in the store, it knows that the object is a Baz instance, but it does not know any of the old Baz behaviors. The implication of this is that even -valueForKey: and -setValue:forKey: will fail if the -foo or -setFoo: accessors (which the system runs in their stead) have been overridden to perform business logic which invoke other subclass methods. Unrecognized selector exceptions are raised when these other subclass methods are invoked. Now, one does not generally want an app's regular business logic to be run during a migration anyhow; any business logic should be implemented within the migration sandbox. Therefore, it seems that, as a general rule, in -createDestinationInstancesForSourceInstance, one should access properties only via the primitive accessors -primitiveValueForKey: and -setPrimitiveValue:forKey:. At least I seem to have solved this morning's little programming challenge by adding Primitive to the accessors which were raising exceptions. Should I go through all of my -createDestinationInstancesForSourceInstance implementations and change all accessors to the primitive accessors? I can't find any discussion of the lameness of the source instances in the Core Data Model Versioning and Data Migration Programming Guide, and the phrase Primitive does not even appear in that document. Thanks, Jerry Krinock ___ 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: Detecting reading a key in KVC
Op 12 nov 2010, om 19:16 heeft Quincey Morris het volgende geschreven:
As as been said several times in this thread, you *shouldn't*
override 'valueForKey:', but instead override
'valueForUndefinedKey:' like this:
Is this kind of override ok?:
valueForKey: {
[properties valueForKey:key];
}
Otherwise the valueForKey is called on my wrapper, instead of the
dictionary that contains the real keys. I don't see how else the KVC
logic should find out about that instance variable.
@implementation PropertiesController
- (id) valueForUndefinedKey: (NSString*) key {
id retVal=[properties objectForKey:key]; // note: NOT 'valueForKey:'
if (!retVal) {
//fetch value from network
//We do not wait for the value
}
return retVal;
}
@end
If you want to know how control reaches this method, read the
documentation:
http://developer.apple.com/library/mac/#documentation/Cocoa/
Conceptual/KeyValueCoding/Concepts/SearchImplementation.html%23//
apple_ref/doc/uid/2955-CJBBBFFA
Unfortunatly, this does not seem to hold for a NSDictionary. It always
returns something instead of calling valueForUndefinedKey:
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Nov 12, 2010, at 11:13, Remco Poelstra wrote: Otherwise the valueForKey is called on my wrapper, instead of the dictionary that contains the real keys. I don't see how else the KVC logic should find out about that instance variable. The dictionary is a private implementation detail of your wrapper class. The KVC logic knows nothing about it. As far as KVC is concerned, it's your wrapper class that has undefined keys, and that's why execution ends up at your wrapper class's 'valueForUndefinedKey:' method. That method, which you write, has the knowledge to go get property values from the private dictionary (and to fetch the values first as necessary). Incidentally, this means that your fetch completion code should set the fetched value via 'setValue:forKey:' *on the wrapper object*, not by putting the value directly in the dictionary. Otherwise, the wrapper object won't be properly KVO compliant. I guess what's confusing, in this discussion, is that there are two general strategies for doing what you want: 1. Subclass NSDictionary, and use *no* wrapper. In that case, you'd have to override 'valueForKey:', which is probably not a very good idea. Also, subclassing into the NSDictionary class cluster itself makes this strategy more complicated. 2. Use a wrapper class with a NSDictionary as a private instance variable. In that case, you override 'valueForUndefinedKey:' so that your wrapper appears to the outside world to have the 82 keys you want. In case 2, which seems like the superior solution, the private dictionary isn't being accessed via KVC at all, so the only KVC behavior you're concerned with is that of the wrapper. ___ 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: Detecting reading a key in KVC
Op 12 nov 2010, om 20:44 heeft Quincey Morris het volgende geschreven: In case 2, which seems like the superior solution, the private dictionary isn't being accessed via KVC at all, so the only KVC behavior you're concerned with is that of the wrapper. Ah, that explains. If I understand it correctly, for all properties, each and everytime, valueForUndefinedKey is called? So I do also need to override setValue:forUndefinedKey in case 2? To make sure that the properties end up in the dictionary? Basically it's the same to what I've now (based on the discussion with Graham), but adding Undefined to my method names, I do keep the performance enhancements of the original implementation? 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Nov 12, 2010, at 12:05, Remco Poelstra wrote: If I understand it correctly, for all properties, each and everytime, valueForUndefinedKey is called? Correct. So I do also need to override setValue:forUndefinedKey in case 2? To make sure that the properties end up in the dictionary? Correct. I omitted the setter behavior for brevity in the discussion. Basically it's the same to what I've now (based on the discussion with Graham), but adding Undefined to my method names, I do keep the performance enhancements of the original implementation? It has *better* performance than the original implementation. Originally, *every* call to 'valueForKey:' involved custom code and an extra dictionary lookup. With this implementation, that only happens for your keys -- and genuinely undefined keys, of course. ___ 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
forcing accessibility focus
Hi All. I'm working on accessibility in an app, and would like to have a view pop up on screen and immediately become the focused item so that its text will be spoken. There seems to be no call to becomeAccessibilityFocus like there is becomeFirstResponder. Is there a way to do this? Any help is greatly appreciated. -Kenny ___ 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: RTFDFromRange returns different data
I workedaround the problem archiving the data directly from the attributedString this way: NSData* stringData = [NSKeyedArchiver archivedDataWithRootObject:mTextMutableString]; That's not guaranteed to always give you the same NSData either. Maybe it works now for your small test case, but given more complex inputs, an OSX update, or any other number of little thing you have no control over, the data could change. And I think there should always be a way to get the same out-data, given the same in-variables. That's not really how archiving is designed. The whole point is that you don't (and shouldn't) care about the archived data. As Glenn mentioned, the only thing you can be sure of is that you will restore the same content upon unarchiving. ~Martin ___ 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: [iPhone] Toolbar button and Touch Down
I struggled this too, but without solution. It seems that toolbar 'buttons' aren't real buttons -- they're class UIBarButtonItem from UIBarItem from NSObject. Since they're not really buttons, there doesn't appear any way to modify their behavior. If there is a way, I'd like to know, too... From: Jonathon Kuo newsli...@autonomy.caltech.edu To: Cocoa-Dev List cocoa-dev@lists.apple.com Sent: Fri, November 12, 2010 10:02:15 AM Subject: [iPhone] Toolbar button and Touch Down I'm doing an iPhone 4.1 app and I have a toolbar at the bottom with bar buttons. The problem is that I need to set one of the bar buttons to Touch Down instead of the default Touch Up Inside but IB doesn't show any touch options for toolbar buttons (it does for buttons not in the toolbar). Is there a programmatic way to set this? Thx ___ 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/rf_egr%40yahoo.com This email sent to rf_...@yahoo.com ___ 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
How we can simulate a USB/Wifi connection (between iPad and Mac) on iPhone simulator to test my app being shown as file sharing apps in iTune
*When an iPad is connected to another Mac (through USB/Wifi), iTune application comes in picture and lists all the file sharing app. I am trying to create file sharing application for iOS. I am unable to figure out how we can simulate this USB/Wifi connection on iPhone simulator to test my app being shown as file sharing apps in iTune. Is it even possible to test this iTune display on iPhone simulator? Please suggest a better approach if this is not possible. I am new iPad dev, please help. Thanks a lot.* ___ 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: [iPhone] Toolbar button and Touch Down
Random idea (untested, just spouting here) What about initing a barButtonItem with a custom view (that view being a UIButton that has the target/action set on the appropriate touch down inside [the end zone! - sorry, couldn't resist]), and then setting the target/action of the barButtonItem itself to nil? In other words, let a different control handle the target/action instead of the bar button item itself. Dave On Nov 12, 2010, at 11:57 AM, Jon Sigman wrote: I struggled this too, but without solution. It seems that toolbar 'buttons' aren't real buttons -- they're class UIBarButtonItem from UIBarItem from NSObject. Since they're not really buttons, there doesn't appear any way to modify their behavior. If there is a way, I'd like to know, too... From: Jonathon Kuo newsli...@autonomy.caltech.edu To: Cocoa-Dev List cocoa-dev@lists.apple.com Sent: Fri, November 12, 2010 10:02:15 AM Subject: [iPhone] Toolbar button and Touch Down I'm doing an iPhone 4.1 app and I have a toolbar at the bottom with bar buttons. The problem is that I need to set one of the bar buttons to Touch Down instead of the default Touch Up Inside but IB doesn't show any touch options for toolbar buttons (it does for buttons not in the toolbar). Is there a programmatic way to set this? Thx ___ 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/rf_egr%40yahoo.com This email sent to rf_...@yahoo.com ___ 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/davedelong%40me.com This email sent to davedel...@me.com ___ 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
