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

«‹›2 »

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

Kallikrates posted:

Xcode7 seems to have improved it quite a bit.

Outside of that I noticed that putting logic in extensions that are then referenced in multiple places can have a really bad effect. For example a method in an extension on UIViewController. I don't have measurements but whenever I need to make a change in one of these files, the resulting build time is significantly degraded. So I have been using less extension and more combining related classes in files.

Unlike Obj-c where even very small classes would have their own file I don't do that for Swift. Small classes live along side the viewcontroller that uses them for example.

Interesting about the extensions, that kinda sucks. But yeah, good call on Xcode 7. Good to hear 7 is already doing better.

# ¿ Aug 27, 2015 17:27

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 19:29

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

Is it possible to have a protocol's default implementation in an extension work for selectors? For example, I'd like an extension to provide some gesture recognizers:

code:

protocol Draggable: class, UIGestureRecognizerDelegate {
    func didPress(pressGesture: UILongPressGestureRecognizer) -> Void
    func didPan(panGesture: UIPanGestureRecognizer) -> Void
}

extension Draggable where Self: UIView {
    func wasAddedToParentView() {
        let panGesture = UIPanGestureRecognizer(target: self, action: Selector("didPan:"))
        panGesture.delegate = self

        let pressGesture = UILongPressGestureRecognizer(target: self, action: Selector("didPress:"))
        pressGesture.minimumPressDuration = 0.001
        pressGesture.delegate = self
        
        self.addGestureRecognizer(panGesture)
        self.addGestureRecognizer(pressGesture)
    }

    func didPress(pressGesture: UILongPressGestureRecognizer) {
        // do pressing things
    }
    
    func didPan(panGesture: UIPanGestureRecognizer) {
        // do panning things
    }
}

Sadly, when I tap on the view, I get a "does not recognize selector" error. If I then add in the functions in my object that is of the Draggable prototype, there's no crash and it recognizes it (but I don't want that, I just want it handled in the extension). I believe this doesn't work because pure Swift classes don't handle respondsToSelector: and that's what would be used in the UIGestureRecognizer addTarget:action methods.

# ¿ Sep 25, 2015 04:44

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

Flobbster posted:

Maybe the protocol (and the methods in it too, perhaps) need to be marked @objc?

I tried that but the compiler yells at you "Members of protocol extensions cannot be declared as @objc". :saddowns:

rjmccall posted:

It's an area of some debate, but at least some variants of it would probably be okay, and the current inability to do that is just an unnecessary restriction.

Oh okay, cool. Well here's a +1 to allowing that in a future release of Swift. I should be fine maybe making a lightweight base class that'll receive the selectors for the time being (or something to that effect).

Also really enjoying 2.0 so far, great job

# ¿ Sep 25, 2015 12:50

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

Axiem posted:

The real solution is to replace methods that take selectors with methods that take functions. I was rather disappointed that iOS 9 didn't do that through more of UIKit.

Definitely.

I just hobbled together an extension on UIGestureRecognizer to do just this with some object association. Feels pretty dirty.

# ¿ Sep 26, 2015 22:48

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

Doh004 posted:

Definitely.

I just hobbled together an extension on UIGestureRecognizer to do just this with some object association. Feels pretty dirty.

If anyone's curious, I put up a repo with my Draggable extension: https://github.com/BayPhillips/draggable-swift

# ¿ Oct 3, 2015 21:21

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

So this is a thing: http://perfect.org/

"web brains"

# ¿ Nov 24, 2015 02:33

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

Yeah this is more super cool stuff :respek:

# ¿ Dec 3, 2015 19:38

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

Snapchat A Titty posted:

Burn them!

Figure a guillotine would be more appropriate!

# ¿ Dec 5, 2015 06:09

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

Is this intended:

code:

var numbers = [1, 2, 3, 4, 5]
numbers.sortInPlace({ $0 > $01 })

Primarily, the $01 being valid?

# ¿ Feb 17, 2016 20:35

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

rjmccall posted:

I doubt we ever explicitly considered it, but it seems reasonable enough. What else could we reasonably do, warn "hey, you probably fat-fingered something here, and we're pretty sure it's what you actually wanted, but maybe you fat-fingered something else nearby since you're such a lovely typist"?

