Syncfusion Inc, 2016. — 52 p.Before digging deeper into the contents of this e-book, I believe that we should first analyze why a book like this was considered useful and needed at this point in time. At first, this might sound like a pretentious goal, but during the course of this e-book, and for the most part in this introductory chapter, we will understand that at the end of the day it was quite clear and somehow obvious. I believe that the purpose of technology is to help individuals achieve their goals, whether they use it consciously or not. My job, and probably yours, since you’re reading this, is about leveraging technology to build stuff that at the end of the day will empower someone. We are witnesses of this momentum on a daily basis with the unstoppable growth of mobile technologies, platforms, and devices. Devices are announced and their computational power increases every year (if not every six months) and we, first as consumers and then as developers, are faced with the never-ending challenge of choosing what to build, how to build it, and for whom. I believe that the most sensitive aspect of this is that any of those three choices inevitably comes with a price…and many times we pay with our most precious currency, time. Since time is a finite resource and there’s no way to earn time, we must be sure not to waste it. Rephrasing this is a more technological way, we must value our previous investments in the best way we can. However, until recent days, this hasn’t been an easy task. Let’s analyze what used to happen, and what we as Microsoft developers were used to facing. Twelve years since the release of the first .NET framework, we were used to having fragmented versions of .NET for different platforms. From the .NET Compact Framework to Silverlight, Windows Phone, and Windows Store applications, every time Microsoft has taken .NET to a new platform, the supposedly “common” language runtime has ended up with a different subset. Each time, there’s a different runtime, framework, and application model, with different development being done at each layer and APIs that go back to a common code base but haven’t always stayed common. Back in those days, Microsoft tried endlessly to reassure us, talking about common skill and reusing what we already knew, but the reality was one: fragmentation (and many headaches). Microsoft tried to tackle this problem by introducing Portable Class Libraries, Shared Projects, and finally, Universal Apps. The core concept of the first two approaches was the idea of contract, or in other words, a way of abstracting the APIs so you can use them as if they were the same for each platform. These approaches ended up becoming standard de-facto in modern application developments, and once Xamarin came up, it allowed us to take this even further by letting us reuse our code on other platforms like iOS, Android, and Mac OS X. That was a sort of glimpse into a cross-platform .NET. Unfortunately, in each case, the implementation of those APIs was different. At this point you might think that the solution to our dilemma was close, but unfortunately it was not…or at least not a complete one. Portable Class Libraries managed to get platforms closer, but were just not capable of making the .NET Framework more modular.
Чтобы скачать этот файл зарегистрируйтесь и/или войдите на сайт используя форму сверху.