Permalink
Browse files

[UI] Implement delegates and selectors for linked table items.

This finally makes it possible to interact with Three20 table views without
depending upon TTNavigator.
  • Loading branch information...
1 parent c35edce commit 1b946f475fb28d60e0aafc9ef394050c642c3a5b @jverkoey jverkoey committed Jul 4, 2010
@@ -18,11 +18,18 @@
#import "Three20UI/TTTableItem.h"
@interface TTTableLinkedItem : TTTableItem {
+ // If a URL is specified, TTNavigator will be used. Otherwise, the delegate+selector will
+ // be invoked.
NSString* _URL;
NSString* _accessoryURL;
+
+ id _delegate;
+ SEL _selector;
}
-@property (nonatomic, copy) NSString* URL;
-@property (nonatomic, copy) NSString* accessoryURL;
+@property (nonatomic, copy) NSString* URL;
+@property (nonatomic, copy) NSString* accessoryURL;
+@property (nonatomic, assign) id delegate;
+@property (nonatomic, assign) SEL selector;
@end
@@ -27,4 +27,6 @@
+ (id)itemWithText:(NSString*)text URL:(NSString*)URL;
+ (id)itemWithText:(NSString*)text URL:(NSString*)URL accessoryURL:(NSString*)accessoryURL;
++ (id)itemWithText:(NSString*)text delegate:(id)delegate selector:(SEL)selector;
+
@end
@@ -27,12 +27,16 @@ @implementation TTTableLinkedItem
@synthesize URL = _URL;
@synthesize accessoryURL = _accessoryURL;
+@synthesize delegate = _delegate;
+@synthesize selector = _selector;
///////////////////////////////////////////////////////////////////////////////////////////////////
- (void)dealloc {
- TT_RELEASE_SAFELY(_URL);
- TT_RELEASE_SAFELY(_accessoryURL);
+ self.URL = nil;
+ self.accessoryURL = nil;
+ self.delegate = nil;
+ self.selector = nil;
[super dealloc];
}
@@ -48,6 +52,7 @@ - (void)dealloc {
- (id)initWithCoder:(NSCoder*)decoder {
if (self = [super initWithCoder:decoder]) {
self.URL = [decoder decodeObjectForKey:@"URL"];
+ self.accessoryURL = [decoder decodeObjectForKey:@"accessoryURL"];
}
return self;
}
@@ -60,7 +65,7 @@ - (void)encodeWithCoder:(NSCoder*)encoder {
[encoder encodeObject:self.URL forKey:@"URL"];
}
if (self.accessoryURL) {
- [encoder encodeObject:self.accessoryURL forKey:@"URL"];
+ [encoder encodeObject:self.accessoryURL forKey:@"accessoryURL"];
}
}
@@ -70,6 +70,16 @@ + (id)itemWithText:(NSString*)text URL:(NSString*)URL accessoryURL:(NSString*)ac
///////////////////////////////////////////////////////////////////////////////////////////////////
++ (id)itemWithText:(NSString*)text delegate:(id)delegate selector:(SEL)selector {
+ TTTableTextItem* item = [[[self alloc] init] autorelease];
+ item.text = text;
+ item.delegate = delegate;
+ item.selector = selector;
+ return item;
+}
+
+
+///////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark NSCoding
@@ -119,6 +119,9 @@ - (void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)
TTTableLinkedItem* item = object;
if (item.URL && [_controller shouldOpenURL:item.URL]) {
TTOpenURL(item.URL);
+
+ } else if (item.delegate && item.selector) {
+ [item.delegate performSelector:item.selector withObject:object];
}
if ([object isKindOfClass:[TTTableButton class]]) {

8 comments on commit 1b946f4

Contributor

Any reason these don't use TT_RELEASE_SAFELY() anymore? using property notation in dealloc can have interesting side effects such as calling KVC/KVO listeners and is sometimes undesirable.

Contributor

This is a fair point. The rationale was that the dealloc method would be less error-prone by using property methods. There is less likelihood of accidentally releasing something that isn't retained or copied this way, for example.

It's very likely that calling KVC/KVO listeners on the dealloc is far less desirable than avoiding the potential for over-releasing something. What's your opinion?

Contributor

I would say go with release/nil like TT_RELEASE_SAFELY does. If you call TT_RELEASE_SAFELY on an assigned property it is most certainly a bug and one that will more than likely cause a crash pretty quickly so it should be easy to identify. I just made the comment because TT_RELEASE_SAFELY is used everywhere in the framework and if anyone is using KVO/KVC they will get some unneeded notifications. Seems like a good plan to keep it all consistent.

Contributor

I'll second the recommendation to use TT_RELEASE_SAFELY. In the past I've tried using the accessors in dealloc methods and that just ends of causing more pain than it's worth.

+1 for TT_RELEASE_SAFELY

Contributor

Fixed in 679e680.

Especially true for dynamic setters. If the setters are not implemented properly, assigning the property to nil may cause problem.

Actually hit this the other day in one of my classes and solved it the same way... +1 for TT_RELEASE_SAFELY.

Please sign in to comment.