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

NSFilePromiseProviderDelegate not implemented properly #5504

Closed
ivanicin opened this Issue Jan 28, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@ivanicin
Copy link

ivanicin commented Jan 28, 2019

Steps to Reproduce

Expected Behavior

NSFilePromiseProvider class is available in AppKit and it supports all its methods

Actual Behavior

NSFilePromiseProvider class is available in AppKit, only INSFilePromiseProvider

When I try to implement INSFilePromiseProvider, it has just one method out of three that it should have.

Environment

=== Visual Studio Community 2017 for Mac ===

Version 7.7.3 (build 43)
Installation UUID: f546b303-006e-4f34-8fa8-4662985b4489
	GTK+ 2.24.23 (Raleigh theme)
	Xamarin.Mac 4.4.1.178 (master / eeaeb7e6)

	Package version: 516000221

=== Mono Framework MDK ===

Runtime:
	Mono 5.16.0.221 (2018-06/b63e5378e38) (64-bit)
	Package version: 516000221

=== NuGet ===

Version: 4.8.0.5385

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	2.1.2
	2.1.1
	2.0.5
	2.0.0
	1.1.1
	1.0.4
SDK: /usr/local/share/dotnet/sdk/2.1.302/Sdks
SDK Versions:
	2.1.302
	2.1.301
	2.1.4
	2.0.0
	1.0.3
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.16.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.4
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Updater ===

Version: 11

=== Apple Developer Tools ===

Xcode 10.1 (14460.46)
Build 10B61

=== Xamarin.Mac ===

Version: 5.2.1.13 (Visual Studio Community)
Hash: a4332c90
Branch: 
Build date: 2019-01-11 13:08:10-0500

=== Xamarin.iOS ===

Version: 12.2.1.13 (Visual Studio Community)
Hash: a4332c90
Branch: d15-9
Build date: 2019-01-11 13:08:09-0500

=== Xamarin.Android ===

Version: 9.1.5.1 (Visual Studio Community)
Android SDK: /Users/ivanicin/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.4   (API level 19)
		6.0   (API level 23)
		7.0   (API level 24)
		7.1   (API level 25)
		8.1   (API level 27)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 27.0.1
SDK Build Tools Version: 27.0.3

=== Microsoft Mobile OpenJDK ===

