Alternative to Auto Layout?


Dave
 

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave








which is to have a look at the Root View’s size and


Steve Mills
 

On Jul 4, 2017, at 06:36, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.

So, how to lay this out without AU?
What's AU? Audio Units?

Steve via iPad


Steve Christensen <punster@...>
 

It sounds like a really easy task. Unless there is something else you haven't mentioned the basic idea is to have two views that sit side-by-side, where the ratio of widths is 1:2. If so then you end up with a view hierarchy like this:

controller_view
player_view
board_view

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

Next, make sure that player_view and board_view are both selected, click on the "add new contraints" button again and click the "equal widths" checkbox, then apply the constraint. IB should now resize the two views so that they have equal widths. You're almost there.

Finally, making sure that just player_view is selected, edit the "equal height to: board_view" contraint and change the multiplier to 2. All done.

Now the views should track the actual screen size, keeping their respective widths in proportion to 1/3 and 2/3 of the screen width.

On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave


Dave
 

On 4 Jul 2017, at 14:52, Steve Mills <sjmills@...> wrote:

On Jul 4, 2017, at 06:36, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.
There isn’t one that I can find and there’s no help available just people telling me to find a good guide! If there was a good guide I’d use it - there isn’t one! So the best thing to do is no stop using it now, before it gets too entrenched. I’ve already done this in a number of Apps, and I’ll do the same here unless anyone has anything else I could look at that does something similar.

I’d advise anyone thinking of adopting Auto Layout to not waste their time, if XCode/IB were any good you might stand a fighting chance, but as it is you are in for a hard and long battle before you realise you are better off without it.


So, how to lay this out without AU?
What's AU? Audio Units?
Apple mail, correcting AL!

All the Best
Dav


Dave
 

Hi,

As I said, the board view is working ok with Auto Layout and also the Frame of the Player View is also working, but that’s the easy bit!

I want to display the following information:

Game: 999                Round: 999

Player:  XXXXXXXXXXXXXXXX

Score: 999                  Total: 999

   Piece Picked  Piece Played
 
<16x16> <16x16>   <16x16> <16>

                    My Pieces
[H Scroll View of Pieces] (Views containing images)

               Opponents Pieces

[H Scroll View of Pieces] (Views containing images)


I’ve sort of got this working with Auto Layout but its so complex and if I want to do the slightest change or worse still add to components of left view, I have to change loads of constraints and then if you are lucky it might work, most of the time it send something else off to the wild-beyond and screws up the initial value. 

I want something I can easily change which using manual layout is easy. 

Apart from anything else, I reckon there are at least 100 constraints just to do the above, I can’t see how this can be efficient, especially as manual layout is sooooo fast.

Can anyone see anything wrong of doing it the way I proposed? e.g. Reading the Root View of the Root View Controller to find it size and then scaling accordingly?

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

I’ve not bothered with separate View Controller, I have one Game Controller, which controls both views, the reason for this is that the Game VC is a delegate of the Game Engine, and makes calls to it, in this case it needs access to both Views…...

All the Best
Dave



On 4 Jul 2017, at 17:33, Steve Christensen <punster@...> wrote:

It sounds like a really easy task. Unless there is something else you haven't mentioned the basic idea is to have two views that sit side-by-side, where the ratio of widths is 1:2. If so then you end up with a view hierarchy like this:

controller_view
player_view
board_view

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

Next, make sure that player_view and board_view are both selected, click on the "add new contraints" button again and click the "equal widths" checkbox, then apply the constraint. IB should now resize the two views so that they have equal widths. You're almost there.

Finally, making sure that just player_view is selected, edit the "equal height to: board_view" contraint and change the multiplier to 2. All done.

Now the views should track the actual screen size, keeping their respective widths in proportion to 1/3 and 2/3 of the screen width.


On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave




 


On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.

There are some alternative UI layout/rendering frameworks … I took a brief look at Texture last weekend and it looks nice, but has its own learning curve. Facebook's ComponentKit looks similar. Both are iOS only though.

(I found both of those through the Awesome iOS directory. There is an Awesome-MacOS as well, but unfortunately it’s focused more on end-user apps, not APIs.)

—Jens


 


On Jul 4, 2017, at 5:52 AM, Steve Mills <sjmills@...> wrote:

