Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two questions about IGListSingleSectionController? #480

Closed
PhilCai1993 opened this issue Feb 10, 2017 · 4 comments
Closed

Two questions about IGListSingleSectionController? #480

PhilCai1993 opened this issue Feb 10, 2017 · 4 comments

Comments

@PhilCai1993
Copy link
Contributor

PhilCai1993 commented Feb 10, 2017

  1. Is it necessary to make configureBlock nonnull?
    When initialize IGListSingleSectionController, a configureBlock is required to be nonnull.
    But sometimes it's not required. For example, when listAdapter:sectionControllerForObject: is invoked to return a sectionController, if object is some special object, it is not necessary to config the sectionController using the object(such a static cell).

  2. How about adding a didSelectSingleSectionHandler to be an alternative to IGListSingleSectionControllerDelegate since we have configureBlock and sizeBlock?
    In this way, it's of benefit to write codes together. Of course it's not difficult to customize a IGListBlockSupportedSingleSectionController if needed.😄

[[IGListSingleSectionController alloc] initWithCellClass:TipCell.class
        configureBlock:^(id item, UICollectionViewCell  *cell) {
// actually sometimes there's no need to do anything here
}
        sizeBlock:^CGSize(id item, id<IGListCollectionContext> collectionContext) {
          return CGSizeMake(DEVICE_WIDTH, TipCell.cellHeight);
        } actionHandler:^(id parameter){
          NSLog(@"select section");
         }];
@rnystrom
Copy link
Contributor

@PhilCai1993 this would be a nice enhancement. No, the configure block should be nullable.

I'm open to the selection change, making that a nullable block as well. We chose a delegate pattern so it would could be nil, but having nil parameters for the blocks should be fine I think!

The only concern w/ the selection part being a block is it will be prone to retain cycles, since I'd imagine consumers will access other state in that method.

For instance, if a view controller created the single section controller and did something like [self presentViewController:...] on selection, self will cause a cycle (assuming the VC owns the IGListAdapter).

Writing it out, I'm probably still opposed to changing that API.

@PhilCai1993
Copy link
Contributor Author

PhilCai1993 commented Feb 16, 2017

@rnystrom
And in IGListSingleSectionControllerDelegate:
- (void)didSelectSingleSectionController:(IGListSingleSectionController *)sectionController;
is it better to be
- (void)didSelectSingleSectionController:(IGListSingleSectionController *)sectionController object:(id)obj, where obj is private property item in IGListSingleSectionController.m

For example:

- (IGListSectionController<IGListSectionType> *)listAdapter:(IGListAdapter *)listAdapter
                                 sectionControllerForObject:(id)object {
 if ([object isKindOfClass:A.class]) {
      IGListSingleSectionController *controller = [[IGListSingleSectionController alloc] initWith:ACellClass ...];
      controller.delegate = self;
      return controller;
} else if ([object isKindOfClass:B.class]) {
      IGListSingleSectionController *controller = [[IGListSingleSectionController alloc] initWith:BCellClass ...];
      controller.delegate = self;
      return controller;
} 
...
}

//And In delegate

- (void)didSelectSingleSectionController:(IGListSingleSectionController *)sectionController {
      I don't know what is the object, A/B?
}

//Then in this way

- (void)didSelectSingleSectionController:(IGListSingleSectionController *)sectionController object:(id)object {
      I know  the "object"
}


@rnystrom
Copy link
Contributor

@PhilCai1993 I like that! You could lookup the object using -[IGListAdapter objectForSectionController:], but agreed providing the object makes it much simpler. PRs for each of these would be very appreciated!

@PhilCai1993
Copy link
Contributor Author

Close #397

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants