20 years later, Microsoft's still hammerin' Xamarin: Bunch of improvements on the way for cross-platform coding toolset Microsoft continues to evolve its Xamarin technology for cross-platform coding with .NET, even though alternatives like React Native and Blazor are getting plenty of attention within the company. The history of Xamarin goes back to the earliest days of .NET. In 2001, when C# and the .NET platform were still in preview, Miguel …
It is extremely telling that such a phrase seems totally normal these days.
Dual screens. We've spent over four decades using IT stuff more and more because prices have, globally, always been falling. For what seems like forever I've only used one screen per computer, like everybody else. But, since between five and ten years, I've been seeing more and more developers use two screens at work, and I've personally been on two screens at home for nine years now. About a third of my career.
I know some people who have three screens. My graphics card has four ports for connecting screens. It is currently managing exactly 10 512 000 pixels.
Technology is awesome.
Yeah, I had 2 1920x1200 monitors (one landscape, one portrait) until NewEgg had a sale on 4K monitors (3840x2160) last Christmas, so that went in the middle landscape, and the older monitors are in portrait to each side.
Boy, do I miss it when I can't work from home.
"Technology is awesome."
Got that right. Imagine if this coronavirus thing had hit a couple of decade earlier: smack on the dotcom boom/bust, most people still on dial-up, no home delivery services for groceries, hours of waiting on on engaged phone lines...
I had three screens attached to my RT PC at IBM in 1990. For the past 15 years I've worked exclusively on laptops, and I've never bothered to hook multiple screens up to them. With my last couple of laptops the company ordered docking stations for me, and I shipped those back to IT to use as spares. They'd just sit in the box at my place.
Clearly many people find them desirable, and one might hope actually useful; but I haven't felt any desire to have a multiheaded system in decades.
It's been improving steadily. I suspect from your description that you actually it used it over two years ago. That's when I started using it and I agree that it was a pain. The tooling was chronic - ten minutes for a build and sometimes the build just hung or failed for no reason.
But since about summer last year it's become not a lot worse than Wpf development. Having to build on a Mac is still a pain and some debugger features aren't implemented or can be a bit fickle but it's nothing an experienced software developer should be shocked about.
I'd say that any Wpf development team considering a cross-platform product would be well advised to look at Xamarin. We support WPF, Android and iOS and 95% of our code is shared between projects. The only thing we have to do for the mobile versions is a bit of UI tweaking and occasionally inject platform specific services.
AndrueC, it's experiences such as yours that are very intriguing for somone who has yet to dip their toes into mobile app development, but may soon have to. It sounds (and not just from your post, I've quite a lot of encouraging stuff elsewhere too) that MS / Xamarin / .NET Core / etc might just be evoloving into the ecosystem to use, even if it is a bit rough still.
It would also be a right turn up for the books if MS ended up accidentally having a stranglehold on mobile app development, by having control of the one cross-platform technology that actually does it well enough for most purposes. All it takes is for a majority of developers to move to MS's tools, et voila. The question then is what would Google and Apple pay MS to ensure that their phones are well supported by MS's tools? And if this did happen, i) it'd be a massive miss by Oracle / JAVA, ii) that'd teach Google and Apple not to build walled gardens.
The only thing that worries me about this is that, with control over all the libraries, etc. that everyone would then be using for all mobile development, would MS take the opportunity to slurp a load of data by loading those libraries with lots of "additional" functionality? Afterall, if most mobile apps ended up being written using MS technology, and run on either iOS or Android, that'd give MS more slurping power than either Google or Apple. Is there any hint yet in Xamarin of this kind of thing going on? I hope not...
For 'day to day' development you can mostly ignore the mobile stuff. Anything UI related involves a bit of extra thought but here's what we've done. We have split our view models into two parts. A common service class that contains as much of the VM logic as possible. These are then injected into 'target' specific view models where target is either 'desktop' or 'mobile', each of these VMs is as 'lite' as possible. There's a little bit of ugly if you want to bind to a property that is implemented on the service but you can hook into the notification event and in effect chain it:
_commonService.RaisePropertyChangedNotification += OnCommonPropChangedNotification;
..
private void OnCommonPropChangedNotification(object sender, e) =>
RaisePropertyChanged(e.PropertyName);
Then your lite property just returns the common property:
public Whatever Wibble{get =>_commonService.Wibble; set=>_commonService.Wibble=value;}
This does require that you keep the property names the same across classes which is a weak area but that's what unit tests are for I suppose.
Other than that the only biggie we ran into was the fundamental difference between how Wpf applications bootstrap and run and how mobile applications do it. Eg; Android has Activities. That pain is probably unavoidable, it's the nature of mobile.
My conclusions: If you have an existing Wpf team looking to create or migrate to a cross platform solution I think Xamarin is probably the least painful path. Now if you were taking on a whole new mobile only project it might be different. If you have no prior mobile experience then you should look at everything and I don't think C# is even a sensible choice for that.
Oh and IoC and interfaces are your friend. For instance we have an IPlatformSpecificHelper which offers methods for doing things that every platform does (eg; getting a Font, creating a bitmap) but does differently. At the heart is AutoFac and each platform has its own registration module which supplies the classes that actually implement the interfaces. So Wpf applications will be using WpfSpecificHelper and mobile apps use XamarinSpecificHelper. Since they both implement the above interface they can be passed into platform common code with impunity. In fact we use this technique extensively to allow us to separate functionality by module by assembly thus aiding in general code portability across our projects.
A related trick is to have an interface for platform specific objects eg; IPlatformSpecificFont. Then you use platform specific converters to return the actual object. I find that better than just using 'object' everywhere.
It's been a few years, but one thing that kept me away from a fully unified approach was when you had to do any kind of animation - and I'm only talking 2D not even 3D here.
I still ended up using things like SpriteKit, so Forms just wasn't an option and I still ended up with separate codebase for iOS and Android.
SkiaSharp was in its infancy - for me it simply would not play nice. Has that improved?
Actually something else I'd recommend is SyncFusion. They offer a very powerful set of Xamarin components. The only fly in the ointment there for us that we were already using DevExpress components on WPF so now we are paying for two third party frameworks.
Unfortunately it seems that DevExpress have given up supporting Xamarin.
"...experiences such as yours that are very intriguing for somone who has yet to dip their toes into mobile app development, but may soon have to."
As with all things it depends. Much of the low hanging fruit is with webby stuff, which is why you have stuff like react native, ionic, cordova, electron etc. With many (most?) apps being effectively front ends for websites, why make it more complicated? Webby folks are used to designing for a variety of screen sizes (or should be), so there isn't that big of a leap.
Coming from desktops on the other hand has been shown to be less easy. Just look at windows 8.
That said, if you already have a load of C#/ASP code ready to be imported, anyone is going to think twice before trying to re-implement that in javascript. The old saying of "if all you have is a hammer" applies. It also applies to the webby stuff too (performance etc), but that's a post for another time.
As someone who's worked with xamarin forms for nearly 3 years now, I am thrilled that it's actually becoming more usable. Anyone who had the displeasure of using XF in 2017 will remember how much of an absolute nightmare it was.
Although I appreciate everything getting better, my application which I started in mid 2017 still works, but recent updates to VS break the tooling because of how the projects used to be set up. I fear that I'll have to completely rebuild the application.
Probably not a bad thing. XF apps used to require some horrific hacks for fairly basic functionality.
I'd never used Xamarin until last year, at that point I couldn't understand why people were always trashing it. I guess it used to be a major pain. Oh well, I think we're goiing to continue using React Native for most projects, the team seems to like it.
P.S. Anyone who's response is "JavaScript in an app is super slow". I write line of business apps, so even if they're twice as slow it doesn't matter and React Native's performance is surprisingly good (I did a bunch of testing before we started using it). Sometimes development cost is more important that performance, that's why we don't write everything in assembly.
I think one of the most valuable things they’ve done in Mono Touch is to somehow parse Apple’s objective C API headers and auto-generate C# equivalents, with forwarding stubs. I have sometimes wondered about trying to hack that to create C++ wrappers for the iOS APIs. Maybe someone has already done that? Could be an interesting quarantine priject.
Xamarin, and its predecessor Ximian, were always part of Microsoft. Miguel de Icaza and Nat Friedman were Microsoft saboteurs working inside the Linux and Open Source community. They derailed the ascendance of KDE as the universal Linux desktop by introducing GNOME and spreading trolltech FUD, and then they derailed cross-platform development by tainting Linux with Microsoft .NET
Those two have been on the Microsoft payroll since LONG before it was official.
Do not recommend using xamarin. The way they treat developers is what you should pay attention too. Latest xamarin management sucks. They make show and ignore features. They are waiting for the "right moment to implement it and intentionally block most wanted features" Example, https://github.com/xamarin/xamarin-macios/issues/6210#issue-comment-box
We are abandoning Xamarin and Xamarin Forms, because the promise didn't deliver in the last 2 years. The specific failures we saw are:
1. We never got the same functionality on iOS, Android, MacOS, iPadOS, and UWP. UWP processing performance has been awful -- and this is a MS core product?
2. XF Graphics performance is slow - you can see repaints of the screen on refresh, visibly. On every platform. On A11 chips. On SnapDragon 845 chips.
3. WebRTC performance is awful - we get echoes, dropped connections, etc., running on a 1Gbps connection between two sites (200 miles apart). We used the same library compiled into a test Electron app -- perfect performance at 4K. No echo, no dropped connections, nothing. It's so much better we tried the connection to a satellite internet user. Video was choppy in Electron, voice is great; neither will connect or if connected, stay up, in Xamarin over the same library. It's not the WebRTC library, TURN servers, or network, it's Xamarin.
4. Developer staff are not available. We both contracted out and trained our internal team. None of them could make things work. I know it isn't the dev team, because they just delivered Electron demo apps that work in 4 weeks having to learn the Electron cold.
5. Opacity of the layers causes debugging issues.Because we can't track where the errors come from, fixing on one platform breaks another.
6. MS support of this platform is beginning to smell like Lotus Notes and Oracle Forms.
We are going to Electron (node.js) for desktop platforms, and native apps with underlying wrapped C/C++ libraries, because we need this to work. The only good thing I can say is that we have the experience to know how to integrate a library with a Xamarin app, if you really want to do that.
Xamarin hasn't been part of Microsoft for 20 years. It hasn't existed for 20 years. It started about a decade ago with a port of Mono for Android, and some Visual Studio plugins to allow coding on a Wintel dev box.
They did *act* like Microsoft: When they released the second version of their dev kit they disabled the first one, stating that one had to download the new one in order to keep using it, then when one fired it up it announced that one had to purchase a second license.
And Microsoft did finally buy Xamarin, but that's been only a few years ago. More on that below....
I know all this. I was there. I used Mono for Android at the time for a few projects. I watched all this happen.
Next, Mono doesn't belong to Xamarin, and it doesn't belong to Microsoft. When the EU refused to continue to use Microsoft's programming products unless they made C# an open standard, Novell promptly assembled a team and made an open-source version: Mono.
Microsoft would *like* for you to believe that when they bought Xamarin they bought Mono, indeed they tried to buy Novell when it became evident that the project would succeed. They've been trying to stuff that genie back into the lamp since about 2005.
Finally, Xamarin's Mono for Android rapidly evolved into a bloated and nearly useless programming platform. They may since have fixed that, indeed it looks as if they're now using Net Core instead of Mono, but they lost a lot of traction in the process.
Someone has been treating Microsoft press releases as if they were actual, recorded history, which the are not. Sad, that.
Xamarin 'development' is the cruellest joke ever inflicted on a community developing mobile applications. It is fucking useless right from the word go. None of the examples work. None of the samples work. The Nuget download is CONSTANTLY being updated, and even with the latest version the CarouselView is unusable. Even the simplest task - such as printing - are not available. I have wasted 5 years of my life trying to get this heap of steaming excrement to even get to a stage where a simple cross-application app works without horrendous, indescribable problems. Xamarin has been foisted on us by a bunch of people NONE of whom can ever have worked as commercial developers as it is apparent they don't have a clue. Nothing works. Nothing. Absolutely nothing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
