Saturday, November 16, 2013

MvvmCross 3.0.14

After 3 betas, I've now pushed 3.0.14 to nuget and to the binary repo :)


This is probably the last 3.0.x release


The next release will hopefully be 3.1.x - for this next version we will drop Windows Phone 7.x support and aim to more fully support the new releases from Xamarin/Microsoft (Xamasoft?)


For my latest on how to use nuget with Xamarin, please see the run-through in http://slodge.blogspot.co.uk/2013/11/quick-run-through-using-pcls-in.html



The changes in 3.0.14 over 3.0.13 are:
  • Changes to nuspec files for more generic targets (I believe switching nuget to the latest 2.7.2 release will also help some users)
  • Improvements in intrinsic boolean conversions
  • Optimisation in nested bindings - changes to reduce the number of times source properties are fetched during updates
  • Fix for spinner which caches the DataContext when a child window is switched off of the screen and then back in again (without going through an Adapter GetView)
  • Virtual keyword additions to allow additional overrides for CreatingBinding and for GetIoCParameterValues
  • Changes to ValueCombiners to allow them to better support UnsetValue - these now return the UnsetValue if any child is Unset
  • Redirecting the Progress value in the Seekbar so that reflection is not used (very minor optimisation)
  • Refactoring of Android layout inflation code - allowing custom view creation if required
  • Provision of some Folder methods for the MvvmCross File plugin on WindowsStore (Win8/WinRT)
  • A fix for MvxLinearLayout refresh issues
  • A change of protected API for CreateBindingView in MvxAdapter - it now returns an IMvxListItem instead of an MvxListItem (this method is seldom overridden - but is a breaking change if you did override it)
  • A fix for ThreadUtils - Wpf Package
  • A fix for ViewModel creation for activities displayed via external Intents - e.g. from Mail or push links
  • Change to Droid and Touch collections/lists - nullify the datacontexts of individual listview items when removed
  • Wpf ThreadUtils assembly has been added
  • Improvements in binding parsing of properties beginning with and containing underscores
  • Improved error messages when binding fails
  • Binding for Android RatingBar control
  • ShouldReturn binding for iOS
  • Fix to Or logic in ValueCombiner
  • Provision for default parameters in ViewModel Init methods
  • Inclusion of additional LinkerPleaseInclude entries for Android
  • Trace optimisation - no messages shown for null datacontexts


Any problems/issues, please do report them via forums, stackoverflow or via github issues

Thursday, November 14, 2013

Quick run through - using PCLs in Xamarin.Android and Xamarin.iOS with mvvmcross

Following up from yesterday's annoucements, I've just recorded a quick "new project" run-through for PCLs with iOS and Android.


This run-through shows that the process isn't perfect right now - there are a few tweaks along the way - but overall it's a HUGE step in the right direction and you should hopefully be able to get your projects up and running quite quickly.



The source of what I built is on: https://github.com/slodge/Demo


Note that I am using the latest nuget - 2.7.2 - downloaded from http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c


The video is on:






If you've got questions, ideas, suggestions please do start a conversations somewhere - maybe on the MSDN or Xamarin forums, or maybe on Stackoverflow. Please do this in public somewhere - it's great to have open source conversations in public :)


Please do also write your own blog posts and make your own videos - it's fab seeing what others are doing :)

Profiles in the new Portable World

There was lots of great news yesterday - including Microsoft shipping lots of their PCL libraries under a new permissive license and Xamarin working with Microsoft and shipping working PCL support to stable




For those of you who are already ahead of the curve and working with PCLs across all the modern platforms, then this is all really great news. It really reaffirms the direction MvvmCross has been following for the last 18 months.


However, there are some teething problem right now and I'm afraid solid information about what has shipped and how it works is a bit thin on the ground right now.


Right now, if you want to carry on working with PCLs and MvvmCross, then I think some of the steps you may need to take are:

  • If you want to build on Mac, then you may need to change the profile of your PCL from 104 to something newer - with many people currently seeming to choose profile 158. To do this is as simple as editing the csproj file. However, please be aware that doing this will remove support for Windows Phone 7.5 - profile 158 only supports Windows Phone 8 and higher
  • If building Droid projects outside of Visual Studio, you may also need to remove the assembly references to the MvvmCross System.Windows.dll and System.Net.dll - and you may instead need to use the assemblies of the same names that now ship from Xamarin
  • If using nuget, then you may need to update to the latest release (2.7.2) and you may need to use the latest prerelease 3.0.14-beta3 packages from MvvmCross - these are available if you select "include prereleases" inside nuget


