Xamarin Mobile Application Development for Android(Second Edition)
上QQ阅读APP看书,第一时间看更新

The Android bindings design

The core parts of Xamarin.Android are the bindings for the Android APIs. The Xamarin team focused a great deal in developing a consistent approach to create the bindings so that a C# .NET developer would feel at home when using them. This has resulted in a number of key benefits as follows:

  • The Android API feels natural to a C# .NET developer and allows the developer to explore the API using the code completion and pop-up documentation from within the IDE
  • C# developers can leverage the vast array of Java/Android examples and documentation that can be easily transformed for use with C# and Xamarin.Android

Design principles

The following are some of the key design principles for the Xamarin.Android binding. A complete set of design principles can be found on the Xamarin website:

  • Allowing developers to subclass Java classes from the Android application framework
  • Exposing a strongly typed API
  • Exposing JavaBean properties as C# properties
  • Exposing Java event listeners as C# delegates

C# properties

The JavaBean properties, the getter and setter methods, are transformed to C# properties, when appropriate. The following rules are used to determine when properties should be created:

  • Read/write properties are created for the getter and setter method pairs
  • Read-only properties are created for getters without corresponding setter methods
  • No write-only properties are created in the rare case that only a setter exists
  • Properties are not created when the type would be an array

    Note

    As you may be aware, Java does not have a property construct but instead follows a design pattern defined in the JavaBean specification. In order to define a property, a developer simply creates the public getter and setter methods with read-only properties that only provide a getter method.

Delegates

The Android APIs follow the Java pattern for defining and hooking up event listeners. The C# developers are more familiar with using delegates and events, so the Android bindings attempt to facilitate this using the following rules:

  • When a listener callback has a void return, an event is generated based on the EventHandler delegate
  • When a listener callback does not have a void return, a specific delegate is generated that supports the appropriate signature

These events or properties are only created under the following conditions:

  • The Android event handling method has a prefix, for example, setOnClickListener
  • The Android event handler has a void return type
  • The Android event handler has a single parameter

Constants to enumerations

It is common in the Android APIs to see methods that accept or return an int type that must be mapped to a constant to determine its meaning. When possible, the Xamarin team creates a .NET enumeration to replace the constants and adjusts the appropriate methods to work with the enumerations. This provides a significant productivity gain by being able to use IntelliSense from within the IDE as well as enhance the type safety of the methods.