It's not like we're interpreting it as octal or something.

I'd be okay with this warning.

I only saw this while code reviewing a PR. I yelled at the engineer because CLEARLY they hadn't actually attempted to compile their code. Much to my surprise they had and it worked just fine :iiam:

# ¿ Feb 17, 2016 21:14

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

playground tough posted:

So I've had this idea kickin around for an app I'd like to develop while I'm still in school for a while now. I want to prove that I can work with a decently sized project and want to learn more development skills in general. I started messing around with React Native and I'm starting to feel like it is loving dumb since I can't seem to get it to do anything I want it to do without some fuckery or hacks.

If I work with swift, am I going to have an easier time building my app coming from a java & c background than with this react bullshit? Thanks.

Yes 100%. Please learn the actual system first instead of jumping into whatever Facebook's framework of the year may be at the time.

# ¿ Feb 21, 2016 16:34

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

Doctor w-rw-rw- posted:

https://twitter.com/ashfurrow/status/715941778621206529

Yeah this owns.

# ¿ Apr 5, 2016 20:29

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

All of my code is poo poo, regardless of the language.

# ¿ May 5, 2016 19:46

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

Would have been better off not open sourcing the language.

# ¿ Jul 20, 2016 21:00

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

As someone who is not on the Swift-Evolution mailing list, I'd appreciate a way to know who we're talking poo poo about. No, I don't care to join some mailing list or whatever the hell process it is we're talking about from 20 years ago :argh:

# ¿ Jul 31, 2016 23:49

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

Whoa, didn't know others felt the same way I did about the mailing list. I mean, I'm just being lazy and want to be "in the know" without doing any of the work. Also, I find it very hard to believe mailing lists are still the best way to have large scale discussions.

eschaton posted:

If you want a fuller-featured archive interface for a list you can always build one, grab the mbox files for the archives, and put it up.

This is silly. No, I don't want to build an archive interface for something as straightforward as discussions.

eschaton posted:

You have discovered one of the other ways to deal with online discussion better than a web site. Web sites are fine for presenting archival information, for interaction that's why we have—and have had—apps.

So what are web apps? Aren't forums apps?

Toady posted:

If people want to follow the mailing lists without using a mail client or being able to post to discussions, Hirundo is a free Swift mailing list archive browser.

Edit: Actually, if you're subscribed to a list, it will open Mail to compose a reply.

This is cool, I'll try it out. Thank you!

# ¿ Aug 2, 2016 05:09

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

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

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

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

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

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

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

It took us a good 3-4 days of converting from 2.3 and 3.0 and then another week of tracking down horrible bugs.

It's what we get for using a young, active language.

# ¿ Feb 7, 2017 21:28

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

ManicJason posted:

It took me a similarly long time to convert, but somehow everything worked except trying to use Cocoalumberjack for a mixed project. Should I be scared that I have not yet found the horrible bugs?

Nah, just make sure anything that goes from IB to the code behind still works properly. When they changed up the parameter conventions, the converter missed several places that now required an "_" in its signature (but still compiled just fine as expected).

# ¿ Feb 9, 2017 17:06

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

Moogs posted:

So this is a stupid noob question, but I'm a stupid noob... when I'm making an iMessage extension, how do I control what it looks like when it's half screen (like when you have Messages open and hit the app button to switch to it) and when it's full screen? I think the answer is view controllers, is that right?

We made an iMessage application back for the iOS 10 launch: https://itunes.apple.com/us/app/plated-dinner-recipes-ingredients/id954364666?mt=8

Have it operate like any other application, except what would normally be your "UIApplicationDelegate" is the "MSMessagesAppViewController". You'll want to respond to the "willTransition(to presentationStyle: MSMessagesAppPresentationStyle)" and "didTransition(to presentationStyle: MSMessagesAppPresentationStyle)" delegate methods accordingly.

And yes, we used a storyboard to handle these flows.

# ¿ Apr 10, 2017 15:09

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 19:29

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

Uhh, why?

# ¿ Jun 15, 2017 15:03

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

«‹›2 »