There is no such conclusion, that someone must use X technology and not Y.
Frameworks, technologies and programming languages are only tools in our hands and we must choose X over Y and vice-versa.
A programming language is indeed just a tool, but there are good tools and bad tools, and some tools are better for some jobs than others.
There are saws for cutting down trees, and saws for cutting copper pipe, for example.
Take an extreme example, you could write a DTP program in C++ or as a bash script. We can all agree C++ is a better tool for the job. How about a little less extreme, C# or Python? I’ll go C#, but some people might choose Python.
In some various projects , it’s important that you make a decent choice, does not have to be the best choice, but it should be decent.
In theory, all programming languages and tools are equal, in practice, they’re not, they are very far from it.
When you really get into programming, you’ll talk shop with a lot of other technical people about things like one technology vs another. This is a big part of learning and growing as a programmer. And this will happen throughout your career.
As far as debates go, it’s good to be opinionated. It’s bad to be dogmatic. There’s a fine line between the two. With the latter, you pretty much rule out any beliefs that don’t agree with yours. Which means you’ll miss out on other cool things (technologies, etc) that might really benefit you. For some this distinction is obvious; it bears mentioning since we’ve all met someone who was so addicted to their language of choice that they just couldn’t embrace a better alternative.
Overall I’m advocating less attachment to any single technology or paradigm. Every technology is a tool to help us achieve something. If we get too attached to a single tool, we forget about the big picture.
So I’m not dogmatic developer and I love using different technologies while working on X project.
With this article I’m focusing people who thinks that their chosen technology is the best choice and everyone should and must use it.
In this article I want to share you some of my experience about Xamarin, why this technology is worth to try.
Xamarin is a Microsoft-owned based software company founded in May 2011 by the engineers that created Mono, Mono for Android, and MonoTouch, which are cross-platform implementations of the Common Language Infrastructure (CLI) and Common Language Specifications (often called Microsoft .NET).
With a C# shared codebase, developers can use Xamarin tools to write native Android, iOS and Windows apps with native user interfaces and share code across multiple platforms, including Windows and macOs. According to Xamarin, over 1.4 million developers were using Xamarin’s products in 120 countries around the world as of April 2017.
Very often , when I’m talking to the people about Xamarin , their first impressions is “How Xamarin is native ?”
Xamarin is the only other approach to building mobile apps that yields a fully native app and does so without limiting the developer to a subset of the native SDKs. To understand how that’s possible, let’s break down what Xamarin is and a little bit of how it works.
Xamarin is essentially made up of two parts — the first of which is a collection of one-to-one bindings for the entire iOS, Mac, and Android SDKs. What does that mean?
Well Xamarin didn’t reverse-engineer all the frameworks and libraries you’d use to write native iOS and Android apps. Instead, they simply exposed those APIs to C#. When you call an iOS or Android API in your Xamarin app in C#, you’re calling the exact same API of the exact same framework or library you would call using the “indigenous” languages.
So with just this “first part” of Xamarin, you now have access to everything you would if you were writing your app in Objective-C, Swift, Java or Kotlin.
Anything that can be done in an iOS application using Objective-C or Swift, and anything that can be done in an Android app using Java, can be done in C# using Xamarin. There is no exception here.
These one-to-one bindings cover 100% of the public APIs Apple and Google have exposed to developers to write iOS and Android apps respectively.
To put this in context, you could literally take an iOS app written in Swift, or a Android app written in Java or kotlin, and rewrite it line-for-line — using all of the same objects, methods, properties, etc. — in C# with Xamarin and end up with the same app with the same UI, the same performance.
Those of you that’ve been paying attention may have just realized that Xamarin doesn’t sound all that cross-platform at all. If you’re just calling the same APIs in a different language, you’re not going to share any code? Why I shoud try Xamarin ?
You’re right. Xamarin is not really a “cross-platform solution”, but there is a cross-platform “component” to Xamarin — and that’s the second part — Mono.
Mono is an implementation of the .NET base class libraries that’ll run natively inside of your Xamarin app.
There’s plenty of information out there on Mono — if you want to find out more, I’d encourage you to Google it — but in the context of Xamarin, Mono means you can write portable .NET code in C# (or F#) and share it across your native iOS, Mac, Android, Windows apps.
Anything you can do using the .NET base class libraries — or with any third-party portable .NET library — you write once and share that code and functionality across a iOS, Mac, Android, and Windows. A couple of common examples of this are the service layer and data access layers of your application.
Until I will talk about Xamarin pros, lets talk little bit about C# programming language.
C# is an object oriented imperative language — you tell the computer what to do and can wrap those commands into objects modelling your desired world. This paradigm is the most widely used nowadays and therefore a good one to master. Applications patterns and object oriented practices are transferable to many other platforms and languages.
But apart from that, C# also has a number of features from functional languages. You don’t get tail-recursion, but LINQ is a brilliant tool for data transformation and filtering. And with C# 7.0 you get pattern matching as well. So you can expand your skills with other paradigms without leaving your favourite language.
Apart from that, C# is statically typed. That gives you an amazing tool when working on bigger projects with larger team and you realise how helpful it is when you find yourself in this situation in a dynamically typed languages like Ruby.
Also, there are dynamic features of C#. The dynamic keyword and reflection API gives you powerful tools to create nice DSLs or effectively work with JSON APIs. With great power comes also great responsibility and you shouldn’t use them mindlessly, but you have that tool in your toolbox.
Now I want to talk some pros of using Xamarin
- Power of C# on mobile devices
- Native apps with native ui controls
- Native performance
- Sharing more than 90% of code over all platforms
- User writes app in C# instead of java,kotlin (objective-c/swift)
Everything else is the same.
LINQ, async/await, tasks, Attributes (c# developer does not need to edit AndroidManifest.xml — OK rarely)
- Code sharing — Business/Domain Logic is written in Portable class Library. (PCL) with C# or F# and can be shared horizontally across mobile platforms or even desktop and vertically on client and/or server.
Personally my favorite thing about Xamarin is Shared BL across the apps.
The code related to business logic, database access, and network communication can be shared across all platforms.
Are we working on Same project and customer needs native application on iOS and Android ? So first thing we are doing is that, we are writing our PCL(Portable class library) where our apps Domain/Business Logic lives.
Then Android and iOS developers can us this shared library and they will do only mobile things.
Xamarin.Forms: a framework for simple apps and prototypes
Xamarin suggests developers build mobile apps in two ways. The first one is to use Xamarin.iOS and Xamarin.Android, which is considered the main approach. Using Xamarin.Forms, the Visual Studio Library is the second one. Xamarin.Forms allows for rapid prototyping or producing apps with less platform-specific functionality. That’s why Xamarin.Forms is the best fit for apps where code sharing is more important than custom UI. You’ll be able to create a single interface and share it across platforms without designing for each platform individually. You can also build applications where some parts of their user interfaces are made with Xamarin.Forms and the others are engineered using the native UI toolkit.
So when to use :
Xamarin Standard/Traditional approach (Xamarin.Android and Xamarin.iOS)
- UI intensive apps
- usage of platform specific APIs (hardware, utiltities, etc)
- for simple apps
- enterprise data entry apps, no fancy UI
- not for complex (UI intensive) apps
At the highest level, decision comes down to weighing development time and cost vs. delivering a fully native experience. Xamarin.Forms is an abstraction layer that allows you to push common user interface code to multiple platforms, where if you build in Xamarin.iOS and Xamarin.Android, the UI development work is all done in the native platforms.
Xamarin.Forms gives you the most development efficiency — with Forms, Xamarin says on its site that you could theoretically share “nearly 100%” of code and user interface design across iOS and Android (and Windows Mobile). On the other hand, if you choose to go with Xamarin Native and build the UI on the native platforms, the upper limits of code sharing is around 75%.
Summary of this article is that Xamarin has own pros and cons, but this technology is really worth to try. As a developer you will feel the power of C# language and cross-platform app development.
Miguel de Icaza and whole Xamarin team. These guys really know what they are doing.
I really appreciate their hard work.
For more information about Xamarin new you can check this blog.
May be force be with you.