This is great - I primarily develop Silverlight web apps - our customers are now wanting to use ipads and android tablets so we have been investigating mono among other things. The bindings are what is missing from Android/Mono I can see that this is not core for Xamarin as the UI on the different platforms requires different approaches. At the moment our managers are heading towards html5 or windows 8 on tablets however this kind of thing could swing the pendulum towards Android.
I know very little about iOS is there anything similar to WPF bindings in iOS ? Gabriel From: [email protected] [mailto:[email protected]] On Behalf Of Richard Wilburn Sent: Thursday, 10 November 2011 8:18 AM To: Discussions related to Mono for Android Cc: Rhys Walden; [email protected] Subject: Re: [mono-android] MVVM framework 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid _______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
