Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »

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

edit: disregard

(The first time I tried signing up, the listserv never sent me a confirmation email. This time it did)

# ? Oct 30, 2016 01:09

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 09:37

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Everyone wants to move off that stuff, it just takes time to get movement on it. Really we shouldn't have used it in the first place, but management wasn't in that mental space when we were first making the open-source release.

# ? Oct 30, 2016 05:45

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

At least it's not a web forum.

# ? Oct 31, 2016 04:43

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

TIL: Don't put a lot of logic inside of lazy property declarations. Unless you want your build time to blow up astronomically.

Simply moving it into a private method that performs the operations kills the time like crazy.

# ? Oct 31, 2016 21:33

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

I will have to remember that! I have noticed the SourceKit service tends to poo poo a brick when I start typing a lazy property initializer.

I seem to bounce between "hiding all that setup inside the lazy property block is nice and convenient I should do this as much as possible" and "these plain old unadorned properties sure are tidy I should do this as much as possible". That might make it easier.

# ? Nov 1, 2016 00:04

Kallikrates: Jul 7, 2002; Pro Lurker

had a contractor accidentally add one that added 30min to the build. lazy view property with visual layout constraints.

I think the swift JIRA ticket about this issue or a dupe has a sceenshot of an 8 hour build.

# ? Nov 1, 2016 00:37

Vesi: Jan 12, 2005; pikachu looking at?

same with static initialization of arrays/dictionaries with non-POD types

# ? Nov 1, 2016 01:12

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Doh004 posted:

TIL: Don't put a lot of logic inside of lazy property declarations. Unless you want your build time to blow up astronomically.

Simply moving it into a private method that performs the operations kills the time like crazy.

Is this in Swift 3 or 2.3? That was (hopefully) fixed in Swift 3 I think?

# ? Nov 1, 2016 01:28

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

pokeyman posted:

I will have to remember that! I have noticed the SourceKit service tends to poo poo a brick when I start typing a lazy property initializer.

I seem to bounce between "hiding all that setup inside the lazy property block is nice and convenient I should do this as much as possible" and "these plain old unadorned properties sure are tidy I should do this as much as possible". That might make it easier.

Yeah, I added a line to our style guide to no longer allow this. Just not worth it.

ultramiraculous posted:

Is this in Swift 3 or 2.3? That was (hopefully) fixed in Swift 3 I think?

2.3. After reading about the build time improvements of 3, I'm pushing forward our tech debt epic to upgrade much much sooner. Also 8.2 is the last XCode version to support 2.3 so... time to poo poo or get off the pot.

# ? Nov 1, 2016 14:25

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Doh004 posted:

2.3. After reading about the build time improvements of 3, I'm pushing forward our tech debt epic to upgrade much much sooner. Also 8.2 is the last XCode version to support 2.3 so... time to poo poo or get off the pot.

Yeah we had a situation where a dozen lazy vars in three files had turned out to be ~66% of our build time. Converting them to private functions helped noticeably, but now other people are catching on and trying to be helpful. I'm really hoping we can manage to get the Swift 3 changeover done before teams start adopting it as a pattern (I know that at this point if I'm saying this, it's already happening :rip:

)

# ? Nov 1, 2016 22:29

Rastor: Jun 2, 2001

Chris Lattner departing Apple, handing over the �Project Lead� reins:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030063.html

# ? Jan 10, 2017 20:46

sarehu: Apr 20, 2007; (call/cc call/cc)

Rastor posted:

Chris Lattner departing Apple, handing over the �Project Lead� reins:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030063.html

Today I realized his last name's spelled differently than Christian Laettner's.

# ? Jan 10, 2017 21:51

Rastor: Jun 2, 2001

https://www.tesla.com/blog/welcome-chris-lattner

# ? Jan 11, 2017 02:57

uncle blog: Nov 18, 2012

I have a custom UIView class, which responds to touches. What is the best way for that class to access a variable in the presenting ViewController?

