10 ms·

Xamarin makes me sad, here is my message to them

80 points by nreece 12y ago

jpobst 12y ago
I worked for Novell/Xamarin for almost 7 years and this was a large part of why I eventually parted ways with them. I spent a couple of years on Windows Forms, a couple years on Mono Tools for Visual Studio, and a couple of years on Mono for Android. In all that time I never really felt proud of something we released. I always felt more like I was apologizing for our releases than proudly showing them off. Having said that, I gave Mono for Android a try as a hobby again this year and it was light years better than when I left. (Congrats guys!) However there were definitely still bugs that were mildly annoying as a hobbyist that I can see would be infuriating if I had to rely on it for my job.
- deleted 12y ago
  [deleted]
- andycted 12y ago
  Ditto. I really can't think of anything better to say: Working with Xamarin tools is infuriating. You come to expect them to apologize for the level of unreliabity, instead, not long ago, I got an angry reply that I should be careful when reporting bugs and that I'm insulting them. Never did, but I might start.
an0nymousse 12y ago
Everything the original poster said is true. If you want a really terrifying fact: they're on their series C. Series A: $12MM Series B: $16MM Series C: $54MM $82MM and they still haven't fixed the fundamental issues that have existed from day 1. Stability and support should always come first.
cellis 12y ago
C# is a great language and .NET is probably the most advanced VM on earth. Visual Studio is the most polished IDE. It's just a shame that Microsoft had to enforce windows-only so dogmatically, which is the only reason mono and Xamarin exist in the first place. So the real thing that needs to happen is MSFT needs to make tools for .NET and work to make .NET run on *nix.
- deleted 12y ago
  [deleted]
- RachelF 12y ago
  Hopefully Microsoft are in the process of changing their mind with Ballmer gon. They make fantastic tools, but they really do only target Windows.
- deleted 12y ago
  [deleted]