No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.

Great. Where’s that good guide? Xcode’s own documentation is so sparse as to be useless. The 3rd party books I’ve seen are massive doorstops aimed at newbies that spend 990 pages on the basics of Cocoa programming and 10 pages on stuff I don’t know about IB. They also do everything in step-by-step tutorial form, which I find nearly useless for learning from, because it shows me how to do one specific thing without explaining the principles or all the possibilities.

What I want is something akin to the best of the O’Reilly “Nutshell” books, which explain and document things clearly without too much hand-holding and without bloating the page-count with endless screenshots.

—Jens


David Young
 

On Tue, Jul 04, 2017 at 01:04:04PM -0700, Jens Alfke wrote:

On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.
Jens, Dave,

I agree that auto-layout is a bit touchy. If it's any help, I think
that under the hood it is solving a problem in "linear programming,"
https://en.wikipedia.org/wiki/Linear_programming . I have had some
modest success by writing out my inequalities explicitly, and then
fiddling with the auto-layout API and/or IB until I achieved the
layout I wanted. It's been a while, but ISTR that IB would reset my
constraints for reasons that I did not understand or appreciate.

The polygon in the "pictorial representation" of a linear program hints
at the potential power of auto-layout. You can write inequalities that
approximate a circle or other shape, and then use them to constrain an
NSView's x,y-position or height & width. That comes in handy.

Dave

--
David Young
dyoung@... Urbana, IL (217) 721-9981


Alex Zavatone
 

I’ve heard people speak well of Masonry, though I have no experience with it.

- Alex Zavatone

On Jul 4, 2017, at 4:05 PM, David Young <dyoung+cocoa@...> wrote:

On Tue, Jul 04, 2017 at 01:04:04PM -0700, Jens Alfke wrote:

On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.
Jens, Dave,

I agree that auto-layout is a bit touchy. If it's any help, I think
that under the hood it is solving a problem in "linear programming,"
https://en.wikipedia.org/wiki/Linear_programming . I have had some
modest success by writing out my inequalities explicitly, and then
fiddling with the auto-layout API and/or IB until I achieved the
layout I wanted. It's been a while, but ISTR that IB would reset my
constraints for reasons that I did not understand or appreciate.

The polygon in the "pictorial representation" of a linear program hints
at the potential power of auto-layout. You can write inequalities that
approximate a circle or other shape, and then use them to constrain an
NSView's x,y-position or height & width. That comes in handy.

Dave

--
David Young
dyoung@... Urbana, IL (217) 721-9981



 


On Jul 5, 2017, at 5:56 AM, Alex Zavatone <zav@...> wrote:

I’ve heard people speak well of Masonry, though I have no experience with it.

“Why, I wouldn’t become a Mason now if you went down on your lousy stinking knees and begged me!”
—John Cleese, “The Architect Sketch”

No seriously, I hadn’t heard of this before, but it looks very promising; thanks! Supports macOS too...
The Swift-ified version is called SnapKit:

—Jens


Andreas Mayer
 

Am 04.07.2017 um 21:37 schrieb Dave <dave@...>:

I want to display the following information:
This looks like something that can be almost completely solved just by using stack views (NSStackView, UIStackView).

May be worth a try.


- Andreas


Dave
 

I tried that, but the problem is that, you need a lot of sub-StackViews and text is spread across them, when a resize occurs, the font sizes etc. stop being uniform, e.g. The text:

Game: 123    Round: 321  

“Game" would be in one size font and “Round” another and the same for the value fields, you can solve this to some extent by tweaking properties, but what you end up with it a) Not as good as if you did it yourself, b) Hard to understand (try coming back to a UI design a couple of weeks later and trying to figure the constraints!), and c) difficult to change.

Not only that, its so slow with AL, it takes seconds on my system to switch between different screen sizes (e.g. iPhone 5 to iPhone 7+).

Anyway, I’ve stoped using AL now and am glad I did.

All the Best
Dave

On 5 Jul 2017, at 20:27, Andreas Mayer <andreas@...> wrote:


Am 04.07.2017 um 21:37 schrieb Dave <dave@...>:

I want to display the following information:

This looks like something that can be almost completely solved just by using stack views (NSStackView, UIStackView).

May be worth a try.


- Andreas