AutoComplete MVVM and Java Castings without using Java.Lang.Object on ViewModel

3
votes

i've a problem with castings. First i will give an example how to do a custom Adapter for AutoComplete without MVVM in Monodroid: https://github.com/BitStab/Monodroid-Custom-Auto-Complete/blob/master/MonoAndroidApplication1/CustomerAdapter.cs

Now i will try this in MVVMCross, but to do it, i would have to extend my ViewModel by Java.Lang.Object. This would destroy the portability of it. I'm searching right now a workaround and cause i'm no expert on mvvm i need help.

I started to do some new classes in the mvvmCross Bindigs, as you can find it here: https://github.com/BitStab/MvvmCross/tree/master/Cirrious/Cirrious.MvvmCross.Binding/Android/Views

I'm trying to make it as generic as possible, but i need a method to cast from my personal C# object to Java.Lang.Object. Is there a method to do this without extending my ViewModel? If someone has another idea, i'd be happy to get the inspiration!

Thanks for the help!

1
c#xamarin.androidmvvmcross

1 Answers

3
votes

If you want portable code, then you certainly don't want to have Java.anything anywhere near your ViewModels.

I'm afraid I couldn't really follow the CustomerAdapter example code - your filter and publish methods don't look quite right. Further, I had some problems following most of the Java samples I found - from what I've seen, I don't think the threading model on the AutoCompleteTextView is ideal - it blocks a thread for too long (IMHO).

However, after some hacking at a Google Books API sample, then I created a sample - see the video at:

OneTwoThree

This example works using a new alpha databinding Autocomplete class and adaptor within the MvvmCross framework. It may be that these classes never actually make the cut to be full time framework members - in which case they can live in some external library instead.

The basic functionality uses databinding on 3 new properties:

  • PartialText - which is a partial text string - sent from the View to the ViewModel
  • ItemsSource - which is the set of current items available for the supplied PartialText - sent from the ViewModel to the View
  • SelectedObject - which is the current selected item - sent from the View to the ViewModel

You can see these setup in the binding xml as:

<Mvx.MvxBindableAutoCompleteTextView
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  local:MvxItemTemplate="@layout/listitem_book"
  local:MvxBind="{'Text':{'Path':'EnteredText','Mode':'TwoWay'},
  'ItemsSource':{'Path':'AutoCompleteSuggestions'},
  'PartialText':{'Path':'CurrentTextHint'},
  'SelectedObject':{'Path':'CurrentBook'}}"
    />

Note that because of the Android threading model it is essential that every change in PartialText is met by an eventual signalled change in ItemsSource - and this should be a single change in object collection rather than lots of small changes.

The code for this initial sample is in: https://github.com/slodge/MvvmCross/tree/master/Sample%20-%20SimpleDialogBinding/SimpleBinding/DroidAutoComplete

Note that this sample uses "simple binding" rather than the full Mvx framework and as a result there is slightly more threading to worry about in the ViewModel.

The binding view and its adapter are not simple code to follow - the binding code is fairly abstract in nature - but they can be found in:

If you are doing anything network-linked then in the long term I believe it may be better to implement a new autocomplete view rather than to use the built into Android today!