0

I have a shared singleton that contains all relevant information on the current user and its session, through the object [IWSession session] and [IWSession session].currentUser.

The current user (which actually refers to the one logged in the application) might have some of its properties updated frequently through webservice calls (triggered by iBeacon, triggered by a change in its location, etc). This implies to update the GUI accordingly at different places in the app, let's say 5 or 6 class instances.

What's the proper way to update information displayed in the app as soon as any property is updated ?

I thought about

1) Adding a KVO on the [IWSession session].currentUser on himself and for all properties regarding the following link Key Value Observing - how to observe all the properties of an object?

2) The KVO would then trigger a 

  [[NSNotificationCenter defaultCenter] postNotificationName:@"userUpdated" object:nil];

and all classes which need their layout to be updated would listen to that notification.

Is it a good approach ? Any other suggestion ?

Community
  • 1
  • 1
Romain Dorange
  • 831
  • 1
  • 10
  • 23

2 Answers2

0

If you use Notifications then memory will not be released for all the objects in which notification is posted. Because if you use notifications then reference to the object is stored in the heap. So I don't this it would be a good idea to use Notifications.

0

I recently have been using a weak-observer list using hashtables

mObservers = [NSHashTable weakObjectsHashTable];

with semi-delegation messages, for example:

@protocol UserSessionObserver <NSObject>
- (void) userSession:(id)session didUpdateUser:(id)userProfile;
@end

So, any object that would be interested in changes to userProfile or userSession can simply add itself as an ad-hoc observer to the shared userSession. Because it is a weak entry, the object will be removed automatically from the observer table on dealloc.

Trick is to create the correct addObserver message:

- (void) addObserver:(__weak id<UserSessionObserver>)observer;

While this requires you to write your own observer logic, it also means: 1. No memory management issues with strong retain cycles, 2. Simplified and to the point observer messaging (the system notifications and KVO implementation is so generic, it is bordering on incomprehensible imo, but also adds several layers of logic that merely slows down processing).

An example implementation: Weak Observer example

32Beat
  • 284
  • 2
  • 2