문제

We're using MvvmCross in our apps. In our Android app, we use the NavigationDrawer for our Menu. We load our HomeView which contains the NavigationDrawer and the ContentFrame.

<android.support.v4.widget.DrawerLayout >

    <!-- The main content view -->
    <FrameLayout android:id="@+id/content_frame" />

    <!-- The navigation drawer -->
    <ListView android:id="@+id/left_drawer" />

</android.support.v4.widget.DrawerLayout>

When the OnCreate() method is triggered, we load an AudioPlayerFragment into the content_frame based on a database query. In that same method we setup a listener that waits for the user to click one of the ListItem's in the navigation drawer.

protected override void OnCreate(Bundle bundle) {
   // do stuff to build the nav drawer
    _topDrawerList = FindViewById<MvxListView>(Resource.Id.left_drawer);
    _topDrawerList.ItemClick += (sender, args) = > SelectItem(args.Position, null);

    if(bundle == null)
        SelectItem(0, null);
}

private void SelectItem(int position, UserViewModel currentUser) {
    SupportFragmentManager.BeginTransaction()...
}

Our app is working great, and I like how the HomeView is the only View for the app. Everything else is a Fragment.

In our Core library, we have a ViewModel for the HomeView, and we also have a ViewModel for each Fragment in the app. Again, this is working well for us.

  • PCL
    • ViewModels
      • HomeViewModel
      • AudioPlayerViewModel <-- vm for fragment
      • LoginFragmentViewModel <-- vm for fragment
  • Droid.Ui
    • Fragments
      • AudioPlayerFragment
      • LoginFragment
    • Views
      • HomeView <-- Just a container View as the entry point to the app. Everything else is fragmented... AudioPlayerFragment is loaded instantly.

Now I'm trying to build a matching iOS app, but I can't figure out how to structure it. Essentially I'd like the exact same behavior where HomeView is the entry point and can contain both the SlidingPanel bits and some form of a ContentFrame that other "Views" can be loaded into.

Unfortunately, right now I've got this stupid MenuView to deal with, and a corresponding MenuViewModel... and I really don't want either.

  • PCL
    • ViewModels
      • HomeViewModel
      • AudioPlayerViewModel <-- vm for fragment
      • LoginFragmentViewModel <-- vm for fragment
  • Touch UI
    • Views
      • AudioPlayerView
      • HomeView
      • LoginView
      • MenuView <-- UGLY!!!
    • ViewModels
      • MenuViewModel <-- UGLY!!!

I really don't want to create a custom View/ViewModel for the Menu. I'm using SlidingPanels for my iOS "version" of the Navigation Drawer, and the tutorials I'm seeing are requiring an additional View/ViewModel for the menu.

Is there any way to do this and keep continuity with regards to ViewModels so that they can all be reused in a PCL? Is there a nice (read Clean) way to build the layout structure in a similar way to Android?

도움이 되었습니까?

해결책 3

The approach I've settled on is to use the MvxViewController as my base entry point into the app.

public class HomeView: MvxViewController
{
    public override void ViewDidLoad()
    {
        base.ViewDidLoad();

        var myEntryFragement = new MyEntryFragment();
        Add(myEntryFragment);
    }
}

And then use MvxView's as "Fragments"

public class MyEntryFragment: MvxView // essentially a UIView
{

    private MyEntryViewModel _viewModel;
    public MyEntryFragment()
    {
        // manually construct the _viewModel (or alternatively inject it in the constructor)
        // setup all your UI controls in here
    }

}

Then I just load and unload my "Fragment's" as needed.

다른 팁

There have been some attempts to provide unified User Interfaces driven by Portable code. Within MvvmCross, these have especially been driven by the MonoTouch.Dialog type approach to user interfaces. One such attempt/experiment is called "auto-views" - you can see it in action in:

Beneath this autoviews layer, further View code can be shared quite readily within MvvmCross at the Dialog level - e.g. see https://github.com/MvvmCross/MvvmCross-Tutorials/tree/master/DialogExamples


However... with this said... most of the auto-views work to date has still focused on provide rapid prototyping rather than finished apps. For a full rich user interface, most developers still provide custom UIs.

I simply can't wrap my head around the iOS UI. It feels so very foreign to me in comparison to Android.

This isn't that unusual - most XAML developers take to AXML faster than they do to UIKit. However, if you take some time to build some UIViews and to build some user interfaces (pages) with UIViewControllers, then I think you'll get the hang of UIKit quite quickly. Further, I'm confident that once you start seeing the code-based power of things like UIKit animations then you'll even start to fall in love!

You will be able to reuse your View Models, but not your Views. Today, PCL doesn't provide access to the UI stack, so you can't have portable views. For more details, have a look at the blog post How to Make Portable Class Libraries Work for You that our tester wrote.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top