Understanding the layout cycle - .NET MAUI Tutorial

- To level set around Maui UI's, Maui has four different UI concepts: Pages, Layouts, Views, and Cells. A Page is normally a top level entity and would generally contain the entirety of what is seen in an app at one time. A Layout is used to arrange controls in the screen while a View is a single control, or group of controls that act as a single entity. Finally, a Cell is a special type that is used in table views and list views as a single row, column, or intersection of a row and column. A Cell may also contain Layouts and Views when using the view cell. While this all may seem obvious to a developer who is familiar with Maui, what is less obvious is what is revealed when looking at the inheritance trees of those different classes. Pages, Layouts, and Views, all are type of views, or more particularly implement the Iview Interface. Cells on the other hand, are something different and not views at all. Though they do share the same element ancestor. Since cells are not views or even visual elements, we can't confer, they have a different way of laying out their contents and the other three types. The other thing to note, is that while a Page implements the IView Interface it is not a descendant of the View class. Therefore, we can also infer that the implementation of how it is displayed has differences from Layouts and Views. Let's examine what Maui's really doing when it's trying to layout controls on the screen. The first is a top level. Usually a Page assess children, how large they need to be. This is done via a variety of methods depending on the circumstances, but generally they will be something like measure on measure or cross platform measure. These children all implement the IView Interface and they may or may not be able to return a requested size in their own. They too may have collections of children that will need to be queried to find out how large they want to be. This will go on until the lowest level is reached. And it also goes a long way to explain why including unnecessary abstraction layers in our UI can hurt the application's performance. Once all the requested sizes are calculated the top level object will have a requested size for all its children. It knows how much room it has and based on its internal rules, will tell each child the rectangular position on the screen that they will occupy. Each child will in turn follow its allocation rules to tell each of its children the position they will occupy. This will continue until all elements know the coordinates that they will need to draw themselves onto the screen. Each view has a version of measure and a range. Additionally, layouts have layout managers that have their special rules for laying out children. This is different than the compatibility layers and the use of renderers for Xamarin Forms. The odd duck in this list of layout managers is the AndExpandLayoutManager. This is only used by stack layouts and we'll be talking more about them, when we discuss that layout. A view handler is used to convert the concepts and layouts and views to platform specific controls. The screen location accepted by the arrange method will be used by the view handler to properly place and size the native control on the screen. We discuss that Cells do not implement the IView Interface, though they are elements. Cells use an Element handler for the layout cycle. They inherit from a cell renderer base class and serve the same purpose as a view handler for the other element types we discussed. Now that we have a baseline understanding, we can dig a little deeper in the following videos and how the different layout elements work.