meh to Xamarin... you're too constrained imho. Go Unity3D...
- You have 100% control over your entire UI without forking projects per "platform" - You can use things like LightningDB instead of SQL Lite (we've got 800k records that we constantly "search" records on and it does in ms speeds) - You also have access to 3D not just 2D (special effects, animations etc). - You work in Frames Per Second instead of 'Event bubbles". - You're one step closer to making games as well as apps - 2D/3D rendering pipeline is amazingly powerful. There are downsides - Its not .NET Framework its C# ..you write C# but bare in mind its not a Silverlight/WPF all in or nothing framework approach. You're attaching "behaviours" to null objects and decorating them which imho is wayy more optimised development. - You work in FPS time... that being said you can hide a lot of calculations in 16ms :) so settle in on a mix of coroutines and threading hand offs should you escalate the power of code. --- Regards, Scott Barnes http://www.riagenic.com On Wed, Mar 15, 2017 at 8:11 AM, David Richards < ausdot...@davidsuniverse.com> wrote: > +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* >> >> >
