As the first item on the above list indicates, using Xamarin means saying goodbye to the good old Objective C. That is, in my opinion, a good thing. C# is a very modern language offering a lot of features that are also available in Swift. As for all the great frameworks we get to use, while developing iOS apps – they are all there! It\u2019s true that some naming conventions are a bit different but most of the time you\u2019ll feel very much at home.<\/p>\n
Developing in C# is definitely a plus but the greatest benefit Xamarin has to offer is sharing code between multiple platforms. Unfortunately this does not mean, that we have found the Holy Grail of mobile development, which allows us to write code once and run anywhere. The promise that we get is, nonetheless, very attractive. Xamarin lets us to share the majority of our non-UI codebase. If you want more you can take a look at Xamarin.Forms<\/a>, which aims at providing common API for writing UI code! We decided not to use it in our projects due to quite complex and custom UI, as well as the fact that the API does not offer all the native features 1<\/a><\/sup>.<\/p>\n It\u2019s important to mention that Xamarin is not free<\/a>. Depending on your needs, a single annual license will set you back between $300 and $1900. The price includes only one platform, so if you want to target both iOS and Android, you have to multiply it by two. This may seem like a lot, especially when you realise that you need the usual Apple and Google developer licenses on top of that. But if your project is big enough and contains a substantial amount of business logic, then you can probably get your money back by reducing the development time.<\/p>\n Xamarin supports two development environments: Xamarin Studio<\/em> and Visual Studio<\/em> (only Business and Enterprise license). While you cannot choose which one you want to use if you have a Mac, it is possible to run both on a Windows machine. We decided to use Xamarin Studio across the board, mainly to minimise any sorts of incompatibilities.<\/p>\n An added bonus for developers coming from the iOS\/Mac world is that Xamarin Studio looks a lot like Xcode.<\/p>\n We have the familiar Run<\/em> button in the upper left corner, the device selection dropdown as well as the notification bar in the middle. One difference between Xamarin Studio and Xcode, that I was really happy to see, is the Solution Navigator<\/em>. In contrast to Xcode, it actually reflects the structure of directories on disk, not only the contents of an XML file. I\u2019ve spent way too much time trying to keep both of them in sync.<\/p>\n My overall experience, after using Xamarin Studio over the past few months, is positive. It is pretty well organised and fast at launching my apps on a device. That said, I encountered code highlighting issues and my device froze from time to time while connected to the debugger (usually after the screen has been locked for a short while).<\/p>\n As far as designing UI is concerned, Xamarin offers a tool called Xamarin Designer<\/em><\/a>, which allows you to edit storyboards in very much the same way as Interface Builder. I have not used it a lot, to be honest, because it is also possible to stick to our good, old friend IB. It\u2019s really cool that Xamarin automatically picks up the changes you make to a Xib file and new outlets are immediately available in your classes. The only annoyance I encountered was problems in communication between the two IDEs, which result in pesky pop-ups you have to dismiss from time to time.<\/p>\n I must admit that I like C# more and more. It\u2019s a powerful language that boasts a number of very useful constructs. Generics, lambda expressions, optionals and properties, just to name a few. Plus it\u2019s actually quite easy to get the hang of it, especially if you have some experience with Java.<\/p>\n One thing that may be unusual for people moving to C# from Objective C, is the use of exceptions<\/a>. In iOS apps this practice is almost non-existent, while in .NET it\u2019s a very important and integral part of the language. This means no more error codes and error objects. Instead it\u2019s time to get familiar with the try<\/em>, catch<\/em> and finally<\/em> keywords.<\/p>\n Memory management in C# is very different than in Objective C, because of the presence of a garbage collector. Despite that, one thing to be aware of, is that it is still possible to create a retain cycle, for example when using lambda expressions. The reason for that is that the classes that derive from Speaking of memory management, it is very important to understand and use the Dispose pattern<\/a>. It allows you to release memory in a more deterministic way, instead of waiting for another garbage collector pass. The amazing thing about Xamarin is, that even though you\u2019re using a totally different environment and language, you still have all your familiar APIs available at your fingertips. This makes your transition from Xcode and Objective C smooth and fast. You have to be aware of certain naming differences and the C# conventions, though.<\/p>\n Let\u2019s take for example Core Image<\/em>. The iOS framework defines string keys that allow you to set properties on filters that you want to apply to an image. They are all grouped into a long list in If you decide to use The Export<\/em> keyword is used to make sure that the Objective C runtime sees your The greatest advantage you get by choosing Xamarin for your next project is definitely code reuse. The following chart illustrates very well which parts of a codebase can be shared:<\/p>\n Xamarin offers two approaches to sharing your code between multiple platforms: Shared Project<\/em><\/a> or Portable Class Library<\/em><\/a>. The former works in a very simple way. After creating a Shared Project you can make it a dependency of an arbitrary number of other projects, for example iOS and Android. This ensures that all files added to the Shared Project will be included in all projects that depend on it. A consequence of this is, that you need to use compiler directives if you want to include platform specific code in your Shared Project. Here is a quick example:<\/p>\n Since the above code is compiled separately for iOS and Android the compiler can figure out which line should be used.<\/p>\n Portable Class Libraries<\/em> work in a fundamentally different way. They are compiled as a separate target and only then included in other projects. When creating a PCL project, you need to specify which platforms you want to be able to run it on. Moreover, you will not be able to reference platform specific libraries or use some of the classes available in Xamarin.iOS and Xamarin.Android.<\/p>\n With the two Xamarin project running parallel at the moment, our strategy has been to place as much code as possible in a PCL. We wanted to avoid using compiler directives too aften, as this can become difficult to maintain over time. Here is a summary of the projects in terms of lines of code.<\/p>\nGetting started<\/h2>\n
The IDE<\/h2>\n
![\"xamarin_studio\"](\"https:\/\/trifork.nl\/articles\/wp-content\/uploads\/sites\/3\/2015\/05\/xamarin_studio-1024x619.png\")
<\/a>The language<\/h2>\n
NSObject<\/code> still work with reference counting under the hood.<\/p>\nUIImage<\/code> serves as a good example. The object representing an instance of UIImage<\/code> uses only 20 bytes of memory, but it contains a pointer to the raw image data, which can be megabytes in size. The garbage collector sees only the negligible 20 bytes, so it can take a long time before another GC pass will be triggered. By that time we may have run out of memory and ended up evicted by the system.<\/p>\nThe frameworks<\/h2>\n
CIFilter.h<\/code>. Xamarin goes a little bit further by defining a static class CIFilterInputKey<\/code>, which contains static properties representing different keys. In my opinion, this makes it easier to find the one you\u2019re looking for.<\/p>\nUITableView<\/code> in your project, you may be surprised that UITableViewDelegate<\/code> and UITableViewSource<\/code> are classes, not interfaces. This is because interfaces in C# are mandatory, whereas Objective C offers the @optional<\/code> keyword. It is therefore much easier to create an abstract base class, so that subclasses can override the optional methods they need. This, in turn, results in the fact that it is not possible to make your controller the delegate or the data source. To do that ,you have to implement the IUITableViewDelegate<\/code> and IUITableViewDataSource<\/code> interfaces. They contain only the mandatory methods. The optional ones can be implemented as follows:<\/p>\n[Export(\u201cnumberOfSectionsInTableView:\u201d)]\npublic int NumberOfSections(MonoTouch.UIKit.UITableView tableView)\n{\n ...\n}\n<\/code><\/pre>\nNumberOfSections<\/code> method as the numberOfSectionsInTableView:<\/code> method declared in the UITableViewDataSource<\/code> protocol.<\/p>\nWhat it\u2019s all about: sharing code<\/h2>\n
![\"ConceptualArchitecture\"](\"https:\/\/trifork.nl\/articles\/wp-content\/uploads\/sites\/3\/2015\/05\/ConceptualArchitecture.png\")
<\/a>#if __IOS__\nnsDispatcher.BeginInvokeOnMainThread(NotifyListeners);\n#elif __ANDROID__\nDispatcher.RunOnUiThread(() => NotifyListeners());\n#endif\n<\/code><\/pre>\n
![\"heapshot\"](\"https:\/\/trifork.nl\/articles\/wp-content\/uploads\/sites\/3\/2015\/05\/heapshot-1024x747.png\")
<\/a>