Hacker News Reader

Comment by untog | Hacker News Reader

Last time I tried Xamarin (and I'll admit it's been a while) cross-platform was surprisingly difficult. A project had to be either iOS or Android - and that included projects that had no UI code in them. So the concept was there, but the execution wasn't yet.

Of course, this may have changed.

View on HN

Portable Class Libraries help here. They aren't perfect, and honestly they're justly badly reinventing Java's loosely coupled jars, but they give you the ability to link stuff together in a little more general of a way.

In my current project (a video game), the core library is a PCL - it contains data structures and the interfaces and abstract classes that content (mods as well as the base game) must fulfill. I have a "desktop" library that's a normal .NET 4.5 class library that contains stuff like "load your config data from files, include the runtime-compilation mod system", and I have runner projects--text-mode via curses for now, eventually graphical post-prototype--for MacOS, Windows, and Linux[1]. I use configurations (not platforms, leave everything as AnyCPU unless you want to hate your life) to provide preprocessor flags for #if; my solution has ended up with an ugly number of "Windows-Debug", "MacOS-Release", etc., but the differences between XS and VS make it hard to do things "right".

[1] - all source/content files added via a single template .csproj, using a Ruby watcher I'm going to eventually open-source, because using MSBuild correctly to handle this situation breaks in both VS and Xamarin. (That last bit, you may be realizing, is a common theme. .NET has such good stuff, but half of it is broken at any time.)

Assuming you don't need to pass around binary libraries, take a look at shared projects-- added in Visual Studio 2013 and Xamarin Studio 5, IIRC. Unlike PCL projects, they compile in the context of the projects that reference them, so you have full access to the libraries that are common between each platform, and (if your coding style allows it) full access to platform-dependent APIs as long as they're protected by the appropriate #if __IOS__/#if __WIN32__/etc.

Keeping common code in shared projects is like night and day compared to the mess that is keeping common code in a PCL and having to deal with common APIs that aren't present (or worse, are incomplete) in your chosen PCL subset. They really clean things up a lot, even if you're treating them like they're a PCL and avoiding any platform-dependent code.

Ooh. I didn't know about this. I'm using VS2012, because I don't want to shell out again for VS2013 but want ReSharper - I'll have to look at this...thank you!

There is still a degree of that, depending on how you structure the application, and how much of it is reliant on your UI layer vs backend business logic.

Xamarin.Forms is their solution - common UI components wrapped in a generic layer.

They have a nice way to blend Xamarin.Forms, native UI controls and library projects that is getting much better, but still a bit of a pain.

They true value in my eye is that I only have to be proficient in one language, and they have very good documentation.

I still need to have a firm understanding of the API's for both Android, iOS, and WinPhone if I want to make a non-Xamarin.Forms application, but at least I'm not mentally shifting between 3 languages.

Picking up languages really isn't that te key, it's always been the library that's hard, so I can't say I can see the value if it's just that.

I suppose the value is that you don't have to rewrite your application logic multiple times. That takes time even if you're fluent in all languages. It is also a duplicatio which increases the risk of later bugs due to not doing all changes in all copies.

Exactly - and as a after work only developer, the less I have to do over, the less I have to consult the docs, the more comfortable I am with a single tool, the more productive I become.

Reply on news.ycombinator.com