It's time to declare war on "Hello, World"

Whoa there. Harsh title? 

Perhaps. War is such a strong word. However, through experience, I have reached the conclusion that this teaching approach cannot be tolerated anymore, and forceful removal is necessary. Stumbling blocks being what they are in this industry, I feel it's time to talk about this, and without any beating around the bush. Let's start with an analogy:

Danny wants to be a board game player. He looks up how to play a board game on the internet. He selects checkers as it's a simple game to learn for someone new. After playing the game a time or two, he feels confident enough to sign up for a beginner board game competition. He is assigned to play chess - which is also a board game, so he figures he can apply what learned from checkers and figure it out as he goes along. His first turn, he moves a piece and feels good about that. The next move that ensues from his opponent leaves him scratching his head. He doesn't understand it exactly, so he decides to shake it off and move another pawn. That's how he learned to do it with checkers, so it can't be that different. It's just a board game. The game progresses with each move from his opponent removing his pieces, one by one, and he can't seem to confiscate any of their pieces in return. Even though he was moving his pieces forward, he didn't understand that each TYPE of piece represents different levels of capabilities. Before he knew it, he was outwitted and checkmated. All he knew was how to move a piece forward one space, like in checkers. But this was not checkers - this was chess. While both games, on a board, with some movement - how you get to the end of a real game is vastly different.

Danny failed to learn the strategy and approach to the game. 

This is what new developers, or experienced developers switching to an unfamiliar tech stack, experience often. As teachers, we believe in breaking things down to it's most basic and simple level. When presenting a quick reference of help, like on Stack Overflow or in the comments section of a blog, this approach is welcome. But when you prepare a tutorial, article, video course or speaking session, you have a greater responsibility to show a more complete application.

Wait a minute. Hello World was not designed to teach people design patterns and architecture. It's just to communicate a small example of what a particular thing does. Why is there a problem with this?

Teaching how to do something that is REAL WORLD in how you would be expected to execute it shouldn't be a concept that we leave behind for the sake of brevity. Documentation examples are notorious for this. One of the fundamentals of clean code is to handle naming in a human readable fashion, as robust as is necessary. Most would agree that getTimezoneAbbreviation() is clearer than the shortened version getTAbbr().

I don't have time to arrange the holy grail of teaching courses. I'm just going to put all my code in one file so I don't have to worry about a bigger structure. As long as it runs and proves the point of the functionality I'm showing, I call it good.

Sure, you could do that. In fact many of the authors of instructional code do this. It doesn't make it good for the student to learn. Why set up the learner for failure? It doesn't really take that much longer to JUST DO IT RIGHT in the first place. At the very least you show proper placement in a real environment, and what kinds of hurdles will have to be overcome in relation to the rest of the application. In addition you also educate, indirectly, how good architecture can work. Reinforcing the fundamental best practices of thoughtful development is the responsibility of all of us. Why take time out to do it any other way? Common sense programming doesn't exist until we make it commonplace.

The reign of Hello, World has had it's time, but a new approach should be considered that can assist the learning curve and make more sense. That is a tutorial style I know I'd be more likely to dive into. Therefore, I issue everyone the challenge to craft more of your examples this way whenever possible. Perhaps we can refer to it as:

Hello, Real World.

Because context matters.

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.

Handling the Heap: Xamarin Forms Memory issues on Android

Memory management is, by Xamarin's own admission, an advanced topic in their framework. In order to make the right design pattern decisions with the exciting Xamarin Forms library, you have to first understand what is going on in translation between C# and the native platform you are deploying to. In this article we will tackle the Android build using the Portable Class Library in a XF (Xamarin Forms) solution.

Your Garbage, My Garbage

Java is the language responsible for the native performance on your Android device. It's namespace handles garbage collection differently than the language we are using to build this XF application, which is C#. More than just the .Net approach to garbage collection is Xamarin's custom garbage collector as well. That's three to keep track of. Note that the C# namespace does not contain knowledge of the actual size of your native object - only a small pointer to it, which is exponentially smaller in size (maybe only a 2k object). When it gets collected in .Net/Xamarin Forms will be different than when the native platform disposes of it's objects. It's important to understand this, so you can tackle handling when objects are disposed of in the correct project - PCL or Device-Specific.

Custom Renderer Usings

A great rule of thumb is to wrap Java objects in a using statement when implementing anything on the Android project. For example, a code snippet inside of a Task method class will go from this:

var bitmap = await BitmapFactory.DecodeByteArrayAsync(imageData, 0, imageData.Length, options);

return bitmap;

To this:

using (var bitmap = await BitmapFactory.DecodeByteArrayAsync(imageData, 0, imageData.Length, options))
            {
                return bitmap;
            }

Using statements call Dispose() once the code inside of it has completed, queuing the object for the platform's garbage collector to free it from memory. It won't happen immediately, but it will promote it for priority collection, and should happen faster.

Welcome!

So much is happening. Stay tuned.