Java SDK: /Users/ivanicin/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.9
openjdk version "1.8.0-9"
OpenJDK Runtime Environment (build 1.8.0-9-microsoft-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android Device Manager ===

Version: 7.7.1.0
Hash: 06ceaea1

=== Xamarin Inspector ===

Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1

=== Build Information ===

Release ID: 707030043
Git revision: 5896ab2acba037c62271742e9e56b900c96c1d8f
Build date: 2019-01-15 21:18:33+00
Build branch: release-7.7
Xamarin extensions: e5b43ba963b7b407aa5b9f2c59018c32a709e6ab

=== Operating System ===

Mac OS X 10.14.2
Darwin 18.2.0 Darwin Kernel Version 18.2.0
    Mon Nov 12 20:24:46 PST 2018
    root:xnu-4903.231.4~2/RELEASE_X86_64 x86_64

Build Logs

Example Project (If Possible)

@dalexsoto dalexsoto added this to the Future milestone Jan 29, 2019

@dalexsoto

This comment has been minimized.

Copy link
Member

dalexsoto commented Jan 29, 2019

Hello @ivanicin

Thank you for reaching us! I think you are talking about the actual NSFilePromiseProviderDelegate, it is fully bound as you can see here

xamarin-macios/src/appkit.cs

Lines 25603 to 25614 in 40c998e

interface NSFilePromiseProviderDelegate
{
[Abstract]
[Export ("filePromiseProvider:fileNameForType:")]
string GetFileNameForDestination (NSFilePromiseProvider filePromiseProvider, string fileType);
[Export ("filePromiseProvider:writePromiseToURL:completionHandler:")]
void WritePromiseToUrl (NSFilePromiseProvider filePromiseProvider, NSUrl url, [NullAllowed] Action<NSError> completionHandler);
[Export ("operationQueueForFilePromiseProvider:")]
NSOperationQueue GetOperationQueue (NSFilePromiseProvider filePromiseProvider);
}

It has one @required member and two @optional members, the required member is part of the defined members inside INSFilePromiseProviderDelegate interface and the optional members are included as extensions of INSFilePromiseProviderDelegate . You should be able to do the following in order to use NSFilePromiseProviderDelegate

public class FilePromiseProvider : NSObject, INSFilePromiseProviderDelegate {

	NSFilePromiseProvider provider;

	public FilePromiseProvider (NSFilePromiseProvider provider) => this.provider = provider;

	public string GetFileNameForDestination (NSFilePromiseProvider filePromiseProvider, string fileType)
	{
		// Do something
	}

	[Export ("filePromiseProvider:writePromiseToURL:completionHandler:")]
	void WritePromiseToUrl (NSFilePromiseProvider filePromiseProvider, NSUrl url, Action<NSError> completionHandler)
	{
		// Do something
	}

	[Export ("operationQueueForFilePromiseProvider:")]
	NSOperationQueue GetOperationQueue (NSFilePromiseProvider filePromiseProvider)
	{
		// Do something
	}
}

So the optional members must be decorated with the Export attribute and the ObjC selector they are binding, the IDE should offer autocompletion including the Export for the optional members as I describe in this StackOverflow answer https://stackoverflow.com/a/36761749/572076.

Hope this helps! Feel free to reopen the issue if this does not solve your inquiry.

@dalexsoto dalexsoto closed this Jan 29, 2019

@ivanicin

This comment has been minimized.

Copy link
Author

ivanicin commented Jan 29, 2019

Basically you have confirmed what I said, except for one 'should' that doesn't stand the test.

So to conclude:

  1. There is no AppKit.NSFilePromiseProviderDelegate class
  2. Those optional methods are not implemented properly (and no they aren't available in IDE auto-complete otherwise I wouldn't file the bug. Of course I can use Export for any unmapped API so including [Export] it may work but it wasn't the point of the question or answer).

I think this issue shouldn't be closed?

@spouliot

This comment has been minimized.

Copy link
Contributor

spouliot commented Jan 29, 2019

It's a *Delegate type so it should have a [Model] concrete helper class.

@spouliot spouliot reopened this Jan 29, 2019

@spouliot spouliot added bug and removed question labels Jan 29, 2019

@ivanicin

This comment has been minimized.

Copy link
Author

ivanicin commented Jan 29, 2019

Thanks.

As far as I can tell you need to make a sample not just because sample is needed but because this API is not tested at all and it seem to have several bugs (right now I think I found several by now), and I can't actually make it work at all.

Aside from two bugs mentioned above I can't see any pages in the documentation for this API and also one constructor of NSFilePromiseProvider that has string and NSFilePromiseProviderDelegate as parameters seems to crash simply by calling it.

On the other hand in the several pages you present this API like recommended way of implementing something, and I guess that you should actually test it in sample before telling something like that.

dalexsoto added a commit to dalexsoto/xamarin-macios that referenced this issue Jan 30, 2019

@dalexsoto

This comment has been minimized.

Copy link
Member

dalexsoto commented Jan 30, 2019

You are right, I missed the lacking of Model and BaseType attributes still, the approach of having your custom NSObject with the Export's and adopting INSFilePromiseProviderDelegate should also work. That said if you encounter more issues please keep filing them, this is the only way we can fix things we do not know about, we try our best on having ios, macOS samples and our unit tests but unfortunately due to the big amount of API's available and moving pieces we can't tests every single bit of them.

Thanks a lot for taking the time to report this!

dalexsoto added a commit that referenced this issue Jan 30, 2019

@ivanicin

This comment has been minimized.

Copy link
Author

ivanicin commented Jan 30, 2019

You are right, I missed the lacking of Model and BaseType attributes still, the approach of having your custom NSObject with the Export's and adopting INSFilePromiseProviderDelegate should also work. That said if you encounter more issues please keep filing them, this is the only way we can fix things we do not know about, we try our best on having ios, macOS samples and our unit tests but unfortunately due to the big amount of API's available and moving pieces we can't tests every single bit of them.

I know that is not something that can be considered as GitHub issue, but exactly what you said above shows that Xamarin has some problem in managing this project.

So yes, I agree macOS has many APIs, they are not even completely mapped, let alone tested. No problems with that. However, there is a bit of difference between 'any API' and 'API advertised in the official documentation'. It is not normal that you are not sure whether APIs mentioned in this text: https://docs.microsoft.com/en-us/xamarin/mac/platform/introduction-to-macos-sierra/modern-cocoa-apps don't work. What is the worse when faced with the argument that they don't work you should not close the bug by the opinion that they 'should' work. According to everything presented in this bug, Xamarin is not interested in anything beyond whether the very critical API 'should' work. Even now you can't say anything more than that it 'should' work after the fix (and the fix 'shoudn't' have been required too).

@chamons

This comment has been minimized.

Copy link
Member

chamons commented Jan 30, 2019

I believe you are misunderstanding @ivanicin.

A few points:

  • NSFilePromiseProviderDelegate is a protocol, which is similar to an interface in C#, and thus we bind it as INSFilePromiseProviderDelegate. @dalexsoto example is the correct way to handle this. We are not missing an API here, we are reflecting the protocol into C# interface.
  • As @dalexsoto pointed out, there is a difference between required and optional protocol methods, and the way we expose them is different. There is a bit of a mismatch between ObjC and C#, please read the documentation to learn more.
  • Xamarin.Mac does not claim to have 100% API coverage. The API surface on macOS is significantly larger than iOS and we only bind a subset. If you find some documentation that refers to XM having that coverage (not XI) please let me know and we'll get if fixed.
  • If there is a bug in the documentation, you can report it at the bottom of the page.
  • If you believe there is a bug in a sample, you can report it here.

Right now, I don't see a concrete bug, so closing it is correct.

If you wish to learn more, I would suggest starting with this documentation:

https://developer.xamarin.com/guides/mac/application_fundamentals/patterns/
https://developer.xamarin.com/guides/mac/application_fundamentals/mac-apis/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.