5 ms·
> 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
by theflagbug 10y ago
> 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 10y agoMost 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.