From XAML to Xamarin

Recently I started exploring Xamarin Cross-platform framework (Xamarin.Forms) to develop apps for Android, iOS and UWP.

There are couple of frameworks for doing cross-platform mobile app development, however,  as I am dominantly a C#/WPF developer, I chose Xamarin.Forms. This decision turned out to be the best decision, mainly because I had vast experience using Xaml and C# and saved 80% of my learning time.

It was a great experience with Visual Studio integration of Xamarin and It took only 4-5 days to get acquainted with Xamarin.

I will soon be uploading my app on Play stores, but first let me share the Pros and Cons I found:

Advantages:

  • Xamarin & .NET are very well architectures. C# is a fantastic language.
  • Being able to use C# to develop on not just one, but 3 platforms.
  • Since 2017, its completely Free.
  • Xamarin allows to take my knowledge of C# and apply this to the iPhone and then Android. Can use existing c#/.net knowledge in iOS and Android.
  • It allows you to use almost 100% native libraries of both Android & iOS.
  • It’s easier for developers to move from one project to another. You won’t be stuck with Android developers not being able to do anything while the iOS developers are too busy.
  • No context switching between languages. We can go from iPhone to android to the web using one language.
  • Plug in components that make adding SDKs for commonly used services like Dropbox, Azure, AWS, Auth0 etc. a breeze.
  • Cross platform support for phone functionality like camera, Geo-location etc. with Xamarin Mobile.

Disadvantages:

  • It is not an open source application, so community help is not as good as native Android.
  • Performance is a bit slower than native android OR iOS (since Xamarin is still evolving), but difference is only within few milliseconds.

Comments

Post a Comment

Popular posts from this blog

How UI Layout Works

Image
Few days ago, I was stuck with a GUI issue where WPF controls were not getting rendered in memory. Everything was arranged properly in a Visual Tree of parent control but still somehow child was not able to draw with custom size. So, to solve this issue I took  help of a book called WPF Control Development by Kevin Hoffman. I thought I should share how this layout process works under the hood. So there it is: ___________________________________________________________________________ The layout system in WPF is a conversation between the layout container and its children. This conversation takes place in two stages that are often referred to as passes. This two-pass approach starts at the root of the visual tree and recursively traverses the tree until all containers have been given the chance to perform the layout process with their children. In the first pass of the conversation, the parent asks its children how much space they need to display themselves. The parent infor
Read more

Binding Previous Item's data in ItemsControl

For a data-bound ItemsControl, each item in the source collection is the DataContext for the generated UI container.  By default, the binding expressions used in the ItemTemplate  are evaluated with respect to this DataContext.  This is useful if all of the information that  the template needs is contained in this context. This is actually the case in the vast  majority of data binding expressions.  However, there might be times when you also want  to take a peek at the previous item to do some work.  For example, say you are plotting a  sales chart and you want to show the percentage change in market share over five years. Here the change can be calculated within the ItemTemplate and shown in red for a decrease and in green for an increase. In this case, it is necessary to have information about the previous item in the data-bound list.  This is where the exact scenario that the  RelativeSource class was designed for with its PreviousData property.  RelativeSource.PreviousDa
Read more