Obviously these instructions are "a little sketchy" right now. Sorry - we're doing are best to work with the information that's available. It's not yet really clear what the current state is - how stable the released things are. Hopefully, we'll all learn a lot in the coming days :)


It does seem like Microsoft have forced the retirement of WP7.x development - so it does look likely that we will retire WP7.x support from MvvmCross


It may also be that the future of MvvmCross (v3.1?) lies in one of the 4.5 profiles - like profile 78 - rather than in the 4.0 profiles like 104 or 158. However, this depends a bit on how well the new open Bcl packages can work with Xamarin - and it depends on how we find a way to continue our Silverlight and Unity3D support.


I'll be back with more definitive news real soon :)


The future is portable... and it's now? :)

Wednesday, November 13, 2013

3.0.14-beta3 pushed to nuget

Have updated the build


Have pushed to nuget


Have also pushed VS2012 only binaries to the binaries repo (in theory the XS-built binaries are no longer needed)

In addition to Beta2, Beta3 has:


  • Changes to nuspec files for more generic targets (I believe switching nuget to the latest 2.7.2 release may also help some users)
  • Optimisation in nested bindings - changes to reduce the number of times source properties are fetched during updates
  • Fix for spinner which caches the DataContext when a child window is switched off of the screen and then back in again (without going through an Adapter GetView)
  • Virtual keyword additions to allow additional overrides for CreatingBinding and for GetIoCParameterValues
  • Changes to ValueCombiners to allow them to better support UnsetValue - these now return the UnsetValue if any child is Unset
  • Redirecting the Progress value in the Seekbar so that reflection is not used (very minor optimisation)
  • Refactoring of Android layout inflation code - allowing custom view creation if required
  • Provision of some Folder methods for the MvvmCross File plugin on WindowsStore (Win8/WinRT)





Beyond this, the features included in 3.0.14 beyond 3.0.13 remain:


  • A fix for MvxLinearLayout refresh issues
  • A change of protected API for CreateBindingView in MvxAdapter - it now returns an IMvxListItem instead of an MvxListItem (this method is seldom overridden - but is a breaking change if you did override it)
  • A fix for ThreadUtils - Wpf Package
  • A fix for ViewModel creation for activities displayed via external Intents - e.g. from Mail or push links
  • Change to Droid and Touch collections/lists - nullify the datacontexts of individual listview items when removed
  • Wpf ThreadUtils assembly has been added
  • Improvements in binding parsing of properties beginning with and containing underscores
  • Improved error messages when binding fails
  • Binding for Android RatingBar control
  • ShouldReturn binding for iOS
  • Fix to Or logic in ValueCombiner
  • Provision for default parameters in ViewModel Init methods
  • Inclusion of additional LinkerPleaseInclude entries for Android
  • Trace optimisation - no messages shown for null datacontexts

Portable support is changing within Xamarin right now - but the news is mainly at the "announcement" level right now - as we get details through then we will update MvvmCross to make sure we can all get on with doing dev work instead of setup :)

Thursday, November 07, 2013

N=42 - Is my ViewModel visible? Can I kill it?

Today's N+1 is all about whether or not your ViewModel is Visible - and about how to kill it when it gets removed from the screen.


This is a fairly FAQ topic - see questions like http://stackoverflow.com/questions/15961664/viewmodel-lifecycle-when-does-it-get-disposed and http://stackoverflow.com/questions/19816819/how-are-views-and-viewmodels-freed-up-in-mvvmcross


MvvmCross doesn't provide any built-in event notification - but it is easy to add it for your app.


In this video, I show how to add and invoke interfaces like these to some view models which are shown by a standard MvvmCross presenter:




If you have custom presentation, then you'll need to adapt this technique to suit your needs - but, since it is your custom presentation, then you should hopefully be in the best place to do this.


The source for today's video is in https://github.com/MvvmCross/NPlus1DaysOfMvvmCross/tree/master/N-42-Lifecycles


The video itself is:




The audio skips in the first few seconds - making me sound even odder than normal ;)


For a full N+1 index, please see Aboo's fabulous work on http://mvvmcross.wordpress.com

Wednesday, November 06, 2013

Why you should always Dispose your HttpWebResponse objects

I very recently came across a "hard to solve" issue.


