For the last couple of weeks I've been kicking off a new big project - it's top secret for now so I can't tell you much about the actual contents of it…
What I can say, though, is that it's an MvvmCross project built on top of all of WinRT, WP7/8, Mono for Android and MonoTouch.
It's being built with a .Net dev team - some young guys who've clearly got a lot of Win8 and WinPhone expertise and who also know their ASP.Net Mvc, know their Umbraco and know a wide breadth of Azure too - not just web and blob, but also more specialist things like the shiny new Media Service APIs.
So why am I teasing and boring you with this information?
Well, because it's **good news**.
It's been really interesting to step back and become a user of MvvmCross - to be working with some great .Net devs who've not seen MvvmCross before, and to experience some of the plans and pleasures of kicking off a new project. It's also been very interesting to find myself writing more of the iOS/MonoTouch code - spending more time in MonoDevelop and trying afresh to use things like the XIB designer in xCode.
What have I learnt:
1. The MonoTouch MvvmCross support had definitely slipped behind the other platforms a bit - a situation I've started to rectify by revisiting some of the View classes - especially things like Image, Table and Collection. I think we've now got already got much better support for those - and I'll be sure to keep doing more code and more samples in MonoTouch again from now on.
2. There are some pain points in setting up MvvmCross cross-platform - especially with all the nonsense surrounding PCLs. However… I've been really impressed with the fact that the professional devs I've been working with have just gotten on with it. If there's a 10 minute setup and that setup requires manually fixing something like the PCL build path on the Mac, then they just do it - and then they get on with coding their app.
Of course, one potential problem here could be the risk that 10 minute setup tasks can go wrong - and if 10 minutes ever turns into an hour or worse, then that's when there's a risk of the dev just giving up…
Clearly, Iweneed to think about this…. and we need to up the quality of the documentation and the setup instructions. If anyone else wants to help with this - especially by blogging about how they've got things working - and how they've solved any issues - then please do. If you share information that helps other devs get started, then 'the law of averages' (or Karma) will one day complete the circle - one of those devs will one day maybe post a sample, answer a stackoverflow question or somehow produce something that helps you out…
3. C# devs need resharper. Really they do. And if you're consuming code written using resharper, then that's doubly true.
For example, the number of namespaces inside MvvmCross… means Alt+Enter for resolving namespaces is really needed!
If you don't have devexpress or resharper or similar, then buy it for your dev work today - it'll pay you back inside a couple of weeks (if not sooner)
4. The Mono toolflow isn't as good as VS2012 with Resharper.
However…. it is actually really rather good :)
MonoDevelop has come a long way since I first used it 3 years ago - the built-in editors, intellisense, refactoring, designers, debugger, etc are all good - and even sometimes excellent. Obviously as a PC user I sometimes feel lost with the mac keystrokes… but the reverse is also happening - it's not that unusual to find me missing some of the Mono tools when I switch back to the PC….
Also, things like the XIB integration on MonoTouch are pretty good at the moment - I can design dynamic data-bound resizing new UICollectionViewCells really quickly and nicely right now. I'll post some blog posts on this soon!
5. MvvmCross really needs a build server and a binary distribution… I'm still working out how to do this - bear with me…. or volunteer to help!
6. The overall approach of MvvmCross/MonoTouch/MonoDroid/WindowsPhone is really good for dev - and it's really quick for existing Mvvm devs (from Prism, MvvmLight, Calliburn, etc) to pick up.
I really very much LIKE the way MvvmCross encourages users to separate out their code - it encourages us to use IoC, it encourages us to write tests, and it allows us to spend our time worrying about our code architecture. Really, this has been eye opening to me… it's reminded me of why we started using a framework in the first place.
So that's it. I just wanted to blog what I've learnt these past few weeks. It's basically a BIG THANKS to the dev team I'm working with - they've taught me heaps; and the project and team have helped me fall back in deep, deep love with MvvmCross again.
Now enough of that…. back soon to talk about some new features and more for the future :)