+1 (Except it's been 36 years for me) I'll add an interesting anecdote... I had a Xamarin Forms application keep crashing for no obvious reason and no logged error. After about a week of frustration, I discovered it would crash if you tried to show a button in a list view item and the button had text. If I removed the text, it stopped crashing. The customer now has the button text in a label and a blank button next to it. That was about a year ago so I have no idea if that would still happen. But I have seen Xamarin bugs that were reported years ago and have never been fixed.
David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On 14 March 2017 at 09:03, Greg Keogh <gfke...@gmail.com> wrote: > My manager now wants me to learn Xamarin, but I don't feel confortable >> doing mobile apps etc. >> How stable is the technology, should I buckle down and learn it, or >> should I start looking for another job? >> > > Cough! In the 37 years that I've been writing software, I can tell you > without a doubt that developing using Xamarin is by a long-shot the most > abysmal experience I have ever endured. Many times each day my wife will > hear me scream out the phrase that I plan to have chiselled into my > gravestone ... "Everything f***ing doesn't work". My bad experience is > tainted by the fact that I'm using Xamarin Studio on an iMac. > > Here's the bad news ... official Xamarin releases may randomly break your > development completely (satellite assembly resources are currently broken > for example). Debuggers misbehave or fail in undiagnosable ways. The > code/XAML editor has weird quirks and insane intellisense. Tiny code or > XAML mistakes cause crashes in seemingly impossible locations. Breakpoints > go haywire. The complex dependencies involving the large numbers of > independent platforms, kits and the 3rd party ecosystem is as fragile as a > spider's web. App appearance varies in subtly irritating ways on different > devices. Web searches for help usually produce vast screenloads of outdated > unresolved arguments and crazy suggestions. And this is the tip of the > iceberg. > > Here's the good news though ... once you learn to live with and avoid most > of the serious Xamarin quirks and pitfalls (and you'll learn the hard way), > it's still probably faster than writing Objective-C/Swift and Java to > produce parallel native apps. I have some basic rules of Xamarin > development: > > - Don't "push it" too hard or you'll dig your own hole. Try to work > with what the platform can do. > - Don't write UWP apps, write native ones in Visual Studio and you'll > get apps that feel "right" on Windows. > - Avoid 3rd party packages and anything that touches the native > platforms as much as humanly possible. We've had shocking problems which > were cured by stripping out "fancy" packages and platform specific code. > - Don't make too many changes in one go or you'll break something and > not know what it was, then waste hours trying to backtrack to where you > were. > - Write your whole app as a stand-alone controller which behaves like > a state machine in a portable project. The Xamarin UI is then as thin as > possible and it just binds to the app controller's properties and calls its > methods. *(This is a sensible design in any case, but do it strictly > and carefully in Xamarin and you'll be far better off)*. > > Good luck! > > *GK* > >