Well, it certainly felt like one...


The problem showed itself via all my HttpWebRequest's blocking - they didn't timeout, they didn't exception - they just blocked.


I couldn't work out what was causing this - and the situation was complicated because the servers I were talking to were quite complicated - they were PHP apps running on Apache, but hiding behind nginx running node.js middleware.


The one thing I could see was that just before things went wrong, these servers were returning "chunked" HTTP 1.1 responses.


The problem also looked more complicated because when I used Fiddler to try to debug the issue, then the problem disappeared (this is because Fiddler alterred the way the responses were received - it doesn't quite mirror responses perfectly - for chunked responses it concatenates them)


Some research led me to various blog posts, stackoverflow answers, etc which all suggested issues - e.g. things like http://blog.degree.no/2011/06/webclient-httpwebresponse-problems-with-chunked-transfer-encoding/


I wrote a test harness, got the case reproducible and then reached out to some friends in MS to see if I had found a genuine issue.


I had, of course, not found one....


Instead, one of the MS guys answered quickly and from his gut:

my gut feel is that you aren’t emptying the body of the first request when using HttpWebRequest.  Can you ensure you are reading the entire body of the first request before sending the second one with HttpWebRequest?


I checked all our calls....


... and in one of them we weren't reading the response at all.


... so I added a `Dispose()` to the response there (instead of reading its stream)


... and that caused the Http stack to start behaving again


... :)


So, it seems like what was happening was that when this "Chunked Transfer Encoding" occurred, then the HttpWebRequest stack got "stuck" waiting for code to read the incomplete response - and this prevented future calls from working.


So the moral of the story is: Dispose() your HttpWebResponse objects - or, if not, at least read them in their entirety.


It's also worth noting: this problem didn't really show up when we switched the code to the newer HttpClient - so, if you are looking at new code, then please do use HttpClient instead!


Thanks especially and hugely to @dsplaisted and @theesj for pointing out (using just their guts) the error. Hopefully by posting this here, it will help others.... 

Monday, November 04, 2013

3.0.14-beta2 on nuget

Have updated the build

In addition to Beta1, Beta2 has:

  • A fix for MvxLinearLayout refresh issues
  • A change of protected API for CreateBindingView in MvxAdapter - it now returns an IMvxListItem instead of an MvxListItem (this method is seldom overridden - but is a breaking change if you did override it)
  • A fix for ThreadUtils - Wpf Package
  • A fix for ViewModel creation for activities displayed via external Intents - e.g. from Mail or push links


Overall, the features included in 3.0.14 beyond 3.0.13 remain:


  • Change to Droid and Touch collections/lists - nullify the datacontexts of individual listview items when removed
  • Wpf ThreadUtils assembly has been added
  • Improvements in binding parsing of properties beginning with and containing underscores
  • Improved error messages when binding fails
  • Binding for Android RatingBar control
  • ShouldReturn binding for iOS
  • Fix to Or logic in ValueCombiner
  • Provision for default parameters in ViewModel Init methods
  • Inclusion of additional LinkerPleaseInclude entries for Android
  • Trace optimisation - no messages shown for null datacontexts

Saturday, November 02, 2013

3.0.14 Beta1 on nuget

The latest build - 3.0.14-Beta1 - has survived some preliminary testing and is now on nuget


There is one significant change which may break client apps in this build.


The change is to do with the way that collection items have their DataContext set to null when the bindings are cleared. It should help prevent a problem that Blewzman reported when he used long-living nested static collections in his viewmodels.



This change may effect your existing views, valueconverters and bindings if they don't cope well with null DataContexts.



For example, in the ApiExamples project this required me to add a check for null to the Convert method:

         protected override string Convert(string value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
         {
             if (value == null)
                 return null;
             return value.Replace((string)parameter, string.Empty);
         }
 

Overall, the features included in 3.0.14 beyond 3.0.13 are:

  • Change to Droid and Touch collections/lists - nullify the datacontexts of individual listview items when removed
  • Wpf ThreadUtils assembly has been added
  • Improvements in binding parsing of properties beginning with and containing underscores
  • Improved error messages when binding fails
  • Binding for Android RatingBar control
  • ShouldReturn binding for iOS
  • Fix to Or logic in ValueCombiner
  • Provision for default parameters in ViewModel Init methods
  • Inclusion of additional LinkerPleaseInclude entries for Android
  • Trace optimisation - no messages shown for null datacontexts