Tag Archives: C#

Responsive Universal Apps

If you’ve ever developed an application for Windows 8 and Windows RT, you enjoyed a development experience that was seamless across a range of device types, from ARM tablets to x86 tablets to desktop PCs. You didn’t have two projects for ARM and x86, or between tablets and desktop PCs. You write one application, with one project file, one binary per cpu type, and one code base written against a single API. There were no “shared code” projects or #ifdefs or platform-specific code paths – your application just runs everywhere, responsive to the screen size, pixel density, and snap state that its being run in.

But Windows Phone never played well in this ecosystem. Back in the Windows Phone 7 days, we were stuck with multiple solutions or multiple projects in a solution, and shared code had to be linked in both projects from the same location on disk, with #ifdefs surrounding platform specific code (of which there was plenty).

It was such a hassle and so difficult to get right that I didn’t even bother with my Windows Phone 7/Windows 8 application Telnet. Much of the code was shared between the WinRT and WP7 applications, but any changes in one I just manually merged into the other using a code diff tool (WinMerge, if you’re curious). Believe it or not, that was faster, easier, and less prone to error than trying to actually share code files between the two apps.

Then came Windows Phone 8, the Windows Phone Runtime API, and Universal Apps. These were a big step in the right direction, reducing (but not eliminating) the biggest obstacle to shared code: two very different sets of APIs and UI stacks. However, Universal Apps are still nowhere near as good an experience as developing an application cross-platform between Windows RT and Windows 8. And, fundamentally, it’s still the same two-project solution we had before. All we’ve done is moved the shared code and resources into a separate ‘shared code’ project. I’m not even convinced that’s an improvement over just including shared code directly in each project – at least then I can see all the files that go into the project in one project tree.

As an experienced web developer, I’ve been writing responsive web applications for years with frameworks like Bootstrap and custom CSS and JS based frameworks before that. One thing that experience has taught me is that it really shouldn’t be that difficult to write responsive applications that can scale from phone all the way to retina displays, WITH the right tools and frameworks.

Which is why I have to ask: why is it necessary for Windows Phone and Windows 8/10 to have their own projects, their own application binaries, their own slightly different sets of APIs? Why on earth do I need so much ceremony to create a less-than-5MB craft organizer application that runs on windows 8 and windows phone, and just adapts the UI to the phone or the tablet? I’m already writing the windows 8 app to be responsive to different snapped states, different screen sizes and pixel densities. In Windows 10 I’ll need it to be responsive to any number of window sizes when the app is running on a desktop PC. What is Windows Phone but just ONE more context I need to support?

And there’s another, VERY compelling reason why we should get rid of separate apps for windows phone and windows for tablets and desktops. What if you could take any Windows 10 phone, phablet, or tablet, plug it into a dock on your desktop (or connect it via miracast or mini-hdmi), and run all your Windows Store apps in desktop mode – including, the touch-friendly Office applications? Even in Windows 10, this would not be possible, because the way Universal Apps work today forces them to be two physically different applications. It doesn’t have to be this way. “Responsive” universal apps could just switch to desktop mode and back depending on whether you have it docked, just like any other hybrid device.

Low-end devices might not support the desktop mode, even if docked and connected to a desktop monitor, but might still run universal apps full-screen like they do when you enable tablet mode on a desktop PC. And games, which might have an SD and HD set of resources, could download the right set of resources after install (or bundle the SD versions and ask to optionally download the HD versions), possibly after asking the user which they’d prefer given their device’s storage limitations.

Xamarin, Mono, and a not so modest proposal

First things first

Xamarin is an awesome company, and all of it’s Xamarin Studio products are worth the price they charge for them. And Xamarin uses that revenue to constantly pour a ridiculous amount of magic rainbow unicorn dust into their products. The new MonoDevelop redesign for Xamarin Studio 2.0, for instance, is so good that I am actually starting to prefer it to Visual Studio. “Nonsense!” you say, but believe it. It’s that good. Watch the Xamarin Evolve 2013 keynote. Get excited. I really have no bones to pick with the awesome team at Xamarin.

JavaScript is donkey poo

.NET also happens to be the ONLY realistic, production ready competitor to JavaScript in terms of sheer client platform reach. That’s important, because JavaScript is a pile of Donkey poo covered in malaria-infested horse flies, and NO SANE PROGRAMMER WRITES CODE IN IT BECAUSE IT’S THE BEST TOOL FOR THE JOB! They write JavaScript code because it’s the only tool for the job of producing a product with reach across all of today’s client platforms. JavaScript sucks, HARD. But it’s absolutely free, and it runs on anything worth running on. And so you will never have a difficult time finding components, libraries, books, programmers to hire, etc…

But here’s the problem

