All native control handlers must implement INativeControlHandler, so might as well call INativeControlHandler.SetControlProperty() directly. (The Reflection code path was not used anymore at all.)
- For Blaxamarin, only default control types are used and IFormsControlHandler implementations delegate all work to an inner-created control.
- Started re-layering controls to match the real control hierarchy.
- Renderers no longer create the root control. All they do it *add* a given component to a given parent. The platform-specific code is in charge of creating the root component.
- This now avoids creating unnecessary wrappers (e.g. BlazorContentViewWrapper) that muddy the native control hierarchy
- Also updated BlaxamarinTodoApp to use new MasterDetailPage and have Counter as an option
- Swipe from the left of the Blaxamarin app to show the "Master" page with choice of Todo or Counter
- Register an instance of IBlinFormsStartup for user code to run at app start
- Updated BlinForms sample to use more DI services, have Dev/Prod configuration
The wrong subset of the tree was being searched for where to create elements. Previously only the previous siblings of the native parent would be searched. This was wrong because it skipped searching any intermediate ancestor's previous siblings, which could have also had native controls that were the sibling of interest.
Without this, walking up Parent ancestors can end up with bizarre results because there's no native control at the root. The RootControl is created by the framework-specific renderer, so it's a bit different than other controls created as elements.
This should fix the sibling index miscalculation when figuring out where to insert a new element. In general, it finds the nearest parent that has a physical control, and then based on where the current adapter is, it finds the previous sibling that also has a physical control in the aforementioned parent. Hopefully, it works.
Eilon Lipton
Steve Sanderson
Jon Lipsky