Open jonpryor opened 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?
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.
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 theAndroid.Views.View
type. Searching forandroid.view.view
would ideally showAndroid.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.