Date
1 - 12 of 12
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: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:
toggle quoted message
Show quoted text
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: |
|
Dave
On 4 Jul 2017, at 14:52, Steve Mills <sjmills@...> wrote: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.On Jul 4, 2017, at 06:36, Dave <dave@...> 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. 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. Apple mail, correcting AL!So, how to lay this out without AU?What's AU? Audio Units? 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
|
|
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 |
|
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:
Jens, Dave,On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote: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. 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.
toggle quoted message
Show quoted text
- Alex Zavatone On Jul 4, 2017, at 4:05 PM, David Young <dyoung+cocoa@...> wrote: |
|
“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@...>: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@...>: |
|