-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Provided support for iOS 13 Context Menus #1430
base: main
Are you sure you want to change the base?
Provided support for iOS 13 Context Menus #1430
Conversation
Not sure about what to do with Travis failing, as per the following PR Fix the podlint error #1428 it seems it's a known issue. |
hey @jjbourdev , thanks for the PR! mind rebase from master and trigger the build again? thx! |
b38510c
to
78a5fc0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good, pls fix the pod lint error (you could run the command locally) and ensure CI pass.
|
||
@note The default implementation does nothing. **Calling super is not required.** | ||
*/ | ||
- (nullable UIContextMenuConfiguration *)contextMenuConfigurationForItemAtIndex:(NSInteger)index point:(CGPoint)point API_AVAILABLE(ios(13.0)) API_UNAVAILABLE(tvos); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this actually compile or work? I saw you have some lint error here: https://travis-ci.org/Instagram/IGListKit/jobs/655541844?utm_medium=notification&utm_source=github_status which is related to this file change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it does, I don't really get why it complains here, it seems it wants the nullable
to be apart from the return type.
I double checked on all samples, deintegrating / reinstalling all pods, it works pretty well, on multiple iOS versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the local execution of the lint:
$ machine:IGListKit jbourdev$ bundle exec pod lib lint IGListSwiftKit.podspec --allow-warnings "--include-podspecs=*.podspec"
-> IGListSwiftKit (4.1.0)
- NOTE | xcodebuild: note: Using new build system
- NOTE | xcodebuild: note: Planning build
- NOTE | xcodebuild: note: Constructing build description
- NOTE | xcodebuild: warning: Skipping code signing because the target does not have an Info.plist file and one is not being generated automatically. (in target 'App' from project 'App')
IGListSwiftKit passed validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Travis builds on Xcode 10.2.1 - 10E1001 while I locally build on Xcode 11.3.1 - 11C504. It shouldn't be an issue though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same result if I do my setup the same as the CI... @lorixx any idea? :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lorixx The error is different from a CI run to another... It compiles properly locally, on all targets, and for each example app. How could I solve the issue so this PR gets accepted?
2a6dfb5
to
92e927a
Compare
Hey, what about merge?) |
I wish I can :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about merging it to the master?
@lorixx any ETA?
// forward this method to the delegate b/c this implementation will steal the message from the proxy | ||
id<UICollectionViewDelegate> collectionViewDelegate = self.collectionViewDelegate; | ||
if ([collectionViewDelegate respondsToSelector:@selector(collectionView:contextMenuConfigurationForItemAtIndexPath:point:)]) { | ||
[collectionViewDelegate collectionView:collectionView contextMenuConfigurationForItemAtIndexPath:indexPath point:point]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here should be return [collectionViewDelegate collectionView:collectionView contextMenuConfigurationForItemAtIndexPath:indexPath point:point];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope it's a call to the delegate.
I don't see anything blocking in this PR, apart from the fact it's getting old now :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My 2 cents: I too think this line is missing a return
in the beginning. As far as I'm aware collectionView:contextMenuConfigurationForItemAtIndexPath:point:
's purpose is to return a context menu configuration, not simply to notify the delegate (see docs).
If you do return
here you would give the developer option to either add context menu configuration to collectionViewDelegate
or to sectionController
. If you do not return here there's no reason to implement this method in collectionViewDelegate
since it wouldn't do anything.
At least I would have been surprised if I had implemented collectionView:contextMenuConfigurationForItemAtIndexPath:point:
in collectionViewDelegate
, returned proper configuration and it wouldn't cause context menu to show up.
|
||
@return An object that conforms to `UIContextMenuConfiguration`. | ||
*/ | ||
- (UIContextMenuConfiguration * _Nullable)sectionController:(IGListBindingSectionController *)sectionController |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with IGListKit
, but this seems like an unnecessary forwarding of the call — after all it's IGListBindingSectionController**Selection**Delegate
, not a "general delegate" — why would a "delegate that receives selection events from cells" be interested in context menu events?
dc15a92
to
e662826
Compare
Hi, Any update on this |
@TimOliver has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
3b2f186
to
95fb46b
Compare
@jeromeboursier has updated the pull request. You must reimport the pull request before landing. |
Hi folks! I'm so sorry for the amount of time it's taken to get back to this PR. I had a play with the PR in the sample app, and I gotta say this is a pretty dope feature! I tried importing it into the Instagram codebase, and after a bit of review, I think we need to tweak it a bit. Namely, that new method in We might need to have a think about this, but it might be more appropriate to add a new property/protocol to What do you think? |
Hi @TimOliver , Any update on this? |
Changes in this pull request
Issue fixed: Provided support for Context Menus
Checklist
CHANGELOG.md
for any breaking changes, enhancements, or bug fixes.