Why Xamarin?

I am both an IOS and .NET developer. I have been tasked with evaluating Xamarin as a possible option to help us get into the Android space. I am struggling with the advantage Xamarin will give us versus going directly to Android Studio. Our back end in a windows environment and we have our services running either through DataPower or directly through IIS. Either way we publish a REST interface for consumption. Why wouldn't I just build new mobile apps in Android Studio and Xcode and hit my services directly rather than building a whole new layer?


  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    Shared code. You can write your models (even view models if you architect your code right) service calls, data layer, and business logic, in a common library that can be shared by your Android, iOS, and Windows Phone apps. All of this, again if you do it right, can be unit testable, tried and true. Using XCode, Android Studio, etc, you'd be doing the same thing in a different platform, each with their own headaches and unit tests, etc.

    The only thing you would worry about is writing your User Interface for each platform. And call into your common libraries for your models, data layer, business logic, etc. If you're familiar with concepts like dependency injection, MVC, or MVVM, it makes cross platform development more robust and less off a headache. This is assuming if you design your solutions correctly.

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    Also, you're not really building a "new layer". Xamarin.iOS and Xamarin.Android are (at a very high level) bindings to their respective SDKs. I hesitate to use the term "wrapper" because there's a little more to it than meets the eye. But basically, from a developer point of view, you have full access to the iOS and Android SDKs via C#. If you're familiar with iOS and C#, then you'll fell right at home. In a lot of cases, Xamarin ".NETifies" some of the SDK. For example, you can wire up an asynchronous event handler for a button click really easily.

    myUIButton.TouchUpInside += async(sender, e) =>
       var results = await MyWebService.GetDataAsync();
       //etc. etc. the webservice can be called by Android too.
  • fitzfitz USMember

    Thanks for the quick response. So basically, I can use Xamarin to interact with my back end services then do whatever heavy lifting I have using C# in Xamarin. Then my iOS and/or Android project would use the libraries I created in this first step.

    We will need to learn how to build the UI for Android obviously, but it sounds like that will be a small portion of the overall effort.

    Are there any limitations to the .NET libraries that can be used in Xamarin such as System.IdentityModel?

  • AdrianStevensAdrianStevens CAMember, University, XamUProfessors, Developer Group Leader

    There are few limitations mostly due to iOS not allowing JIT. There's a good article here:

    And here's a list for the supported assemblies on the iOS side:

    And Android:

    You get a lot :)

  • PeterDavisPeterDavis USMember ✭✭✭

    Building the Android UI isn't any different from doing it with Eclipse or Android Studio, I don't believe. It's the same xml.

    We've managed a pretty good amount of code reuse. I would say roughly 80% of our code is in a PCL (Portable Class Library) that's shared between our Android and iOS app. We're using an MVC architecture. Of the MVC architecture, the views are in the client apps while the controllers and models are all implemented in the PCL.

    We use interfaces and an IoC container to manage the views and specific client-side implementations of shared functionality (see this post for a description of what I mean).

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    The only limitations on .NET library are those that may be specific for the Windows platform. So any of the GDI+ libraries, Win32, etc. If you're currently using 3rd party .NET libraries, you can run them through http://scan.xamarin.com to see which platforms they are compatible with. A lot of times, there are Portable Class Library versions out there that are compatible.

  • SKallSKall USMember ✭✭✭✭

    Ruben, there are other restrictions as well, like Adrian pointed out mainly due to iOS requiring AOT compiler. Dan, what Ruben described as the benefit is spot on! Take a piece of your existing iOS app and port it over to Xamarin. Try to move as much as possible to PCL libraries. Then create the same view on Android and see what you would need to do to use the new PCL libraries. It might take some time to get used to but in the end you will discover that sharing code is a huge benefit. The advanced C# stuff is gravy on top.

  • fitzfitz USMember

    Guys.....I really appreciate the feedback. It sounds like I should jump in and at least do a POC. Once I prove it out. We can take the next step.

    Have a great weekend.

  • SKallSKall USMember ✭✭✭✭

    Lets say you want to create a client for a web service and unit test that all DTO's are serialized and deserialized correctly. This would be quite simple code in C# using JSON/XML serializers, the code would be the same for all three mobile platforms (iOS, Anroid & WP8) and the same unit tests could be used to test on the actual hardware (NUnit for iOS/Android, WP uses MS Test platform but the test can be shared of course).

    How do you currently do it in iOS? Are you using some sort of mapping library like RestKit or are you manually mapping a JSON dictionary to objects? With Xamarin/C# you get the benefit of being able to reuse the DTO's from server side on the mobile and automatically map the response back into DTO. Since you have control over the REST API there should be no need to manually parse the JSON or XML responses.

  • KMullinsKMullins USMember, Xamarin Team Xamurai

    I'd like to quickly add that via Nuget packages you can install and use NUnit test on WP if you want to standardize your testing platform. The Nunit platform can also be made to work with TFS.

  • KevinFordKevinFord USUniversity, Certified XTC Partners ✭✭✭

    I've found Xamarin to be an excellent choice in the following scenarios:

    • You have strong internal .Net capabilities and little or no Objective-C/Java experience
    • You plan on writing cross platform applications where there is significant client side non-UX logic that must occur. This may be a business logic, or offline capabilities, etc.

    The UX will still be native in Xamarin so if all you are doing is writing a very thin UX wrapper that calls into a remote service where all the logic lies, you will gain very little code sharing benefits. Those applications certainly exist and are still very common. Having said that, the continual user desire is for richer and richer UX experiences and that usually equates to pulling more and more logic to the client to reduce the latency of calling into server side logic. YMMV.

  • KevinFordKevinFord USUniversity, Certified XTC Partners ✭✭✭

    Speaking of serialization and DTOs, for serialization of the information keep in mind that if you are writing consumer applications there is the possibility that your DTOs will be out of sync if you don't force them to always be running the latest version of the application or maintain multiple versions of the server side service. That is to say if you add a new property to your DTO then all the old versions of the software won't be expecting it. So you either need to force everyone to upgrade, keep running an old version of the server side service or deal with the fact that one or more properties may be missing from the data being sent from the client to the server. The reverse is true if you ever remove a property for a DTO, the client would have to be written with the understanding that most fields from the server could be missing and handle that.

    In some ways the easier way to deal with this problem is by forcing upgrades to the newest version of the software which once again you will want to write into the client version of the application right from the start.

  • DanyalDanyal GBBeta

    @PeterDavis, are you using MvvmCross, or something home grown?

  • PeterDavisPeterDavis USMember ✭✭✭

    @danyal We're using a homegrown system, though we did steal an old version of the IoC container from MvvmCross and added our own dependency injection support to it. But the MVC framework we've built is entirely homegrown.

  • DanyalDanyal GBBeta

    @PeterDavis Sounds like it might be useful to the community :D

  • PeterDavisPeterDavis USMember ✭✭✭

    @danyal I'm not entirely satisfied with how we're handling views in our MVC. If I come up with a more elegant solution I'd be more inclined to release it, but at the moment, I'm not happy enough with it to release.

  • DanyalDanyal GBBeta

    @PeterDavis np, I understand. Thanks for the info anyway, you've inspired me to do something similar.

Sign In or Register to comment.