[wsloth]

When using Xamarin I always get the feeling I'm writing Java code--but in C#. The cross-platform project is a blessing, it's truly amazing to be able to write code once and use it on all platforms (especially if you use Dependency Injection for even more sharing).

The downside to this is that making a UI seems to even out your gained time--it's extremely messy and even complicated. Code that's valid in C# produces vague underwater bugs in Java code, which makes you keep hacking around until you find a working solution.

Not to mention the docs: some parts of the documentation are completely outdated to the point of not even compiling on an older version of Xamarin. For example, the tutorials on using Google Maps in your Xamarin.Droid application are way out of date, ignoring the fact that the "Google Play Services" component has split off into thirty-or-so components. Some of the most used API's are not documented at all, simply having a "To be added" description.

All in all I find much potential in Xamarin, and I really want to love it, but it's a messy nightmare to use, and it only makes me want to use Java and Swift separately for apps.

[theflagbug]

> The downside to this is that making a UI seems to even out your gained time--it's extremely messy and even complicated. Code that's valid in C# produces vague underwater bugs in Java code, which makes you keep hacking around until you find a working solution.

Interesting, I had the exact opposite experience, since the Java->C# mappings often reduce much of the boilerplate code that you have to write if you were using Java (e.g C# events, properties, etc..)

I also never came across any bugs in the mappings, but I can't say for sure that there aren't any.

[wsloth]

Most of my problems often come from constructors. For example, using a custom parametered constructor in an Activity or Fragment seems impossible, so constructor injection is already out of the question. This is valid C#, but will not compile. Hence, I stated that using Xamarin feels like programming Java in C#, which makes me feel like I would actually be happier writing Java code.

Instead, for this example you could subclass Activity/Fragment and use reflection to find properties on the activity to inject services into.

This is only one of countless annoying Xamarin problems I have encountered in my few months of use, and this one was relatively easy to solve. Vague problems also ensue when forgetting to inherit a class from Java.Lang.Object which leads to vague exception messages like "Specified cast invalid".

Sure, sometimes parts can be made faster in C#, but more often than not I spend day(s) debugging extremely vague bugs related to non-documented mappings.

[miguelrochefort]

> Some of the most used API's are not documented at all, simply having a "To be added" description.

I rarely find myself reading the Xamarin documentation, and mostly browse documentation and StackOverflow as if I was coding a native iOS/Android app. This works because the Xamarin wrapper is pretty much identical to native APIs.

[ghuntley]

Agreed. I never read the Xamarin documentation, instead I'm looking at objc or Java and then impl as c# instead. The method names, signatures and idioms match almost one for one. When the API doesn't match it's because it makes sense to; Pickup a copy of the dotnet framework design guidelines and you'll see what I mean about the previous statement.

[snarfy]

I've written a few apps in C++/COM with a UI written in Visual Basic. The VB app was 'button code', with the heavy lifting done in COM. I wonder if this approach would work for Xamarin - write the core logic in C# but leave the UI in Java.