Dave,
I’m not sure what it is you need in terms of “more documentation”.
I’m more than happy to expound on whats there is you can give me some idea of what it is you’re looking for.
I appreciate you attempting to help…
But what I cannot fathom is what all the items in XOJO’s Autolayout dialog mean, and how they relate to each other, and to the final layout of controls on a given device.
Xojos approach seems to be “similar” to what I have seen other websites attempt to explain as the “programmatic” way of applying Autolayout rules… But again, they (and trust me I have a headache from reading many of them), don’t clearly explain the interaction of each property. Xcode only (via IB) seems to support either “springs and struts” or “autolayout”, and with autolayout to me its a freaky bowl of spagethi (orange and blue lines, no way to delete contrainsts). And while I can usually learn alot by “playing in the sandbox”, this isn’t a subject that lends itself to that learning method.
Here is what I percieve as the differnce between Xojo and Xcode…
XOJO - Equal, Min, Max Xcode =,>=,<= Ok, that comparison makes sense
XOJO - Edge : Left,Right, Top etc Xcode pretty much the same
XOJO - Width/Height not sure, Xcode - a hard value [you say can be flexible, don’t know how [yet] )
XOJO - Scale - Xcode - only seen this in “programmatic rules”, no in IB (not saying its not there)
XOJO - Offset - seems to be same [just wonder what ‘Standard Gap’ really means
XOJO - Priority - assume Low=250, High=750, Required=1000, Manual is users choice, Auto ???
This all looks like it becomes some huge simultaneous equation, with no distinct starting point, and too many ways to either leave something out, or create a conflict, or a recursion (align top of A with bottom of B, but align bottom of B with Top of A and both are “required”)
I don’t see what would be so difficult about laying out documentation that addressed each element in the Autolayout Dialog, what it meant, how it related to a View or other control, how it might create a conflict, how to visualize the results, and simple examples as well as complex examples… “to achieve xyz result” you need to do this, and why…
Perhaps my brain just cannot comprehend a concept as abstract as this… I understand why it is needed…
You can just add a Height or Width constraint that is a fixed value
Xcode calls this “Multiplier” when you edit a constraint
Standard gap for the given version (of iOS at this moment)
Right - Xcode makes you set them but has some values that it likes to snap its slider to
[quote=158191:@Dave S]This all looks like it becomes some huge simultaneous equation, with no distinct starting point, and too many ways to either leave something out, or create a conflict, or a recursion (align top of A with bottom of B, but align bottom of B with Top of A and both are “required”)
[/quote]
It is an entire system of linear equations
Manifold answers to this
- not sure WHAT to write and “write everything” is not viable
- what needs to be illustrated will vary depending on your project requirements
[quote=158191:@Dave S]
Perhaps my brain just cannot comprehend a concept as abstract as this… I understand why it is needed…[/quote]
Oh I’m sure it can since I’d put money on it you’ve actually written code to move things around in a layout or resize things in a layout as it resizes.
Thats roughly what you get from specifying the constraints - they’re relative positioning rules.
Yeah my first iOS project (written in Swift and not yet submitted to MAS) is a complex calculator (think OSX calculator on steroids) and it has code that detects what device (it is portrait only) and creates and moves all the buttons (setting sizes and fonts etc) based on which device. What it does do that I don’t think Autolayout can do (or if it can it would be a trick), is that in any given calculator mode, on the iPhone4s you have a different set of keys (with a shift key to get the rest), where on all other devices there is enough room to lay them all out.
FYI… my app has no XIB or storyboards… 100% code… it was a learning experience …
And to be honest…one thing I am trying to learn is how Autolayout works, so I can write code to implement the rules, as I dislike Interface builder with a passion.
yeah you could actually remove & show a key with autolayout
writing all the code to do what autolayout already does is … well … slightly masochistic
you should just watch the WWDC videos
from https://developer.apple.com/videos/wwdc/2011/
session 103 - Cocoa Autolayout
from https://developer.apple.com/videos/wwdc/2012/
session 232 - Auto Layout by Example
session 202 - introduction to autolayout for iOS and OS X
session 228 - Best Practices for Mastering Auto Layout
And quite honestly there are things that autolayout will make possible that you just wont want to write code for (or simply wont be able to get right without making a pile of compromises)
Like left to right and right to left systems
Automatically handling resizing controls when the language changes (makes internationalization way easier)
Watching these videos etc will tell you a bunch about the front end of how things work
Back end you can start with http://constraints.cs.washington.edu/cassowary/
And everything else is layered on top of that
That seems more of a task for views, one for each mode, than for Auto Layout.
Greg alluded to Auto Layout being able to resize labels according to content but did not explain how that could be obtained. There is no mention of relative to content in the auto layout inspector. Is it implemented yet ? How ?
I know how to do it in code, but if Auto Layout can automate it, that would be great indeed.
How about putting together some real world examples, with at least 4 controls.
Show how scale, priority, equal, min, max effect the outcome.
I realize this would be a big job, but it would be a big help.
Dave has your understanding grown?
In regards to AutoLayout… I keep seeing this sign above the door
And have designed my own method for dealing with the requirements of multiple devices, that works well for me so far.
Please elaborate…
This is exactly where I’ve gone. Autolayout was too “unpredictable” for me.
As far as I know, Dave is using Swift for iOS development, so he has the luxury not to use Auto Layout, or to create his own methods.
In Xojo iOS, Auto Layout is mandatory. It is not as difficult as it seems, though.
First, you can perfectly set each constraint in absolute values, as you would in Desktop. Then it works exactly the same. Won’t be very pretty when the device rotate, but it may be easier for a start.
Then, I tried to summarize a basic example in the thread you started at
https://forum.xojo.com/18846-autolayout-more-documentation
I do think Auto Layout is a fantastic tool. But coming from manual layout or the crude (sorry) locking mechanism of Desktop, it can feel a bit like Modern Mathematics coming from algebra.
While Auto Layout can do remarkable things, it can become labyrinthine when it comes to shuffling controls around to obtain the best layout possible in Portrait and Landscape without staying with a basic autoscale.
It may be a lot easier to switch views in Resized when the layouts are too different.
IMHO though, Auto Layout is paramount to alleviate the screen resolution fragmentation. It would be foolish to have a set of views per device, when you go for instance from 414 x 736 on an iPhone 4 up to 1920 x 1080 on an iPhone 6 plus. Not mentioning not yet released phones and tablets with new resolutions.
For anybody interested in native iOS auto-layout, one of the lectures of Developing iOS 8 Apps with Swift is about it. Helped me a lot to understand what the concept of auto-layout really is and what it is not.