Xamarin Binding: Survey Monkey SDKs

Xamarin Binding: Survey Monkey SDKs

Recently I helped someone who was having problems binding Android and iOS native SDKs to Xamarin. Xamarin binding is a complicated subject and though Xamarin has documentation, there are some sticking points that are not quite obvious.

The two Survey Monkey SDKs can be found here and here:

The github project with my binding solution

Survey Monkey Android Binding Library

Binding native Android to Xamarin is done though through creating a special Android Binding project. In Visual Studio 2015 this project type can be found under installed templates under Android:

Once the project is created, it will contain a couple special folders: Jars and Transforms. Jars contains any jar (or aar) files that need binding. Additionally you need to add any jars it references. If they are already bound like Android Support v4, you can just add the Nuget package.

Transforms contains a set of xml files that use what appears to be xpath to select nodes and then perform tweaks.

The transformation process works like so:

1. Reflect over the jar and aar classes.

2. Produce an internal xml file detailing the classes, properties and methods. After building the project once you should be able to see an example of this at <project dir>/obj/Debug/api.xml.

3. The files in the transforms directories apply transforms to this api.xml file, which is then used to generate the C# wrapper code.

In the case of Survey Monkey after adding a nuget reference to Android Support v4, there were three errors:
Inspecting the code GetRespondentTaskLoader shows this method signature that’s causing the error.
GetRespondentTaskLoader derives from AsyncTaskLoader. AsyncTaskLoader’s LoadInBackground returns a Java Object. In C# an overridden method can’t change the return type. The fix is to update the transform code to change the return type. This is done in Metadata.xml in the Transforms directory with this line.

This tells the Android binding project to change the return type of the loadInBackground method on the GetRespondentTaskLoader class to a Java.Lang.Object.

The other error we encountered was exactly the same, but for another class. The fix for it is the same:

The last error is not fixed with the transform. The generated class is a partial class. We can fix this error by supplying another part of the partial class that contains the LoadInBackground method to fulfill the implementation:
With those changes, the build complete with 12 warnings and 0 errors:


12 Warning(s)

0 Error(s)

Time Elapsed 00:00:04.4374710

———————- Done ———————-

Build: 0 errors, 12 warnings


The Android Binding Project is ready. See the github for the example of how to use it. It is exactly the same as the native Android Survey Monkey SDK.

It is worth noting that it may not be necessary to access the 3 task classes RetrieveSPageTask, GetRespondentTaskLoader, and GetRespondentTokenTaskLoader directly. We could possibly just remove the class definitions using the Metadata.xml transforms file. I opted to leave them in case there is a use for them.

The latest version of Xamarin, as of this writing, will not run correctly out of the box on some x86 emulators. This is easily fixed by adding x86 or x86_64 to the ABIs for the Advanced tab under Android Build:

Survey Monkey iOS Binding Library

An iOS binding library is created through a completely different means. Rather than reflecting over the binaries, a command line tool named Objective Sharpie is used to scan header files and create decorated C# classes, similar to P/Invoke.

The default framework option with sharpie didn’t work. I think that is because Survey Monkey’s iOS SDK framework doesn’t follow the right naming convention. Fortunately it is possible to reference the header files and generate the stubs:

Which responds with:


Parsing 2 header files…


[write] ApiDefinitions.cs

[write] StructsAndEnums.cs

Binding Analysis:

Automated binding is complete, but there are a few APIs which have been flagged with [Verify] attributes. While the entire binding should be audited for best API design practices, look more closely at APIs with the following Verify attribute hints:

MethodToProperty (1 instance): An Objective-C method was bound as a C# property due to convention such as taking no parameters and returning a value (non-void return). Often methods like these should be  bound as properties to surface a nicer API, but sometimes false-positives can occur and the binding should actually be a method.

StronglyTypedNSArray (2 instances): A native NSArray* was bound as NSObject[]. It might be possible to more strongly type the array in the binding based on expectations set through API documentation (e.g. comments in the header file) or by examining the array contents through testing. For example, an NSArray* containing only NSNumber* instances can be bound as NSNumber[]  instead of NSObject[].

Once you have verified a Verify attribute, you should remove it from the binding source code. The presence of Verify attributes intentionally cause build failures.

For more information about the Verify attribute hints above, consult the Objective Sharpie documentation by running ‘sharpie docs’ or visiting the following URL:


Submitting usage data to Xamarin…

Submitted – thank you for helping to improve Objective Sharpie!



It gives a couple warnings, which in this case can be ignored. The latter of the two StronglyTypedNSArray just means that we may have to cast an NSObject to a particular type before we can use it.

An important thing to notice is the Verify attribute. Sharpie will put this in the generated code, but will not compile. This will force you to look at the line and make sure the generated code is correct. In this case everything was ok, so I removed the [Verify] from the code.

The files generated by sharpie aren’t the same name as the default files generated when I created the binding project. If you look at the properties for the two .cs files created in the project you’ll see this. (From Xamarin Studio)

If you decide to just add the files, make sure the build command is set to ObjcBindingApiDefinition.

I simply pasted the contents into the existing files.
Fixing an objective sharpie error with enums. The code for StructsAndEnums did not compile:

If you know this will only run on 64 bit devices, then the quick fix is to change the type to a ulong:
The last thing I had to do was add some code to make sure it loaded the binary file. This is done in the SurveyMonkey.framework.linkwith.cs file:

Then the binding project is ready to go. Just add the binding library project to the Xamarin iOS project and you can start using.

Next Steps

There are a few things I will add in the future:

1. Create a nuget project. Everyone loves nuget. It would make it easier to use without having to muck around with projects.