# ? Jan 18, 2017 09:20

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

Your question sounds like an XY problem:
http://meta.stackexchange.com/a/66378

It's not necessarily a good idea to couple whatever custom view you're writing closely to the behavior of your ViewController. What are you really trying to do?

If you're sure you need that though, have the view controller set a weak property on the view to itself.

# ? Jan 18, 2017 10:09

uncle blog: Nov 18, 2012

When the user touches the custom UIView, the view should generate a UImageView at that location. This object is determined by what the user has selected in a TableView, which itself refers to an array of objects in the viewcontroller. I'm pretty new at this, so there might be better ways to handle this.

# ? Jan 18, 2017 16:34

lord funk: Feb 16, 2004

uncle blog posted:

When the user touches the custom UIView, the view should generate a UImageView at that location. This object is determined by what the user has selected in a TableView, which itself refers to an array of objects in the viewcontroller. I'm pretty new at this, so there might be better ways to handle this.

It's really the job of the view controller to do things like generating a UIImageView. What you're looking for is delegation. Basically, the UIView is only there to report back activity to the view controller, who then acts upon it.

To set that up, you create a weak property of the view (often just called 'delegate') which conforms to a protocol. In that protocol, you declare a method which reports back to the delegate that something has occurred. When the view controller makes the view, it assigns that view's delegate to itself, which means it will then catch the method call so it can respond.

code:

protocol CustomViewDelegate {
    func userDidRequestSomething(sender: CustomView)
}

class CustomView: UIView {

    var delegate: CustomViewDelegate?
    
    override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?) {
        delegate?.userDidRequestSomething(sender: self)
    }
    
}

Don't forget to set the delegate to the view controller when making the custom view:

code:

class ViewController: UIViewController, CustomViewDelegate {

    override func viewDidLoad() {
        super.viewDidLoad()
        
        let cView = CustomView()
        cView.delegate = self
        view.addSubview(cView)
        
    }
    
    func userDidRequestSomething(sender: CustomView) {
        //react to the delegate call
    }
}

All of this can be summed up in a simple mantra: views are stupid. Never assign any task to a view which requires knowledge of your model / data. Views don't do anything: they just show or react to input.

# ? Jan 18, 2017 16:44

uncle blog: Nov 18, 2012

Wow, thanks for a detailed write-up. Have seen delegates referenced in several tutorials, but never fully explained before.

# ? Jan 18, 2017 18:10

lord funk: Feb 16, 2004

No problem.

Since you are new to this, you're just about one step away from understanding an important concept. SO...

1. Views (are dumb). The view should not know what information it's supposed to show or why. It should never store anything. It's just there to show it, or react to a user interaction. So who should know the information? Maybe it's the...

2. ...View Controller? Well almost. Let's say the user touches a view, which means 'please add an image to the screen.' The view controller responds to this. Maybe it should figure out what image to show, then create the image, store it, and then push it to the view? That *almost* makes sense, but the only real job it has is push it to the view. The actual decisions should come from the...

3. Model. You need a model object that deals with logic, decisions, and storage. The view controller can tell the model to do things (make a new image, store it). The model then holds that state. The view controller watches the model, and updates its views to reflect its current state.

Model View Controller (MVC).

# ? Jan 18, 2017 18:25

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

And preferably, your models know nothing about UIKit, and have interfaces that are value-based and easily tested independent of the VC/V. In practice, that can sometimes be hard.

# ? Jan 18, 2017 19:18

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

In case you missed it, Chris is a guest on the Accidental Tech Podcast and he talks about all sorts of stuff.

# ? Jan 19, 2017 03:15

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

eschaton posted:

In case you missed it, Chris is a guest on the Accidental Tech Podcast and he talks about all sorts of stuff.

This is great stuff. If you normally don't care for the hosts, listen anyway, it's like two hours of good questions and thoughtful answers.

# ? Jan 19, 2017 06:09

uncle blog: Nov 18, 2012

