Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Integrated mytoolkit custom frame within mvvmcross #835
@Cheesebaron Jup... only made the mytoolkit implementation work with MvvmCross. I agree it needs to be cleaned up a bit by removing some duplicate logic. Could you help me out with that? What is your view on this PR?
ICommand implementation will be cleaned up to use MvxCommand (see other PR with discussion with @slodge).
What do mean by another implementation of INPC? Do you mean those classes like MvxWindowsLoadStateEventArg?
This implementation also introduces one xaml file to the project. This will result in a xbf file and a pri file. It seems both are needed in a possible future nuget package. See also: http://www.bartlannoeye.com/blog/update-your-nuspec-file-to-include-xr-xml-files-in-your-nuget-package
I looked at MyToolkit and it seems like it would be a pain to integrate and possibly not necessary. I added MyToolkit to my project via nuget and then because of the awesomeness of Mvx, implemented stuff to make it work. I created a new setup from MvxSetup, view dispatcher, and windows view presenter, and used the suspension manager from MyToolkit. I also made a change found here: http://goo.gl/AgualJ
I'll throw a sample together and put it on github.
I like this - suspect it is what I'd personally want to use is I were writing a Win8.1 Jupiter app - I definitely want to see if we can merge this in somehow.
I'm wondering if the best way to do this is to put the MyToolkit integration in a separate assembly and nuget package.
This would mean that users could choose to stay with "nothing", could choose implement their own system, or could choose to use the MyToolkit integration. If we were really clever about this it might even be possible to pull MyToolkit in using nuget.
Depending on how we package and ship this, it could also then give people the freedom to develop and iterate independently of Mvx (and independent of me being slooooow)
e.g. we could take all of:
One complicated point is what to do with
I think we could work out a way to hide these things behind interfaces - MvxWindowsFrame can then implement that interface and we can write an
We could then change
Hope that doesn't all sound too insane... I'll go do some prototyping to see if I can explain better in code...
So... I had a play - see 0652e11 - obviously this isn't a complete cleanup, just an idea I'm sharing.
I think by introducing an
If we went this route then I think for MyToolkit we could:
I think the advantages in doing that would be:
(The only disadvantage I can see is that there would be a possibly overlap between things like
What do you think....
I really like the interface you introduced! Opens MvvmCross up to allow more flexible use of the Frame. The PR I provided was just to test if the code would actually work and start up the discussion. Great to see that we were able to extract this into an interface!
I don't think it is wise to depend on the MyToolkit from any of the MvvmCross NuGet packages. I do think we should include the plain vanilla Frame adapter in MvvmCross. Any custom Frame implementation should be put in a separate packages.
From my pont of view, the disadvantage of the overlap between RelayCommand and MvxCommand could be resolved by re-coding the MyToolkit classes to use MvxCommand (like I did in this PR). Don't know if the author of MyToolkit approves as we are copying his code but that would basically solve the issue (and shrink the user IL code size)
Let me try to pull in your commit and use the interface in the current implementation. I'll extract my implementation in a separate library. I'll also try to create the MyToolkit adapter.
pushed a commit
this pull request
Nov 23, 2014
Thanks both - really happy to refactor the interfaces to make them more usable - and I think the breaking change shouldn't be significant for most existing users.
Have pushed the changes to the head of 3.5
Personally, I'd love to see your MyToolkit-based Frame in a new repo and in a new nuget package - I think it should be possible for users to pull it in instead of pulling in the MvvmCross starter pack (just for those WindowsCommon UI projects). Really like what you've done and glad this interface works for all of us :)
@slodge it seems that for this forked implementation this line actually creates the View, not injecting anything. Currently working with this fork in a project of mine to straighten out some bugs, and while trying to inject a IMvxMessenger in one of my views, I got an MissingMethodException which led me to this method.
Could you point me to the MvvmCross implementation of creating Views, and thus optionally injecting registered dependencies?
@slodge Nevermind... I traced things back to
referenced this pull request
Dec 29, 2014
Thanks - I'm going to close this one now without merging - as I think/hope the interface approach gives us a chance to replace the RootFrame.
If more is needed here - e.g. a refactoring of the interface then happy to do it - we should be able to do this without breaking anyone's apps - this is a new interface :)