mono / api-doc-tools

.NET Reference API Toolchain
MIT License
68 stars 48 forks source link

Allow searching by "alternate" identifiers #120

Open jonpryor opened 7 years ago

jonpryor commented 7 years ago

Xamarin.Android and Xamarin.iOS bind native APIs, and may change names in the process. For example, the Android type android.view.View is bound as the Android.Views.View type. Searching for android.view.view would ideally show Android.Views.View; it does not.

What would need to be done to allow searching by the "native" type identifier and have the relevant managed bindings show up in search results?

The Android team would be more than happy to generate and provide a "mapping file" which maps Java identifiers to managed identifiers, if that would be at all useful.

Alternatively, it might be possible to use custom attributes. Xamarin.Android uses an Android.Runtime.RegisterAttribute attribute on types and members to provide the original Java name for a managed binding, e.g.

namespace Android.Views {
    [global::Android.Runtime.Register ("android/view/View", DoNotGenerateAcw=true, ApiSince = 1)]
    partial class View {
    }
}
joelmartinez commented 7 years ago

There was a similar request for iOS, to allow searching by message signature ... as in this case, this information is enshrined in an attribute on the member. My original proposal on this idea was to simply include strings and enum values in member attributes when we populate the search index ... however, the jury is still out whether that would produce useful/relevant search results.

I'm curious to explore your idea of a mapping file ... could the concept be generalized to allow arbitrary association of search terms with, say, IL signatures (or docID, perhaps)? that way, when we are populating the search index, we simply use the signature to see if there are additional terms to include? what would this mapping file look like for your purposes?

jonpryor commented 7 years ago

however, the jury is still out whether that would produce useful/relevant search results.

That would be interesting to know. :-)

In particular, I can imagine people wanting to search for e.g. [android.view.view.animate()](https://developer.android.com/reference/android/view/View.html#animate()), but the custom attributes don't directly connect the types and members. (They're indirectly connected via Reflection.)

namespace Android.Views {
    [global::Android.Runtime.Register ("android/view/View", DoNotGenerateAcw=true, ApiSince = 1)]
    partial class View {
        [Register ("animate", "()Landroid/view/ViewPropertyAnimator;", "GetAnimateHandler", ApiSince = 12)]
        public virtual unsafe Android.Views.ViewPropertyAnimator Animate () {/* ... */ }
    }
}

There's also a bit of a "mismatch" -- the above custom attributes use /, not ., hence android/view/View and not android.view.View. This is to help distinguish between package names (/) and nested types ($), e.g. the nested type android/view/View$OnClickListener.

Something will need to handle this semantic difference, either the search engine itself or the mapping file...

what would this mapping file look like for your purposes

What do you need it to look like? :-D

I can imagine a great many things, e.g. we could have a JSON document, with keys as DocID values, and values as an array of alternate lookup values:

{
  "T:Android.Views.View": [
    "Landroid/view/View;",
    "android.view.View",
    "View"
  ],
  "M:Android.Views.View.Animate()": [
    "android/view/View.animate()Landroid/view/ViewPropertyAnimator;",
    "android.view.View.animate",
    "View.animate"
  ]
}

The primary question should be this: what format makes your job easier? I'm not sure what is easiest for the search-engine side of things to consume.