Skip to content

Tag: Evolve

Why should software developers have a blog?

Of the many conference sessions I attended at Xamarin Evolve16 this year, there was one that was radically different than the others. When you go to a developer conference, you assume that all the sessions are focused entirely around the latest technology trends and improving your development skills. What I did not expect was a session on skills to improve the quality of life and long term success as a software developer. As software developers, we have very analytical minds, and thus we only focus on our quantitative technical skills and ignore the qualitative. In the session, 5 Soft Skills Every Software Developer Should Know, I was introduced to John Sonmez, and his mission is to change that.

John Sonmez is a software developer who was so successful in his day job, he was able to retire at the age of 33. Since then, he has become a software developer coach who has made it his life’s mission to helping developers succeed in their careers and surpass mediocre lives. John has built a unique business revolving around this core mission, called Simple Programmer.

Simple Programmer provides a multitude of services for software developers including blog posts, podcasts, YouTube videos, published books, and training courses. A large majority of this content is completely free and worth exploring.

One course in particular that is worth investigating is his free email course on building a blog. In this course, John sends you weekly emails explaining the simple process of how to build a blog correctly and the reasons for it.  While the content of his emails might first appear to be common sense, if they were so common, why do some many developers do it incorrectly, or not at all?

That’s nice, but why should I even care about blogging? The premise behind developers maintaining a blog is that it acts as a conduit to creating a brand for yourself.  Developers without a brand (or name for themselves) are simply code monkeys that can be easily replaced with another developer. Adversely, developers that have both the technical skills and name recognition within an industry are sought out by employers. In essence, you want to be name not a number in a stack of resumes.

Beyond simply name recognition within an industry, blogging provides a channel of communication between other developers. While Stack Overflow is the usual go to for quick technical issues, blogs are the second resource type that ALL developers depend on. Not only are they another tool in our tool-belt, they are also better mediums for more in depth topics; the format is more conducive for tutorials and longer articles than Stack Overflow.

Most developers usually have a healthy level of skepticism. Why should we trust this John guy whom you might not have ever heard of before? Don’t just listen to him, listen to the advice of other major names in the industry like Scott Hanselman. While John’s advice isn’t some magic get rich quick pill, his advice is a compilation of life skills for developers that, with hard work, could completely change the course of your career.

Switching to Xamarin.Forms?

After attending Xamarin Evolve16 this year, Xamarin.Forms appears to have significantly matured since its introduction two years ago. Having only developed using Xamarin.iOS and Xamarin.Android, I had limited exposure to Forms prior to the conference. While at the conference during trainings and conference sessions, it became clear that Xamarin is really pushing the adoption of Forms.

So the question becomes, what is Forms and should I use it? The main business case for using Xamarin is the ability to share as much code between platforms as possible. Xamarin native allows developers to share a majority of their business logic and models, yet you are still stuck having to write a UI for each platform. The most simplistic way I can describe Forms is that it is Xamarin’s attempt to abstract the UI for extensive code sharing and still deliver native (or nearly native) performance and design. Xamarin claims that they were able to share more than 90% of the code for their 2016 Evolve app between Android, iOS, and Windows.

Xamarin Evolve 2016 Android App Code SharingXamarin Evolve 2016 iOS App Code Sharing Xamarin Evolve 2016 Windows App Code Sharing

Images Source

My first impression to this claim was, this sounds too good to be true, so what’s the catch? The catch to using Forms, is that you “lose” the granular control over your UI and the simplicity of platform specific APIs. My previous statement must be qualified because it is not entirely accurate. Before I can explain further, I first have to explain the structure of a Forms application.

Xamarin Forms PCL Solution StructureA Forms solution contains a project for each platform you intend to target. Therefore, you will have a project for Android, iOS, and each flavor of Windows that you decide to support. Also within the solution, you will have an additional project called the PCL or portable class library. Think of the PCL as the core of your application where a majority of all your code lives. Inside the PCL is the Xamarin.Forms NuGet package, which contains all the required libraries to build a Forms application. The primary difference between a native Xamarin app and a Forms app is the PCL. In other words, a Forms app is exactly the same as a native Xamarin app but with additional libraries. This technically means you have access to all the native Xamarin APIs as before (with a catch).

With a rudimentary understanding of the Forms structure, I can now explain my original claim about losing some native control. Since the purpose of using Forms to build your application is to maximize code sharing, this creates complexities when you need to access platform specific features or complete control over your design. While I technically have access to all the native Xamarin APIs, I have to jump through additional hoops in order to utilize them.

The two main approaches to access the native APIs are to use either a custom renderer or a dependency service. A custom renderer allows you to create native UI elements (such as a UIKit.UIView in iOS or a Android.Views.View in Android) for each platform and then integrate them back into a Forms page or view.  A dependency service allows you to access device specific functionality such as the built-in cameras or GPS.

If we have access to all the native APIs, why don’t we always build Xamarin apps using Forms? Two significant reasons why you should weigh your options before making a decision are performance and path of least resistance. Performance is a factor because the entire UI in a Forms application is a compilation of custom renderers contained within the Xamarin.Forms package. This means that there is an additional performance cost to rendering your views. If your application is graphics intensive or uses a large amount of memory, the end users might notice your application not working smoothly. The path of least resistance comes into play depending on the complexity of your application. If your application requires access to a large amount of the native platform APIs and has significant custom UI needs, you will be spending as much if not more time writing custom renders and dependency services as you were attempting to save by sharing more code between platforms. On the other hand, if it is more important to share code between platforms than direct access to the native APIs, Forms is a strong contender. Xamarin provides a quick one page PDF to help you decide which camp your app falls into.

Over the next few months, I will be writing about my experience of porting existing Xamarin.Android and Xamarin.iOS eCommerce apps over to Xamarin.Forms. After evaluating and testing Forms, my team feels that we could benefit from the adoption of Forms. We believe our existing apps fall under the 80/20 rule, 80% of our apps require very little advance custom UIs and platform specific features, while 20% does. Our hope is that the 80% saves us more development time than the 20% of additional overhead. I hope my experience will help others make the right decision for their apps.