- x0x0 12y ago
  what does .net platform offer over the jvm? (And to be clear, I understand differences between java and c#).
  - catmanjan 12y ago
    Integrated support libraries and such for things that you need to do for almost every project, compare reading contents from a URL in C#: WebRequest.Create("http://www.google.com/" http://www.google.com/").GetResponse() I can't even think of a way to do it safely in Java without "BufferedBuffer" hell
    - x0x0 12y ago
      reread the second sentence in my post
    - eropple 12y ago
      Integrated libraries cause one of .NET's biggest problems, though: the "if it doesn't come from Microsoft, it doesn't matter" effect. The Java ecosystem's openness provides you a lot of choice and has created a lot of innovation; Coda Hale had a good article on the topic[1]. I don't feel like there's a ton of non-Microsoft innovation in the .NET community--there's some iteration and a lot of (often poor--hello, NuGet) porting and adaptation, but there aren't many people doing something like Scalaz Streams on .NET. Even setting aside advancement and research, it's hard to really create a real competitors to Microsoft's existing solutions even when they're terrible. NHibernate is the "best" one I can think of and it's kind of trainwreckish. Outside of that--like, NancyFx has been around a long time at this point but hasn't really made a dent, whereas the JVM application server is rapidly losing ground--and it literally cannot come soon enough for my liking--to frameworks like Dropwizard or Play. You can fight the Man on the JVM and win; I'm not sure you can do so on .NET. That isn't to say .NET doesn't have some significant pluses. If you stay in the sandbox and can stomach having to deal with non-Unix command line tools or Cygwin (haaaa ha ha ha), it is really really nice. But the second you go off-roading, bring a helmet. [1] - http://codahale.com/when-formality-works/ http://codahale.com/when-formality-works/
lucisferre 12y ago
As someone who spent a lot of time in the .NET world, can someone with more experience using Mono/Xamarin tell me what the main goal is with using this rather than switching to a more *nix centric ecosystem? Is it mainly popular with those who want to develop cross-platform desktop apps? From what I can tell it isn't that great for the end user either. I recall once trying to install a mono based tool on OSX. It was... unpleasant and I ended up simply choosing not to use it.
- ZanyProgrammer 12y ago
  Well, its more of a write once, publish everywhere solution from what I understand-it allows .Net devs to develop in C# for Android/iOS. I recently tried downloading MonoDevelop on OSX, and poked at an ASP.NET MVC 3 web app. Straight out of the box I couldn't run it without an error popping up I couldn't get rid of, so I ditched it.
  - pjmlp 12y ago
    > Well, its more of a write once, publish everywhere solution from what I understand-it allows .Net devs to develop in C# for Android/iOS. Except they don't offer a multi-platform UI toolkit. Xamarin.Forms is quite recent and the amount of bugs shows it still has lot to improve.
vlucas 12y ago
You guys should just switch to JavaScript and use Titanium. Same end result and shared codebase. You can use the Titanium Studio IDE, but it's completely optional. I personally use it with vim and the command line, and it works beautifully. There are some minor issues like certain native APIs not being supported in Titanium (more of a problem on Android), but nothing like the problems listed here.
- evincarofautumn 12y ago
  Part of the reason to use Xamarin is in order to take advantage of C# and F#. Using JavaScript throws away or inhibits a lot of useful stuff like static type checking, automatic completion and refactoring, and code browsing. Besides, they’re invested now; switching to another language may be too costly at this point.
  - an0nymousse 12y ago
    TypeScript?
    - eropple 12y ago
      Over time I've become convinced that the two really viable options are dynamic typing or really good static typing; TypeScript occupies a middling and very rudimentary spot compared to F# (or Scala, which I have more personal experience with; ScalaJS is interesting but I have some pretty huge reservations about that).
      - skrebbel 12y ago
        TypeScript's types are way less powerful and expressive than F#'s. The comparison really doesn't fly. It's even less powerful than C#'s, and it doesn't even come close to adequately supporting a whole range of JavaScript patterns (such as generating "classes" - constructor functions - at runtime). My experience has become that TypeScript is really only suitable for classic OO domain programming, with many nice little classes and mutable state. I work on a project where our model layer (MVC) is made like that, and it works like a charm. Interfacing with other libraries tends to work ok, but you'll have to forget about using --noImplicitAny (and hand in a whole bunch of safety guarantees with that). Doing non-classical-OO stuff quickly becomes a pain. I recently spent many days making a nice Om-style immutable model layer with TypeScript and Immutable.js, and it just doesn't work. The generics simply aren't powerful enough, and I spent days (and many worthless lines of code) fighting it. This saddens me.
Zigurd 12y ago
The author's complaints about Xamarin might be true, but it is also likely that Xamarin is less broken than any other cross-platform solution. If a client insisted on one code-base for iOS and Android I would choose Xamarin. Doing what Xamarin does is VERY hard and Xamarin hasn't had big-time funding until recently. And they can't stop and just fix bugs, like the article author would like. Xamarin is on the treadmill and has to keep up with two platforms that are in competition with each other. The only good news in that is that they will probably converge in terms of capabilities. But, damn, I wouldn't want that job. 3rd party dev tools are a thankless and usually VC-less pursuit. The investors are probably hoping for an exit in the form of Satya Nadella taking C# and VS cross-platform and using it for Microsoft's own apps.
- vyrotek 12y ago
  A lot of fans of Microsoft/C# (Myself included) would love to see some sort of acquisition happen. They definitely have some sort of relationship already. What I do find really interesting is that Microsoft seems to be pursuing Cordova (aka PhoneGap) as well. http://www.visualstudio.com/en-us/explore/cordova-vs.aspx http://www.visualstudio.com/en-us/explore/cordova-vs.aspx
  - pit 12y ago
    So is IBM, with their Worklight platform: https://www.ibm.com/developerworks/community/blogs/mobileblog/entry/apache_cordova_and_ibm_worklight_a_partnership_for_building_hybrid_apps https://www.ibm.com/developerworks/community/blogs/mobileblo... Weird.
- vinceguidry 12y ago
  > If a client insisted on one code-base for iOS and Android I would choose Xamarin. Have you considered Ruby? With Ruboto for Android and RubyMotion for iOS, I'd think you could get a pretty good single-codebase solution. I ask because as a Ruby dev who may one day branch out, I'd like to know what I'd be getting myself into, and it sounds like you might have gone down that road.
  - 12y ago
simplehuman 12y ago
Xamarin is hardly a monopoly in any market. What am I missing?
- aaronbrethorst 12y ago
  Nothing. I think the author may be tossing that word around just a wee bit unfairly. I liked Miguel de Icaza's measured, helpful way of saying 'get bent': Exception stack traces are the easiest problems for us to fix. But we need to get a copy of the exception. Would you be so kind of filing a bug every when you get those exceptions? Whatever settings you have or environment you are using is different than mine, and I have not experienced those problems personally.
  - eropple 12y ago
    I might get some flak for this, because while I respect the hell out of Miguel we've never seen eye to eye when we've talked (he's called me a troll twice, I'm very proud of that), I think that's a huge cop-out. I chafe real hard when Miguel says "file a bug and we'll look at it", because...Xamarin's taking money. When you're taking money, it's no longer "we the community," it's "you the profit-seeking organization." It's their problem, not my problem. Xamarin (and Novell before them) have not done a good job of managing a Mono community, even aside from hiring a big chunk of the community and wondering where the community up and went. They've burned the community at times (and don't get me wrong, I understand why that happens, but it does still happen) and they're clearly spending most of their effort on their commercial stuff. Which is cool, but you lose a lot of the "please file a bug" pull. Expecting people to go sign up for your bug tracker and blah blah blah about a bug in your basically-commercial software is such a fundamental failure to understand people that to me it's pretty much a statement that no, you don't care. If you're seriously interested in fixing bugs people kvetch about on Twitter, get your developer relations people (you have developer relations people, right? (if not, why not?)) to send an email and do the legwork around a bug. And frankly, I feel like "file a bug with an exception trace" is a method of symptomatic treatment rather than the fairly core auditing and testing that most of the Xamarin software I run into on a semi-regular basis really needs. From the outside, a lot of it feels rotten. Picking off an exception here or there doesn't seem likely to cure the disease, it just lances a boil or two.
jagawhowho 12y ago
Seems he already knows the solution. Go native with c/c++. Re-write the front end per platform.
- pjmlp 12y ago
  That is my approach. Xamarin requires anyway an UI implementation per device. The time spent fighting integration bugs can be used in productive coding instead.
- cageface 12y ago
  This works pretty well on iOS where you can transparently mix C++ and ObjC but on Android you're looking at JNI hell.
  - pjmlp 12y ago
    Still way better than having to deal with JNI hell plus whatever code, that you don't control, sits between your application and the JNI calls. My little Qt review, which I posted in a sibling thread, reminded me why using the platform tooling is always the best approach.
Moto7451 12y ago
To provide a (small) counterpoint I've shipped code targeting standard mono for OS X, Windows, Linux, and MS's .Net compiler/runtime as source and distributable DLLs and NancyFX based websites and haven't run into any major road blocks aside from minor Xamarin Studio/Visual Studio project file hiccups. Xamarin's .Net runtime/BCL compatibility list has been spot on for my usage. I can definitely see how chasing Apple, Microsoft, and Google's yearly mobile API revisions can be a task. I don't think that necessarily justifies throwing the entire project out (maybe just some careful evaluation of their mobile oriented offerings). It's akin to throwing all of Java out due to your displeasure with Android development (of which I have a long list of grievances).
skrebbel 12y ago
What a mindless rant. As an equally (un)valuable counter-anecdote: I spent about 9 months developing a set of apps for Android and iOS with Xamarin and didn't encounter many of these problems. We did find one bug in the toolchain. We reported it, Xamarin responded with a workaround in 1 day and a fix in 7.
pjmlp 12y ago
Well, to also provide another counterpoint. I just lost a few days of development researching Qt for mobile. With the outcome that it still has a lot of catching up to do. First issue that was found. The common file dialogs present a desktop file selector on mobile devices! Apparently this is being fixed for 5.4, but it requires the UIs to be written in QML. No such luck for those using pure C++ Widgets. Then the documentation about Qt Quick versions, how to integrate with C++ Widgets and the various ways the deployment to mobile devices can be customised requires a bit o hunting and asking questions on the forum. On my case we had deployment working without issues in the emulator, only to be greeted with a blank screen on some mobile devices. Since a good UX requires using the expected platform behaviours, the best approach is to use C or C++ for logic with a thin shim for the UI and device sensors. Way more productive than hunting third party integration issues, without any guarantee of having them fixed.
- mwcampbell 12y ago
  On top of that, Qt has zero accessibility support (that is, support for assistive technologies required by users with disabilities, such as screen readers for blind users) on mobile platforms. So as you said, you're better off using the native UI.
fotcorn 12y ago
Google Cache version: http://webcache.googleusercontent.com/search?q=cache:https://gist.github.com/sadxamarinuser/2717d68996daea0e2f17 http://webcache.googleusercontent.com/search?q=cache:https:/...
deleted 12y ago
[deleted]
nstart 12y ago
Since the original file seems to be missing now, here's the full text for reference I just stumbled upon this https://gist.github.com/anonymous/38850edf6b9105ee1f8a https://gist.github.com/anonymous/38850edf6b9105ee1f8a and decided to write one too. I don't have affiliation with the OP, but I like his idea and really understand his points. I used Xamarin for the past year or something, not givin real date to keep this anonymous so they dont block my account ;) All the information here is subjective, I'm just expressing my rage in a very emotional way, take it with a grain of salt. Xamarin, if you're reading this, PLEASE TAKE SOMETHING POSITIVE FROM THIS AND GO FIX SOME BUGS. TL;DR: I love C# more than any other language, but Xamarin is HORRIBLE. I wish it and mono were never invented. It's a disgrace, completely broken and buggy and just the most broken thing in the entire universe, but I still use it. Why? Because I can write for 2 platforms as if it was one. haha, not really ... but because I work on small apps, I don't have to write all the business crap twice. That is good about Xamarin, that is the only thing. They can actually compile plain C# ... hooray. If only the rest of the crap expensive broken Xamarin crap library actually worked as advertised. I'm sorry for being so dramatic, but really if something costs a thousand dollars a year per platform, you kind of expect the damn company to put some love into the thing. You would expect bugs to get fixed, and for things to work. But no, that is not the case. Look at Xamarin Forms. Oh a shiney new thing that builds real cross platform UI, so nice. EXCEPT THAT THERE ARE MILLION BUGS IN IT. Fundamental bugs, crashes, memory leaks and other memory issues, broken resource handling ... just serious things that normal company would never release to public, but Xamarin debugs on paying customers, on customers who pay thousands of dollars. If you don't believe me, go to https://bugzilla.xamarin.com/ https://bugzilla.xamarin.com/ and look at the bugs, or look at mono release notes. Just look at the list of shiny features of Mono (http://www.mono-project.com/docs/ http://www.mono-project.com/docs/). Well half of that crap is either broken, or was never implemented, or just doesn't work as documented. Everything is just a lie that should make it look good. Xamarin does thousand things, they release new iOS SDK the same day Apple releases it ... wow ... if only they waited a year and then released a working version instead. They make thousand cool features, but they're all broken. All developers make mistakes, we all create bugs ... but software that costs a thousand dollars should work. It shouldn't leak memory like a total noob, it shouldn't crash the compiler when you compile, and it should work the same way when you compile once and when you compile twice, really the compiler is sometimes just so broken. PLEASE STOP ADDING NEW THINGS, STOP MAKING INTERFACE BUILDERS AND SHIT THAT WILL NEVER WORK, AND JUST FIX SOME BUGS. I want to say something positive, but really I just want to scream and cry and I don't know what to say. I wish I could use something else, I wish I could go back to doing things native, but the things I work on are too invested in Xamarin that there is no way back ... I guess I'll just have to run away. Oh btw, in case you're writing something important, like something working with money, or human lives, or just moving around pictures of cats, pick some other technology, maybe go with native C++ if you want to share your biz logic. Maybe write it as a native things, just please, be careful. There are dragons here. A closing thought. Xamarin is trying to do something amazing. Xamarin.Forms is an amazing technology and makes me really happy at times ... but then I try to do something special and find 50000 completely stupid bugs on each platform, and I start raging again. Please Xamarin, I'm begging you, allocate more humans to fix the bugs, stability is important. And if you manage to accidentaly fix something, please don't break it. I'm always shitting my pants whenever there's a new update, because almost always things get broken. P.S. I'm writing this anonymous because I'm trying to say what is really in my heart. I wouldn't be able to do this in any ot her way, because if certain people found out, I could lose my job, and I value it too much. But still I think this is the right thing to do. I'm not trying to put a bad light on Xamarin, I just want to express my feelings.
mwcampbell 12y ago
RemObjects Elements (http://www.remobjects.com/elements http://www.remobjects.com/elements) looks interesting, especially the C# flavor. With that, you can write in C#, then compile to .NET IL, JVM bytecode (and from there to Dex bytecode for Android), and x86/ARM native code targeting the ObjC runtime for Mac and iOS. The RemObjects C# FAQ (http://www.remobjects.com/elements/hydrogene/faq/ http://www.remobjects.com/elements/hydrogene/faq/) includes a comparison with Xamarin.

80 points by nreece 12y ago

I worked for Novell/Xamarin for almost 7 years and this was a large part of why I eventually parted ways with them. I spent a couple of years on Windows Forms, a couple years on Mono Tools for Visual Studio, and a couple of years on Mono for Android. In all that time I never really felt proud of something we released. I always felt more like I was apologizing for our releases than proudly showing them off. Having said that, I gave Mono for Android a try as a hobby again this year and it was light years better than when I left. (Congrats guys!) However there were definitely still bugs that were mildly annoying as a hobbyist that I can see would be infuriating if I had to rely on it for my job.

deleted 12y ago
[deleted]
andycted 12y ago
Ditto. I really can't think of anything better to say: Working with Xamarin tools is infuriating. You come to expect them to apologize for the level of unreliabity, instead, not long ago, I got an angry reply that I should be careful when reporting bugs and that I'm insulting them. Never did, but I might start.

an0nymousse 12y ago

Everything the original poster said is true. If you want a really terrifying fact: they're on their series C. Series A: $12MM Series B: $16MM Series C: $54MM $82MM and they still haven't fixed the fundamental issues that have existed from day 1. Stability and support should always come first.

cellis 12y ago

C# is a great language and .NET is probably the most advanced VM on earth. Visual Studio is the most polished IDE. It's just a shame that Microsoft had to enforce windows-only so dogmatically, which is the only reason mono and Xamarin exist in the first place. So the real thing that needs to happen is MSFT needs to make tools for .NET and work to make .NET run on *nix.

deleted 12y ago
[deleted]
RachelF 12y ago
Hopefully Microsoft are in the process of changing their mind with Ballmer gon. They make fantastic tools, but they really do only target Windows.
deleted 12y ago
[deleted]
x0x0 12y ago
what does .net platform offer over the jvm? (And to be clear, I understand differences between java and c#).
- catmanjan 12y ago
  Integrated support libraries and such for things that you need to do for almost every project, compare reading contents from a URL in C#: WebRequest.Create("http://www.google.com/" http://www.google.com/").GetResponse() I can't even think of a way to do it safely in Java without "BufferedBuffer" hell
  - x0x0 12y ago
    reread the second sentence in my post
  - eropple 12y ago
    Integrated libraries cause one of .NET's biggest problems, though: the "if it doesn't come from Microsoft, it doesn't matter" effect. The Java ecosystem's openness provides you a lot of choice and has created a lot of innovation; Coda Hale had a good article on the topic[1]. I don't feel like there's a ton of non-Microsoft innovation in the .NET community--there's some iteration and a lot of (often poor--hello, NuGet) porting and adaptation, but there aren't many people doing something like Scalaz Streams on .NET. Even setting aside advancement and research, it's hard to really create a real competitors to Microsoft's existing solutions even when they're terrible. NHibernate is the "best" one I can think of and it's kind of trainwreckish. Outside of that--like, NancyFx has been around a long time at this point but hasn't really made a dent, whereas the JVM application server is rapidly losing ground--and it literally cannot come soon enough for my liking--to frameworks like Dropwizard or Play. You can fight the Man on the JVM and win; I'm not sure you can do so on .NET. That isn't to say .NET doesn't have some significant pluses. If you stay in the sandbox and can stomach having to deal with non-Unix command line tools or Cygwin (haaaa ha ha ha), it is really really nice. But the second you go off-roading, bring a helmet. [1] - http://codahale.com/when-formality-works/ http://codahale.com/when-formality-works/

lucisferre 12y ago

As someone who spent a lot of time in the .NET world, can someone with more experience using Mono/Xamarin tell me what the main goal is with using this rather than switching to a more *nix centric ecosystem? Is it mainly popular with those who want to develop cross-platform desktop apps? From what I can tell it isn't that great for the end user either. I recall once trying to install a mono based tool on OSX. It was... unpleasant and I ended up simply choosing not to use it.

ZanyProgrammer 12y ago
Well, its more of a write once, publish everywhere solution from what I understand-it allows .Net devs to develop in C# for Android/iOS. I recently tried downloading MonoDevelop on OSX, and poked at an ASP.NET MVC 3 web app. Straight out of the box I couldn't run it without an error popping up I couldn't get rid of, so I ditched it.
- pjmlp 12y ago
  > Well, its more of a write once, publish everywhere solution from what I understand-it allows .Net devs to develop in C# for Android/iOS. Except they don't offer a multi-platform UI toolkit. Xamarin.Forms is quite recent and the amount of bugs shows it still has lot to improve.

vlucas 12y ago

You guys should just switch to JavaScript and use Titanium. Same end result and shared codebase. You can use the Titanium Studio IDE, but it's completely optional. I personally use it with vim and the command line, and it works beautifully. There are some minor issues like certain native APIs not being supported in Titanium (more of a problem on Android), but nothing like the problems listed here.

evincarofautumn 12y ago
Part of the reason to use Xamarin is in order to take advantage of C# and F#. Using JavaScript throws away or inhibits a lot of useful stuff like static type checking, automatic completion and refactoring, and code browsing. Besides, they’re invested now; switching to another language may be too costly at this point.
- an0nymousse 12y ago
  TypeScript?
  - eropple 12y ago
    Over time I've become convinced that the two really viable options are dynamic typing or really good static typing; TypeScript occupies a middling and very rudimentary spot compared to F# (or Scala, which I have more personal experience with; ScalaJS is interesting but I have some pretty huge reservations about that).
    - skrebbel 12y ago
      TypeScript's types are way less powerful and expressive than F#'s. The comparison really doesn't fly. It's even less powerful than C#'s, and it doesn't even come close to adequately supporting a whole range of JavaScript patterns (such as generating "classes" - constructor functions - at runtime). My experience has become that TypeScript is really only suitable for classic OO domain programming, with many nice little classes and mutable state. I work on a project where our model layer (MVC) is made like that, and it works like a charm. Interfacing with other libraries tends to work ok, but you'll have to forget about using --noImplicitAny (and hand in a whole bunch of safety guarantees with that). Doing non-classical-OO stuff quickly becomes a pain. I recently spent many days making a nice Om-style immutable model layer with TypeScript and Immutable.js, and it just doesn't work. The generics simply aren't powerful enough, and I spent days (and many worthless lines of code) fighting it. This saddens me.

Zigurd 12y ago

The author's complaints about Xamarin might be true, but it is also likely that Xamarin is less broken than any other cross-platform solution. If a client insisted on one code-base for iOS and Android I would choose Xamarin. Doing what Xamarin does is VERY hard and Xamarin hasn't had big-time funding until recently. And they can't stop and just fix bugs, like the article author would like. Xamarin is on the treadmill and has to keep up with two platforms that are in competition with each other. The only good news in that is that they will probably converge in terms of capabilities. But, damn, I wouldn't want that job. 3rd party dev tools are a thankless and usually VC-less pursuit. The investors are probably hoping for an exit in the form of Satya Nadella taking C# and VS cross-platform and using it for Microsoft's own apps.

vyrotek 12y ago
A lot of fans of Microsoft/C# (Myself included) would love to see some sort of acquisition happen. They definitely have some sort of relationship already. What I do find really interesting is that Microsoft seems to be pursuing Cordova (aka PhoneGap) as well. http://www.visualstudio.com/en-us/explore/cordova-vs.aspx http://www.visualstudio.com/en-us/explore/cordova-vs.aspx
- pit 12y ago
  So is IBM, with their Worklight platform: https://www.ibm.com/developerworks/community/blogs/mobileblog/entry/apache_cordova_and_ibm_worklight_a_partnership_for_building_hybrid_apps https://www.ibm.com/developerworks/community/blogs/mobileblo... Weird.
vinceguidry 12y ago
> If a client insisted on one code-base for iOS and Android I would choose Xamarin. Have you considered Ruby? With Ruboto for Android and RubyMotion for iOS, I'd think you could get a pretty good single-codebase solution. I ask because as a Ruby dev who may one day branch out, I'd like to know what I'd be getting myself into, and it sounds like you might have gone down that road.
- 12y ago

simplehuman 12y ago

Xamarin is hardly a monopoly in any market. What am I missing?

aaronbrethorst 12y ago
Nothing. I think the author may be tossing that word around just a wee bit unfairly. I liked Miguel de Icaza's measured, helpful way of saying 'get bent': Exception stack traces are the easiest problems for us to fix. But we need to get a copy of the exception. Would you be so kind of filing a bug every when you get those exceptions? Whatever settings you have or environment you are using is different than mine, and I have not experienced those problems personally.
- eropple 12y ago
  I might get some flak for this, because while I respect the hell out of Miguel we've never seen eye to eye when we've talked (he's called me a troll twice, I'm very proud of that), I think that's a huge cop-out. I chafe real hard when Miguel says "file a bug and we'll look at it", because...Xamarin's taking money. When you're taking money, it's no longer "we the community," it's "you the profit-seeking organization." It's their problem, not my problem. Xamarin (and Novell before them) have not done a good job of managing a Mono community, even aside from hiring a big chunk of the community and wondering where the community up and went. They've burned the community at times (and don't get me wrong, I understand why that happens, but it does still happen) and they're clearly spending most of their effort on their commercial stuff. Which is cool, but you lose a lot of the "please file a bug" pull. Expecting people to go sign up for your bug tracker and blah blah blah about a bug in your basically-commercial software is such a fundamental failure to understand people that to me it's pretty much a statement that no, you don't care. If you're seriously interested in fixing bugs people kvetch about on Twitter, get your developer relations people (you have developer relations people, right? (if not, why not?)) to send an email and do the legwork around a bug. And frankly, I feel like "file a bug with an exception trace" is a method of symptomatic treatment rather than the fairly core auditing and testing that most of the Xamarin software I run into on a semi-regular basis really needs. From the outside, a lot of it feels rotten. Picking off an exception here or there doesn't seem likely to cure the disease, it just lances a boil or two.

jagawhowho 12y ago

Seems he already knows the solution. Go native with c/c++. Re-write the front end per platform.

pjmlp 12y ago
That is my approach. Xamarin requires anyway an UI implementation per device. The time spent fighting integration bugs can be used in productive coding instead.
cageface 12y ago
This works pretty well on iOS where you can transparently mix C++ and ObjC but on Android you're looking at JNI hell.
- pjmlp 12y ago
  Still way better than having to deal with JNI hell plus whatever code, that you don't control, sits between your application and the JNI calls. My little Qt review, which I posted in a sibling thread, reminded me why using the platform tooling is always the best approach.

Moto7451 12y ago

To provide a (small) counterpoint I've shipped code targeting standard mono for OS X, Windows, Linux, and MS's .Net compiler/runtime as source and distributable DLLs and NancyFX based websites and haven't run into any major road blocks aside from minor Xamarin Studio/Visual Studio project file hiccups. Xamarin's .Net runtime/BCL compatibility list has been spot on for my usage. I can definitely see how chasing Apple, Microsoft, and Google's yearly mobile API revisions can be a task. I don't think that necessarily justifies throwing the entire project out (maybe just some careful evaluation of their mobile oriented offerings). It's akin to throwing all of Java out due to your displeasure with Android development (of which I have a long list of grievances).

skrebbel 12y ago

What a mindless rant. As an equally (un)valuable counter-anecdote: I spent about 9 months developing a set of apps for Android and iOS with Xamarin and didn't encounter many of these problems. We did find one bug in the toolchain. We reported it, Xamarin responded with a workaround in 1 day and a fix in 7.

pjmlp 12y ago

Well, to also provide another counterpoint. I just lost a few days of development researching Qt for mobile. With the outcome that it still has a lot of catching up to do. First issue that was found. The common file dialogs present a desktop file selector on mobile devices! Apparently this is being fixed for 5.4, but it requires the UIs to be written in QML. No such luck for those using pure C++ Widgets. Then the documentation about Qt Quick versions, how to integrate with C++ Widgets and the various ways the deployment to mobile devices can be customised requires a bit o hunting and asking questions on the forum. On my case we had deployment working without issues in the emulator, only to be greeted with a blank screen on some mobile devices. Since a good UX requires using the expected platform behaviours, the best approach is to use C or C++ for logic with a thin shim for the UI and device sensors. Way more productive than hunting third party integration issues, without any guarantee of having them fixed.

mwcampbell 12y ago
On top of that, Qt has zero accessibility support (that is, support for assistive technologies required by users with disabilities, such as screen readers for blind users) on mobile platforms. So as you said, you're better off using the native UI.

fotcorn 12y ago

Google Cache version: http://webcache.googleusercontent.com/search?q=cache:https://gist.github.com/sadxamarinuser/2717d68996daea0e2f17 http://webcache.googleusercontent.com/search?q=cache:https:/...

deleted 12y ago

[deleted]

nstart 12y ago

Since the original file seems to be missing now, here's the full text for reference I just stumbled upon this https://gist.github.com/anonymous/38850edf6b9105ee1f8a https://gist.github.com/anonymous/38850edf6b9105ee1f8a and decided to write one too. I don't have affiliation with the OP, but I like his idea and really understand his points. I used Xamarin for the past year or something, not givin real date to keep this anonymous so they dont block my account ;) All the information here is subjective, I'm just expressing my rage in a very emotional way, take it with a grain of salt. Xamarin, if you're reading this, PLEASE TAKE SOMETHING POSITIVE FROM THIS AND GO FIX SOME BUGS. TL;DR: I love C# more than any other language, but Xamarin is HORRIBLE. I wish it and mono were never invented. It's a disgrace, completely broken and buggy and just the most broken thing in the entire universe, but I still use it. Why? Because I can write for 2 platforms as if it was one. haha, not really ... but because I work on small apps, I don't have to write all the business crap twice. That is good about Xamarin, that is the only thing. They can actually compile plain C# ... hooray. If only the rest of the crap expensive broken Xamarin crap library actually worked as advertised. I'm sorry for being so dramatic, but really if something costs a thousand dollars a year per platform, you kind of expect the damn company to put some love into the thing. You would expect bugs to get fixed, and for things to work. But no, that is not the case. Look at Xamarin Forms. Oh a shiney new thing that builds real cross platform UI, so nice. EXCEPT THAT THERE ARE MILLION BUGS IN IT. Fundamental bugs, crashes, memory leaks and other memory issues, broken resource handling ... just serious things that normal company would never release to public, but Xamarin debugs on paying customers, on customers who pay thousands of dollars. If you don't believe me, go to https://bugzilla.xamarin.com/ https://bugzilla.xamarin.com/ and look at the bugs, or look at mono release notes. Just look at the list of shiny features of Mono (http://www.mono-project.com/docs/ http://www.mono-project.com/docs/). Well half of that crap is either broken, or was never implemented, or just doesn't work as documented. Everything is just a lie that should make it look good. Xamarin does thousand things, they release new iOS SDK the same day Apple releases it ... wow ... if only they waited a year and then released a working version instead. They make thousand cool features, but they're all broken. All developers make mistakes, we all create bugs ... but software that costs a thousand dollars should work. It shouldn't leak memory like a total noob, it shouldn't crash the compiler when you compile, and it should work the same way when you compile once and when you compile twice, really the compiler is sometimes just so broken. PLEASE STOP ADDING NEW THINGS, STOP MAKING INTERFACE BUILDERS AND SHIT THAT WILL NEVER WORK, AND JUST FIX SOME BUGS. I want to say something positive, but really I just want to scream and cry and I don't know what to say. I wish I could use something else, I wish I could go back to doing things native, but the things I work on are too invested in Xamarin that there is no way back ... I guess I'll just have to run away. Oh btw, in case you're writing something important, like something working with money, or human lives, or just moving around pictures of cats, pick some other technology, maybe go with native C++ if you want to share your biz logic. Maybe write it as a native things, just please, be careful. There are dragons here. A closing thought. Xamarin is trying to do something amazing. Xamarin.Forms is an amazing technology and makes me really happy at times ... but then I try to do something special and find 50000 completely stupid bugs on each platform, and I start raging again. Please Xamarin, I'm begging you, allocate more humans to fix the bugs, stability is important. And if you manage to accidentaly fix something, please don't break it. I'm always shitting my pants whenever there's a new update, because almost always things get broken. P.S. I'm writing this anonymous because I'm trying to say what is really in my heart. I wouldn't be able to do this in any ot her way, because if certain people found out, I could lose my job, and I value it too much. But still I think this is the right thing to do. I'm not trying to put a bad light on Xamarin, I just want to express my feelings.

mwcampbell 12y ago

RemObjects Elements (http://www.remobjects.com/elements http://www.remobjects.com/elements) looks interesting, especially the C# flavor. With that, you can write in C#, then compile to .NET IL, JVM bytecode (and from there to Dex bytecode for Android), and x86/ARM native code targeting the ObjC runtime for Mac and iOS. The RemObjects C# FAQ (http://www.remobjects.com/elements/hydrogene/faq/ http://www.remobjects.com/elements/hydrogene/faq/) includes a comparison with Xamarin.