Introduction to Android native development using Xamarin’s Mono for android.

-

 

It’s been couple of months since I’ve had a chance to post here, but it’s been an amazing time for me in terms of adapting new/old technologies for my development skills, and I have a bag full of new knowledge which has been accumulated and is waiting to be put on the blog, So in the coming weeks I’ll start posting a lot of code samples, architectural guidelines and how-to-do’s.

In My professional career as a software developer, the first contact I had with OOP was with C#, back in 2007 as part of a course I took for web development which involved mostly ASP.Net, Windows forms and at the time - the diapers of WPF and Silverlight which were the latest buzz by Microsoft along with c# 3.0 and the 2.5 .Net framework.

As time passed, I took on Java in order to acquire the skills which will allow me to program for the Android platform, which is my (Native) passion in the last 3 years or so. Developing for Android in Java is really something all java programmers are able to adapt to as well as J2ME developers or any other flavor of Java.

So six months ago I found myself with extensive experience in Android with Java, and some basic skills of C#, what can I say? No knowledge can be spared or forgotten. I took on a new project which involved using C# as the programming language, and was bound to provide a cross platform native solution utilizing the extensive capabilities of C# with a framework called Xamarin.

To make a long story short, the Xamarin project information can be found here.

I was skeptical at first to say the least, but I was so wrong, let me explain why:

Using C# as the language I code with, along with the .Net framework’s latest features like the TPL library, or LINQ has made my life so much easier and simplified. The code became shorter and cleaner which made it more maintainable and easier to inject changes when needed.

SHARED CODE – the shared code which write (ONCE!) can serve all native platforms when needed (Android, iOS, Mac, Win Phone, Win8).

Ok, but what to I mean by shared code? It’s basically a C# class library project which acts as a service for the Android/iOS or any other native client platform project.

Components which can be shared with all projects:

1. Database handling (Creation, CRUD operation, and all SQLITE queries on the client)

2. Data Models – all the classes representing the entities in the project are shared

3. SQLite.Net – an ORM which allows me to map the objects to SQLite tables simplifies the entire process of managing transaction with the db.

4. LINQ – querying and iterating over collections, clean short code

5. Http request handling is done with RestSharp library which encapsulates so much boilerplate code such as managing sessions, cookies and request response handling.

6. Json.Net – a really easy to use Json Parser which was proven to be very efficient

7. Utilizing MVVM – simplifies data binding using the ViewModels (Part of the .Net framework) which makes it easy to manage the data binding the notifying the UI with changes that happen in the models using events

8. Components from the Xamarin Component store, such as Xamarin.Mobile which allows cross platform access to contacts API, camera API, and GeoLocation.

9. Built-in MVVM allows me to have an Architecture which is easy to maintain and share across platforms.

I’m sure that I’ve missed some, but you can obviously get the picture. More time can and should be spent on providing an amazing user experience rather than focusing the time on mostly boilerplate code which can be a huge hassle when programming for several platforms, each with its own advantages and disadvantages which are managed separately.

In the following weeks I’ll start posting useful data which makes my life as a developer easier which I think you might find useful and make your coding experience better and much less frustrating.

Comments

Post a Comment

Popular posts from this blog

Spinner VS AutoCompleteTextView

-
Image
       We’ve all been in a situation where we needed to show a list of some sort, a list which should be triggered by a user interaction (click, tap, etc..) A list is simple enough, probably even a spinner if we don’t want to spend that much screen real-estate on showing a list which the user clicks once and probably doesn’t need to see it after that. A spinner can be a real bug once there are too much entries for the user to choose from, how much is too much? that’s a good question – probably it differs from user to user, and probably this will have some performance issues with areal large number of entries, you cannot scroll forever to find what you’re looking for. A simple solutions for the problems mentioned above is an AutoCompleteTextView. it’s a control which is basically a combination of a TextView, EditText, and a Spinner all wrapped up in a single easy to use and configurable control. let’s see how it’s done:   first, in the layout file, create an AutoCompleteTextView
Read more

How to update UI from a different thread

-
     Google has set it’s tone on some tough guidelines for developing android apps, basically there aren’t any strict rules but one very easy to misunderstand. there is a single Thread which is called the “main” thread, or “UI thread” on some places. this is the thread which is in charge on the views and interaction with the users gestures. based on the guidelines of any mobile platform at the moment, all the work that shouldn’t be done on the main thread should be done on background thread. this can be achieved in many ways, you can use AsyncTask, Or A Handler, Or a simple thread with an implementation of the   run() method within the declaration of the runnable. ok, so if I’m pulling some server data, or performing long calculations, pulling stuff from or to the Sqlite database I’ll probably use an AsyncTask. but let’s say for instance that I want to simply update the UI once every couple of seconds (update a TextView or an ImageView’s content etc..), here’s a simple example of i
Read more

Utilizing Http response cache

-
     A typical mobile application will probably consume some resources from a web server using http requests. This repeated task has some drawbacks: Bandwidth has a cost, polling the same data over and over again results in a waste of user’s quota. the responsiveness and user experience is compromised once the user keeps waiting for data. If the requested data hasn’t changed on the server, then there’s no reason for us to fetch it. Of course, local caching of data is a must, but we also need to be able to refresh the data if it has changed on the server. A simple solution which comes out of the box for API 4+ is http response caching. Http response caching is a mechanism which enables us as developers to save a footprint of the response utilizing the abilities of the Http protocol. Basically, is holds a simple cache of the response which can be defined and enabled in code, and it prevents from fetching unchanged data from the server which was already fetched and processed into t
Read more