lord funk posted:

No problem.

Since you are new to this, you're just about one step away from understanding an important concept. SO...

1. Views (are dumb). The view should not know what information it's supposed to show or why. It should never store anything. It's just there to show it, or react to a user interaction. So who should know the information? Maybe it's the...

2. ...View Controller? Well almost. Let's say the user touches a view, which means 'please add an image to the screen.' The view controller responds to this. Maybe it should figure out what image to show, then create the image, store it, and then push it to the view? That *almost* makes sense, but the only real job it has is push it to the view. The actual decisions should come from the...

3. Model. You need a model object that deals with logic, decisions, and storage. The view controller can tell the model to do things (make a new image, store it). The model then holds that state. The view controller watches the model, and updates its views to reflect its current state.

Model View Controller (MVC).

We have model classes, but they contain very little beyond initialisers and variables. But I guess relevant methods should be put there as well. Then I assume the view controllers only contain instances of the used classes, and calls the methods placed within them?

If I want to create an array of objects of a custom class, should that array then have its own class too, or be placed within the view controllers?

# ? Jan 19, 2017 08:54

uncle blog: Nov 18, 2012

Axiem posted:

And preferably, your models know nothing about UIKit, and have interfaces that are value-based and easily tested independent of the VC/V. In practice, that can sometimes be hard.

This seems really smart. Got any simple examples of it in practice?

# ? Jan 19, 2017 08:54

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

I suggest you check out the other main iOS/Cocoa thread: https://forums.somethingawful.com/showthread.php?threadid=3400187

What you're asking for isn't Swift specific

# ? Jan 19, 2017 13:31

Siguy: Sep 15, 2010; 10.0 10.0 10.0 10.0 10.0

Swift String Manifesto

Very cool to see how much thought is being put into better Unicode strings for Swift 4 and 5. A lot of the details here fly over my head because I'm not well versed in the complexities of Swift's type system, but I'm glad to see the team is going back to treating Strings as collections. I understood why they went away from collections, but working with strings in Swift 3 feels like it requires you to learn all the intricacies of Unicode to do any operation.

# ? Jan 20, 2017 19:46

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

uncle blog posted:

This seems really smart. Got any simple examples of it in practice?

Unfortunately, nothing in Swift that's public. At some point I want to write a blog post or something in my TIL for it, but I haven't yet. I might try to write it up soon; I'll try to remember to post it here when/if I do.

The best I can dig up was the example project for ESCObservable, which is written by a colleague of mine. He includes a "Presenter" object that has wiring tests; I would just wire in the VC and not write wiring tests, myself. And I use more closures and callbacks to handle it, but some of the ideas are still there.

# ? Jan 20, 2017 20:26

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

The book Cocoa Design Patterns by Yacktman & Buck taught me a lot about how Objective-C & Cocoa worked, but it's super old. I guess Swift is still too much of a moving target for a similar book on that?

# ? Jan 20, 2017 21:27

uncle blog: Nov 18, 2012

Axiem posted:

Unfortunately, nothing in Swift that's public. At some point I want to write a blog post or something in my TIL for it, but I haven't yet. I might try to write it up soon; I'll try to remember to post it here when/if I do.

The best I can dig up was the example project for ESCObservable, which is written by a colleague of mine. He includes a "Presenter" object that has wiring tests; I would just wire in the VC and not write wiring tests, myself. And I use more closures and callbacks to handle it, but some of the ideas are still there.

Thanks, I'll have a look at that, and maybe see if I can find some examples of this in other languages.

# ? Jan 22, 2017 15:26

Gul Banana: Nov 28, 2003

lord funk posted:

Model View Controller (MVC).

live from wwdc!
https://www.youtube.com/watch?v=YYvOGPMLVDo

# ? Jan 23, 2017 06:35

Huckleduck: May 20, 2007; giving you the hucklebuck

lord funk posted:

No problem.

