[mono-android] MVVM framework

Wed Nov 9 16:18:14 EST 2011

Hi all,

I have launched this project(https://github.com/rhwilburn/MVVM-for-Mono) on
GitHub, anyone who wants to join or watch the projects progress can here:

https://github.com/rhwilburn/MVVM-for-Mono/wiki

As the project is in its early stages its open to more influence now. Some
vague outline code of what the object model might look like has been
uploaded currently.

*We need people* especially in these areas:

   - Analysis and Documentation (to grow our wiki and make code examples).
   Scoping items would be helpful too. Writing a good sales pitch etc would be
   nice too.
   - Analysis and Unit test writer (to spec our requirements). Continuous
   integration would be nice too if practical.
   - MonoDroid and MonoTouch Developers to satisfy specs/unit tests.

*
Any level of participation*, even to provide constructive criticism is
appreciated as many hands make light work. Currently we have myself and one
other person signed up.

Our project will enable *more code sharing* between WP7/Android/iOS which
should benefit most if not all of us as Mono users by *increasing
producivity*. The less people we have the tighter we will have to scope the
project, meaning that we would scope ourselves currently to Android only
and a minimum set of binding features (I would love to support iOS asap).

Thanks,
Richard.

On Wed, Nov 9, 2011 at 10:17 AM, Richard Wilburn <rhwilburn at gmail.com>wrote:

> Hi Emiel
>
> I have given it a few thoughts already (based off only a quick class
> diagram that was sketched up over a few hours), and the main flow at the
> moment is (definately flexible to change):
>
> 1) parse the xml in the axml and put it into object model.
> 1.1) strip out bindings from the axml file and fetch the id etc of that
> element. Fetch the property and binding info before stripping it and put it
> in the object model.
> 2) use a visitor pattern in a parser like way to decipher the binding data
> 2.1) as a visitor visits a valid binding, it pushes it to a bindingfactory
> class.
> 3) BindingLifecycleFactory class is an abstract factory that handles the
> lifecycle of the bindings, ie setup, teardown and caching of bindings with
> respect to pages. (caching low priority)
> 4) BindingFactory will setup a single binding between a control and a
> viewmodel property. It will interact with the following parts:
> 4.1) ValueConverter
> 4.2) Binding (which only works against objects which use
> INotifyPropertyChanged interface)
>
> As for the question about reflection, im not sure that it would matter if
> we did use reflection because:
>
> 1) We can cache bindings, so they will only be created once and can be
> "paused" when no longer relevant.
> 2) we can as part of our caching, we can pre cache bindings before going
> to the next page via a background worker process.
> 3) a non type safe binding is never stored, so reflective style processing
> would only ever be done once.
>
> I do however believe that it is ideal to minimize or remove reflection,
> but this would be a secondary aim after getting a proof of concept working.
> I am definately open to ideas on how to get this working. I imagine we
> might be able to emit some code or something if we really had to go there.
> I think ultimately though, that caching should work because with MVVM you
> shouldn't be creating bindings on the fly, everything is created up front,
> even for situations like treeview controls etc where they use heirarchical
> templates and bindings again are done up front.
>
> We are definately keen to get more people interested in this, even if only
> to provide critique or suggestion of our approach (or for one off effort,
> ie no commitments). I think MVVM can add alot of value to Mono developers
> because viewmodels can be shared, meaning potentially only  some value
> converters and all views are platform specific. With that said, we can also
> potentially make axml look very similar in bindings to WPF to reduce the
> learning curve down, making Windows phone and android development almost
> identical. iOS looks more like winforms, which can be bent to a MVVM
> pattern (I haven't investigated that in depth).
>
> We also have experience in setting up projects for nuget, so we would also
> be bringing that to the project. See here:
> https://github.com/edys/Ninject-prism-ext
>
> -Richard.
>
>
> On Tue, Nov 8, 2011 at 8:28 PM, Emiel Metselaar <edmetselaar at gmail.com>wrote:
>
>> Richard
>>
>> Interesting. Do you already have some thoughts on how to implement the
>> bindings, reflection seems expensive. I have played around with the func
>> and action delegates to do some form of binding, but ofcourse this does not
>> work from an axml file...
>>
>> Emiel
>>
>> On Mon, Nov 7, 2011 at 9:50 PM, Richard Wilburn <rhwilburn at gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> A friend and I are looking at making a MVVM framework that will enable
>>> monodroid (and eventually iphone too) to have bindings like silverlight etc.
>>>
>>> We have started some modelling work on this, based off of what we have
>>> learned from a hack migration of this poorly modeled project:
>>> http://www.codeproject.com/KB/android/AndroidMVVM.aspx
>>>
>>> We are keen to put this project onto github/nuget if there is interest
>>> from anyone else in developing it. I don't believe the size of the project
>>> is that large, since we can scope it down nicely. Even if someone is
>>> interested in doing a single class to help out that would be cool.
>>>
>>> We feel that a MVVM framework will maximize our reuseability between
>>> WPF/Silverlight/WP7/Android/iphone.
>>>
>>> If you are interested just reply to this email, and we will set up our
>>> current code on github, and share our details.
>>>
>>> Cheers,
>>> Richard.
>>>
>>> _______________________________________________
>>> Monodroid mailing list
>>> Monodroid at lists.ximian.com
>>>
>>> UNSUBSCRIBE INFORMATION:
>>> http://lists.ximian.com/mailman/listinfo/monodroid
>>>
>>>
>>
>> _______________________________________________
>> Monodroid mailing list
>> Monodroid at lists.ximian.com
>>
>> UNSUBSCRIBE INFORMATION:
>> http://lists.ximian.com/mailman/listinfo/monodroid
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodroid/attachments/20111110/cd555e3b/attachment-0001.html 