I understand the importance of Autolayout and why it is necessary. Its just driving me crazy. How it looks when you are editing the view and how it looks when you actually run the app are often quite different. Also, I nudge one thing in one direction and other controls simply disappear.
It would also be great if you could turn Autolayout off, set all your controls where you want them to appear, then click a button on, and that sets all the rules for each control relative to their current positions.
It would be very helpful the folks at Xojo create a webinar how to use this feature. Any chance of that happening? I’m just not getting the hang of this and I’m spending a lot of time with trial and mostly error.
One big tip is to never nudge anything. Just set everything up using the auto-layout controls instead of trying to resize or move things around in the view. It works much better that way even though it takes a little longer to set up.
The problem is, if I do manage to position the controls in the design of the View - iPad Landscape which is the only orientation I’m offering, the controls are all in different spots. What you see when you design the view is not what you get when the app runs in the simulator.w
The IDE is simulating whats going to happen at runtime
Since we can’ use iOS runtime version of Autolayout IN the IDE thats the best we can do - and there are aspects of that that differ
As everyone else has said, if you hang in there and mess around with it, it starts making more sense. I’m starting to get somewhere now. It just seems that there should be an easier way to create the layout. I still vision being able to simply layout the view in the traditional way, then click a button and have all the rules for the relative positions of the controls automatically set.
Then the controls would adjust like Michel’s RubberView. I know its easy for me to say that and another thing to pull off, but I think there can be a better way of doing this. In Live Code, which I did not like at all, you would create a layout in Portrait and then switch to Landscape and move the controls around and they would remember their positions. That was cool, but it did not work perfectly all the time, and had its own share of problems.
[quote]Oddly enough as we were implementing all this in the IDE thats basically what apple switched to in Xcode
I think there’s an FR for exactly this[/quote]
Sorry, whats a FR? Did Apple adopt your method or a method like one I describe above.
I don’t mind the way it works now, I just feel like it always takes me too long to click on all of the popups and bevel buttons to setup each constraint. Would be really cool if there was some sort of way to type in the auto layout constraints with autocomplete, but I can’t see that happening.
Maybe even responding to key down events (such as enter to edit the selected constraint and enter to select “Done” when finished).
In the end though it all saves us some time from having to code in layouts (besides the basic locking ones) in the resized events.
I would not say never
Have a look at Apple’s version of the ASCII art way of defining a constraint
Being able to use that in the IDE OR at runtime would be really nice and is plausible - not immediately - but certainly plausible
Another would be to make the constraints visible on the layout so you can click them & edit them directly
I still think auto-layout should be able to be turned off. If I want to design different views based on the orientation and device, I would like to be able to accomplish this without auto-layout getting in the way. I would hate to try to design a window for a desktop app that has a hundred or so controls with this tool. I would stop using the product.
I think the goal should be that all these constraints using auto-layout be implemented under-the-hood. The user can layout their view by hand (the old fashion way), click a button and the constraints of auto-layout are created for you behind the scenes based on the positions of the controls as they are at the time. Its a snapshot. If you want to make changes, turn off auto-layout, move your controls around, and hit the button again to make a new snap shot. That would certainly bring the RAD back into the development process.
Maybe I’m just not getting the real gist of how auto-layout should be implemented, thus my original request to see if a webinar could be put together the show how it really should be used. To me, having to change each constraint of each control in relation to other controls and the container they are in, kind-of takes the auto out of auto-layout.
Christian’s Elastic Window and Michel’s RubberView tools allow the user to layout their window and then depending on the screen resolution, be able to adjust the control sizes and positions relative to each other automatically. For the most part, with a few exceptions this works really well. Creating a tool that accomplishes the same thing in iOS would be very helpful.
It’s more complicated than that and there’s no way for it to magically know what you want to have happen when a view is resized or the orientation changes.
The whole point of auto layout is that you can control all of that without any code. Xojo would be able to guess what you’re trying to do (which it already does) but if everything was under the hood and you couldn’t modify the constraints manually then auto layout would be almost useless.
The other aspect of auto layout is that it should future proof your app for new devices. If you had to design a view for every size/position (which already with iPhone 4-6+ and the various iPad is way too much work), it would break immediately on a new device that you hadn’t prepared for.
I must point out that both Elastic Window and RubberViews are technically not auto layout, or not in the complete sense. If I was to borrow terminology from Android, they are providing Auto Scale. It is a terrific tool for Desktop, where display is very seldom changing aspect ratio (always landscape). However, it could lead to very odd results when the screen rotates, as happens on mobile devices.
iOS Auto Layout is not as evil as one may think. In fact, I used the very same features as a basis for RubberViewsWE auto layout. I think the issue is more with the layout editor, which assumes things and modifies constraints in a way that is not quite obvious to a newcomer to that technology. In Desktop and Web, one always relies on Left, Top, Width and Height. So is the case with RubberViews. In the iOS layout editor, Xojo tried to maintain that for the first control , and one can see that placing a button on a view creates pretty much the same : Left, Top, Width, Height. Sometimes relative to the center of the view, but that is not too difficult. Where it becomes devilish is when other controls are added. That is when the layout editor starts guessing about the relationship between controls, and it can be really strange.
I wonder if it would not be possible to turn off all that guessing in the layout editor, so in effect constraints would remain relative to the view. That would equate pretty much to what you wish as “turning off” auto layout.
I did look into the possibility to provide Auto Scale in iOS. Unfortunately, since constraints need naming to be addressed in code, it does not seem doable. If ever Xojo was to provide an easy way to access constraints without the need to name them, it would be great, though, since code could tweak the response of Auto Layout and permit quantities of things very cumbersome today.