|
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 |
|
|
# ? May 30, 2024 13:07 |
|
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 |
|
At least it's not a web forum.
|
# ? Oct 31, 2016 04:43 |
|
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 |
|
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 |
|
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 |
|
same with static initialization of arrays/dictionaries with non-POD types
|
# ? Nov 1, 2016 01:12 |
|
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. Is this in Swift 3 or 2.3? That was (hopefully) fixed in Swift 3 I think?
|
# ? Nov 1, 2016 01:28 |
|
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. 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 |
|
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 )
|
# ? Nov 1, 2016 22:29 |
|
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 |
|
Rastor posted:Chris Lattner departing Apple, handing over the “Project Lead” reins: Today I realized his last name's spelled differently than Christian Laettner's.
|
# ? Jan 10, 2017 21:51 |
|
https://www.tesla.com/blog/welcome-chris-lattner
|
# ? Jan 11, 2017 02:57 |
|
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 |
|
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 |
|
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 |
|
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:
code:
|
# ? Jan 18, 2017 16:44 |
|
Wow, thanks for a detailed write-up. Have seen delegates referenced in several tutorials, but never fully explained before.
|
# ? Jan 18, 2017 18:10 |
|
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 |
|
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 |
|
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 |
|
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 |
|
lord funk posted:No problem. 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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. 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 |
|
lord funk posted:Model View Controller (MVC). live from wwdc! https://www.youtube.com/watch?v=YYvOGPMLVDo
|
# ? Jan 23, 2017 06:35 |
|
lord funk posted:No problem. 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 |
|
IMO unit testing UI is generally way more effort than payoff. Unit test core logic. Integration test the UI.
|
# ? Jan 24, 2017 08:11 |
|
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 |
|
Is it used in your bridging header, maybe?
|
# ? Jan 24, 2017 17:39 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
|
# ? May 30, 2024 13:07 |
|
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 |