MultiLayoutPanel vs. LayoutMaster

How-to Discussions
1

Recently I happened upon the ‘Tabs using multi layout’ example (https://www.fusetools.com/examples/tabs-multi-layout). I found this example quite confusing, and when I went to the documentation for MultiLayoutPanel, I was further puzzled by this section

Note: MultiLayoutPanel is a good option for when you want to have different layouts based on on the value of certain data. In the cases where you are mostly interested in using different layouts as a means of creating animations, using the Element.LayoutMaster property might be a better choice.

I tried this suggestion, and the example does seem to look more readable using LayoutMaster - just tell the indicator, i.e. the rectangle used to underline the tab, who its new layout master is (see code below). My question then is, what’s a use case where using MultiLayoutPanel makes more sense than LayoutMaster? I think the name MultiLayoutPanel is also a bit confusing to me as it implies that a Panel has multiple possible Layouts, but that doesn’t seem to be the case here - or is it? Any clarification you can offer is greatly appreciated! Thanks!

<App Background="#eee">
	<DockPanel>
		<Font ux:Global="RobotoMedium" File="Roboto-Medium.ttf" />
		<Panel ux:Class="Tab" ux:Name="self" ClipToBounds="false" Margin="0,0,0,4" Background="#bdc3c7">
			<string ux:Property="Text" />
			<Text Value="{ReadProperty self.Text}" Color="#FFF" Font="RobotoMedium" Alignment="Center" />
		</Panel>

		<StackPanel Dock="Top" Background="#bdc3c7">
			<StatusBarBackground />
			<Fuse.iOS.StatusBarConfig Style="Light"/>
			<Grid ColumnCount="3" Height="50">
				<Panel ux:Name="page1Tab">
					<Rectangle ux:Name="indicator" Alignment="Bottom" Height="4" Fill="#6c7a89">
						<LayoutAnimation>
							<Move RelativeTo="WorldPositionChange" X="1" Duration="0.4" Easing="BackIn"/>
						</LayoutAnimation>
					</Rectangle>
					<Tab Text="Page 1">
						<Clicked>
							<Set navigation.Active="page1" />
						</Clicked>
					</Tab>
				</Panel>
				<Panel ux:Name="page2Tab">
					<Tab Text="Page 2">
						<Clicked>
							<Set navigation.Active="page2" />
						</Clicked>
					</Tab>
				</Panel>
				<Panel ux:Name="page3Tab">
					<Tab Text="Page 3">
						<Clicked>
							<Set navigation.Active="page3" />
						</Clicked>
					</Tab>
				</Panel>
			</Grid>
		</StackPanel>

		<PageControl ux:Name="navigation">
			<Text ux:Class="WelcomeText" FontSize="30" Alignment="Center"/>
			<Page ux:Name="page1" Background="#eee">
				<WhileActive Threshold="0.5">
					<Set indicator.LayoutMaster="page1Tab" />
				</WhileActive>
				<WelcomeText>Welcome to Page 1</WelcomeText>
			</Page>
			<Page ux:Name="page2" Background="#abb7b7">
				<WhileActive Threshold="0.5">
					<Set indicator.LayoutMaster="page2Tab" />
				</WhileActive>
				<WelcomeText>Welcome to Page 2</WelcomeText>
			</Page>
			<Page ux:Name="page3" Background="#f2f1ef">
				<WhileActive Threshold="0.5">
					<Set indicator.LayoutMaster="page3Tab" />
				</WhileActive>
				<WelcomeText>Welcome to Page 3</WelcomeText>
			</Page>
		</PageControl>
	</DockPanel>
</App>
2

Generally we’re trying to avoid using MultiLayout for any standard animation or minor changes to the layout. If LayoutMaster works for what you’re doing it’s the preferred choice. It has much less performance impact than multi-layout does. It’s really good at moving individual bits around in response to page changes.

MultiLayout is more useful when you have a fundamental change in the layout of your page, such as between portrait and landscape. It’s much easier to just create two layouts and move the controls between them. It is more limited in terms of how animation can respond, and has some caveats with regrad to rooting/unrooting the control (though we attempt to eliminate those).

However, if you’re building a state-driven interface with data bindings it’s likely even easier to just build a different layout and forget about sharing the controls at all. Just let the data-bindings populate a new page. This of course doesn’t allow any animation between the elements, but on major layout changes (like portrait/landscape) you generally don’t want that anyway.

3

edA-qa mort-ora-y wrote:

However, if you’re building a state-driven interface with data bindings it’s likely even easier to just build a different layout and forget about sharing the controls at all. Just let the data-bindings populate a new page. This of course doesn’t allow any animation between the elements, but on major layout changes (like portrait/landscape) you generally don’t want that anyway.

Can you please drop some few lines of code that shows this example ie. switching between portrait/landscape layouts. Thanks

4

@Cjay: if you’re asking about switching between portrait/landscape in general, then we now have Responsive layout article covering the topic.

Using MultiLayout or LayoutMaster then becomes sort of a secondary concern, since that describes how the UI reacts to change.

May you have further questions, ask them in a new forum thread.