I have looked over some ideas for how to supply a context to a UIAlertView. The common answers are save it in a dictionary or subclass UIAlertView. I don’t like the idea of saving the context in a dictionary, it’s the wrong place for the data. Subclassing UIAlertView is not supported by Apple, so by my standard, is not a good solution.
I came up with an idea, but I’m not sure what to make of it. Create an instance of a context object that is the delegate of UIAlertView. The alert view context, in turn, has it’s own delegate which is the view controller.
The trouble is releasing memory. I set alertView.delegate to nil and call [self autorelease] to free the context object in -alertView:didDismissWithButtonIndex:.
THE QUESTION IS: What problems am I causing myself? I have a suspicion that I’m setting myself up for a subtle memory error.
Here is the simple version which only supports -alertView:clickedButtonAtIndex:
Use
- (void)askUserIfTheyWantToSeeRemoteNotification:(NSDictionary *)userInfo
{
[[[[UIAlertView alloc] initWithTitle:[userInfo valueForKey:@"action"]
message:[userInfo valueForKeyPath:@"aps.alert"]
delegate:[[WantAlertViewContext alloc] initWithDelegate:self context:userInfo]
cancelButtonTitle:@"Dismiss"
otherButtonTitles:@"View", nil] autorelease] show];
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex withContext:(id)context
{
if (buttonIndex != alertView.cancelButtonIndex)
[self presentViewForRemoteNotification:context];
}
Interface
@protocol WantAlertViewContextDelegate <NSObject>
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex withContext:(id)context;
@end
@interface WantAlertViewContext : NSObject <UIAlertViewDelegate>
- (id)initWithDelegate:(id<WantAlertViewContextDelegate>)delegate context:(id)context;
@property (assign, nonatomic) id<WantAlertViewContextDelegate> delegate;
@property (retain, nonatomic) id context;
@end
Implementation
@implementation WantAlertViewContext
- (id)initWithDelegate:(id<WantAlertViewContextDelegate>)delegate context:(id)context
{
self = [super init];
if (self) {
_delegate = delegate;
_context = [context retain];
}
return self;
}
- (void)dealloc
{
[_context release];
[super dealloc];
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
[self.delegate alertView:alertView clickedButtonAtIndex:buttonIndex withContext:self.context];
}
- (void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex
{
alertView.delegate = nil;
[self autorelease];
}
@synthesize delegate = _delegate;
@synthesize context = _context;
@end
You can use the concept of associated objects. Using the functions
objc_setAssociatedObject()andobjc_getAssociatedObject(). You can use these properties to essentially add a new property, in your case to hold anNSDictionary, to an object through a category.Here is an example of a
UIAlertViewcategory. These files should be compiled withoutARC,-fno-objc-arcflag set if the project is using ARC.UIAlertView+WithContext.h:
UIAlertView+WithContext.m:
This category is easily used.
SomeViewController.m: a
UIAlertViewDelegateusing ARC or not.When you press the alertview’s OK button you will see:
A couple of notes:
1) Make sure the association type matches the property declaration so things behave as expected.
2) You probably shouldn’t use
userInfofor the property/association since Apple may well decide to add auserInfoproperty toUIAlertViewin the future.Edit To address your concerns about your
[self autorelease];It is imperative that you balance your implicit
allocretain from this line:delegate:[[WantAlertViewContext alloc] initWithDelegate:self context:userInfo]. You achieve this balance by calling[self autorelease];in the finalUIAlertViewdelegate method.Granted, this does feel wrong. Mostly because there is no way when looking at this that it doesn’t at first blush look like memory mis-management. But there is one simple way to avoid this “controlled leak” API you are creating; Have the instance of
WantAlertViewContextexplicitly retain itself. For example:Now your class has some internal harmony. I say some because this is still not perfect. For example, if an instance is never an alert-view delegate it will never be released. It is still just a “semi-controlled” memory leak.
Anyway, now your instantiation call can look more logical:
I think that this particular design pattern is fraught with danger. If you do end up using it keep a close eye on it.