Alex Sorokoletov Notes     About     Archive     Feed

Easy way to create Xamarin.iOS binding from CocoaPods

Hey, Xamarin developers! Developing iOS apps quite often includes using native libraries and Xamarin for iOS supports this by creating bindings. This was 100% manual process until ObjectiveSharpie. After, ObjectiveSharpie began supporting CocoaPods (it is NuGet for iOS developers, so everything is in there). However, it doesn’t work in many cases (it can’t build something or reflect ObjectiveC code correctly).

Also, sharpie doesn’t support dependencies within pods. This is where the new objc-automatic started.

But first, let me show you a demo how easy it is to create Xamarin.iOS binding for cocoapod.


Easiest way to migrate from Xamarin.Insights to HockeyApp

Xamarin.Insights was and still is a great exception tracking system for Xamarin applications. However

… Do also note that Xamarin Insights is now considered to be end of life: since the acquisition by Microsoft, Insights has been deprecated in favour of HockeyApp.

Many of us have apps integrated with Xamarin.Insights. Now it’s time to ditch Xamarin.Insights and put HockeyApp SDK instead. HockeyApp has different integration points and API and some of the features from Insights are missing.

What would be the easiest way to migrate from Xamarin Insights to HockeyApp?


Named parameters in Func<T>/Action<T> type in C#?

If you ever wondered, why Visual Studio (and Visual Studio for Mac) suggest you to name your lambda arguments with names like arg1, arg2 … argN and so on…

Here is a common situation where somewhere in your library or helper class you have a method taking in Func<T> or Action<T>. Definition of your method using Func/Action classes and then when you want to use this method VS suggests you following names: arg1 and arg2. Like there is nothing better than that :) Definition of your method using Func/Action classes

There is a cheap and easy solution for that.

  • Define your own delegate with same signature as Func<T> or Func<T1,T2,T3> you are using already.
  • Specify intended names for these arguments (in my case arg1 could be better described as service, where arg2 is actually a token).
  • In original method, replace Func with this new delegate.

Defining custom delegate with correct names and using it in the original method After these changes when you are going to use the method, you will see intellisense suggesting correct names and not generic ones. Now you get better names from VS as a suggestion