MvvmCross roadmap 5.x

[martijn00]

Proposal for MvvmCross 5.0 release:

• [x] CI for builds (#1301)
• [x] Automated release builds and nightly builds (#1301)
• [x] WP Silverlight removal (#1460)
• [x] WP8.1 & WindowsStore removal
• [x] AutoView/CrossUI/Dialog removal
• [x] NavigationService with url / deeplink navigation (#1315) (#1595)
• [x] Reproduction samples in main repo
• [x] New event hooks for View > ViewModel loading (#1531 #1601)
• [x] Refactored iOS presenter (#1274) (#1671)
• [x] New website for blog and documentation (#1686)
• [x] Add improved support for Xamarin.Forms

Proposal for 5.x

• [x] More NavigationService improvements
• [x] New Android presenter with support for Dialogs (https://github.com/MvvmCross/MvvmCross/issues/1934)
• [x] New MacOS and tvOS presenters (https://github.com/MvvmCross/MvvmCross/pull/1913)
• [x] Improved first View / ViewModel in StartPack nuget (#1658)
• [ ] Reloading and caching of Views and ViewModels like Fragments (with data) (https://github.com/MvvmCross/MvvmCross-AndroidSupport/issues/194)
• [ ] Handle Android permissions (https://github.com/MvvmCross/MvvmCross-Plugins/issues/82)
• [ ] No dependency on splash screen for loading app

Proposal for 6.0

• [ ] .NET Standard (#1396)
• [ ] Use Bait & Switch with PCL/.NET Standard for plugins (https://github.com/MvvmCross/MvvmCross-Plugins/issues/49)
• [ ] More Async (depends on platform) (#1136)
• [ ] Make it more easy to inherit from base classes when adding new view / class types

Work on MvvmCross 5 will happen on the develop branch. From now on we will use this as our main branch, and use the 4.0 and 3.x branches for bugfix releases(if necessary).

Of course we could use your help so get ready to jump in! Please provide feedback so we can get our requirements ready for this release!

[Cheesebaron]

I think a better structure for working is. Ditch the 4.0 and 3.x branches entirely. Make a develop branch where magic happens. Then push releases and tags into master from develop.
I am not a big fan of having silly LTS support in a OSS project, where resources to begin with are sparse. If that is something you want to do, go ahead and do it in a fork or something.

Otherwise, I like the list. Silverlight needs to be eliminated anyways, if we are switching to NetStandard if I recall correctly.

Bait+Switch for plugins is just a matter of doing all the grunt work. It fairly straight forward.

I tried doing more async startup, but there is always a problem that the platform itself is not async, but there might be ways around that.

Not sure what you mean with Reloading and caching of Views wand ViewModels (with data), you might need to elaborate that a bit.

Repro samples in main repo is a good idea. A more complete API sample app would also be great. Again time and grunt work has to go into that.

[Cheesebaron]

A couple of other thing I'd like to see in 5.0 is something similar to RxUI's Interaction concept, for dialogs etc.

[promontis]

Nice list! What about tackling the plugin loading (order and such)?

What do mean with 'New event hooks for View > ViewModel loading'? Is that to measure performance and such?

[Cheesebaron]

What about tackling the plugin loading (order and such)?

I think that has been solved for the DownloadCache plugin by lazy loading, no?

[martijn00]

Which NetStandard profile should we choose? If we go for 1.2 i suggest to remove everything related to silverlight and win8.0.

If we want to move up to 1.4 also wp8.1 and win8.1 will be removed and only Xamarin project types, UWP and .NET 4.6.1 and higher will be supported.

See https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#mapping-the-net-platform-standard-to-platforms

[Dexyon]

I think a better structure for working is. Ditch the 4.0 and 3.x branches entirely. Make a develop branch where magic happens. Then push releases and tags into master from develop.
I am not a big fan of having silly LTS support in a OSS project, where resources to begin with are sparse. If that is something you want to do, go ahead and do it in a fork or something.

I agree on this one. We should have a dev for bleeding edge merges/development and is for people who want to use nightly-builds. Our Master should represent the last releases.

Not sure what you mean with Reloading and caching of Views wand ViewModels (with data), you might need to elaborate that a bit.

Maybe a good idea to have some kind of explanation per point so everybody is on the same page on what needs to be done and what the current status is.
E.G. The nightly builds and CI are quit easy to set-up as there is already a CI env for the Android-support

[Cheesebaron]

The nightly builds and CI are quit easy to set-up as there is already a CI env for the Android-support

Only thing blocking is building the Mac projects on Windows. Hopefully Xamarin fixes that soon.
I've been setting up builds for a lot of my own projects on AppVeyor, and it works very well.

Maybe a good idea to have some kind of explanation per point so everybody is on the same page on what needs to be done and what the current status is.

I think ultimately we would like a set of issues made from these points, which describe in more detail what they each are about.

[Dexyon]

Maybe take another step of porting Mvx to TvOS/WatchOS?

[cjlotz]

The one aspect that still requires a lot of manual wiring up is the menu navigation in Android. Would be nice to do menu inflation. I know this is a non-trivial exercise though.

[kjeremy]

Menu inflation would be fairly error prone. There isn't a hook into menu
inflater... If I recall you can't override it on any useful way but I will
have to check.

On Aug 24, 2016 4:42 PM, "Carel Lotz" [email protected] wrote:

The one aspect that still requires a lot of manual wiring up is the menu
navigation in Android. Would be nice to do menu inflation. I know this is a
non-trivial exercise though.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MvvmCross/MvvmCross/issues/1415#issuecomment-242201430,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEIBRP79Bgjc-NStbCNZ4xJMlTO2qVG3ks5qjKyqgaJpZM4JqtY8
.

[nmilcoff]

A hard (but valuable) enhancement is to add a "destroy" callback to ViewModel's lifecycle. Let's say a place to dispose resources, such as subscription tokens...
Althougt this has been discused many times, I think we are all handling this in similar ways. Maybe we can make something standard.

Btw I'd like to add a new sample in Samples repo that integrates other libraries like PropertyChanged.Fody or AsyncEx to showcase usage.

[kjeremy]

Can we remove CrossUI? Does anyone use it?

[heytherewill]

I didn't understand the last item, @martijn00. What does it mean?

[cjlotz]

I'm still using CrossUI here and there - only on iOS side though.

[Cheesebaron]

@kjeremy I use CrossUI once in a while. However, it wouldn't be the end of the world if it got removed.

@willsb yeah, we need clarification on that one. I would guess make it consistent that methods are marked virtual and visibility of important things are correct.

[kjeremy]

@nmilcoff I think destruction of ViewModels makes a lot of sense but it probably needs to be tied into the presenter somehow and be heavily configurable. It's not always obvious where to destroy ViewModels but maybe we should provide a Cleanup function or similar (that is called via Dispose) and it's up to the user to figure out the best place to call it (or we provide reasonable defaults).

[kjeremy]

I've was looking at cake recently as a build tool and it looks promising. It should help with #1301 and would allow us to dump the pack.bat stuff and automate nuget releases.

[kjeremy]

We could also use cake to automate some kind of superbuild via submodules. Dealing with the android support repo can be a PITA if the interfaces don't match the latest nuget package.

[b099l3]

I was wondering if now that wearables are becoming abit more popular possibly adding support for watchOS and Android wear?

[nmilcoff]

What about AutoView? Is it still used? It doesn't seem to be in active development

[flyingxu]

No dependency on splash screen for loading app

I don't understand this one.
Currently I'm using MvvmCross for both iOS and Android, and I have removed the splash screen myself. To be honest, I didn't know mvvmcross was depending on splash screen.

[nmilcoff]

What about documentation?

There are a lot of awesome things integrated that have no documentation at all. Mvx is also considered complex to get started with, we should improve the learning curve for starters...

We could open a new issue and list what needs to be documented or what document should be improved / updated.

[Cheesebaron]

The docs shouldn't hold back a release. There are so many things to document, that we would never get one...

[martijn00]

I've updated the description and split the releases up in 3 categories. This makes it easier to release 5.0 with the current progress. Since NetStandard 2.0 is first coming in Q3 we probably need to wait for that until MvvmCross 6.0.

[martijn00]

About the NetStandard support. Looking at how many projects we have in the solution, it might be good to refactor this into MultiTarget projects, explained here: https://oren.codes/2017/01/04/multi-targeting-the-world-a-single-project-to-rule-them-all/

Doing this would make it easier to develop, but also speed up loading of the solution a lot.

Another proposal for MvvmCross 6.x i would like to make is doing the same as https://github.com/Reactive-Extensions/Rx.NET/issues/199
We have a lot of projects, and some are almost always required. The proposed new structure could be:

Assembly/csproj: MvvmCross
Includes:

• MvvmCross.Core
• MvvmCross.Binding
  This also includes all subprojects for Core and Binding for targets like, Android, iOS, Uwp, etc. Using MultiTarget we should be able to do this.

Assembly/csproj: MvvmCross.Platform
Includes:

• MvvmCross.Platform
• MvvmCross.Droid
• MvvmCross.(All other platform names)
  This one would contain all view dependent platform code.

If we let the actual code files stay in the same namespace this should mostly be compatible for everyone.

The plugins could work as one csproj per plugin.

@onovotny do you see any objections in doing this?

[clairernovotny]

Seems reasonable to me!

If you need to generate typeforwarders for old assemblies that are being redirected to a new one for compat, the GenAPI tool is the one to use. It can take an assm and output the list of TypeForwardedTo attributes for every public type in the assembly. The latest one is dotnet buildtools myget feed

You'll probably need the MSBuild.Sdk.Extras package to do the iOS/Android builds. https://github.com/onovotny/MSBuildSdkExtras

Other things to look at are the use of Directory.build.props and Directory.build.targets to remove redundancies across any projects (you can see this in the Rx repo in the develop branch).

[ipalfy]

The removal of AutoView/CrossUI/Dialog from MVVMCross indeed makes sense.

However: I have a lot of Dialogs! Can someone give me a hint how I could continue to use them with upcoming versions 5.0+ ?

[kjeremy]

It's the MvvmCross.Dialog namespace that was nuked not dialog support.

[andrestalavera]

In my opinion, plugins should disappear. Leave the IoC, dependency injection, and above all, the choice to the user to choose the starting mode (Lazy, Singleton, ...)

• MvvmCross.Plugin.DialogMessage
• MvvmCross.Plugin.DialogMessage.UWP
• MvvmCross.Plugin.DialogMessage.Droid
• MvvmCross.Plugin.DialogMessage.Touch
• App1.Core
• App1.UWP
• App1.Droid
• App1.Touch

In MvvmCross.Plugin.DialogMessage\Plugin.cs, as modernhttpclient

    public class Derp
    {
            public void Herp(string derrr)
            {
                    throw new NotImplementedException();
            }
    }

In App1.XXX\Setup.cs :

    public Setup(Frame rootFrame) : base(rootFrame)
    {
    }

    protected override IMvxApplication CreateApp()
    => new App();

    public override void LoadPlugins(IMvxPluginManager pluginManager)
    {
        base.LoadPlugins(pluginManager);
        Mvx.LazyConstructAndRegisterSingleton<IDialogMessagePlugin>(() => new WindowsDialogMessage());
    }

    protected override void AddPluginsLoaders(MvxLoaderPluginRegistry registry)
    {
        // do nothing more here
    }

    protected override void InitializeLastChance()
    {
        Mvx.Register<IDialogMessagePlugin>(() => new WindowsDialogMessage());
        base.InitializeLastChance();
    }
}

And merge idea with Balt and switch plugins

[jaroslavrehorka]

Does anyone have a good alternative to CrossUI.Dialogs? I use it with iOS only, however the only alternative I have found is Monotouch.Dialogs which misses some stuff (like changed events or common ValueElement)

[mvanbeusekom]

@jaroslavrehorka not sure this is the right place for this question, Slack or StackOverflow are better suited places. However I use Acr.UserDialogs a lot.

[jaroslavrehorka]

@mvanbeusekom you are right, I will ask there. (I use Acr.UserDialogs too,
nevertheless CrossUI has a bit different use case for me - I use it for making custom dialogs and modals]

[Cheesebaron]

@mvanbeusekom CrossUI.Dialogs is not the same as AlertDialogs. CrossUI.Dialogs was based on MonoTouch.Dialogs, and was a way to declaratively define UI in code. Very nice for table based views.

Problem with CrossUI is that no one was maintaining it and it had serious flaws, such as two-way bindings rarely working.

@jaroslavrehorka we don't provide an alternative. You could maybe use Xamarin.Forms instead for this.
Alternatively, you could switch to the 4.4.0 tag, yank out CrossUI and maintain it yourself and just build it against newest MvvmCross

[munkii]

@jaroslavrehorka We use CrossUI.Dialogs too. With it being binned in MVVMCRoss 5.0 and our client wanting to support approx 110 new data entry forms I am in the process of building a PoC that will allow moving from MvvCross Native Views to XF views and back out. I have something mostly working for Android, working on iOS now

[Cheesebaron]

What is it that makes MonoTouch.Dialogs better than say MvxCollectionView with a simple override of a GetView to select template based on ViewModel?

[jaroslavrehorka]

I have never tried to do that with MvxCollectionView, but what I like about CrossUI.Dialogs, resp. about MonoTouch.Dialogs is the way of declaring the UI. It is really easy to write or read and the only issue I have with data binding is binding the result of radio selection, everything else work just fine :).

@munkii nice! do you need any help?

[munkii]

I'll get it up on Github today and list my current issues. After iOS I'll need to get WPF and UWP working :-) Then ye any help would be awesome

[martijn00]

@munkii We would like to add support for mixing native views with Forms views in the MvvmCross.Forms package. Maybe you could update the presenter in there?

[munkii]

I will once we get this Proof of Concept HACK working. It's not pretty right now

[munkii]

@jaroslavrehorka (and anyone else who is intertested) https://github.com/munkii/MvxAndXamForms has my PoC so far.

[munkii]

I've integrated my PoC inot a Fork of MVVMCross here https://github.com/munkii/MvvmCross. There is a new project under Forms\TestProjects called "NativeToXF". Currently broken on UWP