OK, so I’m beginning to slowly get my head around auto-layout and creating constraints and all. I get how you can position controls relative to other controls, etc. Here’s one I have not figured out…
So let’s say I am dynamically creating some controls. Let’s say I want to create a number of buttons in a view. Now, an iPhone 6+ can contain more buttons of a given size across it’s width than an iPhone 6 which can contain more buttons across its width than an iPhone 5, etc.
How do you set a layout constraint for that? So let’s say I want to create 8 buttons. On a 6+ I want to have 4 columns of buttons (2 rows), on a 6 I want to have 3 columns (3 rows) and on a 5, I want to have two columns (4 rows).
Can this be done in a constraint formula or do I need a bunch of if/then/else statements where I set the constraints individually depending on the width of the view (which would seem to defeat the putpodr of auto-layout).
my understanding of AL (and I will admit I stopped trying to wrap my head around it), is that for the most part its main purpose is to alter the size of controls so that the layout is relative and proportional to the device it is displayed on.
If you want DIFFERENT layouts on each device (like on a 4s you might need 2 views to show what the 6 can do in one view), then you are entering a whole nother realm.
Also… to the best of my knowledge… AL doesn’t deal with FONTSIZE at all… other than assigning a too big size, and setting the AUTOFIT parameter … but then YOU still are relying on iOS to choose a size, which may or may not be precisely what you want.
IN AL you specify the layout basically from “left to right top to bottom” (not strictly true* but lets just pretend thats the way it mostly is)
This really doesn’t have a means to move controls based on available space, or based on the side of the device
Thats NOT the intent at all and you would need to write different constraints for that
The animations you see when on the home screen and you rotate a device ARE AL constraints being altered live & animated.
On my ipad mini this takes a portrait display that is 5 rows of 4 icons and when I rotate to landscape live animates and rotates it 4 rows of 5 icons
You can do that - name the constraints & on rotation remove the portrait ones & set up landscape constraints that fit the new size & orientation an vice versa
AL doesn’t normal scale fonts up because that usually doesn’t give you a nice rendition of them and just does a poor scaling job
And it just scales the UI rather than making the UI adapt better to having more space so it can show more information
the reason I say this is NOT strictly true is that AL handles left to right & right to left in a very elegant manner
instead of using “left” - which always means “left” if you use “leading” then on a left to right system that means “left” but on a right to left system it means “right”
Thanks, Norman and Dave. That’s what I was looking for.
I was really hoping that AL could adjust control placement based on the size of the device being used. It sounds like it should but it doesn’t. To me, that’s true “auto” layout - I can use one bit of code that will lay my controls out based on the size of the screen. So auto-layout really is not fully “auto.”
It’s really OK as I’ve written code to do what I want to do already. My web app does this - if you change the size of the browser window it moves controls around to fit in the most efficient manner. Given all the headaches involved with AL, I would have figured it would do this.
Most of my controls are dynamically created as it is. So for the last 5 years, I’ve been doing my own “auto-layout” spacing things out when creating controls, etc. The “old” way of doing things worked fine for me.
Auto Layout does not necessarily change the size of controls. Good old Width and Height are still here, so it is perfectly possible to have fixed size controls relative by their XCenter and YCenter so they nicely spread over the view without growing.
Indeed Auto Layout as it stands today does not address content size, would that be pictures or fonts. In VB there is the notion of Autosize, where a control grows relative to text. Autofit would be font size changing so text never get cut ? Between the two, it may be difficult to choose.
Anyway, neither exist at this time in Xojo iOS. At least for fonts. ImageView does have what I would call AutoFit for pictures.
When implementing text autofit in RubberViews for Desktop, I had to add constraints so text size does not outgrow the control.
In RubberViewsWE for Xojo Web, I quickly found out that text autofit is not always necessary, as users actually do not expect text size to grow with control size, at least to a certain extent, until text becomes too small or too big.