So, JavaScript sucks, Mono/.NET is awesome and works everywhere JS does. “Just buy a Xamarin Studio license and be happy! What’s the problem?” you might ask. It’s this. While I don’t necessarily disagree with Xamarin’s business model from a philosophical viewpoint, I can’t help but notice a serious flaw. And it’s a flaw on multiple fronts. Mono isn’t just a middleware product, like some set of charting controls or a graphics engine. Mono, or more accurately the .net stack, represents an ecosystem. It is an enabling technology that can drive innovation from many individuals and business. Like any platform, good or bad, you must rely on the ecosystem for components, libraries, community documentation, books, etc… to get any work done. The ecosystem is critically important. Without it, you can’t really use the platform no matter how good it is.

Pay walls are still walls

The problem is, .NET can only be considered ubiquitous if you count mono’s implementation. And the sad fact is that you can’t count Mono, because for all CLIENT platforms that actually matter in 2013 and beyond, mono is locked behind a pay wall, and JavaScript is not. And that fact alone will, at best, limit its use to a niche middleware product. At worst, it will result in a cascading collapse of the entire .net ecosystem for client-side development.

Whoa, surely not?

That’s an extraordinary claim. So, I’m going to try to back it up with some facts. First of all, if you are involved in enterprise development, or really any development at all in the last five years, you may have noticed a growing trend. That trend is that the decision makers at enterprise companies (and indie devs too), have begun to realize three things. First, that open source projects move at a pace that proprietary, closed-source projects are finding it hard to keep up with. Second, that closed source components are a major liability when it comes to the increasingly short development cycles that are becoming normal. And finally, that the cost-to-benefit ratio of paid, proprietary middleware is no longer adding up, when there are free and adequate alternatives.

It’s all about the CultureInfo.CurrentCulture.NumberInfo.CurrencySymbol’s

What this means is that major enterprise development firms, and indie devs alike are both fast moving away from expensive proprietary vendor lock-in towards free and open alternatives, even when they’re not quite as good. That’s a problem for Xamarin. While a company may be perfectly willing to pay for services that immediately saves them a ton of time and money but don’t lock them into a particular vendor, like Xamarin’s new cloud testing services, they are increasingly wary of expensive vendor lock-in (and the vendor longevity risks that come along with it) when it comes to platforms and critical libraries on which to build their own products. Even industry mainstays, like Microsoft’s own commercial .NET implementation, are being looked at with a wary eye as companies move more and more to free but only-just-good-enough alternatives like java, javascript, or ruby.

The LGPL is a broken license

I’m probably going to get some heat for this claim, but in my opinion the LGPL license is well and truly no longer relevant. The LGPL was meant to allow a developer to use an open source library without making their code also LGPL, while still maintaining some control over the library itself. However, with few exceptions, this is no longer possible on almost any client platform that matters in 2013 and for the foreseeable future. Its original writers may not have imagined a world where all applications were delivered as self-contained bundles with all third party libraries packaged along with the app as read-only binaries, rather than shared between apps or user replaceable. Or maybe they wrote the LGPL to help prevent such a future. Either way, the LGPL no longer serves the purpose it was designed for, and is not usable at all on most of today’s client platforms.

Don’t forget the FOSS

For the LGPL, it’s even worse than just not fulfilling its original purpose. Because on today’s modern client platforms, it is ALSO making it more difficult, if not impossible, to comply with the LGPL even when you are yourself an open source app! Not everyone agrees with the interpretation that an open source app need only supply the source or object files to comply with the LGPL for a packaged, bundled app. And so there is uncertainty that it is even possible to use an LGPL license at all on these platforms. This certainly goes against the intent of the LGPL license.

A not so modest proposal

I’m about to make a proposal that is going to sound crazy. But bear with me, because I think the logic is perfectly sound. I think that Xamarin should re-license the core mono runtime and runtime libraries, which are currently licensed under the LGPL. Instead, the core of mono should be licensed under Apache 2.0.

Wait, come back!

OK, if what I just said sounds like “Xamarin should give away the one thing they sell for free.””, then hear me out. First of all, Xamarin now has a secondary revenue source in its cloud testing platform, which after watching the presentation on it, let me tell you I could sell that to any mobile team in any enterprise firm in a heart-beat. That service is a no-brainer, time and money saving miracle. Secondly, I am not including the android/iOS add-ins or build chain in MonoDevelop or Visual Studio. I think Xamarin should still charge for those, and I think developers will still buy them. In fact, I think MORE developers will buy them (but I’ll get to that in a second).

If you build it (and make it free), they will come (and end up buying more)

One thing the MMORPG and app industry has taught us, is that if you start free, and charge for extras and add-ons, you will inexplicably end up with more revenue than if you start off as paid. I believe the same thing will happen if Mono becomes an Apache 2.0 licensed library and runtime. Having an Apache 2.0 license for the mono runtime will give developers the confidence they need that they are not locking themselves into a single vendor. This could greatly expand the .NET ecosystem beyond what is possible with a strictly paid product. And a more robust and diverse ecosystem is better for everyone, especially Xamarin! In the end, while you may lose a few Xamarin Studio licenses to open source alternatives, I think that in fact this would result in a net gain for Xamarin, because the serious devs will still purchase Xamarin licenses, and there will be more serious devs because the overall ecosystem is that much healthier.