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

[ios11-beta1] Initial UIKit Drag and Drop support #2190

Merged
merged 11 commits into from Jul 10, 2017

Conversation

migueldeicaza
Copy link
Contributor

No description provided.

@monojenkins
Copy link
Collaborator

Build failure

@migueldeicaza
Copy link
Contributor Author

The build breaks with some Jenkins script while dowloading some code, dont know what to do here.

@rolfbjarne
Copy link
Member

build

@monojenkins
Copy link
Collaborator

Build failure

interface INSItemProviderReading {}

[Watch (4,0), TV (11,0), Mac (10,13), iOS (11,0)]
[Protocol, Model]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this protocol is supposed to be implemented by existing types that can be dragged/dropped, in which case [Model] doesn't make sense, it can be only [Protocol].


[Abstract]
[Export ("initWithItemProviderData:typeIdentifier:error:")]
NSObject CreateFrom (NSData providerData, string typeIdentifier, [NullAllowed] out NSError outError);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an Objective-C constructor, so I don't think binding it as an instance method will work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, what should we do in this case?

On the one hand, we should flag the classes that implement this, and manually add the constructor there (NSAttributedString, UIColor, UIImage). The other part is more complicated, given a class that implements this interface, probably our best bet is to have a factory method as an extension class that does the work:

static class NSItemProviderExtensions {
     public INSItemProviderReading CreateFromData (INSItemProviderReading self, NSData providerData, string typeIdentifier, etc) 
     {
         // something here.
     }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

src/uikit.cs Outdated
@@ -15405,6 +15435,24 @@ partial interface UIInputViewController : UITextInputDelegate {
void HandleInputModeList (UIView fromView, UIEvent withEvent);
}

[NoWatch, NoTV, iOS (11,0)]
[Protocol, Model]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This protocol is supposed to be implemented by existing types, so [Model] (and [BaseType]) should be dropped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it

src/uikit.cs Outdated
interface IUIDropInteractionDelegate {}

[NoWatch, NoTV, iOS (11,0)]
[Protocol, Model]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs [Model].

src/uikit.cs Outdated
}

[NoWatch, NoTV, iOS (11,0)]
[Protocol, Model]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs [Model].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it

Dropped the [Model] from protocols that do not need it, as well as the [BaseType] attribute.

Inlined the constructor for NSItemProviderReading in UIColor, NSAttributedString and UIImage as
we do not have support for making interfaces require a constructor and filed a bug with the
remaining work that would have to be done to support something like this:

https://bugzilla.xamarin.com/show_bug.cgi?id=57650
@monojenkins
Copy link
Collaborator

Build failure

[Static, Abstract]
[Export ("readableTypeIdentifiersForItemProvider", ArgumentSemantic.Copy)]
string[] ReadableTypeIdentifiersForItemProvider { get; }

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 work? From what I can tell trying to bind the Static property inside the interface doesn't seem to actually generate the code for it.

//
//[Abstract]
//[Export ("initWithItemProviderData:typeIdentifier:error:")]
//INSItemProviderReading CreateFrom (NSData providerData, string typeIdentifier, [NullAllowed] NSError outError);
Copy link
Contributor

@timrisi timrisi Jun 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the method being bound separately in the different classes instead of having the classes implement INSItemProviderReading?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See bug: https://bugzilla.xamarin.com/show_bug.cgi?id=57650 for details.

The runtime needs some changes to support the idiom.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I've stated on the bug I believe the runtime doesn't need changes to make it work, so this can be uncommented (and the CreateFrom method should be a proper Constructor, not a method).

The registrars can provide some help for users, but it needs these methods properly defined in order to have enough information to help users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What this patch does is to inline the constructor in all three places that conform to this procotol.

I tried doing what you suggested (a) removing the above line, and (b) removing the inlined constructors that this patch contains everywhere and (c) making those classes adopt the NSItemProviderReading interface, but that does not inline the constructor anywhere, nor does the interface gain anything out of having this method declared here.

The result is thus a step backwards, the patch to that is here:

https://gist.github.com/migueldeicaza/e22f44007e7ac093a0076276187dcb16

So I am not sure what is that you are suggesting I do with this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant only uncommenting the code here, inside NSItemProviderReading, not removing the inlined members elsewhere.

In any case I can fix this when I look at the corresponding bug.

…ses the static NSItemProviderReading class method, and tracking the documentation requirements here: https://bugzilla.xamarin.com/show_bug.cgi?id=57735
@monojenkins
Copy link
Collaborator

Build failure

@migueldeicaza
Copy link
Contributor Author

I am at a loss here, the build failure is an assertion that does not quite make sense:

3 errors found in 1613 static selector validated:
Foundation.NSAttributedString : readableTypeIdentifiersForItemProvider
UIKit.UIColor : readableTypeIdentifiersForItemProvider
UIKit.UIImage : readableTypeIdentifiersForItemProvider


  Expected: 0
  But was:  3

STACK TRACE:
at Introspection.ApiSelectorTest.StaticMethods () [0x001a4] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/introspection/ApiSelectorTest.cs:625 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in /Library/Frameworks/Xamarin.iOS.framework/Versions/10.99.0.44/src/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:305 

But these methods are there and respond to that selector:

screen shot 2017-06-24 at 10 28 38 am

@migueldeicaza
Copy link
Contributor Author

Sebastien replied: when I inlined these methods, I did not inline the availability attributes.

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build failure

@rolfbjarne
Copy link
Member

build

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build failure

@dalexsoto
Copy link
Member

Unrelated test failure: [FAIL] MessageHandlerTest.DnsFailure(System.Net.Http.NSUrlSessionHandler) : Exception -> https://bugzilla.xamarin.com/show_bug.cgi?id=57762

Copy link
Member

@dalexsoto dalexsoto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One tiny bit from my end :)

src/uikit.cs Outdated
[NoWatch, NoTV, iOS (11,0)]
[BaseType (typeof(NSObject))] // If Apple adds a delegate setter: Delegates=new string [] {"Delegate"}, Events=new Type [] { typeof (UIDropInteractionDelegate)})]
[DisableDefaultCtor]
interface UIDropInteraction : IUIInteraction
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you want to use UIInteraction interaction instead or the generator will pick the wrong interface

interface UIDropInteraction : UIInteraction

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do that, but can you explain the reason, I have forgotten :-)

@rolfbjarne
Copy link
Member

The remaining test failure is not related to this PR, so this is good to go once it's approved by @timrisi / @dalexsoto (I see Alex just added a new comment, so that should be addressed too).

src/uikit.cs Outdated

[Abstract]
[Export ("canLoadObjectsOfClass:")]
bool CanLoadObjectsOfClass (INSItemProviderReading aClass);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CanLoadObjectsOfClass > CanLoadObjects

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think this is a good idea.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's check what Swift is using, they normally use API name very close to the .net we have been promoting for years (and it also makes ease googl'ability)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See https://bugzilla.xamarin.com/show_bug.cgi?id=58079#c1

Swift code:

session.loadObjects(ofClass: UIImage.self) { imageItems in
        let images = imageItems as! [UIImage]

        /*
             If you do not employ the loadObjects(ofClass:completion:) convenience
             method of the UIDropSession class, which automatically employs
             the main thread, explicitly dispatch UI work to the main thread.
             For example, you can use `DispatchQueue.main.async` method.
        */
        self.imageView.image = images.first
}

src/uikit.cs Outdated

[Abstract]
[Export ("hasItemsConformingToTypeIdentifiers:")]
bool HasItemsConformingToTypeIdentifiers (string[] typeIdentifiers);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure it's the best C# name we can come up with, maybe HasConformingItems?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

src/uikit.cs Outdated
CGSize Size { get; }

[Export ("retargetedPreviewWithTarget:")]
UITargetedDragPreview RetargetedPreviewWithTarget (UIDragPreviewTarget newTarget);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RetargetedPreviewWithTarget > RetargetedPreview

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went with GetRetargetedPreview

@monojenkins
Copy link
Collaborator

Build failure

@monojenkins
Copy link
Collaborator

Build failure

@migueldeicaza migueldeicaza dismissed timrisi’s stale review July 8, 2017 02:17

Addressed in the comments.

@rolfbjarne rolfbjarne merged commit 35462f0 into xamarin:xcode9 Jul 10, 2017
@praeclarum
Copy link
Contributor

I notice that UIDragInteraction is missing from this. Is that intentional?

@rolfbjarne
Copy link
Member

@praeclarum yeah, we know it's not complete. We have tests that flag everything we haven't implemented.

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

Successfully merging this pull request may close these issues.

None yet

9 participants