{"id":58627,"date":"2023-09-28T20:18:59","date_gmt":"2023-09-28T14:48:59","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=58627"},"modified":"2024-01-02T17:37:06","modified_gmt":"2024-01-02T12:07:06","slug":"advance-layout-techniques-in-swiftui","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/advance-layout-techniques-in-swiftui\/","title":{"rendered":"Advance Layout Techniques in\u00a0SwiftUI"},"content":{"rendered":"

SwiftUI offers a range of tools and capabilities that can truly elevate our layouts. Throughout this article, We will explore advanced layout techniques, including GeometryReader<\/strong>, preference keys, and layout priorities. <\/strong>These techniques help us to create layouts that are not only responsive and dynamic but also visually stunning in our SwiftUI applications. So, let\u2019s dive right in and unlock the full potential of SwiftUI\u2019s advanced layout capabilities.<\/p>\n

Responsive Layouts with GeometryReader<\/h2>\n


\n<\/strong>In SwiftUI, the GeometryReader view is like a container that gives us access to important information about the size and position of its parent view. This can be really helpful when we want to create layouts that work well on different devices and screen sizes.<\/p>\n

With GeometryReader, we can find out things like how much space is available and where things are located. We can use frame<\/em>, safeAreaInsets,<\/em> and size<\/em> modifiers with geometry readers. This allows us to adjust the size and position of our child’s views to fit the available space perfectly. Using GeometryReader makes it easier to create layouts that automatically adapt to different devices and orientations.<\/p>\n

This is similar to UIKit\u2019s UIScreen and UIView classes, which provide access to information about the screen size and available space. Let\u2019s understand GeometryReader with a simple example –<\/p>\n

<\/figure>\n

In ContentView, we use GeometryReader to access the available space information. It helps arrange the content in a vertical stack using VStack. Inside the VStack, we have an HStack with three Rectangle views that represent columns. Each Rectangle is sized equally using geometry.size.width \/ 3.<\/p>\n

To accommodate the safe area, we add a top padding of geometry.safeAreaInsets.top to the HStack. This ensures that the columns are positioned below any notches or status bars. We then add a Spacer to push the remaining content towards the bottom of the screen. Below the Spacer, we display the safe area insets using Text views styled appropriately. The Text views are placed in an HStack with a grey background and rounded corners.
\nBy leveraging GeometryReader and geometry.safeAreaInsets, our layout adjusts to the safe area, ensuring a consistent and user-friendly experience on different devices.<\/p>\n

Handling Data with PreferenceKeys<\/strong><\/h2>\n

SwiftUI\u2019s PreferenceKeys are an excellent way for views to communicate with their parent or ancestor views without needing complicated callbacks or delegates. They streamline communication within our view hierarchy, making it easy to create interactive and dynamic user interfaces with minimal code.<\/p>\n

In UIKit, achieving similar functionality as PreferenceKeys can be more complex, often involving delegates, notifications, or callbacks. While UIKit provides ways to pass data between views, they often require more boilerplate code and are less straightforward than SwiftUI\u2019s PreferenceKeys. The data collected using PreferenceKeys can be used for various purposes, such as adjusting layout, updating UI components, or sharing information across different parts of the app.<\/p>\n

Let\u2019s explore how PreferenceKeys work with a step-by-step code example:<\/p>\n

Let\u2019s suppose we have a list, and when we tap on an item in the list, it will navigate to the detail view. The detail view displays the selected item\u2019s name and an option that allows us to select or deselect it. When we select or deselect an item in the detail view, the background color of the selected item in the list should be updated accordingly.<\/p>\n

Create a Custom PreferenceKey<\/strong>: We start by defining a custom PreferenceKey, which acts like a data collector. In our example, it collects background color preferences.<\/p>\n

<\/figure>\n

Now, let\u2019s understand how PreferenceKey<\/strong> operates:<\/p>\n

    \n
  • defaultValue<\/strong>: This sets the initial value for the preference data. It\u2019s like the starting point for accumulating values as we move through the view hierarchy. In our case, we set it to nil as the default background color preference.<\/li>\n
  • reduce<\/strong> Method<\/strong>: The reduce method tells SwiftUI how to merge preference values when they\u2019re encountered at different levels of the view hierarchy. It has two essential parts:<\/li>\n
  • val<\/strong>ue (inout)<\/strong>: This is like the current collection of data.<\/li>\n
  • nextValue<\/strong> (closure)<\/strong>: It provides the next piece of data to add to the collection.<\/li>\n<\/ul>\n

    The reduce method gets called for each child view using\u00a0.preference<\/code>. It allows us to gather values from multiple child views and merge them into a single preference value that’s accessible to the parent view. This is where we specify how to update or replace the previous collection of data (value) with the new data (nextValue).<\/p>\n

    PreferenceKeys plays a crucial role in data flow within SwiftUI. defaultValue<\/code> sets the initial state and reduce<\/code>determines how values are combined as they travel up the view hierarchy. This mechanism efficiently manages data communication between views.<\/p>\n

    In our example code, we have three essential structs:<\/p>\n

    1. ListItemView:<\/p>\n

    <\/figure>\n
      \n
    • ListItemView<\/code> represents an item in a list.<\/li>\n
    • It displays the item\u2019s name and updates its background color based on selection.<\/li>\n
    • Tapping on an item toggles its selection state.<\/li>\n
    • The background color is determined by whether the item is in the set of selected items (selectedItems<\/code>).<\/li>\n
    • The onTapGesture<\/code> handler toggles the selection and updates the selectedItems<\/code> set.<\/li>\n<\/ul>\n

      2. ContentView:<\/p>\n

      <\/figure>\n
        \n
      • ContentView<\/code> manages the main view of the app.<\/li>\n
      • It displays a list of items that we can tap to view details.<\/li>\n
      • The selectedItems<\/code> state keeps track of which items are selected.<\/li>\n
      • It uses a NavigationView<\/code> to enable navigation between views.<\/li>\n
      • The List<\/code> displays each item as a ListItemView<\/code>.<\/li>\n
      • The\u00a0.onPreferenceChange<\/code> modifier listens for changes in the background color preference.<\/li>\n<\/ul>\n

        3. DetailView:<\/p>\n

        <\/figure>\n
          \n
        • DetailView<\/code> displays the details of a selected item.<\/li>\n
        • It shows the item\u2019s name and a button to select or deselect it.<\/li>\n
        • The button title (\u201cSelect\u201d or \u201cDeselect\u201d) changes based on whether the item is selected.<\/li>\n
        • Tapping the button updates the selectedItems<\/code> set.<\/li>\n<\/ul>\n

          In this code, we can select items in the list, and the detail view will show the selected item. The preference key is used to communicate the background color of the selected item from the detail view to the content view. This allows us to update the background color of the selected item in the list without having to pass the color explicitly.<\/p>\n

          <\/figure>\n

          As shown in the image above, initially, we selected \u201cItem 2\u201d and then clicked on \u201cItem 3\u201d to navigate to its detail page. There, we selected \u201cItem 3\u201d and then returned. In the last part of the image, we can observe that both the previously selected item and the item selected on the detail page (i.e., \u201cItem 3\u201d) are displayed as selected in the Parent View.<\/p>\n

          See, how the preference key works here:<\/p>\n

            \n
          1. The DetailView<\/code> sets the BackgroundColorPreferenceKey<\/code> preference to the background color of the selected item.<\/li>\n
          2. The ContentView<\/code> listens for changes to the BackgroundColorPreferenceKey<\/code> preference.<\/li>\n
          3. When the BackgroundColorPreferenceKey<\/code> preference changes, the ContentView<\/code> updates the background color of the selected item in the list.<\/li>\n<\/ol>\n

            We can also use the @published<\/code> protocol to communicate the background color of the selected item from the DetailView<\/code>to the ContentView<\/code> But Preference keys are a better choice for communicating data between views in most cases because they offer a number of advantages over the @published<\/code> protocol. First, preference keys are more performant, especially for large and complex views. Second, preference keys are declarative, which means that you don’t need to write any additional code to handle the data flow, and preference keys are reusable.<\/p>\n

            In summary, PreferenceKeys provides a way for child views to communicate with their parent views in SwiftUI. This is especially useful when we need to send data from a child view to its parent without passing the data explicitly through the view hierarchy. PreferenceKeys are a powerful tool for enhancing data flow between views, making our code more reusable and maintainable.<\/p>\n

            Layout Priorities<\/h2>\n

            Layout priorities help us to control how views are sized and positioned in parent containers. They become vital when space is limited, deciding which views get more or less space. let\u2019s consider this example –<\/p>\n

            <\/figure>\n

            In this example, there are four Text views with different lengths and priorities. Views get priorities using\u00a0.layoutPriority(_:) with higher values for higher priority. Default is 0, but we can modify it.<\/p>\n

            Our priorities:<\/strong><\/p>\n

            – \u201cHigh Priority View\u201d: 1 (highest)<\/p>\n

            – \u201cMedium Priority View\u201d: 0.5 (medium)<\/p>\n

            – \u201cLow Priority View\u201d: 0.1 (lowest)<\/p>\n

            – \u201cAdditional View\u201d: 0 (lowest)<\/p>\n

            Effects of Layout Priorities<\/strong>:<\/p>\n

            In spacious layouts, views show full content, and priorities have minimal impact. Limited space demonstrates their importance.<\/p>\n

            – \u201cLow Priority View\u201d shows full content first.<\/p>\n

              \n
            • \u201cAdditional View\u201d is also visible without competition.<\/li>\n
            • \u201cMedium Priority View\u201d truncates before \u201cHigh Priority View\u201d due to higher priority (0.5 vs. 1).<\/li>\n
            • \u201cHigh Priority View\u201d truncates only with extremely limited space.<\/li>\n<\/ul>\n

              Layout priorities are crucial in SwiftUI\u2019s advanced layouts. Essential content remains visible, while non-essential may get truncated or compressed. Understanding priorities enables responsive layouts for better user experiences.<\/p>\n

              In conclusion, SwiftUI\u2019s advanced layout features are the key to creating responsive and visually stunning apps. Keep coding and unlocking the full potential of SwiftUI!<\/p>\n

              <\/div>","protected":false},"excerpt":{"rendered":"

              SwiftUI offers a range of tools and capabilities that can truly elevate our layouts. Throughout this article, We will explore advanced layout techniques, including GeometryReader, preference keys, and layout priorities. These techniques help us to create layouts that are not only responsive and dynamic but also visually stunning in our SwiftUI applications. So, let\u2019s dive […]<\/p>\n","protected":false},"author":1648,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":73},"categories":[1400],"tags":[5460],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/58627"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1648"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=58627"}],"version-history":[{"count":3,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/58627\/revisions"}],"predecessor-version":[{"id":59666,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/58627\/revisions\/59666"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=58627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=58627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=58627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}