It's deliberately made up of lots of small assemblies rather than a few big ones.
The advantages of this are that it keeps the runtime image size smaller, and that it makes the platform more easily extensible.
The
disadvantages, however, are that it can make mvvmcross look a little
complicated initially, and that adding 'using' namespace statements in
code can feel a bit more awkward, especially in environments where tools
like resharper are not available.
This article provides some detail on the assemblies used in an MvvmCross application.
Cirrious.MvvmCross - the core mvvm and IOC library.
Cirrious.MvvmCross.Binding - provides binding functionality for
platforms which don't have built-in data-binding. Currently this means for all non-xaml
platforms.
Cirrious.MvvmCross.Dialog - provides a link between MvvmCross and CrossUI. CrossUI itself is a branch of MonoTouch.Dialog
and MonoDroid.Dialog projects - hopefully these will be joined soon by WP.Dialog
and WinRT.Dialog.
Cirrious.MvvmCross.AutoView - provides an
initial implementation of our cross platform user interface definitions.
Currently this is an 'alpha' level of functionality only...
Plugins -
each plugin provides functionality for a specific task. e.g. for
geolocation, for json parsing, for accelerometer, etc. These plugins are really just a formalisation of how to do cross-platform IoC. Importantly, you can easily
build and distribute your own plugins.
Just Mvvm
If you want to build a simple
mvvm app, then you can build this just at the first Cirrious.MvvmCross
level.
An app built in this way would:
include view models and IOC;
would be able to use
data binding in wp and winrt;
in touch and droid, there would be no declarative data-binding, but you would instead
be able to use C# code which manipulated the ViewModel and which listened to
ViewModel.PropertyChanged events.
To add this level of functionality:
your core app project needs to reference the portable Cirrious.MvvmCross.dll assembly. This portable class library contains the core trace, IOC and mvvm functionality.
your UI projects need each to reference both the portable Cirrious.MvvmCross.dll assembly and the specific implementation for that platform - e.g. the MonoTouch UI needs to reference Cirrious.MvvmCross.Touch.dll
Adding DataBinding
If you want to use data binding
in Droid and Touch, then you need to add the Cirrious.MvvmCross.Binding assemblies to your UI projects.
For Droid, this means you must add both Cirrious.MvvmCross.Binding and Cirrious.MvvmCross.Binding.Android
For Touch, this means you must add both Cirrious.MvvmCross.Binding and Cirrious.MvvmCross.Binding.Touch
These assemblies:
enable you to use MvxBind statements in android axml;
enable you to
use UIViewController-based data binding in Touch;
include
helpers for controls such as android listviews and ios table views.
If you wish to use the image controls within the MvvmCross binding projects, then you will also need to include some plugins within your UI projects - as the image controls rely on Cirrious.MvvmCross.Plugins.File and Cirrious.MvvmCross.Plugins.DownloadCache for downloading and caching image files from http sources.
Adding 'Dialog' UIs
If
you want to take advantage of the code-constructed UIs similar (very similar!) to those offered by MonoTouch.Dialog and MonoDroid.Dialog, then you can get this by
including both the CrossUI and the Cirrious.MvvmCross.Dialog assemblies.
This is currently only available for Touch and Droid. And this is only available in Alpha - more testing and more dev is needed.
If you want to define some default dialog or list-based User Interfaces in your ViewModels, and to then let MvvmCross generate
the client User Interface - then you can do this using Cirrious.MvvmCross.Autoview
assemblies.
Plugins
Plugins are a formalised method for providing cross-platform IoC.
Basically, each plugin comes with a core PCL project/assembly and then individual implementation projects/assemblies for each platform.
It's deliberately made up of lots of small assemblies rather than a few big ones.
The advantages of this are that it keeps the runtime image size smaller, and that it makes the platform more easily extensible.
The disadvantages, however, are that it can make mvvmcross look a little complicated initially, and that adding 'using' namespace statements in code can feel a bit more awkward, especially in environments where tools like resharper are not available.
One other thing to note: PCL support in the MonoDevelop tools is particularly 'alpha' still right now - so you may find you need to implement 'workarounds' like only using PCLs built in MonoTouch for use on MonoTouch. This situation is slowly improving... but in the meantime, sorry!
This article provides a QuickStart on creating an MvvmCross application.
Create a PCL project - named MyApp.Core - make sure it is in the magic 'Profile104'
Add a reference to the assembly - Cirrious.MvvmCross.dll
Add a 'main' App.cs which will own the Services, ViewModels and other classes in the application.
Add a Trace.cs file - so that your application trace is easily identifiable.
Add a StartupApplicationObject.cs class - which identifies which ViewModel will be shown on app startup.
Add a ViewModels folder.
In this folder, place BaseViewModel.cs, derived from MvxViewModel
In this folder, place HomeViewModel.cs, derived from BaseViewModel
This will give you a set of files something like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
note that for this code to compile, then you will need to add using statements for:
using Cirrious.MvvmCross.ExtensionMethods;
using Cirrious.MvvmCross.Interfaces.ServiceProvider;
using Cirrious.MvvmCross.Interfaces.ViewModels;
add a Setup.cs file:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
create a new page in the Views folder - call it HomeView.xaml
change the HomeView.xaml.cs file so that it inherits from a BaseHomeView class which in turn inherits from MvxPhonePage
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Create a new MonoDroid App project - name it MyApp.UI.Droid
Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Binding.dll and NewtonSoft.Json.dll
Add a reference to the android specific libraries of Cirrious.MvvmCross.Droid.dll, Cirrious.MvvmCross.Binding.Android.dll, System.Net.dll and System.Windows.dll
Add a reference to the Core project in your solution
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a SplashScreen activity and /Resources/Layout/SplashScreen.axml file like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the Views folder and in the Resources Layout folder, add a HomeView like
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: On the Mac to target iOS, you need a different set of MvvmCross binaries - in the release folders on http://slodge.blogspot.co.uk/p/mvvmcross-binaries_7.html you will generally find 2 sets of binaries - one for using with VS for Droid/RT/WPF/etc and one for MD on the Mac for iOS.
Note: If you haven't already done: You must edit your targets file. See here: http://slodge.blogspot.co.uk/2013/01/if-pcls-will-not-build-for-you-in.html
To add a MonoTouch UI:
Create a new MonoTouch App project - name it MyApp.UI.Touch
Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Binding.dll and Newtonsoft.Json.dll
Add a reference to the Touch specific libraries of Cirrious.MvvmCross.Touch.dll, Cirrious.MvvmCross.Binding.Touch.dll, System.Net.dll and System.Windows.dll
Add a reference to the Core project in your solution.
Add a Setup.cs file a bit like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the Views folder, add a HomeView using the XIB UIViewController option, but then modify the view controller's inheritance and constructor like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Plugin.Json.dll and NewtonSoft.Json.dll
Add a reference to the WinRT specific libraries of
Cirrious.MvvmCross.WinRT.dll, Cirrious.
Add a reference to the Core project in your solution
Add a file for Setup.cs like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Modify the App.xaml.cs file to provide setup initialisation like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the Common Files folder, edit the LayoutAwarePage.cs file:
Change it so that it inherits from
Cirrious.MvvmCross.WinRT.Views.MvxWinRTPage
Change the OnNavigatedTo method so that it calls the base method
base.OnNavigatedTo(e);
Change the OnNavigatedFrom method so that it calls the base method
base.OnNavigatedFrom(e);
A WPF UI
To add a WPF UI:
Add a new WPF project - Casino.UI.Wpf
Add a reference to the portable Cirrious.MvvmCross.dll, Cirrious.MvvmCross.Plugin.Json.dll and NewtonSoft.Json.dll
Add a reference to the Wpf specific library of
Cirrious.MvvmCross.Wpf.dll
Add a reference to the Core project in your solution
Add files for Setup.cs, SimplePresenter.cs, and Program.cs
Modify the App.xaml.cs and MainWindow.Xaml.* files
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the Views folder and add a HomeView using 'New User Control' to produce a file like:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because we have added an extra Main to our project, go to project properties in Visual Studio and modify the startup application in the Application tab. Set the startup object to Casino.UI.Wpf.Program
To use this interface for a small in-memory list - e.g. less than 1000 'small' objects - all you have to do is to change your List for an ObservableCollection
- the ObservableCollection is a class from the core .Net libraries
(from Microsoft or Mono) and it will fire the correct events when you
Add/Remove list items.
that the binding is OneWay - this means that binding is still only going from ViewModel to View - there are no updates going from View to ViewModel.
that ObservableCollection is designed to be single-threaded - so
make sure all changes to the collection are done on the UI thread - not
on a worker thread. If you need to, you can marshall work back onto the
UI thread using InvokeOnMainThread(() => { /* do work here */ }) in a ViewModel.
that in Android, the way lists work (through the base AdapterView)
means that every time you call any update on the ObservableCollection
then the UI List will ignore the action hint (Add, Remove, etc) - it
will treat every change as a Reset and this will cause the entire list
to redraw.
For larger collections - where you don't want all the items in memory
at the same time - you may need to implement some data-store backed
list yourself.
Unfortunately I've had a lot of problems getting this running on the same machine as Windows 8/Windows Phone 8/Hyper-V... I hope you have better luck than I do - as a good emulator is a wonderful tool to have.
MonoTouch projects require a little tinkering to make them load - they require VSMonoTouch2012 - a completely unsupported installer for this is available on my SkyDrive account - http://sdrv.ms/U6FKrz - some hint at where it came from are on https://github.com/follesoe/VSMonoTouch/issues/13 - obviously you install this at your own risk.
"Copy the MonoTouch binaries from your Mac development environment..."
"Add a RedistList-folder ..."
Warning: See section below on some known issues in VSMonoTouch in VS2012.
For MonoMac/Xamarin.Mac I'm not aware of any way to load these in VS2012 at present.
For older targets like Silverlight and WindowsForms I've not tried anything yet.
Some known issues for VSMonoTouch 2012
I have found VSMonoTouch2012 to be *very* slow when VS first
loads a new solution/project - eg. it took *hours* to load MvvmCross_All
the first time. After this, however, it seems to work quite well.
There are some arguments that VSMonoTouch and MonoDevelop/MonoTouch have over project files. These especially seem to concern the TargetFramework - the fact that VSMonoTouch is set to 1.0 does confuse things (I think). I have seen some projects where I have had to hack in a build step for "The type or namespace name 'TargetFrameworkAttribute' does not exist" - see http://slodge.blogspot.co.uk/2012/09/the-type-or-namespace-name.html
Install a file called "MonoAndroid,Version=v1.6+.xml" in
"C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\SupportedFrameworks" with content:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Install a similar file called "VSMonoTouch,Version=v1.0+.xml" in the same directory and for its content use:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: the VSMonoTouch file is slightly hackier than the MonoDroid one - it points the
portable tools at Full .Net v1.0 exactly as the VSMonoTouch
plugin does - but I think this can cause some tool confusion sometimes.
After creating these xml files, then you should be able to use PCL projects of profile 104 across all platforms.
There are however some small additional problems you may need to solve at build time:
If you share solutions back to the Mac, then MonoDevelop currently only likes Profile1 at Build time. To work around this, you may find you need to force Profile104 across to Profile1 using a conditional statement in your csproj file. Jon Pepper found this solution - thanks - http://slodge.blogspot.co.uk/2012/10/a-temporary-solution-for-profile1-only.html
If you share solutions back to the Mac,and if you have an older MonoDevelop installation, then you may also find that it fails to open .sln files. This bug has been around since May, but is almost fully fixed now. To workaround it you can manually change the .sln to say 11 rather than 12 - see https://bugzilla.xamarin.com/show_bug.cgi?id=4919
To make use of some of the namespaces included in PCL you may need to setup shim assemblies to redirect DLL references. I've done this for System.Net, System.Windows and part of System.Xml.Serialization - see https://github.com/slodge/MvvmCross/tree/vnext/PortableSupport
Note that these projects are quite simple - they just do type redirects from the full .Net assembly names to the Silverlight equivalents (Silverlight/MoonLight is where MonoTouch and MonoDroid started life)
I hope that these Shim assemblies become standard somewhere sometime soon - my versions are MS-PL and I would love to see someone (MS or Xam) take them and ship them more officially.
Using PCLs in Mono for Android inside VS2012 is very straight-forward.
You can easily reference Profile104 projects
You can easily reference Profile104 pre-built assemblies.
Sometimes you need to add the shim DLLs to add support for things like System.Net - but this is a solved problem - just reference the shims from the MvvmCross project and you are there.
Sometimes you seem to need to build a solution twice to make it work
You cannot debug (breakpoints, step into, etc) inside a PCL
Neither of these problems occurs currently in VS2010 using PCLs and Mono for Android - so maybe it is better to code there if you can.
PCLs and MonoTouch
Using PCLs in VSMonoTouch inside VS2012 is very straight-forward.
One word of warning - if you want to share PCLs at a binary level - then build these PCLs in the VisualStudio tools - not in MonoDevelop. This I think is because of code signing and reference assembly issues.
PCLs and Playstation Studio
I've briefly tried reusing PCLs with Playstation Studio/PSVita.
But this nuget package does not like the MonoDroid and VSMonoTouch additions. If you want to add the package then the advice is:
If you've modified your profile
to support MonoTouch and MonoDroid, then a NuGet package typically won't
install because the package doesn't list those platforms as supported.
The workaround is to quit VS, go to the profiles
directory and rename the xml files you added, re-launch VS, and then
reference the NuGet package
Daniel Plaisted did lots of work around this for his BUILD talk - http://channel9.msdn.com/Events/Build/2012/3-004 - the resources for this project include a working MonoDroid async/await sample.
Using nuget
nuget does now contain Portable Library support, but there are some limitations to extending this to monotouch and monodroid targets.
From v2.3 nuget will also contain some monodroid, monotouch and monomac support.
However, this support is very early days - I expect the tools will need some more work to make the experience really fly. I personally intend to invest some time in this - maybe in lobbying, but hopefully in coding (nuget is open source). If anyone wants to join this effort, please do.
I believe nuget when fully working across PCLs, MonoMac, Mono for Android and MonoTouch will be *amazing*
Is it worth the effort? Can't I just use file linking?
I personally love PCLs because they have definitely improved my speed of writing and refactoring code. I'm not claiming that progress is easy... but I am loving using them - so thanks to all in MS, in Xam and in the community (VSMonoTouch and beyond!) who are helping make these better. Indeed, much of the input from MS and Xam seems to have come while 'off duty' :)
The future
I've heard ongoing rumours that Xamarin may have a VS plugin for MonoTouch in development. I believe this was even demo'd live in early 2012... but maybe I was imagining it. Certainly Xamarin have some lovely new products lined up for 2013 - I'm hoping this is part of one of them.
Being able to build all of of PCL, WindowsStore, MonoDroid, MonoTouch, WP, WPF and MonoMac projects within one solution is already amazing today.
Making this support more official (without the VSMonoTouch and PCL reference hacking) and then adding full nuget support would be *fabulous* - I'm so looking forwards to doing single machine binary release and publishing.
Honestly I don't expect this future to arrive in the next month or three... so I do expect anyone who wants to build cross-platform solutions to need some patience and to do some considerable swearing... but the progress in the last year has been remarkable - and we are moving forwards.
MvvmCross today is a single solution containing 120 projects from 7 different project types - it builds, it supports refactoring and it offers me a really stable development environment.
I have gone through setup pain in the past, but this work means I can now spend my time coding - which makes me happy :)
Huge thanks to Xamarin for choosing Sphero Ball Control as the Grand Prize winner in their first developer showdown.
To win a prize is always great :)
But in this case it's even more special:
because the prize is for code
because the voting was done by a great bunch of developers who I have so much time and respect for; from a team who frequently release totally jaw-dropping awesome software - both in product and in source code form.
To be honest, I hoped I had a shot at winning the Windows Phone prize, but I genuinely thought I had no chance at the big one. Especially when you look at some of the apps I was up against:
Evolve from Bill Holmes - using all 3 Xamarin.Mobile parts on iOS:
Wsh Lst from Jonathan Dick (@Redth) - supporting all 3 platforms, plus web services, plus bar code scanning, plus a website - wow:
Prattle from John Heerman - an Android group messaging app I need (and I love the Darth Vader party invite in the video):
Congratulations to all of the above on their prizes - and more importantly on your great apps and code.
All 3 of the apps above are open source - helping everyone to build apps - check them out:
And while I'm saying thanks.... there's also again to Xamarin for hosting the MvvmCross Xaminar - it's awesome to see them embracing and promoting so many different flavors of C# development.
Today I look at the Xamarin blog and I'm all over it :) Thanks, monkeys!
However.... actually the stuff just off the bottom of the page is much more interesting - check out:
I don't know about you.... but I use the WindowsPhoneGeek website a **lot**
.... so I thought it was time I gave a little back!
To help, here's the first article I've written for them - it's about getting started with Bluetooth:
It's mainly based on my BallControl project - but I hope it's a bit easier to follow than the main project - a bit gentler as an introduction into Bluetooth, WP8 and Sphero.
Although actually it wasn't really about PRISM - instead it was more about 'Could MvvmCross be used in WPF?' and 'Could MvvmCross support more complicated Composite UIs?'
I was pretty sure MvvmCross could - especially given our PCL base and our presenter-based Show mechanisms.
So I set about providing it....
And a few hours later - I've checked in some code :)
A lot of people are doing awesome things with MvvmCross.
To celebrate, I'm announcing today:
MvvmCross Badges of Awesomeness
I'm keen to award these out to anyone you know has:
developed an awesome app using MvvmCross
githubbed an awesome MvvmCross extension or plugin
blogged an awesome bit of MvvmCross information
presented an awesome session on MvvmCross
done something else Mvvm and/or Crossie which is awesome....
I'll be awarding the first batch of badges in the next week... and I'll be posting about each and every badge award here on the blog - probably on a special page.
I'm hopeful this will help spread the word about awesome things developers can do with MvvmCross and also help customers find skilled contractors too - because we are worth it!
If you think you deserve one or more badges - or if you know someone who does - please let me know! If you think someone is awesome, then they probably are.
I've ported the Sphero Ball Control to Windows Store
However, because Windows Store apps can't access a very full Bluetooth stack, then I had to use a desktop element (a Windows Service) to make the code work.
This means that the app can not currently be submitted to the Windows Store.
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.
Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we'll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.
As the first comment says:
The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don't always adhere to Test First religiously. But I'm surprised too.
Meet my latest open source project - meet BallControl for Sphero:
Here's a first video I made for the project - sorry about the low audio volume!
Xamarin the Native, Sphero the Ball and Lumia the Phone....
After a long week of coding, this experiment in sleep deprivation reaches its inevitable conclusion.... Featuring: - Xamarin.Mobile Picture capture - Native voice control - Native accelerometer control - Native UI with lots of touch - Native BlueTooth - Guest Starring Sphero the ball - Cross platform Mvvm Xamarin the Monkey.... because going Native matters Can I sleep now?
Here's the apps first public outing to a local user group:
Some technical info
The project demonstrates Xamarin.Mobile by using Xamarin.Mobile media picker.... But, beyond that it also extends Xamarin.Mobile tackling some elements of several Xamarin.Mobile requests on uservoice:
a non-working Windows Store app - it seems that Windows Store does not yet support BlueTooth SPP devices - which is so bad :(
I will get a MonoTouch app working soon....
I will also post to the WP8 app store soon.
And I will post some more videos soon....
If anyone is interested in how the app was built I did live blog the first 10 hours of coding... see PDF at http://sdrv.ms/V8xdmV (or email me for a Word doc). Sorry I didn't blog the whole lot - but there was a lot of code to write... and I did it in 5 days end-to-end while still holding down the day job too.
For the last month I've been swearing at the Visual Studio 2102 and WP8 teams...
The reason: because when I open my WindowsPhone 7 solutions, then it shows them as "unavailable" - which makes me very very sad - because I have to use VS2010:
However, last night @dsplaisted asked me if I'd tried right-clicking on them and reloading them.
It worked
I can now open my Windows Phone 7 projects in VS2012 :)
Apparently, the problem was:
I first tried to open this solution before the WP8 SDK was installed
Visual Studio 2012 didn't know about how to open these - so it marked them 'do not open' in my solution options.
I am sooooooooooooo glad I can open all my projects in VS2012 again!
It seems to work quite well - to see it in action, just include it in your project and then you can use it in your axml or in your C#
The code:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's basically an Mvvm framework using the Xamarin tools. It takes it all the way up to the UI layer, so that the only thing you are building is, for example on the Windows 8 side, just the XAML; on the iOS side just the XML that describes the screens; and the same thing on the Android side.
And you're binding - that's it!
Everything else from that UI definition down is all shared code - so you're basically building almost your entire app with shared code. You're just defining the views each time.
There were plenty of "So Cool", "pretty exciting" and "Awesome" comments thrown in - and some inciteful remarks about:
the importance of native UI
how MvvmCross provides you a native UI
how it allows you to swap out views on each platform
how it helps lower the cost of native development
and about how MvvmCross is ideal for business apps
Thanks to John Sonmez and the Tablet Show team for the nice comments about the 'huge potential for cross-platform development' :)
The MvvmCross story started early in November 2011 when I started work on the Star Wars Kinect social app.
I had a plan to technically build that app using WindowsPhone, MonoTouch and Mono for Android, and I had a basic WindowsPhone prototype that I'd hacked together using TweetSharp and some code-behind... but, beyond that, I really didn't know what I was building or how I was going to do it.
Luckily, towards the middle of the month, MonoCross 1.0 was released. I downloaded it eagerly, and also struck up some online conversations with some of the MX guys, especially Kenny Goers who patiently and skillfully dealt with all of my queries.
Over the next week or two I talked, walked and typed through lots of code. There were lots of prototypes written, lots of emails and code exchanges back and forth, and lots and lots of time spent swearing at compilers, debuggers and phones.
I *loved* what the MonoCross guys had done in trying to put down a rigid MVC structure for their apps - in trying to provide a formal structure for sharing code cross-platform. However, I also hit a few problems with the MVC pattern itself, with the way MonoCross memory management was architected and with the static nature of the MX code base.
To try to work around these problems somewhere around the 25th November, I checked in my first Cirrious.MonoCrossExtensions commit - and Kenny and I again exchanged some emails - especially about memory management, about IoC and about charging forwards...
It was also at about this point that we had a technical meeting inside the Star Wars Kinect project... and at some point during that meeting one of myself or John McLoughlin (imaji on Twitter) said something like:
We could just go the whole way with Mvvm. How hard can it be?
That question hung there for a while....
How hard can it be....?
And so... on the 28th November I ended up abandoning Cirrious.MonoCrossExtensions and commiting the first files into Cirrious.MvvmCross
This was the first proper MvvmCross commit - 'OMG! What haz I done?' - just 280 changed files and 60,000 additions...
I'm really grateful for some of the input I've gotten recently from Microsoft and Xamarin.
Especially:
1. Daniel Plaisted at Microsoft has just heroically supplied a detailed idiot-proof solution to the strong naming issues for ICommand, ObservableCollection, etc.
This solution is:
I think this is what you need to do to get around the type sharing / strong name signing issues for portable libraries on Mono:
-> Extract the public key of System.Windows.dll, and put it in the project directory for the Droid System.Windows project:
Sn –e "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\System.Windows.dll" system_windows.snk
-> Modify the Droid system.windows project to delay-sign using the extracted key. Put the following in a PropertyGroup in the csproj file:
-> Change the assembly version of the Droid System.Windows project (in AssemblyInfo.cs) to:
2.0.5.0
In my testing, I didn't seem to need to disable strong name verification. So I don't think it will present any extra barriers for newbies – once you have these changes made they'll just need to get your code and it will build correctly.
However, if you do run into problems, try running the following from an admin VS command prompt:
These changes may sound trivial, but they've been making code sharing very hard since May this year - and it's great that I can now dropbox/skydrive share my projects and solutions again now between Mac and PC :)
Firstly.... apologies if these changes cause you any problems... but I've tidied up the source tree in vNextDialog and I think these changes will have positive benefits for all users. So I'm merging the changes back into vNext.
The key details of the changes are:
Dialogs
I've added a version of Android.Dialog/MonoDroid.Dialog to the source - this is in CrossUI.Droid
I've added a PCL library - CrossUI.Core - which contains the shared Dialog/Menu/List code
I've moved the MT.Dialog code out of MvvmCross Dialog and back into a CrossUI.Dialog class
AutoViews
I've added projects for AutoViews - these aren't finished yet... but are a very good step in the right direction!
I've added an AutoView sample - based on CustomerManagement. This isn't a 'best practice' sample - it's more a 'here's 3 ways of using autoviews' - so may not be easy to follow yet.
AutoViews currently only exist for MonoTouch and MonoDroid
Build Paths
I've changed the build paths so that all the DLLs build into /bin/debug and /bin/release
Importantly this means it should be easier to do a binary release of MvvmCross again soon :)
One side effect of these changes is that you probably won't be able to build both of Droid/Touch at the same time - this is because they will fight over the System.Windows and System.Net Assembly names - but otherwise they should still build individually.
MonoTouch project configurations
The MonoTouch library projects are now switched to simpler Debug/Release only - I'll try to maintain this as we move forwards!
If these changes break your code.... sorry
The main things that will need changing to get you back building are:
If you were using MonoTouch.Dialog, then you will need to add the CrossUI.Core and CrossUI.Dialog projects and you will need to change some Cirrious.MvvmCross.Dialog.Touch.Elements namespaces to CrossUI.Touch.Dialog.Elements
If you were relying on the iPhone/iPhoneSimulator project configurations, then you will need to use the Configuration Manager to adjust these back to simpler Debug/Release dependencies.
Sorry again for making these changes so suddenly... but I was informed today that a new user was having problems building the main tree... and I wanted to fix these problems.
This merge back seemed like the best way to fix them and to provide the best possible platform moving forwards.
Worth a listen - there's lots of good technical info; interesting questions like 'what does Miguel do all day?'; some great phrases like 'the delight of using Native APIs'; an intriguing comment right at the end about a major product launch next year - "a universe of goodness"; plus some interesting background on the relationships between Mono, Ximian, Novell, Xamarin, MonkeySpace, Microsoft and ... of course ... Monkeys :)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If you are trying to use SpeechRecognition and you see this general Exception - "The speech privacy policy was not accepted prior to attempting a speech recognition" - or possibly you see the "The text associated with this error code could not be found."...
It was a real Autumn day... rainy... overcast... gloomy...
Which made it perfect to test out the PureView floating lens in the 920 :)
These photos are just 'snaps' taken on the run... and the deer in Bushy Park weren't being at all friendly... but I'm definite that 'yes, the 920 has a quite nice camera!'
So a big thank you for the major contribution your framework has made to this project. It has allowed us to share the complex algorithms for deriving the driver rating scores between Android, iOS and Console/Test apps. In fact 90% of the code is shared and easily testable.
This project is still ongoing - http://www.aviva.co.uk/drive - and I think the above quotation says everything you need to know about MvvmCross.... :)
If you've been using MvvmCross, and you have any feedback, then please do send it to me :)