so I am able to successfully have another class of mine be notified via KVO notification when a class instance value changes, but I have no idea of how I would go about transferring data between the two objects. I am aware that it is possible to do such things via the context: parameter, however Apple's documentation fails to indicate how to go about doing that.
I am aware that you place a pointer to an object as the context parameter in the addObserver:forKeyPath:options:context: message, but how does the object that is being observed "see" that object that is pointed to so it can make modifications accordingly?
Thanks!
The context argument is not meant as a data-transfer device, it just helps the observing class to distinguish different observations from each other. I’m not sure if you understand KVO right. KVO is used when you want to know about updates to a certain property. Upon receiving the notification you usually do something with the old/new property value:
- (void) observeValueForKeyPath: (NSString*) keyPath ofObject: (id) sender
change: (NSDictionary*) change context: (void*) context
{
id newValue = [change objectForKey:NSKeyValueChangeNewKey];
NSLog(#"New property value: %#.", newValue);
}
In this use case it does not make much sense to talk about “transferring data” between the two parties. If you want to get some extra data in addition to the property changes, you can easily expose that data as a property on the class being observed. Or forget about KVO and trigger a regular NSNotification with all the required data passed as the user info object:
NSDictionary *info = [NSDictionary dictionaryWithObjectsAndKeys:
foo, #"foo", bar, #"bar", nil];
[[NSNotificationCenter defaultCenter] postNotificationName:#"Foo"
object:self userInfo:info];
So I got it working like so...
I have an object (obj A) that needs to observe another object (obj B) and implements the following function: observeValueForKeyPath:ofObject:change:context:
Obj B calls the following in its init function:
[self addObserver:[<some singleton class> sharedManager] forKeyPath:#"someVar" options:(NSKeyValueObservingOptionNew) context:self];
Of course the observer class does not need to be a singleton class, but of course it is very convenient. I passed in the object being observed as the context and that allowed obj A to access all ivars for obj B in the observeValueForKeyPath:ofObject:change:context: function.
As I discovered, different background threads aren't used for KVO notifications, so I am reverting back to using protocols to transfer information as they both work out the same.
This form of data transfer is not recommended, but I wanted to just point out that it is indeed possible.
Related
In my program I use KVO manually to observe changes to values of object properties. I receive an EXC_BAD_ACCESS signal at the following line of code inside a custom setter:
[self willChangeValueForKey:#"mykey"];
The weird thing is that this happens when a factory method calls the custom setter and there should not be any observers around. I do not know how to debug this situation.
Update: The way to list all registered observers is observationInfo. It turned out that there was indeed an object listed that points to an invalid address. However, I have no idea at all how it got there.
Update 2: Apparently, the same object and method callback can be registered several times for a given object - resulting in identical entries in the observed object's observationInfo. When removing the registration only one of these entries is removed. This behavior is a little counter-intuitive (and it certainly is a bug in my program to add multiple entries at all), but this does not explain how spurious observers can mysteriously show up in freshly allocated objects (unless there is some caching/reuse going on that I am unaware of).
Modified question: How can I figure out WHERE and WHEN an object got registered as an observer?
Update 3: Specific sample code.
ContentObj is a class that has a dictionary as a property named mykey. It overrides:
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)theKey {
BOOL automatic = NO;
if ([theKey isEqualToString:#"mykey"]) {
automatic = NO;
} else {
automatic=[super automaticallyNotifiesObserversForKey:theKey];
}
return automatic;
}
A couple of properties have getters and setters as follows:
- (CGFloat)value {
return [[[self mykey] objectForKey:#"value"] floatValue];
}
- (void)setValue:(CGFloat)aValue {
[self willChangeValueForKey:#"mykey"];
[[self mykey] setObject:[NSNumber numberWithFloat:aValue]
forKey:#"value"];
[self didChangeValueForKey:#"mykey"];
}
The container class has a property contents of class NSMutableArray which holds instances of class ContentObj. It has a couple of methods that manually handle registrations:
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)theKey {
BOOL automatic = NO;
if ([theKey isEqualToString:#"contents"]) {
automatic = NO;
} else {
automatic=[super automaticallyNotifiesObserversForKey:theKey];
}
return automatic;
}
- (void)observeContent:(ContentObj *)cObj {
[cObj addObserver:self
forKeyPath:#"mykey"
options:0
context:NULL];
}
- (void)removeObserveContent:(ContentObj *)cObj {
[cObj removeObserver:self
forKeyPath:#"mykey"];
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context {
if (([keyPath isEqualToString:#"mykey"]) &&
([object isKindOfClass:[ContentObj class]])) {
[self willChangeValueForKey:#"contents"];
[self didChangeValueForKey:#"contents"];
}
}
There are several methods in the container class that modify contents. They look as follows:
- (void)addContent:(ContentObj *)cObj {
[self willChangeValueForKey:#"contents"];
[self observeDatum:cObj];
[[self contents] addObject:cObj];
[self didChangeValueForKey:#"contents"];
}
And a couple of others that provide similar functionality to the array. They all work by adding/removing themselves as observers. Obviously, anything that results in multiple registrations is a bug and could sit somewhere hidden in these methods.
My question targets strategies on how to debug this kind of situation. Alternatively, please feel free to provide an alternative strategy for implementing this kind of notification/observer pattern.
Update 4: I found the bug using a mixture of breakpoints, NSLogs, code reviews and sweating. I did not use the context in KVO, although this is definitely another useful suggestion. It was indeed a wrong double registration that - for reasons beyond my comprehension - resulted in the observed behavior.
The implementation including [self willChange...]; [self didChange...] works as described (on iOS 5), although it is far from beautiful. The issue is that as NSArray is not KVO-compliant there is no way to talk about changes to its contents. I had also thought about notifications as suggested by Mike Ash, but I decided to go with KVO as this seemed like a more Cocoa-ish mechanism to do the work. This was arguably not the best of decisions ...
Yes, calling -addObserver: twice will result in two registrations. A class Foo and some subclass of Foo, Bar, may both (legitimately) register for the same notification, but with different contexts (always include the context, always check the context in -observeValueForKeyPath and always call super in -observeValueForKeyPath).
This means that an instance of Bar will register twice, and this is correct.
However, you almost certainly don't want to register the same object/keypath/context more than once accidentally, and as #wbyoung says overriding -addObserver:forKeyPath:options:context: should help you make sure this doesn't happen. If nesessary keeping track of observers/keypath/context in an array and making sure they are unique.
Mike Ash has some interesting thoughts and code on his blog about using contexts. He is right about it being broken but in practise KVO is perfectly useable.
That is, when you use it to do something it is meant todo. It used to be that you absolutely could not do something like this..
[self willChangeValueForKey:#"contents"];
[self didChangeValueForKey:#"contents"];
because it's a lie. The value of 'contents' when you call -willChange.. must be a different value from when you call -didChange... The KVO mechanism will call -valueForKey:#"contents" in both -willChangeValueForKey and -didChangeValueForKey to verify the value has changed. This obviously won't work with an array as no matter how you modify the contents you still have the same object. Now i don't know if this is still the case (a web search turned up nothing) but note that -willChangeValueForKey, -didChangeValueForKey are not the correct way to handle manual kvo of a collection. For that Apple provides alternative methods:-
– willChange:valuesAtIndexes:forKey:
– didChange:valuesAtIndexes:forKey:
– willChangeValueForKey:withSetMutation:usingObjects:
– didChangeValueForKey:withSetMutation:usingObjects:
It may not still be true that the value must change, but if it is, your scheme is not going to work.
What i would do is have one notification for modifications to your collection. And a different notification for modification of items in that collection. i.e. at the moment you are trying to trigger notifications for #"contents" when instead you could have #"contents" and #"propertiesOfContents". You would need to observe two keypaths but you can use automatic kvo instead of manually triggering the notifications. (Using automatic kvo will ensure that the correct versions of -willChange.. -didChange.. are called)
For automatic kvo of an array take a look at (no NSArrayController needed) :-
Key-Value-Observing a to-many relationship in Cocoa
Then each time an item is added to the collection, observe the properties you need (as you are doing now) and when they change flip a value for self.propertiesOfContents. (ok as i read that back it doesn't necessarily sound less hacky than your solution but i still believe it may behave better).
In response to your modified question, try overriding addObserver:forKeyPath:options:context: in your custom class and setting a breakpoint on it. Alternatively, you can just set a symbolic breakpoint on -[NSObject addObserver:forKeyPath:options:context:], but that will probably get hit a lot.
In a project I have taken on, the original author has opted to use objc_setAssociatedObject() and I'm not 100% clear what it does or why they decided to use it.
I decided to look it up and, unfortunately, the docs aren't very descriptive about its purpose.
objc_setAssociatedObject
Sets an associated value for a given object using a given key and association policy.
void objc_setAssociatedObject(id object, void *key, id value, objc_AssociationPolicy policy)
Parameters
object
The source object for the association.
key
The key for the association.
value
The value to associate with the key key for object. Pass nil to clear an existing association.
policy
The policy for the association. For possible values, see “Associative Object Behaviors.”
So what exactly does this function do and in what cases should it be used?
Edit after reading answers
So what is the point in the following code?
Device *device = [self.list objectAtIndex:[indexPath row]];
DeviceViewController *next = [[DeviceViewController alloc] initWithController:self.controller
device:device
item:self.rootVC.selectedItem];
objc_setAssociatedObject(device, &kDeviceControllerKey, next, OBJC_ASSOCIATION_RETAIN);
What is the point in associating the device with the view controller if it's already an instance variable?
objc_setAssociatedObject adds a key value store to each Objective-C object. It lets you store additional state for the object, not reflected in its instance variables.
It's really convenient when you want to store things belonging to an object outside of the main implementation. One of the main use cases is in categories where you cannot add instance variables. Here you use objc_setAssociatedObject to attach your additional variables to the self object.
When using the right association policy your objects will be released when the main object is deallocated.
From the reference documents on Objective-C Runtime Reference:
You use the Objective-C runtime
function objc_setAssociatedObject to
make an association between one object
and another. The function takes four
parameters: the source object, a key,
the value, and an association policy
constant. The key is a void pointer.
The key for each association must be unique. A typical pattern is to
use a static variable.
The policy specifies whether the associated object is assigned,
retained, or copied, and whether the
association is be made atomically or
non-atomically. This pattern is
similar to that of the attributes of
a declared property (see “Property
Declaration Attributes”). You specify
the policy for the relationship using
a constant (see
objc_AssociationPolicy and
Associative Object Behaviors).
Establishing an association between an array and a string
static char overviewKey;
NSArray *array =
[[NSArray alloc] initWithObjects:#"One", #"Two", #"Three", nil];
// For the purposes of illustration, use initWithFormat: to ensure
// the string can be deallocated
NSString *overview =
[[NSString alloc] initWithFormat:#"%#", #"First three numbers"];
objc_setAssociatedObject (
array,
&overviewKey,
overview,
OBJC_ASSOCIATION_RETAIN
);
[overview release];
// (1) overview valid
[array release];
// (2) overview invalid
At point 1, the string overview is
still valid because the
OBJC_ASSOCIATION_RETAIN policy
specifies that the array retains the
associated object. When the array is
deallocated, however (at point 2),
overview is released and so in this
case also deallocated. If you try to,
for example, log the value of
overview, you generate a runtime
exception.
Here is a list of use cases for object associations:
one: To add instance variables to categories. In general this technique is advised against, but here is an example of a legitimate use. Let's say you want to simulate additional instance variables for objects you cannot modify (we are talking about modifying the object itself, ie without subclassing). Let's say setting a title on a UIImage.
// UIImage-Title.h:
#interface UIImage(Title)
#property(nonatomic, copy) NSString *title;
#end
// UIImage-Title.m:
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
static char titleKey;
#implementation UIImage(Title)
- (NSString *)title
{
return objc_getAssociatedObject(self, &titleKey);
}
- (void)setTitle:(NSString *)title
{
objc_setAssociatedObject(self, &titleKey, title, OBJC_ASSOCIATION_COPY);
}
#end
Also, here is a pretty complex (but awesome) way of using associated objects with categories.. it basically allows you to pass in a block instead of a selector to a UIControl.
two: Dynamically adding state information to an object not covered by its instance variables in conjunction with KVO.
The idea is that your object gains state information only during runtime (ie dynamically). So the idea is that although you can store this state info in an instance variable, the fact that you're attaching this info into a an object instantiated at runtime and dynamically associating it with the other object, you are highlighting the fact that this is a dynamic state of the object.
One excellent example that illustrates this is this library, in which associative objects are used with KVO notifications. Here is an excerpt of the code (note: this KVO notification isn't necessary to run make the code in that library work.. rather it's put there by the author for convenience, basically any object that registers to this will be notified via KVO that changes have happened to it):
static char BOOLRevealing;
- (BOOL)isRevealing
{
return [(NSNumber*)objc_getAssociatedObject(self, &BOOLRevealing) boolValue];
}
- (void)_setRevealing:(BOOL)revealing
{
[self willChangeValueForKey:#"isRevealing"];
objc_setAssociatedObject(self, &BOOLRevealing,
[NSNumber numberWithBool:revealing], OBJC_ASSOCIATION_RETAIN_NONATOMIC);
[self didChangeValueForKey:#"isRevealing"];
}
bonus: take a look at this discussion/explanation of associated objects by Mattt Thompson, author of the seminal AFNetworking library
To answer your revised question:
What is the point in associating the device with the view controller if it's already an instance variable?
There are several reasons why you might want to do this.
the Device class doesn't have a controller instance variable, or property and you can't change it or subclass it e.g. you don't have the source code.
you want two controllers associated with the device object and you can't change the device class or subclass it.
Personally, I think it is very rare to need to use low level Objective-C runtime functions. This looks like a code smell to me.
I need to pass a message up to a controlling class (which creates an instance of the class which will be sending the message) So, I cannot directly reference the class name in my file, without either making it a Global (which is ridiculous to do if "NSNotification" advertises to be able to pass all kinds of messages, regardless of where / what class they are.
So without further ado...
(calling from Say ClassB)
ClassA creates instance of ClassB
Now in ClassB, I need to pass messages regarding button presses back up to ClassA
(insdie ClassB)
- (void)viewDidLoad
{
[[NSNotificationCenter defaultCenter] addObserver:ClassA
selector:#selector(doLoginAction)
name:#"SomeButton"
object:nil];
[super viewDidLoad];
}
This will NOT compile, even when I include, sorry, "#import "ClassA.h"
Now if I do something stupid like,
ClassA *classa = [[ClassA alloc]init];
and then use this Newly created instance of classa in addObserver:classa it will compile, but as I thought, will do absolutely nothing... (I knew that, but surprisingly this kind of code is prevalent in Iphone programming books...) So I tried it anyway.
But if I put this function in ClassA and use addObserver:ClassB
it will get called, but will cause a stack dump unrecognized selector sent to instance
or use addObserver:self.
I am tempted to delete Xcode and go back to vim and use a good old "C" callback...
So, if I get it right, you have a ClassA which creates instances of ClassB. Those instances, in turn, should send notifications directly to ClassA without knowing anything about it.
If that is correct, then NSNotificationCenter is exactly what you need.
In ClassA implementation add an initialialize method like this:
#implementation ClassA
+ (void)initialize
{
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:#selector(YourSelector:)
name:#"YourNotificationName"
object:nil];
}
+ (void)YourSelector:(NSNotification *)notification
{
NSDictionary *userInfo = [notification userInfo];
// ...
}
// ...
#end
Then, instances of ClassB should post their notifications using only its name:
#implementation ClassB
- (void)postNotification
{
NSDictionary *userInfo = ...; // may be nil
[[NSNotificationCenter defaultCenter]
postNotificationName:#"YourNotificationName"
// the same name is used in the `addObserver` call
// in the previous code snippet
object:nil
userInfo:userInfo];
}
// ...
#end
To sum it all up, you do not need to know anything about the receiver of notifications if you are using NSNotificationCenter. In fact, you may subscribe as many objects as you like to receive the same notification, and each of them will call its appropriate method (specified in addObserver) upon receiving the notification object.
Please remember that in the case when you add a class instance as an observer, rather than the class object itself, you should call [[NSNotificationCenter defaultCenter] removeObserver:self] in that instance's dealloc method.
I see a couple of problems here.
First you need to stop trying to use classes and instances interchangeably. Until you have a reasonable mental model of what your classes and instances represent and what they are responsible for you're going to have all sorts of confusion around when to use which one and OOP in general.
NSNotificationCenter allows you to register a specific instance of a class, a single object, as an observer of particular notifications. You need to be aware of, and have a reference to, the observing object in order to register it as an observer.
Secondly you need to consider what each of your classes, and therefor their instantiated objects are responsible for. What they should know, what they do not need to know, and how they can communicate.
Let's assume you create ObjectA as an instance of ClassA and it creates ObjectB which is an instance of ClassB. Now ObjectA is aware of ObjectB, after all A just created B so it is easy for A to have a reference to B. ObjectB is not yet aware of ObjectA; B was created but it need not know by which object or even what class that object was an instance of. If you want ObjectB to be able to communicate with ObjectA you have a couple of options.
Delegation: ObjectA sets a property on ObjectB to point back to ObjectA, now B can send messages to A directly. Now your two objects are coupled together which can be both useful and problematic.
Notifications: ObjectB can post notifications, ObjectA can observe notifications. B does not need to know that A is observing those notifications and A does not need to know that the notifications originated with B (though it could). These objects are very loosely coupled and you could change many things about your application without them ever being aware of it.
Importantly, if ObjectA is to listen for notifications then it is A's responsibility to add itself as an observer. Since B is not aware of A there's no way B can make A an observer. A's creator could since that object would have a reference to A but A's children cannot unless they were given some reference to A.
Looks like Alex chimed in with an excellent answer so hopefully this will all be useful.
I have a ViewController that initializes another class that loads data into a mutable array and saves it as a property on itself.
here is my ViewController init code:
-(id) initWithCollectionID:(NSString *)aCollectionID {
if (self = [super init]){
collectionID=aCollectionID;
dataSource = [[CollectionListDataSource alloc] initWithCollectionID:collectionID];
}
return self;
}
once dataSource has loaded all of the data into it's property dataSource.collectionItems I set dataSource.loaded = #"true";
how do I use addObserver to watch that value and fire off a function in my ViewController?
something like this I'd assume:
[self addObserver:dataSource forKeyPath:#"loaded" options:NSKeyValueChangeNewKey context:nil];
Then what do I do?
As your code stands now, it will pause until the data is loaded regardless of whether you use notifications or not. It will not progress past:
dataSource = [[CollectionListDataSource alloc] initWithCollectionID:collectionID];
...until the CollectionListDataSource object has completed its own initialization (which I presume also means the loading its data) and returns an instance of itself.
If you want the CollectionListDataSource object to load while the view controller keeps on initializing, you will need to put the CollectionListDataSource object on another thread. However, you can't have an attribute object running on separate thread.
You seldom need to jump through such hoops. Unless this array is very large (10k+ objects) you most likely don't have to worry about. In most cases, you need the data before the view can function anyway so there's no point in letting the view go on without the data.
If you do need actually need to observe an attribute of another object, see Key-Value Programming Guide: Registering For Key-Value Observing for details.
I'm looking for a reliable design for handling assignments that have asynchronous requests involved. To further clarify, I have a class which handles Data Management. It is a singleton and contains a lot of top level data for me which is used throughout my iPhone application.
A view controller might do something such as the following:
users = [MySingleton sharedInstance].users;
MySingleton will then override the synthesized users getter and see if it is set. If it is not set, it will speak to a Connection Manager (a wrapper for NSURLConnection and its delegate methods) which fires off an asynchronous request, and this is where problems begin. I cannot guarantee when "users" will be available. I could change the request to synchronous, but that will directly effect user experience, especially in a mobile environment where bandwidth is limited already.
I need to be able to at some point, have some kind of locking/synchronization code going on in my getter that doesn't return users until it is available or is nil.
Once the NSURLConnection has the data available, it needs to callback something/somewhere with a response object and let the getter know the data is available.. whether it's failed or succeeded.
Any suggestions on handling this?
I solved this problem a couple ways in different apps.
One solution is to pass an object and selector along to notify such as:
- (id)getUsersAndNotifyObject:(id)object selector:(SEL)selector
This breaks the nice property behavior however. If you want to keep the methods as properties, have them return immediately, with either cached data or nil. If you need to go out to the network, do so asynchronous and then let the rest of the app know the data changed via KVO or the NSNotificationCenter. (Cocoa Bindings would be an option on the Mac, but they don't exist on iPhone).
The two methods are fairly similar. Register for updates with your shared instance, and then ask for the data. KVO is a little lighter weight if you just dealing with raw observable properties, but an NSNotification might be more convenient if you're interested in several different pieces of data.
With an NSNotification, the client object could register for one type of notification which includes the changed data in its userInfo dictionary instead of having to register obvservers for every single key path you're interested in.
An NSNotification would also allow you to pass back failures or other status information a lot more easily than straight KVO.
KVO method:
// register observer first so you don't miss an update
[[MySingleton sharedInstance] addObserver:self
forKeyPath:#"users"
options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld)
context:&kvo_users_context];
users = [MySingleton sharedInstance].users;
// implement appropriate observeValueForKeyPath:ofObject:change:context: method
NSNotification Method:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(sharedDataChanged:)
name:MySingletonDataUpdatedNotification
object:[MySingletonDataUpdatedNotification sharedInstance]];
users = [MySingleton sharedInstance].users;
// implement appropriate sharedDataChanged: method
You can either use a delegate pattern or a notification pattern here.
A delegate would let a particular object know when users is complete, a notification pattern would notify any object that wants to know. Both are valid, depending on your situation.
Just remember: if you have any race issues in your app, your architecture is probably all wrong.
It took me a while to realize what the best way of handling this kind of typical task; it turns out the clue is in the design of many of Cocoa and CocoaTouch's own APIs: delegation.
The reason so many of Cocoa's APIs use delegation is because it fits very well with the asynchronous nature of many GUI apps.
It seems perfectly normal to want do do something along the lines of:
users = [MyDataFactory getUsers];
Except, as you point out, you have no idea when the getUsers method will finish. Now, there are some light-weight solutions to this; amrox mentioned a few in his post above (personally I'd say notifications aren't such a good fit but the object:selector: pattern is reasonable), but if you are doing this kind of thing a lot the delegation pattern tends to yield a more elegant solution.
I'll try to explain by way of an example of how I do things in my application.
Let's say we have a domain class, Recipe. Recipes are fetched from a web service. I typically have a series of repository classes, one for each entity in my model. A repository class' responsibility is to fetch the data required for the entity (or a collection of them), use that data to construct the objects, and then pass those objects onto something else to make use of them (typically a controller or data source).
My RecipeRepository interface might look something like this:
#interface RecipeRepository {}
- (void)initWithDelegate:(id)aDelegate;
- (void)findAllRecipes;
- (void)findRecipeById:(NSUInteger)anId;
#end
I'd then define a protocol for my delegate; now, this can be done as an informal or formal protocol, there are pros and cons of each approach that aren't relevant to this answer. I'll go with a formal approach:
#protocol RepositoryDelegateProtocol
- (void)repository:(id)repository didRetrieveEntityCollection:(NSArray *)collection;
- (void)repository:(id)repository didRetrieveEntity:(id)entity;
#end
You'll notice I've gone for a generic approach; you will likely have multiple XXXRepository classes in your app and each will use the same protocol (you may also choose to extract a base EntityRepository class that encapsulates some common logic).
Now, to use this in a controller, for example, where you previous would have done something such as:
- (void)viewDidLoad
{
self.users = [MySingleton getUsers];
[self.view setNeedsDisplay];
}
You would do something like this:
- (void)viewDidLoad
{
if(self.repository == nil) { // just some simple lazy loading, we only need one repository instance
self.repository = [[[RecipeRepository alloc] initWithDelegate:self] autorelease];
}
[self.repository findAllRecipes];
}
- (void)repository:(id)repository didRetrieveEntityCollection:(NSArray *)collection;
{
self.users = collection;
[self.view setNeedsDisplay];
}
You could even extend this further to display some kind of "loading" notice with an additional delegate method:
#protocol RepositoryDelegateProtocol
- (void)repositoryWillLoadEntities:(id)repository;
#end
// in your controller
- (void)repositoryWillLoadEntities:(id)repository;
{
[self showLoadingView]; // etc.
}
Another thing about this design is that your repository classes really don't need to be singletons - they can be instantiated wherever you need them. They may deal with some kind of singleton connection manager but at this layer of abstraction a singleton is unnecessary (and its always good to avoid singletons where possible).
There is a downside to this approach; you may find you need layers of delegation at each level. For instance, your repositories may interact with some kind of connection object which does the actual asynchronous data loading; the repository might interact with the connection object using it's own delegation protocol.
As a result you might find you have to "bubble up" these delegation events throughout the different layers of your application using delegates that get more and more coarse-grained as they get closer to your application-level code. This can create a layer of indirection that can make your code harder to follow.
Anyway, this is my first answer on SO, I hope its been helpful.