15 replies to this topic

[TODD GARLAND]

Gents,

 

So I moved to STV 4.05 and selecting tableview row. Previously the above fired upon selection. With the new version, and absent delegates how do I get this to fire, or what do I use in lieu of this. Generally, when selecting row, I would push a view controller or retreive values etc.

 

Thanks

 

TRG

[ozie]

how about

     self.tableViewModel.cellActions.didSelect = ^(SCTableViewCell *cell, NSIndexPath *indexPath)
    {
        NSLog(@"Cell at indexPath:%@ has been selected.", indexPath);
    };

 

if you only have one section.. say using SCArrayOfObjectsSection you might want to link that objects .cellActions.didSelect block

 

depending on what you really want to do you might want to check out some of these too which might come in handy

self.tableViewModel.cellActions.detailxxxxxxxxxxxx

Edited by ozie, 19 December 2014 - 08:33 PM.

[TODD GARLAND]

Ozie,

 

Thanks for the quick reply. I have got to plead ignorance though. I looked through all the methods of the static framework and there is no longer a method similar to xcode wherein you were able to call "didselectRowAtIndexPath" for a tableviewcontroller. So if a user clicks on a tableview row in a tableview controller, what in STV4.05 fires? For the present methods in the framework I located "willappear", willdisappear, didentereditingmode etc, but no didselectRowAtIndexPath.

 

Drawing a blank here.

 

Thanks

 

TRG

[ozie]

that would be

.cellActions.didSelect = ^(SCTableViewCell *cell, NSIndexPath *indexPath)

 

so there are a number of ways to use this such as

    SCEntityDefinition *def = [SCEntityDefinition definitionWithEntityName:@"Tasks" managedObjectContext:moContext autoGeneratePropertyDefinitions:YES];
    SCPropertyDefinition *completeDef = [def propertyDefinitionWithName:@"complete"];
    completeDef.cellActions.didSelect = ^(SCTableViewCell *cell, NSIndexPath *indexPath)
    {
        NSLog(@"Cell at indexPath:%@ has been selected.", indexPath);
    };

 

hope that helps

[TODD GARLAND]

Ozie,

 

Thanks. So essentially, the row selection methods of xcode are gone for STV. Thus, if I use STV's new interface to IB to automatically create master/detail etc, I still have to code in SCEntity definitions in order for STV to trigger events to get at the rows/cells etc.

 

As an aside, you are a sick puppy for being up so early, where ever you are located, unless of course you are doing something entertaining.

 

TRG

[ozie]

its only 9:45pm saturday here

[ozie]

I'm still very much a coder and haven't completely started an app using as much IB only

but from guessing you can create your own Segues in IB.. that is to make simple detailviewcontroller etc that you can design in IB.. but if you need more control you would need to use code

 

Tarek would have a clearer idea on what IB completeness is there

[David DelMonte]

Ozie, are you in Oz?

[ozie]

yup:)

[TODD GARLAND]

Ozie,

 

Per chance have you figured out or know the structure/Format for predicates in the new STV IB interface. There was previous discussion I got involved on, but no real response. Also, there is little or no documentation that I have found.

 

Thanks

 

TRG

[ozie]

i just did a quick play with it

so far i have only tested it with complete strings 

 

this works

title = 'Task 1'

 

but i have no idea as to how to use variables yet or if that would even work.. but would be nice if say a segment control was being tapped to filter or something

[TODD GARLAND]

Ozie,

 

Have another question that applies to this topic, which I am bashing my head over. 

 

We create master controller using IB and the following methods fire when the buttons are selected:

 

self.actions.editButtonTapped = ^BOOL(SCTableViewController *viewController) {

        return TRUE;

    };

    self.actions.doneButtonTapped = ^BOOL(SCTableViewController *viewController) {

        return TRUE;

    };

 

Now the question is...how do I access the detailviewcontroller or modalviewcontroller actions for these same buttons. For example, I add a new item and the modal comes up. I then have choice of Cancel or Done button, same with detailviewcontroller....

 

"self.actions.doneButtonTapped does not work, so I tried the entity definition etc to no avail.

 

Any help/direction would be appreciated. As an aside is there a way to implement the delegates any more?

 

Thanks

 

TRG

[ozie]

firstly.. NEVER use SELF inside block code

