Compatibility: Xamarin Forms 2.0 and UI for Xamarin by Telerik

The new year brings new changes to the Xamarin framework, and most notably the Xamarin Forms abstraction library. With the release of Xamarin 4 and Xamarin Forms 2.0, we have inclusion of Material Design for Android, a new API for ListViews, enhancements for Windows Phones, lot of extras and of course much needed bug fixes. It's a solid release, and looks to make the use of XF even more efficient. The upgrade looks perfect for what is in demand right now.

Sounds good, but I still dislike messing with the visual design. Are there any other options?

Enter UI for Xamarin by our friends at Telerik. Although the Android and iOS libraries were presented previously, support for Xamarin Forms was released in late 2015 with a basic set of controls. More are being added quarterly. They bring the familiarity and ease of their Rad controls to a Xamarin mobile app (if you have had any experience implementing them on .Net applications, they are second to none in quality). You can find out more about the plugin here.

Fantastic! I'm sold. Plugin trial downloaded, Xamarin project started, I'm only gonna focus on Android for now. Adding the plugin references and... wait, why won't my project build?

At this time, UI for Xamarin is compatible with the previous version of Xamarin Forms. Since 2.0 is so new that it just came out, Telerik has not had a chance to test their plugin against it and make it compatible. Do not be dismayed, fellow developer. It is still possible to try out the suite of controls with a few extra steps (which ultimately should be fixed in the next release).

Things you need to know:

• When you download Xamarin 4, you get Xamarin Forms 2.0
• If you use the Visual Studio plugin for Xamarin, the project templates have old references to XF, so a package update via NuGet would be necessary anyway
• Telerik's UI for Xamarin compatibility is only for Xamarin Forms version 1.5.1.6471 [reference]
• You will need the most recent Android SDK (API 23) installed

How to run UI for Xamarin in Xamarin 4

For this example, I choose to set up the app for the Telerik Xamarin Forms ListView control.

1. Create a blank Xamarin Forms Portable app in Visual Studio

2. Uninstall the existing version of Xamarin Forms that is shipped with the visual studio project template. Note the version.

3. Install the Xamarin.Forms NuGet package (must be version 1.5.1.6471 - done through the Package Manager Console in Visual Studio) to the PCL and platform-specific projects. See NuGet command.

4. Add references to the UI for Xamarin Forms controls from Telerik to the PCL and platform-specific projects as you need them. Read the API documentation for specifics about using the ListView control, for example.

5. Pay close attention to what additional NuGet packages are required for the Android project to get up and running using Xamarin.Forms. There is an excellent blog post on installing the necessary references for the Telerik ListView for Xamarin Forms here.

6. Build the project to make sure you are ready to proceed with building your app. If you still find issues building, make sure to clean and build. It may also be necessary to open the bin folder of your Android or iOS project and delete anything that was previously in the Debug folder before building again (thanks to the Xamarin Forums for that suggestion). I only ran into that once at the beginning of this process. After that, no problems with running the Android app.

Eureka! We got a welcome screen. Is this something that could happen again, or just for this version?

Always Be Prepared

Handling compatibilities between software can be a bit of a bear, to be sure. With the ever-changing landscape of mobile apps, we want the growth and enhancements to occur. Seldom does it come with easy integration into existing technologies. But take heart! It won't be long before subsequent min versions should be able to clean that up for us. In the meantime look at it as an opportunity to examine how the fabric of a Xamarin Forms application is woven together with third party plugins. Knowledge that will certainly serve you well in the future.

The SPROC Stress Buster: SQL Table Types

Most recently I worked on a .Net project that required a layer of database obfuscation by working with stored procedures and not the data tables directly.

...Say what now? Why not just Entity Framework for my data access layer like normal?

There are several reasons you might find yourself in this position. Perhaps the DBA does not want to allow you to write records at the table level for added security or you might be batch processing a lot of rows at once... or perhaps the database is in such a state that accessing views might be more preferable. For this project, that requirement meant eliminating Entity Framework as an ORM option for the application - as it requires direct access to the schema in order to reflect the data objects properly.

Translation: Now I must think about database work a little more. 

Kind of a pain in the easy world of plug and play EF. There are always trade offs when determining which architecture piece is the priority: ease of development or additional security approaches. In this case, I needed to put my DBA hat on. The solution involved utilizing a Micro ORM that would execute a stored procedure a layer above the individual tables in the aforementioned SQL database. For this approach a micro ORM was selected: Dapper - the lightweight, quick and nifty framework that allowed you to handle CRUD in a variety of ways with anonymous objects (important if your ORM will have no true knowledge of the database schema).

Re-thinking Repositories

I had several rows that needed to be inserted in bulk. In other words - I didn't want to insert the rows one by one. The performance would be nasty. I had an average of 50 rows to insert all at once that a stored procedure would need to handle. So how do I hand those off to the SPROC within my data access layer in code?

This is starting to sound complicated. Can I give a stored procedure a collection of objects?

Why yes, yes you can. With a table-valued parameter, utilizing user-defined table types.

Great!...What does that mean and how is it done?

It means you decide what the object properties are at the SQL level in the User-Defined Table Types folder in the database (see screen shot below) and that is the data type the stored procedure will expect to receive as a parameter - the entire data table. You just model it after the object you are sending.

What does a database-level data type have to do with Entity Framework's capabilities?

At the time of this project (early 2015), EF did not support user-defined table types. It does not import them from the database and convert to a virtual object that you can access in code and then hand off to an ExecuteStoreProcedure() operation. So, I would loop through my objects and painfully, individually insert them one by one... but this post isn't about the ORM choice (which are ever evolving and add features all the time) - it's about understanding and harnessing type tables to handle your bulk lists of objects and insert them in ONE TRANSACTION.

Why do I care about inserting rows in one transaction? What's the big deal?

Depending on the amount of data, bandwidth. Give it all to the SQL database and let it do the lifting - that's what it's made for, handling large amounts of data. It's important to realize what is going on when you call an Insert() in an ORM. When it comes to scaling up larger data sets, sometimes you need to get your hands in deeper to get more control over the end result.

A Little More Effort for a Lot More Efficiency

This approach is a bit more hands-on but I'd argue that until I did a project like this I never really thought much about how to make data insertion more efficient. Now this is something I can really utilize for shuttling a list of objects to a stored procedure. Table-defined parameters are a great option.


Editor's note: See this post for an excellent how-to with a NuGet package that you can now add onto EF that will handle part of this for you.