To me it's simple - here's a rendering pipeline, here's some demo code, now write.
It's no polished "Silverlight/WPF" *rolls eyes* way of doing things but if you get past the limitations of the out of the box code and just embrace the write it all yourself way of life, you come to an acceptance model a lot quicker. I'm not to pissed about that either, as for me I'm ok with rolling my own way of doing things a lot of the time as now it feels like i'm in more control over my destiny than relying on others more. I also think the approach is a lot more leaner in terms of code density than WPF/Silverlight as one thing has always bugged me about my beloved product(s) of past was that it also often felt like i was taking a lot of extra heavy duty code-base with me to just make a button or layout change. I like the idea that everything is on a diet & budget code wise for performance / battery reasons as well. That being said Xamarin maybe my 50 shades of grey codewise ... --- Regards, Scott Barnes http://www.riagenic.com On Mon, Sep 7, 2015 at 12:39 PM, Greg Keogh <[email protected]> wrote: > Folks, it's not Friday, so hang on to your hats and fascinators... > > I hope you'll agree that what the Xamarin Platform product attempts to > achieve is very ambitious and technically amazing. For 6 full working days > I have been learning and using Xamarin in anger to prove its primary claim > of writing, emulating and deploying an app on three platforms from a common > C# code base. This is part of an investigation into how to replace a > Silverlight 5 app. > > I'm going to summarise my experience in the hope it will help guide others > or possibly produce helpful advice. This post is not for young children or > people with heart conditions. > > If you have a $2500 iMac, Windows 8 or higher, $130 Parallels, a $125 > Apple developer account, a $1750 Xamarin licence for both platforms (look > for a small business discount) and the required mobile hardware > ($thousands), then you can start installing the several gigabytes of > dependent software on Mac and Windows. It took me about 12 hours to install > and configure all components to the point where I thought I could start > coding. I had initial terrible trouble activating all the licences on the > machines and software, and it was unclear which software or SDK components > needed to be installed where. > > There are many, many links in the chain of Xamarin development for > targeting 3 platforms: Windows, OS X, WinPhone 8 components, Android SDK, > Android Player, iOS Build Host, Parallels, VirtualBox, Xcode, Visual > Studio, and much more. As you start to develop you will find that every > single one of these links in the long chain will fuck up, all the fucking > time with incomprehensible errors that will utterly confound you. After > learning most of the quirks, timing, commands and options in failed build > attempts over 12 hours I managed to get the word "Hello" to display on the > Windows Phone emulator. Several later I stumbled upon the Android Player > and managed to see "Hello" in an emulator on OS X. The same iOS app was > unresponsive and after being stopped dead for almost 2 days, Xamarin > support found that the "busy indicator" control was transparently covering > the iPhone window, so a workaround finally got all 3 sanity test apps > running in three emulators after about three 14 hour working days. Xamarin > helped me with good online documentation and samples. > > I am now slowly developing a small realistic app with a login screen, 2 > pick list screens and a detail screen. I have it running on three emulators > and my real Nexus 5 phone, mostly. But here's the sobering news: I quite > seriously estimate that at least 60% of all time coding in Xamarin is spent > trying to get all the links in the chain to work, or searching the web for > answers to mind-boggling errors. I have read reports from other developers > with a similar experience, and possibly worst figures. While developing, > absolutely everything will blow up at any time: communication errors, > stalls, build errors, conflicts, lock-ups and incredible error messages. > > Here's an example: On Friday night I stopped coding while everything was > working acceptably well and I was testing on the Android Player. At 9am > this Monday morning I very carefully start it all up again and return to > where I think I was, but first I get weird compile errors, then it won't > deploy and all I see is a blinking cursor in VS2015. After several > desperate reboots, commands, reconnects and more useless web searching, > something came good (I have no damn idea what) and it started working at > around 10:15am. A little later the iOS simulator is miraculously working > OK. Then the Windows Phone test dies with "metadata file is invalid" in the > 2nd service call, which has never happened before and there are no clues > anywhere about what to do. This is all typical, it's SNAFU at almost all > times and quite often FUBAR. > > Writing Xamarin Forms in VS2015 is a poor experience compared to writing > WPF and Silverlight, as there is no intellisense in the XAML subset, which > is crippling on productivity. In fact the intellisense fights you and > continuous Ctrl+z is needed to keep backing out the crazy auto-completion. > Also, many familiar shortcut keys in VS2015 (Ctrl+Shift+Arrow for example) > are absorbed by OS X and you will find yourself flipping into weird Mac > modes. I'm sure there are ways around this, but I'm spreading myself really > thin to do more research. > So in summary, developing in the environment I have described is like > flying on an airline with a fleet of gigantic expensive all-purpose planes > that have pieces constantly falling off them in the air and everyone on > board is patching them up on-the-fly and improvising to keep them flying. > You may have unexpected stopovers for days while some incredible technical > glitch is fixed. You'll probably finish your journey eventually, but it's > an endurance test of funds, sanity and skill. I am actually wondering if it > would be quicker to learn to write iOS, Android and Windows mobile apps in > their native languages and kits instead of using Xamarin ... and it's > frightening that I would even consider such an alternative. Perhaps Xamarin > productivity will rise as I get used to the pain and quirks. And, I have > not even mentioned the learning curve or the struggle to get unified > behaviour. > > *Greg K* >