typeof(self) weak_self = self;
block ^(blah *blah) {
    weak_self.object = blah blah;
};

 

for the main view you can use.. there are actions for add too i think

- (void)editButtonAction {
    
}

- (void)doneButtonAction {
    
}

 

for the detail view i am not sure if there is some action block we can use.. since in IB we can generate the detail views you can create your own class and add the code that way..

maybe someone might know if there is some way to use code like

    SCEntityDefinition *myDef = [SCEntityDefinition new];
    myDef.cellActions.detailModelConfigured = ^(SCTableViewCell *cell, NSIndexPath *indexPath, SCTableViewModel *detailModel)
    {
       detailModel.xxxxx
    };

 

else you can use delegates

@interface MyViewController : SCViewController <SCTableViewControllerDelegate>

 

-(void)tableViewControllerWillDismiss:(SCTableViewController *)tableViewController cancelButtonTapped:(BOOL)cancelTapped doneButtonTapped:(BOOL)doneTapped {
    
}

[hmlongco]

firstly.. NEVER use SELF inside block code

typeof(self) weak_self = self;
block ^(blah *blah) {
    weak_self.object = blah blah;
};

 

This is a modern-day urban legend.  Let's look at the sample code given in Apple's documentation on blocks and retain cycles:

 

@interface XYZBlockKeeper : NSObject
@property (copy) void (^block)(void);
@end
@implementation XYZBlockKeeper
- (void)configureBlock {
self.block = ^{
[self doSomething]; // self is captured here
};
}
@end
 

 

Here, the use of self in the block "captures" a strong reference to self because it will be needed when the block executes. That wouldn't normally be a problem, because everything retained would be released when the block goes out of scope.

 

However, the block (with reference to self) was ALSO assigned to a property on self, and THAT'S what created the retain cycle. Functionally, they did the equivalent of...

 

@interface XYZBlockKeeper : NSObject
@property (strong) XYZBlockKeeper captured;
@end
@implementation XYZBlockKeeper
- (void)init {
self.captured = self;
}
@end
 

 

And that's the type of retain cycle you need to watch out for. Something like the following...

 

- (IBAction)doneAction:(id)sender {
[self.navigationController dismissViewControllerAnimated:YES completion:^{
[self.model save];
}];
}
 

 

Should work just fine without the need for __weak typeof(self)weakSelf = self or @weakify.

 

Block is saved on the stack with captured reference to self, block executes and falls out of scope, retained object (self) is released, and all is right with the world.

Edited by hmlongco, 30 December 2014 - 03:09 PM.

[ozie]

Should work just fine without the need for __weak typeof(self)weakSelf = self or @weakify.

 

 

'should work'.. does sound like a confident response to me but thanks for the info

 

i'll keep doing it the way i know works and the way instruments lets me know works..  i never use self inside STV action blocks

[hmlongco]

'should work'.. does sound like a confident response to me but thanks for the info

 

i'll keep doing it the way i know works and the way instruments lets me know works..  i never use self inside STV action blocks

 

"Should work" was simply meant to be a polite turn of phrase, but if you're looking for something more definite...

 

There are two issues here. The first is the fallacy of NEVER using self inside of ANY block code. The second is understanding when retain cycles actually occur and what to do about them when that happens.

 

So, and again, to be clear and completely unambiguous: My last example is perfectly safe. The completion block is stored as a parameter to the function call. Self is captured as part of that process. Eventually, the block is executed, the scope dissolves, and the retained "self" is released.

 

Apple's example, however, illustrates what happens when you use "self" in a block AND you retain a reference to a block in the same object. In the words, using self by itself in a block doesn't create a retain cycle. Using self AND storing the block in the same object, however, does. 

 

Which, as it turns out, is exactly what happens when you save a block in a STV Action array. 

 

self.actions.didSomethingOrOther = ^{ [self doSomthing]; };

 

So in that case, you're correct. self shouldn't be used in a STV Action array and you need all of the weak self rigamarole. (Not to mention strong self, but that's another discussion.)

 

Which, by the way, isn't clear from most of the STV documentation. In fact, having to do all of that special handling obviates most of the simplicity gained from using blocks in the first place. 

 

To sum up:

 

1) Don't use self in an action block. 

2) Don't clutter the rest of your code (completion handlers, etc.) with weakself/strongself weakify/strongify unless it's needed.