vistianopensource / birch Goto Github PK

The implementations of the comparers always return a list of Operations.

There are however a few different ways in which this list of operations is consumed.

We have a couple of extensions which apply the operations to an IList or call a sequence of actions but we need to check any other usages and if possible use these standard extensions instead.

There currently isn't an implementation to instantiate a Carousel View. The attributes/properties are mapped, there just isn't a way of constructing the class and consequently, no shadow mapper either.

There would appear to be an issue with Xamarin Forms Listview when using template selectors for items and headers - namely the header template selector also gets called for cells !

See xamarin/Xamarin.Forms#3407

I suspect that some of the configurable elements of the framework e.g. transaction model, cloning of models etc currently are being specified through the environment builder.

The current error policy is one whereby two differing methods are specified for the handling of errors. One of these returns an IPrimitive , the other is for a 'fatal' error during the commit phase.

What we don't current have however is the ability to 'reset' and start again.

So a 'reset' capability needs to be added to base implementation of host instances AND, the way in which the error policy is used needs to reflect this. It should be remembered that the current implementation of the layout uses Reactive Extensions and currently the way the error policy ia used is pretty prescriptive.

Currently the automatic reflection based attribute mapper do nothing to try and provide any equality comparers for comparing values, other than default behavior.

We perhaps need some ways in which this could be adjusted / enhanced. Either a repository of equality comparers which could be used, or a way of overriding the default behaviour once setup?

The standard Android controls have been 'mapped' but the additional ones in the support libraries like RecyclerView, CoordinatorLayout etc haven't.

The specification for the assembly needs to be generated and then the code mapping generated. Recycler has been manually done already and needs tidying up and shifting over.

When the hosts state bag is updated, a complete layout is performed. Whilst the user doesn't see this effort since its moved onto a background thread there may be some room to perform a 'smarter' update.

One possible way could be as follows:

We enhance the layout context to include a 'map' which contains a map between stateful containers and their primitive.

When the initial layout is performed, this map is automatically updated.

When a new stateful change occurs (which should be the only way in which a layout is performed) we can then use the map to try and identify 'where' we should perform an update. This could 'need' a reference to the container '1' up to perform the 'update' .

I suspect this isn't that difficult to achieve, one just needs to tread carefully!

Other than some platform specific implementations to get the Xamarin Forms elements working, we don't have any of the native iOS views mapped.

Xamarin Forms has the concept of behaviours, since I haven't used Xamarin Forms much I'm not sure how relevant there are to what has been constructed or how one goes about utilising them from code, not markup.

The implementation of images on Android hasn't been tested/tried.

The code generator when writing a specification file currently embeds the templates within specification file. Whilst this is nice and compact its a real pain for editing. We need an option to either embed, or to create separate files.

Currently we have classes like BuildHost and PlatformEnvironment that potentially exist in the same name space - i.e. the namespace for the Android assembly is the same as the core.

When one needs to use differing platforms in the same solution e.g. Xamarin Forms pulling in Android elements for things like platform specific implementations this may result in class name conflicts that are difficult to resolve.

A lot of the code can just be re-used from F#, but it would be nice to identify areas where enhancements could be made to make F# interop better - e.g. the Message sample in the sample counter app would be far better with DUs and pattern matching than what C# provides.

Currently IPrimitives are directly compared and if their underlying type is different then they are immediately considered as not being suitable. No consideration is given to how the IPrimitive was created e.g. if they both came from Username password Widget then it would make more sense to try and re-use rather than just drop everything and start again. The end result is the same but we may be able to reduce the number of UI transactions.

It could well be that we could attach a 'TargetKey' when PerformLayout is used and store it as an attribute, OR, place something within the layout context.

Whilst the code generator currently warns about missing IEquatable implementations when creating the specification , we don't currently have anyway of specifying a custom implementation for IEquatable which could be used.