2. Create a cross-platform Xamarin Forms plugin so that Survey Monkey can be used from a Forms App.

3. Unify the return data type between iOS and Android. Right now Android returns a json string to the calling activity. iOS returns an object hierarchy. Before a Xamarin Forms plugin can work in a useful way, the way the data is consumed needs to be the same.

Let me know if you have any questions, comments or inquiries at curtis@saltydogtechnology.com
Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

This most efficient business solution to manage risk is a Minimum Viable Product (MVP). At Salty Dog Technology we create MVP’s to test the basic functionality needed to verify solutions.

Having a MVP that includes a back-end amplifies risk beyond a stand-alone architecture. These risks fall into three common categories: cost, time and flexibility.

Cost matters.  An MVP’s costs can spiral if the back-end implementation is expensive operate or takes a lot of hours to build. Though not in plain sight, the server’s cost should not be underestimated.

Time matters.  If you go the route of building everything from scratch, it can take longer, be more error prone and require more testing. There is a lot of “plumbing” that needs to be implemented in that case.  You can miss product release goals if this is not taken into account when making development schedules.

Flexibility matters.  Building a back-end from scratch requires finding or creating a bunch of scaffolding functionality. If you use a 3rd party framework, then you bring its baggage along, which may be more trouble than it’s worth. All frameworks are built with assumptions that may, or may not be ideal for your app’s back-end. A back-end implementation that cannot easily change will incur higher costs and take more time.

There are some 3rd party back-end services you can try such as Facebook’s defunct and now open-sourced Parse Server, or Google’s Firebase. They have a vested interest in locking you into their service and libraries, and often they have tiered pricing which may not reflect your usage. This means that you may end up having to pay a lot more and have less ability to change.


A Middle Solution


At Salty Dog, we use a strategy that combines three Microsoft programs: Azure Functions, Azure DocumentDB and Xamarin.

Azure Functions:  Azure  Functions are a way of providing server functionality without actually having to create a server. You are charged for the resources when they are used, as opposed to a virtual machine which incurs ongoing costs independent of actual usage.

Azure functions are not tied to single computational resources. The more that your Azure functions are accessed, the more computational resources will be automatically applied. This allows the Azure functions smoothly scale according to application needs.

Azure functions provide a rich programming environment where the functionality can be implemented in a number of languages including C #, PHP, JavaScript, Python and others.  They can utilize third-party libraries to provide extra functionality, as well as access external resources such as databases and messaging infrastructures.

DocumentDB:   DocumentDB is a server-less, schema-less JSON document database. Document DB stores the data in hierarchical JSON documents. They are indexable by primary and secondary keys. Like Azure Functions, it scales smoothly as your needs grow.

This means that time doesn’t have to be spent creating the schema, updating the schema, making sure that all data passed conforms to the structure. All of those things take time. Purists would argue that those up-front definitions provide a higher level of quality, and they’re right. However, that purity and build-in checking comes at a cost that isn’t necessary with an MVP.

Azure provides is an SQL interface to DocumentDB that understands some aspects of JavaScript syntax. This gives you a known query language that can leverage Javascript data aspects.

Xamarin:  Xamarin provides a set of tools to build Android, iOS, and Mac OS apps using C#. Rather than writing in Java, Objective-C or Swift, you write in C#. It is compatible with a lot of existing .Net libraries that can be used directly in the applications.

There are multiple ways to use similar functionality across the platforms in a generic way. Typically this is done using an IoC or Inversion of Control, system.  This means that someone can create a GPS widget that is used the same way, down to the API level, on both Android or iOS.  Below the surface, it accesses the specific native functionality on the device. This means the code you write doesn’t have to know if it is running on Android or iOS.

Xamarin has created a cross platform user interface library called Xamarin Forms. Xamarin Forms provides a usable lowest common denominator UI with the ability to customize and enhance it. For less fancy or performance sensitive applications, such as games, it can speed up development.


The Right Building Blocks


Together, the three tools provide a solution to the main risks we identified.

Cost is saved.  Infrastructure, routing, and boilerplate are built in. A lot of the “plumbing” is in place.  Azure Functions feels like you’re working with a bigger web framework, without sacrificing flexibility.

Pricing is relative to the actual time a particular function is performing work. If one month the Azure Function is only used for an hour demo, we will only be charged for that hour. Conversely, if the month after that, we put our app in the hands of 50 potential clients and they use it heavily, the infrastructure will smoothly scale to meet their demand without any intervention on our part.

Using Xamarin for mobile development, especially Xamarin Forms, enables code reuse, since the same piece of code may be able to run on either Android or iOS. Development will not be done twice as it would have been if building native apps.

Time is saved. Apps can be developed locally, unit tested, and put on the server using common source control methods, like Git and branching.  It isn’t necessary to continually upload to the servers and test. This makes it easy to add features, find bugs and fix them. When the code is ready changes are pushed to the right branch, and then Azure Functions will execute a pull from the control panel. This allows multiple live versions that correspond to production phases such as “beta” and “development,” or whatever makes sense for our product. With Xamarin, the app can be separated into distinct parts  for testing in isolation outside of a mobile device.  This can save time in the develop, test, and fix cycle.

Flexibility is saved.  Since the interface between the application and the web server is the well-known REST standard, your app isn’t locked in because of special libraries.




Creating MVP’s for mobile need not be time consuming or require huge infrastructure investments.  Using Azure Functions, Azure DocumentDB, and Xamarin allows code to be quickly developed, unit tested, and reused. Used in conjunction, they allow you to focus on the MVP and its refinement without worrying as much about cost, development time, and flexibility.