Since you are new to this, you're just about one step away from understanding an important concept. SO...

1. Views (are dumb). The view should not know what information it's supposed to show or why. It should never store anything. It's just there to show it, or react to a user interaction. So who should know the information? Maybe it's the...

2. ...View Controller? Well almost. Let's say the user touches a view, which means 'please add an image to the screen.' The view controller responds to this. Maybe it should figure out what image to show, then create the image, store it, and then push it to the view? That *almost* makes sense, but the only real job it has is push it to the view. The actual decisions should come from the...

3. Model. You need a model object that deals with logic, decisions, and storage. The view controller can tell the model to do things (make a new image, store it). The model then holds that state. The view controller watches the model, and updates its views to reflect its current state.

Model View Controller (MVC).

I've been looking at Model-View-ViewController-ViewModel.

1. Views - dumb, same as usual.
2. View Controllers - Control the views, receive input from the user.
3. View Models - Receive inputs from the View Controller, give the View Controller back whatever info it needs (state? data?)
4. Logic, decisions, storage, etc.

I have found it difficult to have unit tests in plain ol' MVC because of the number of things that the View Controller gets up to. ViewModels seem more easily testable though.

# ? Jan 24, 2017 06:50

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

IMO unit testing UI is generally way more effort than payoff. Unit test core logic. Integration test the UI.

# ? Jan 24, 2017 08:11

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

Our application is still using the AddressBook framework which was deprecated in iOS 9. We haven't had the opportunity to move one area of code over to the new framework just yet.

Why do we see this warning for EVERY file we compile within the same target:

4 of our .swift files do reference the ABAddressBook (none of those files in the screenshot have anything to do with it), but I don't understand why this is being checked and warned about for every single file. I'm trying to figure this out in another attempt to speed up our build process.

Doh004 fucked around with this message at 16:56 on Jan 24, 2017

# ? Jan 24, 2017 16:49

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Is it used in your bridging header, maybe?

# ? Jan 24, 2017 17:39

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

rjmccall posted:

Is it used in your bridging header, maybe?

I was going to feel like a really big putz if that were the case, but it is not.

Just did a workspace wide search:

*edit* This is Swift 3 on XCode 8.2 (latest).

Doh004 fucked around with this message at 17:56 on Jan 24, 2017

# ? Jan 24, 2017 17:53

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

If anything included directly or indirectly in your bridging header pulls in a deprecation attribute you'll see exactly that issue. Any external libraries in our bridging header that in turn include AddressBook?

# ? Jan 24, 2017 18:10

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I dunno. The compiler does process other files, but it's supposed to be smart enough to not emit diagnostics for things outside the primary file. But if there isn't a proper source location on the diagnostic, maybe that's subverting that. Implicitly generated code, maybe; probably an implicit initializer on the imported type.

# ? Jan 24, 2017 19:31

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

pokeyman posted:

If anything included directly or indirectly in your bridging header pulls in a deprecation attribute you'll see exactly that issue. Any external libraries in our bridging header that in turn include AddressBook?

I don't think any of our pods require the `AddressBook` framework based off me checking the "Frameworks/iOS` directory in the Pod project.

# ? Jan 24, 2017 19:31

uncle blog: Nov 18, 2012

I'm trying to start a popover segue from a tableViewCell, but I'm unable to set its anchor. If I do it in the storyboard to the prototype cell, I get a "Couldn't compile connection" error. Is there a way to set it programmatically when the segue is performed?

# ? Jan 25, 2017 09:54

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 09:37

lord funk: Feb 16, 2004

Updating code from Swift 2 to Swift 3. Would really love to have some code autocomplete working so these changes could be learnable.

edit: wow, what happened to Range? Let's make this poo poo as complicated as we can now, boys.

(Sorry I'm going to be in a pissy mood because I'm on hour 3 of trying to get my code to compile.)

lord funk fucked around with this message at 21:30 on Feb 5, 2017

# ? Feb 5, 2017 21:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »