Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Data Graham: Dec 28, 2009; 📈📊🍪😋

Yeah, I already had the table view pinned to the containing view; didn't seem to affect it. Neither did any combination of the compression/hugging values.

I think I've got it working though, more or less. I resorted to frame hacking with hard-coded values in the viewDidLayoutSubviews, and it's ugly and does a lot of interim flashing and repainting, but at least it eventually gets to the right layout.

Thanks.

# ? Jun 10, 2016 04:42

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 14:57

stuffed crust punk: Oct 8, 2004; by LITERALLY AN ADMIN

I feel like I've had the good fortune of not having to build very complex UIs... Is there a resource that clearly explains hugging/compression values and their effects?

# ? Jun 10, 2016 05:22

Doc Block: Apr 15, 2003; Fun Shoe

Data Graham posted:

Yeah, I already had the table view pinned to the containing view; didn't seem to affect it. Neither did any combination of the compression/hugging values.

I think I've got it working though, more or less. I resorted to frame hacking with hard-coded values in the viewDidLayoutSubviews, and it's ugly and does a lot of interim flashing and repainting, but at least it eventually gets to the right layout.

Thanks.

I found a way that, while it requires some code, is only a few lines and still has you layout out your UI and constraints in Interface Builder:

1)Set up everything like before, with the table view bottom pinned to the container view, etc.
2)Add a property to your view controller: @property (nonatomic, strong) IBOutlet NSLayoutConstraint *tableViewHeight;
3)Create a height constraint on the table view in Interface Builder. Then, CTRL-drag from the view controller to the table view's height constraint and set it.
4)In your view controller, create the -viewDidLayoutSubviews method:

Objective-C code:

- (void)viewDidLayoutSubviews
{
	self.tableViewHeight.constant = MIN(self.view.bounds.size.height, self.tableView.contentSize.height);
	[self.view layoutIfNeeded];
}

Which gives:

The table view is blue.
The table view's footer is red.
The table view's container view is puke colored.

The table view size is correctly set based on the number of rows and the size of the footer view (which is set as the table view's tableFooterView property), and the container view will grow/shrink based on the size of the table view.

Doc Block fucked around with this message at 06:33 on Jun 10, 2016

# ? Jun 10, 2016 06:28

Small White Dragon: Nov 23, 2007; No relation.

I've seen the code to offer a "preview" of a controller with 3d touch, but is an API (or 3rd party component) to do a 3d touch context menu like on the home screen?

# ? Jun 10, 2016 07:45

Data Graham: Dec 28, 2009; 📈📊🍪😋

Doc Block posted:

I found a way that, while it requires some code, is only a few lines and still has you layout out your UI and constraints in Interface Builder:

1)Set up everything like before, with the table view bottom pinned to the container view, etc.
2)Add a property to your view controller: @property (nonatomic, strong) IBOutlet NSLayoutConstraint *tableViewHeight;
3)Create a height constraint on the table view in Interface Builder. Then, CTRL-drag from the view controller to the table view's height constraint and set it.
4)In your view controller, create the -viewDidLayoutSubviews method:
Objective-C code:
- (void)viewDidLayoutSubviews
{
	self.tableViewHeight.constant = MIN(self.view.bounds.size.height, self.tableView.contentSize.height);
	[self.view layoutIfNeeded];
}
Which gives:

The table view is blue.
The table view's footer is red.
The table view's container view is puke colored.

The table view size is correctly set based on the number of rows and the size of the footer view (which is set as the table view's tableFooterView property), and the container view will grow/shrink based on the size of the table view.

Okay, cool... tried that, but it doesn't seem to have any effect on the container view.

Are you sure the viewDidLayoutSubviews code there is supposed to be operating on self.view.bounds.size.height ? Isn't that the height of the overall view controller? Or are you saying I need to have a separate view controller for the container view too?

E: My table has been auto-sizing correctly, just by having constraints on it apparently. It seems to me like the thing to do would be to set the height constraint on the container view (instead of the table view), and then set its height programmatically in viewDidLayoutSubviews? That's the thing I'm having trouble making pay attention to me.

E2: Hey! that worked! :parrot:

I still have to add a hard-coded padding value, but that's no big.

Thanks for the steer in the right direction!

E3: Actually let me clarify: my table view is resizing itself now because earlier I subclassed UITableView and I have this in its viewDidLayoutSubviews:

code:

-(void)layoutSubviews {
    [super layoutSubviews];
    
    CGRect selfTableFrame = self.frame;
    
    selfTableFrame.size.height = self.contentSize.height;
    dispatch_async(dispatch_get_main_queue(), ^{
        [self setFrame:selfTableFrame];
    });

I imagine I should be able to do all this in one step without subclassing the table view, but I'm-a commit this first

Data Graham fucked around with this message at 14:26 on Jun 10, 2016

# ? Jun 10, 2016 14:04

Doh004: Apr 22, 2007; Mmmmm Donuts...

Regular Nintendo posted:

I feel like I've had the good fortune of not having to build very complex UIs... Is there a resource that clearly explains hugging/compression values and their effects?

I've been doing this for 4 years now and I still barely understand hugging/compression. :ohdear:

Small White Dragon posted:

I've seen the code to offer a "preview" of a controller with 3d touch, but is an API (or 3rd party component) to do a 3d touch context menu like on the home screen?

I haven't done it yet, but this tutorial worked for me when implementing it within our application:

http://code.tutsplus.com/tutorials/ios-9-an-introduction-to-3d-touch--cms-25115

Check out section 4, but from a quick glance:

- You can specify static shortcut items in your Info.plist
- You can dynamically create shortcut items
- You handle the shortcuts in your app delegate in

code:

func application(application: UIApplication, performActionForShortcutItem shortcutItem: UIApplicationShortcutItem, completionHandler: (Bool) -> Void)

# ? Jun 10, 2016 14:35

brap: Aug 23, 2004; Grimey Drawer

Sometimes I can see why people go with react native and flexbox because auto layout can be so drat complicated and not oriented around solving problems developers actually have.

# ? Jun 10, 2016 16:09

Doctor w-rw-rw-: Jun 24, 2008

Doh004 posted:

I've been doing this for 4 years now and I still barely understand hugging/compression.

Gee, if this doesn't make the case against autolayout I don't know what does. No amount of magic justifies the kind of confusion that persists so long in decent engineers.

CGRect math functions (and layout spec objects in complex cases) in layoutSubviews for life. :getin:

(or Components if you don't really need the animations)

# ? Jun 10, 2016 16:13

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

fleshweasel posted:

Sometimes I can see why people go with react native and flexbox because auto layout can be so drat complicated and not oriented around solving problems developers actually have.

I have used worse. At least autolayout doesn't force you to use hierarchical layouts, like "classic" layout engines

# ? Jun 10, 2016 16:26

Doc Block: Apr 15, 2003; Fun Shoe

Data Graham posted:

Okay, cool... tried that, but it doesn't seem to have any effect on the container view.

Are you sure the viewDidLayoutSubviews code there is supposed to be operating on self.view.bounds.size.height ? Isn't that the height of the overall view controller? Or are you saying I need to have a separate view controller for the container view too?

The MIN(self.view.bounds.size.height, self.tableView.contentSize.height); part chooses whichever is smaller: the height of the whole view or the height of the table view's content. This way the table view can't grow bigger than the screen. You can replace it with just self.tableView.contentSize.height if you're confident that can't happen.

quote:

E: My table has been auto-sizing correctly, just by having constraints on it apparently. It seems to me like the thing to do would be to set the height constraint on the container view (instead of the table view), and then set its height programmatically in viewDidLayoutSubviews? That's the thing I'm having trouble making pay attention to me.

E2: Hey! that worked! I still have to add a hard-coded padding value, but that's no big.

Thanks for the steer in the right direction!

The way my example project works is that the bottom of the table view is pinned to a fixed distance from the bottom of its container view, not the other way around. Give them both low vertical compression resistance and set the vertical content hugging to be higher for both of them.

I should mention that the I have the vertical content hugging priority set to 750 for both, and the vertical compression resistance set to (IIRC) 249.

The manual height constraint whose value we're supplying in code will make the table view height match its content. Because the bottom of it is pinned to the container view with a set distance, and because the default priority for that constraint is 1000 (which is greater than the container and the table view content hugging priority), that will basically let the table view dictate the height of its container view. Because the container view's autolayout priorities will try to shrink it to match its content size (the table view), but the distance you set in the table view's bottom edge constraint will have a higher priority and won't let the container shrink past that distance (and make it grow to accommodate the distance if need be).

Seems counterintuitive at first, but makes sense once you understand what's going on.

quote:

E3: Actually let me clarify: my table view is resizing itself now because earlier I subclassed UITableView and I have this in its viewDidLayoutSubviews:
code:
-(void)layoutSubviews {
    [super layoutSubviews];
    
    CGRect selfTableFrame = self.frame;
    
    selfTableFrame.size.height = self.contentSize.height;
    dispatch_async(dispatch_get_main_queue(), ^{
        [self setFrame:selfTableFrame];
    });
I imagine I should be able to do all this in one step without subclassing the table view, but I'm-a commit this first

You don't have to subclass UITableView for this to work.

Also, you don't need the call to dispatch_async(), since the layout calls will always happen on the main queue.

Here is a link to the project that I made so you can see the exact details of how it's all connected, what the exact priority values are, etc

Doc Block fucked around with this message at 16:39 on Jun 10, 2016

# ? Jun 10, 2016 16:32

Doc Block: Apr 15, 2003; Fun Shoe

IMHO the majority of the time autolayout is relatively easy to use and understand. Especially if you don't have to specify constraints in code.

Once Apple fixed Interface Builder to allow constraints to be temporarily invalid or ambiguous, and had it generate fixed constraints to match your IB layout for the stuff you didn't manually put constraints on, I stopped having a reason not to use it.

# ? Jun 10, 2016 16:48

stuffed crust punk: Oct 8, 2004; by LITERALLY AN ADMIN

Yeah it took a while but autolayout is ok by me. Though building uis is much easier than changing them, its possible to have a house of cards collapse if you remove a view

# ? Jun 10, 2016 17:09

Data Graham: Dec 28, 2009; 📈📊🍪😋

Aaagh

I'm trying to follow your example but Xcode has decided that I can't drag from the constraint's context menu to the view controller to create outlets anymore. No hotspot pops up when I hover over the view controller in the object list.

If I break an outlet I had set earler, I can't reconnect it.

I've restarted Xcode, and tried other IB types and they all work fine; it's just constraints that no longer seem to be hookup-able

E: Never mind, I tried creating the outlet from the other direction and it worked, and then the original direction worked again

Data Graham fucked around with this message at 17:29 on Jun 10, 2016

# ? Jun 10, 2016 17:25

Data Graham: Dec 28, 2009; 📈📊🍪😋

Gaaah! That's what it was. My container view had a height constraint on it.

An hour of staring at the two projects side by side and something like that somehow becomes invisible... ugh.

Thanks again.

# ? Jun 10, 2016 17:57

Doc Block: Apr 15, 2003; Fun Shoe

No problem! Glad it's working for you.

# ? Jun 10, 2016 18:06

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Regular Nintendo posted:

Yeah it took a while but autolayout is ok by me. Though building uis is much easier than changing them, its possible to have a house of cards collapse if you remove a view

Yeah, same with me, although I still have issues come up that frustrate me because I don't know how to deal with them and the solutions are less than elegant (see: my bitching about invisible views being used to space content equally, when ideally you could set two vertical separations to equal height just as you can with the height of two different views). I really hated it at first, but now that I've adjusted to it, I quite like a lot of its features.

If anything, I'd say it's an issue of poor instructional materials. Apple is pretty good in general, but AutoLayout is so complex (and each problem uses such a specific subset of its features) that it would lend itself much better to a "cookbook" style of instructional material rather than an ordered tutorial or comprehensive reference.

# ? Jun 10, 2016 18:13

Data Graham: Dec 28, 2009; 📈📊🍪😋

One thing I'll definitely say is that after these last couple of days I've gone from "Autolayout? That's that thing that throws weird errors when I try to run it, just keep hitting Clear Constraints and Add Missing Constraints until it stops nagging you" to "Ah, so that's what each of these constraint types are for and how you apply them and which ones are important and will interfere with one another". It does make sense once you get past that hump.

It's still kind of tedious and awkward to use, but it seems like it has most if not all of the expressiveness of CSS, with a few things that are even more powerful and less opaque (like being able to select neighboring elements to position against).

But yes, it's not what I'd call "discoverable". And Apple's docs tend to be about explaining what exactly everything is rather than how you would use it for common tasks.

# ? Jun 10, 2016 18:45

geera: May 20, 2003

Some reading I've done about AutoLayout in the past suggested just using UIStackViews everywhere instead. I'm only a hobbyist developer, so how practical is that advice, really?

# ? Jun 10, 2016 19:14

Doc Block: Apr 15, 2003; Fun Shoe

I've not used UIStackView myself yet, but it seems pretty great.

# ? Jun 10, 2016 19:43

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

geera posted:

Some reading I've done about AutoLayout in the past suggested just using UIStackViews everywhere instead. I'm only a hobbyist developer, so how practical is that advice, really?

UIStackView is a handy container that just uses auto layout internally. It has its uses but doesn't replace general use of constraints.

# ? Jun 10, 2016 19:50

Vesi: Jan 12, 2005; pikachu looking at?

I don't like IB so I've just been using PureLayout, works great if you prefer to add views programmatically

If this makes intuitively sense to you then you might like it:

code:

        uidLabel.autoPinEdge(ALEdge.Left, toEdge:ALEdge.Left, ofView:self.view, withOffset:48)
        uidLabel.autoPinEdge(ALEdge.Right, toEdge:ALEdge.Right, ofView:self.view, withOffset:-48)
        uidLabel.autoPinToTopLayoutGuideOfViewController(self, withInset:18)
        uidLabel.autoSetDimension(ALDimension.Height, toSize:48)

        passwordLabel.autoPinEdge(ALEdge.Left, toEdge:ALEdge.Left, ofView:self.view, withOffset:48)
        passwordLabel.autoPinEdge(ALEdge.Right, toEdge:ALEdge.Right, ofView:self.view, withOffset:-48)
        passwordLabel.autoPinEdge(ALEdge.Top, toEdge:ALEdge.Bottom, ofView:uidLabel, withOffset:18)
        passwordLabel.autoSetDimension(ALDimension.Height, toSize:48)

        domainLabel.autoPinEdge(ALEdge.Left, toEdge: ALEdge.Left, ofView: self.view, withOffset: 48)
        domainLabel.autoPinEdge(ALEdge.Right, toEdge: ALEdge.Right, ofView: self.view, withOffset: -48)
        domainLabel.autoPinEdge(ALEdge.Top, toEdge: ALEdge.Bottom, ofView: passwordLabel, withOffset: 18)
        domainLabel.autoSetDimension(ALDimension.Height, toSize: 48)

        userImage.autoPinEdge(ALEdge.Right, toEdge: ALEdge.Left, ofView: uidLabel, withOffset: -10)
        userImage.autoAlignAxis(ALAxis.Horizontal, toSameAxisOfView: uidLabel)

        passwordImage.autoPinEdge(ALEdge.Right, toEdge: ALEdge.Left, ofView: passwordLabel, withOffset: -10)
        passwordImage.autoAlignAxis(ALAxis.Horizontal, toSameAxisOfView: passwordLabel)

        domainImage.autoPinEdge(ALEdge.Right, toEdge: ALEdge.Left, ofView: domainLabel, withOffset: -10)
        domainImage.autoAlignAxis(ALAxis.Horizontal, toSameAxisOfView: domainLabel)

        submitButton.autoSetDimension(.Height, toSize: 48)
        submitButton.autoSetDimension(.Width, toSize: 128)
        submitButton.autoAlignAxis(ALAxis.Vertical, toSameAxisOfView: domainLabel)
        submitButton.autoPinEdge(ALEdge.Top, toEdge: ALEdge.Bottom, ofView: domainLabel, withOffset: 18)

        errorLabel.autoAlignAxis(.Vertical, toSameAxisOfView: submitButton)
        errorLabel.autoPinEdge(.Top, toEdge: .Bottom, ofView: submitButton, withOffset: 18)
        errorLabel.autoSetDimension(.Height, toSize: 48)
        errorLabel.autoSetDimension(.Width, toSize: 300)

Vesi fucked around with this message at 20:23 on Jun 10, 2016

# ? Jun 10, 2016 20:19

Small White Dragon: Nov 23, 2007; No relation.

Doh004 posted:

I haven't done it yet, but this tutorial worked for me when implementing it within our application:

http://code.tutsplus.com/tutorials/ios-9-an-introduction-to-3d-touch--cms-25115

Check out section 4, but from a quick glance:

- You can specify static shortcut items in your Info.plist
- You can dynamically create shortcut items
- You handle the shortcuts in your app delegate in
code:
func application(application: UIApplication, performActionForShortcutItem shortcutItem: UIApplicationShortcutItem, completionHandler: (Bool) -> Void)

Sorry, let me clarify - I want to have a similar menu inside the application?

# ? Jun 10, 2016 20:20

Hughlander: May 11, 2005

Hughlander posted:

I have a question about IPV6 requirements in iOS9.

We rely on that ability, but the docs say that it's a requirement for iOS9. Is that sufficient that we support 9.2/9.3 or do we have to strip it now and get it back to 9.1/9.0? What's the right place to ask that?

Got a good reply finally.

https://forums.developer.apple.com/message/136166#136166 posted:

#4 � My app relies on the system�s ability to synthesise an IPv6 address from an IPv4 address. What should I do on older systems?
As described in Use System APIs to Synthesize IPv6 Addresses, starting with iOS 9.2 and OS X 10.11.2 you can use getaddrinfo to synthesise an IPv6 address from an IPv4 address. Your app will be tested on a device running the latest released version of iOS, so you can assume that this support is present.

# ? Jun 11, 2016 00:10

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

It took me three attempts to learn AutoLayout but once I figured it out I've never looked back.

I originally though UIStackView could replace most uses of it but it actually suffers from the same spacing problems as Autolayout in many situations so I end up using UIStackView with spacer views to get things to lay out correctly. I will say it eliminates a lot of manual constraint work which is excellent when you need to go back and edit something that has an intricate layout.

# ? Jun 11, 2016 01:00

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

A key thing for me with stack views is you can still constrain things in a stack view to things outside a stack view.

Another key thing is not to use them literally everywhere, because yeah they aren't the universal solution.

# ? Jun 11, 2016 04:08

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Linking AutoLayout constraints to your code and then loving around with them in viewWillLayoutSubviews is also way, way better than setting a whole bunch of frames manually, assuming you have positioning logic that can't be expressed properly (or easily) in IB. I sort of stumbled across it on my own, but holy poo poo is it ever perfect for some things.

# ? Jun 11, 2016 16:08

Doctor w-rw-rw-: Jun 24, 2008

Am I a layout idiot savant or something (certainly, one half of that is true...)? Concise usage of CGRect functions (namely, inset, offset, and especially divide) in layoutSubviews is like, the easiest thing ever, and scales well in complexity and optimally in performance.

These frameworks slap a GUI or rules systems on top of what is effectively pre-algebra math, adding a bunch of complexity in the process. And maybe some unresolvable NP-completeness with undocumented failure modes for shits and giggles and unpredictable pathological cases (thanks, autolayout).

I'd much rather debug my math in five minutes than debug my layout framework of choice in fifty.

# ? Jun 11, 2016 16:56

lord funk: Feb 16, 2004

Yeah I'm with you doc rw. All my layout is in code, and if nothing else that alone makes layout debugging really really easy.

# ? Jun 11, 2016 17:08

stuffed crust punk: Oct 8, 2004; by LITERALLY AN ADMIN

I was very resistant to it at first as well

I think a big part of accepting it was inheriting projects that had horrible janky frame arithmetic and never wanting to look at it again. Also variable display sizes that could possibly each need their own code for frame layout

# ? Jun 11, 2016 17:11

lord funk: Feb 16, 2004

Regular Nintendo posted:

I think a big part of accepting it was inheriting projects that had horrible janky frame arithmetic and never wanting to look at it again. Also variable display sizes that could possibly each need their own code for frame layout

Well, yeah. But I really like how you just ignore all the layout of different screen sizes in code, and just do what needs doing.

code:

if (sizeIsCompact) { ... } else { ... }

# ? Jun 11, 2016 17:17

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doctor w-rw-rw- posted:

Am I a layout idiot savant or something (certainly, one half of that is true...)? Concise usage of CGRect functions (namely, inset, offset, and especially divide) in layoutSubviews is like, the easiest thing ever, and scales well in complexity and optimally in performance.

These frameworks slap a GUI or rules systems on top of what is effectively pre-algebra math, adding a bunch of complexity in the process. And maybe some unresolvable NP-completeness with undocumented failure modes for shits and giggles and unpredictable pathological cases (thanks, autolayout).

I'd much rather debug my math in five minutes than debug my layout framework of choice in fifty.

I'm also a big fan of calculating and setting frames, it's even nicer now with Swift's computed properties and methods on structs. Nonetheless I can think of a couple reasons that could lead one to Auto Layout:

� Interface Builder. Greatly shortens the fiddle-compile-test cycle. Plus, in my experience, designers are much more comfortable fiddling with constraints in IB (i.e. they'll try it and ask for help if needed) than with layout code (i.e. they won't try it).
� Some layout scenarios are legitimately clearer in Auto Layout. (If anyone wants to reply that it's much more common to go the other direction, I won't argue. That doesn't invalidate the point.)
� Less code. The only metric I'm aware of that consistently correlates with number of bugs in code is the number of lines of code. This is most fully realized in combination with IB, but can be true without.

There are ways of doing every point above and sticking to frame-setting (IBDesignable, Tweaks, helper functions), no doubt. Those are all good things. There's also nothing stopping anyone from making some helpful widgets for Auto Layout. People make their own little CGRect function helpers and split their interface up into components when setting frames. That approach can make Auto Layout stuff easier too (see e.g. UIStackView).

There are of course downsides to Auto Layout. For what it's worth, I think every app I've touched in the last couple years has done layout combining nonzero amounts of constraints, frame-setting, and autoresizing masks (yep, still). Right tool for the job.

# ? Jun 11, 2016 18:24

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

Data Graham posted:

But because subview is a UIView and not a UITableView, it doesn't know about contentSize and barfs. This is more a basics thing I know, but do I need to manually instantiate a UITableView from subview so I can work with it on the basis of its table-specific properties? I'm not sure how/whether I should do that.

I'm kind of surprised your parent view doesn't have references to the UITableViews in it, except in self.subviews. Even if you have a bunch of them, you can put them in an NSMutableArray at the least.

Also, you can always just cast:

code:

for (UIView *subview in self.subviews) {
    if ([subview isKindOfClass:[UITableView class]]) {
        UITableView *tableView = (UITableView *)subview;
       // Things with tableView
    }
}

Also, layout subviews shouldn't ever be called off the main thread, so I don't think you need to dispatch async back to the main thread when setting frames :confused:

Doctor w-rw-rw- posted:

Am I a layout idiot savant or something (certainly, one half of that is true...)? Concise usage of CGRect functions (namely, inset, offset, and especially divide) in layoutSubviews is like, the easiest thing ever, and scales well in complexity and optimally in performance.

In a previous project we were on, we also added a handful of utility functions around CGRect to do things like centering and the like, and it was glorious.

One of my current projects uses IB, and every time I have to make a change to the UI, in the end, I'm like "welp, that took ten times as much time as it would have taken if we had just done all this in code. And I wouldn't have gotten random crashes or errors because in code, it wouldn't have been loving stringly typed all over the goddamn place". Also, opening IB is always roulette between "actually works", "works after freezing Xcode for five minutes", and "crashes Xcode".

Autolayout I have less ill-will towards, so long as it's done in code. Though I've seen warnings from Apple's components (notably, around media playing) spewing constraint errors, and I'm like "if Apple can't even get this right, why should I try?"

I just haven't seen a compelling enough reason to move off of just doing the drat math myself in code and setting the frames manually.

# ? Jun 11, 2016 18:27

brap: Aug 23, 2004; Grimey Drawer

Anybody using react native? How does the experience of using flexbox and having a shorter turnaround for UI tweaks compare?

# ? Jun 11, 2016 18:36

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Axiem posted:

Also, layout subviews shouldn't ever be called off the main thread, so I don't think you need to dispatch async back to the main thread when setting frames

That's a common "trick" to do something after the layout pass (used to be performSelector:withDelay: pre-GCD). It's a really common cargo cult layout "fix". It's almost always an antipattern. Can I be any more sarcastic with my quotes.

# ? Jun 11, 2016 18:46

Toady: Jan 12, 2009

I took to autolayout right away. There are advanced layouts with automatic support for right-to-left locales that can be done with no code. You can also animate constraints.

# ? Jun 11, 2016 19:01

brap: Aug 23, 2004; Grimey Drawer

I have a pretty small (few thousand lines of code) iOS project primarily in Swift that I'm looking at porting to OS X. What kind of solution should I be looking at for this? Single project with some source files building on multiple targets? Multiple projects? Dynamic frameworks?

# ? Jun 11, 2016 20:12

lord funk: Feb 16, 2004

fleshweasel posted:

I have a pretty small (few thousand lines of code) iOS project primarily in Swift that I'm looking at porting to OS X. What kind of solution should I be looking at for this? Single project with some source files building on multiple targets? Multiple projects? Dynamic frameworks?

I don't see why you wouldn't go with a single project, multiple targets, especially if it's a small simple app.

# ? Jun 11, 2016 20:45

dizzywhip: Dec 23, 2005

Doctor w-rw-rw- posted:

Am I a layout idiot savant or something (certainly, one half of that is true...)? Concise usage of CGRect functions (namely, inset, offset, and especially divide) in layoutSubviews is like, the easiest thing ever, and scales well in complexity and optimally in performance.

These frameworks slap a GUI or rules systems on top of what is effectively pre-algebra math, adding a bunch of complexity in the process. And maybe some unresolvable NP-completeness with undocumented failure modes for shits and giggles and unpredictable pathological cases (thanks, autolayout).

I'd much rather debug my math in five minutes than debug my layout framework of choice in fifty.

I resisted autolayout for a very long time (I ranted about it several times in this very thread), but I recently accepted that autolayout works better for complex, dynamic layouts. If you need to layout a lot of views while properly handling lots of different screen sizes, doing the math yourself can get out of hand pretty quickly.

I mix and match because there are still lots of situations that manually setting the frames works better for. I also don't like using interface builder because it can be a huge pain to rearrange your UI after it's been set up, but everyone at my job loves it so I still use it. Using one of the Swift autolayout libraries seems like that would be the way to go.

# ? Jun 11, 2016 21:13

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

fleshweasel posted:

I have a pretty small (few thousand lines of code) iOS project primarily in Swift that I'm looking at porting to OS X. What kind of solution should I be looking at for this? Single project with some source files building on multiple targets? Multiple projects? Dynamic frameworks?

My vote is single project, multiple targets. A framework target for common code might help with writing unit tests and with janitoring target associations but otherwise doesn't buy you much.

# ? Jun 11, 2016 21:31

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 14:57

Doctor w-rw-rw-: Jun 24, 2008

fleshweasel posted:

Anybody using react native? How does the experience of using flexbox and having a shorter turnaround for UI tweaks compare?

ComponentKit, which ports the concepts to Objective-C++, I have found very productive and very performant. Its major weakness is because it's based on state changes triggering tree relayout, you're out of luck for complex animations. But it's otherwise quite capable.

I believe RN has the same conceptual issue, plus it's single threaded (the queue is not on main at least) and JS.

EDIT: it /is/ extra complexity though, but debugging/fixing/rebuilding-mental-model steps of iterating on it are all pretty cheap. It really shines when building feeds with varying cell heights, because it efficiently offloads sizing/layout calculations to background queues. So does RN, IIRC, but only to the JS queue.

Doctor w-rw-rw- fucked around with this message at 23:38 on Jun 11, 2016

# ? Jun 11, 2016 22:56

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »