{"id":3666,"date":"2013-03-22T17:20:38","date_gmt":"2013-03-23T00:20:38","guid":{"rendered":"http:\/\/blog.xamarin.com\/?p=3666"},"modified":"2019-07-03T10:12:30","modified_gmt":"2019-07-03T17:12:30","slug":"producing-better-bindings-2-fields","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/xamarin\/producing-better-bindings-2-fields\/","title":{"rendered":"Producing Better Bindings #2: Fields"},"content":{"rendered":"

\t\t\t\tThis blog post is about producing better bindings of Objective-C libraries for Xamarin.iOS<\/a> and Xamarin.Mac<\/a>. Read the series introduction<\/a> to get a better idea why this is important and can save you time and headaches.<\/p>\n

What can go wrong ?<\/strong><\/p>\n

Maybe nothing! Not every library use fields, e.g. there are no fields in the Cocos2D library<\/a>. However, you should keep this fixture<\/a> in your binding test suite. If any fields are added in the future, then they’ll be tested without further work.<\/p>\n

For bindings that use fields, the most common issue will be typos. The compiler cannot validate the strings, so typos are sadly common, e.g. an extra space [Field (\"MyField \")]<\/code>.<\/p>\n

You’ll also find that some fields might not really exist anymore in a newer version of the bound library, so it’s a handy check to have when updating a native library in your existing bindings.<\/p>\n

What can we check for ?<\/strong><\/p>\n

When an\u00a0NSString<\/code> is defined, it’s generally because it has a non-null value. OTOH if any error (e.g. a typo) is made in the attribute, then you’re likely to get a null<\/code> result. This makes a great and easy condition to test.<\/p>\n

Why is this important ?<\/strong><\/p>\n

You might be giving null<\/code> values to some APIs that will either not work as you expect or will crash. Of course you won’t notice it before you actually use that specific field. This is not something that is easy to debug without looking at the binding source code \u2014something most consumers would prefer to avoid.<\/p>\n

How to fix issues ?<\/strong><\/p>\n

In most cases, it’s simply fixing the typo inside the [Field(\"\")]<\/code> attribute based on the library’s documentation and\/or header files.<\/p>\n

You might find some cases where a field is really meant to be null<\/code>. If this happens, you may skip the test for an entire type or a single property by overriding either Skip(Type)<\/code> or Skip(PropertyInfo)<\/code> methods.<\/p>\n

\n\t[TestFixture]\n\tpublic class BindingFieldTest : ApiFieldTest {\n\n\t\tprotected override bool Skip (Type type)\n\t\t{\n\t\t\t\/\/ uncommon - but you could skip an entire type from being checked\n\t\t\tif (type.FullName == "BrokenType")\n\t\t\t\treturn true;\n\t\t\treturn base.Skip (type);\n\t\t}\n\n\t\tprotected override bool Skip (PropertyInfo p)\n\t\t{\n\t\t\t\/\/ if some fields are meant to be null you can exclude them here\n\t\t\tswitch (p.Name) {\n\t\t\tcase "FieldKnownToReturnNull":\n\t\t\t\treturn true;\n\t\t\tdefault:\n\t\t\t\treturn base.Skip (p);\n\t\t\t}\n\t\t}\n\t}\n<\/pre>\n
What’s missing ?<\/strong><\/p>\n
The current implementation only validates fields that return\u00a0NSString<\/code>. With other types, such as integers and floats, it’s not easy to distinguish between valid and invalid based on their value. The information required to query the symbol (e.g. dlsym<\/code>) is not available, using reflection, in the assembly (i.e. the attribute is used to generate code).<\/p>\n
Also, and just like constructors, we cannot detect missing fields. You might want to grep header files (.h) and your binding files to see if number matches.<\/p>\n
Read the rest of the series:<\/b><\/p>\n