In short, there are various ways to work with breakpoint containers to adjust your content based on the size.
A single breakpoint as the overall container for your view would be best if you only need two different sizes, like switching between desktop and mobile.
Nested breakpoints, each with individual content, can be used to get more granularity, but will increase the complexity.
On the contrary, using nested breakpoint containers to determine a single overall size, then passing that size to a single embedded view for the content, will decrease reduce that complexity.
Using the repeating breakpoint container method described below adds all the granularity you want, while keeping the end result as a single size, but is a more complex system to understand and maintain.
We are using all of the methods above throughout the demo project. Some of the industry specific projects are using the more complex system of repeating breakpoint containers. You can achieve similar results using nested breakpoint containers, which will require little to no coding, but will require a bit more organization on your project with all of the embedded containers. The usage of the _bp template and size strings is just a way to automate breakpoint selection and return a single value for the overall screen size. The automatic way requires more coding, but simplifies the content views as they only need to care about a single size value. It also allows for a single source for your breakpoints, so you can fine tune them from one spot.
The way that system works is by using a flex repeater that embeds the _bp template view. This _bp view is simply an invisible breakpoint container that has an output parameter sent back based on whether it is small or large. The view is given a breakpoint value and name as a parameter. The flex repeater can then be programmed with a list of desired breakpoints, and each instance’s ‘set’ value will reflect whether or not it is currently small or large. From there, you can bind to those values to determine how large your screen is. In the various areas of the demo that use this technique, we are using a single binding to find the maximum breakpoint that is set, returning a single value for the current size. And that size can then be used wherever needed. I would recommend using this technique if the process makes sense to you and would actually improve your specific project. Once in place, it does simplify things as you only need to adjust the _bp instances to adjust your breakpoints. However, it does add complexity to the project and will be another area to maintain. I definitely would not recommend it if you do not need that level of granularity.
The breakpoint container itself is quite simple, but there are different ways we can use it to get different results, and some ways of using it are more efficient solutions for different scenarios. This could be using them in individual areas of a given view, which would give you specific control over individual elements. Or they could be used as the main content container, with embedded containers that get swapped out to adapt the content based on the size. Another method, shown in the demo project, is how we set up the main Header. We have one view that holds the actual content of the header, with a parameter for the view size. Using some nested breakpoint containers with different sizes, we can determine the correct overall size for the final embedded header view. In that way you achieve an end result that is similar to the automated _bp system, but with less complexity.
Overall, I would say that there isn’t going to be a single solution that you should use for all projects, but more of a set of solutions that you should select from for each part of your project.