New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MvvmCross roadmap 5.x #1415
Comments
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. 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. |
A couple of other thing I'd like to see in 5.0 is something similar to RxUI's Interaction concept, for dialogs etc. |
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? |
I think that has been solved for the DownloadCache plugin by lazy loading, no? |
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. |
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.
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. |
Only thing blocking is building the Mac projects on Windows. Hopefully Xamarin fixes that soon.
I think ultimately we would like a set of issues made from these points, which describe in more detail what they each are about. |
Maybe take another step of porting Mvx to TvOS/WatchOS? |
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. |
Menu inflation would be fairly error prone. There isn't a hook into menu On Aug 24, 2016 4:42 PM, "Carel Lotz" notifications@github.com wrote:
|
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... Btw I'd like to add a new sample in Samples repo that integrates other libraries like PropertyChanged.Fody or AsyncEx to showcase usage. |
Can we remove CrossUI? Does anyone use it? |
I didn't understand the last item, @martijn00. What does it mean? |
I'm still using CrossUI here and there - only on iOS side though. |
@nmilcoff I think destruction of |
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. |
I was wondering if now that wearables are becoming abit more popular possibly adding support for watchOS and Android wear? |
What about AutoView? Is it still used? It doesn't seem to be in active development |
I don't understand this one. |
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. |
The docs shouldn't hold back a release. There are so many things to document, that we would never get one... |
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, ...)
In MvvmCross.Plugin.DialogMessage\Plugin.cs, as modernhttpclient
In App1.XXX\Setup.cs :
And merge idea with Balt and switch plugins |
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) |
@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. |
@mvanbeusekom you are right, I will ask there. (I use Acr.UserDialogs too, |
@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. |
@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 |
What is it that makes MonoTouch.Dialogs better than say MvxCollectionView with a simple override of a GetView to select template based on ViewModel? |
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? |
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 |
@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? |
I will once we get this Proof of Concept HACK working. It's not pretty right now |
@jaroslavrehorka (and anyone else who is intertested) https://github.com/munkii/MvxAndXamForms has my PoC so far. |
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 |
Proposal for MvvmCross 5.0 release:
Proposal for 5.x
Proposal for 6.0
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!
The text was updated successfully, but these errors were encountered: