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

Provided support for iOS 13 Context Menus #1430

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jeromeboursier
Copy link

@jeromeboursier jeromeboursier commented Feb 25, 2020

Changes in this pull request

Issue fixed: Provided support for Context Menus

Checklist

  • All tests pass. Demo project builds and runs.
  • I added tests, an experiment, or detailed why my change isn't tested.
  • I added an entry to the CHANGELOG.md for any breaking changes, enhancements, or bug fixes.
  • I have reviewed the contributing guide

@jeromeboursier
Copy link
Author

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.

@lorixx
Copy link
Contributor

lorixx commented Feb 26, 2020

hey @jjbourdev , thanks for the PR! mind rebase from master and trigger the build again? thx!

Copy link
Contributor

@lorixx lorixx left a 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);
Copy link
Contributor

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.

Copy link
Author

@jeromeboursier jeromeboursier Feb 27, 2020

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.

Copy link
Author

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.

Copy link
Author

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.

Copy link
Author

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? :/

Copy link
Author

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?

@jeromeboursier jeromeboursier force-pushed the feature/support-for-context-menu branch from 2a6dfb5 to 92e927a Compare March 3, 2020 13:17
@Flatout73
Copy link

Hey, what about merge?)

@jeromeboursier
Copy link
Author

I wish I can :)

@lorixx lorixx mentioned this pull request Oct 21, 2020
5 tasks
Copy link

@AYastrebov AYastrebov left a 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];

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];

Copy link
Author

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 :)

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
Copy link

@sjchmiela sjchmiela Sep 2, 2021

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?

@amalenduk
Copy link

Hi, Any update on this

@facebook-github-bot
Copy link
Contributor

@TimOliver has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@TimOliver TimOliver force-pushed the feature/support-for-context-menu branch from 3b2f186 to 95fb46b Compare April 27, 2023 08:28
@facebook-github-bot
Copy link
Contributor

@jeromeboursier has updated the pull request. You must reimport the pull request before landing.

@TimOliver
Copy link
Member

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 IGListBindingSectionControllerSelectionDelegate implicitly adds UIKit as a required import for the protocol, which might have ramifications down the line.

We might need to have a think about this, but it might be more appropriate to add a new property/protocol to IGListBindingSectionController to handle context menu configurations in its own silo separate from cell configuration. This also gives us a better space to add more of the context menu protocol methods down the line.

What do you think?

@amalenduk
Copy link

Hi @TimOliver , Any update on this?

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

Successfully merging this pull request may close these issues.

9 participants