NB: The opinions expressed here are mine alone, and do not necessarily reflect those of Falafel Software, its employees or management, or anyone else.
The Prime Directive
The very first thing I’d do if I were Miguel De Icaza (who I admire and who certainly does not need my advice) would be to make clear to every employee in the company that our number one priority, the prime directive of Xamarin, is now to lower the bar to entry for programmers who want to create cross-platform mobile applications.
The logical consequence of this is that I’d put a lot of resources into extending and expanding Xamarin Forms.
|Yes, I know that Xamarin consists of 170 employees, and that Nat Friedman is the CEO and that Joseph Hill (who has been very kind to me) is a co-founder, but Miguel is the face of Xamarin. And while this may be the most presumptuous posting I’ve ever written, let me assure you it is based only on my own analysis and not on any “inside” information or hints about the future.|
Forms are an incredibly powerful library within Xamarin that allow the creation of a cross-platform UI that:
- Has (nearly) 100% code reuse
- Uses XAML or C# to declare the pages, views, layout, etc.
- Supports data binding
- Is extensible
In short, this is the base upon which I’d create Xamarin 4.
There is much work to do: more controls, more properties of existing controls, and most important, our number 2 priority: make extending Xamarin Forms Controls much easier. Again, this is rooted in the prime directive: lowering the bar to entry.
Currently the breakdown of a “typical” Xamarin application (without forms) is something like this:
~25% Reusable cross-platform libraries
~40% Reusable code
~25% User interface code (platform specific)
~10% Platform specific logic/code
OK, I made that up, but it probably isn’t too far from right. This would mean about a third of the code must be written for each platform. A bit less when writing simpler programs.
Reuse Doesn’t Happen By Magic
The typical Xamarin programmer creates even 40% reusable code by creating factories, resource locators and using dependency injection to wrap the platform specific API in a programmer-created abstraction. That is, while the code can be reused, it is far from trivial to create it in the first place.
With forms, however, the 25% platform specific UI code that the developer has to write drops perilously close to zero, changing the equation dramatically.
The more Xamarin Forms can do, the less platform-specfic code you have to write.
Priority #3 – Beyond Forms
Priority #1 was to extend forms and priority #2 was to make it easier to extend the Views that exist in the forms library. Priority #3 is to extend the abstraction provided by Xamarin Forms beyond the UI. The goal is a library of Xamarin and community-created objects that can be assembled into a cross-platform mobile solution.
If Xamarin 4 were to include these changes and improvements, I think Xamarin would be unstoppable. The opportunity to build platform native applications by writing to platform-agnostic libraries in XAML and C# would be a crushing victory over virtually any contending approach, at least for the (hundreds of thousands?) .NET developers who agree with Satya Nadella that the future lies in Mobile and the Cloud.
If this was of interest, you may want to check out my series on Learning Xamarin
Latest posts by Falafel Posts (see all)
- Matching Complex Query String Rewrite Rule in IIS - March 22, 2017
- Disable Content Filters in Sitefinity - March 8, 2017
- On Sitefinity Custom Widget Caching - February 22, 2017
- Dynamic Content Detail Widget Templates in Sitefinity - February 8, 2017
- Using Google Services in UWP C# Apps – Part 2 - February 7, 2017