Great news everyone! Responsive layout system progressed very nicely and is pretty different now from object-based draft I showcased above. First, to remind you what responsive layouts are, simple illustration:
There were two biggest issues with the previous implementation:
- You had to set up the objects in one centralized and unintuitive custom inspector that was disconnected from real UI hierarchy, which is far cry from intuitive and fast anchoring editor every NGUI widget offers you on selection of particular widget within the hierarchy.
- The implementation used simple enabling/disabling of GameObjects, and you really don't want to deal with that most of the time: imagine having half a dozen of functionally identical data-driven scroll lists instead of one, it's awful.
Both of those issues are out and workflow is much more straightforward now. First, you set up desired resolution brackets. For example, maybe you want to have one layout for screens of below 480dp width, another layout for screens between 480dp and 640dp width, and another layout for screens wider than 640dp. Easy! Just set up your intervals with this neat array in the screen manager (featuring auto-configured clamping to nearest neighbors with fancy sliders and warnings):
Second, add a new component to any UI widget you want to be density dependent. Depending on amount of resolution intervals set up in your screen manager, that component will store appropriate amount of anchoring configurations. The component is not attempting to replace the perfect anchoring editor from NGUI - you still use the familiar controls, except you can save your configuration to one of the resolution brackets. Set up your anchoring for a narrow screen, click the copy button on narrow configuration, set up your anchoring for a wide screen, click the copy button on widescreen configuration. Done.
The screen manager maintains a list of resolution-based anchor components and swaps anchoring configuration to appropriate one depending on detected resolution, giving you results
like this while keeping your data-driven UI free from pesky duplicates or other inconveniences. There is no need to set up dozens of resolution-based anchoring configurations either - in some applications, the whole design can be hierarchically anchored to just one widget, necessitating just one collection of configurations on that topmost widget.
Aside from this goodness, I worked on some other stuff like refactoring and new view presenters. One of the new object types is the dropdown menu. While still work in progress, it's already looking quite good:
- It's using just one label for all the options: no separate labels/colliders/delegates, which conveniently prevents hierarchy clutter and instantiation costs on option list length changes. I get the selection from local touch position.
- As usual, everything is animated through a simple evaluation: one tweening method with 0-1 float argument does all the magic with sliding offsets, sheets, shadows, spacing, colors, etc. No dozens of tweener instances, no Unity animations, clean and fast.
- It expands from the list position of a selected value, just like guidelines dictate. Tricky to combine with this animation, but as you can see, it works.
