Great explanation, Sean. I have been watching your videos for over a year now and i have to say, you have REALLY stepped up your game regarding the quality of your instruction, not to say the "old" videos are bad, just that your latest ones are that much better. Well done.
@@seanallen I taught Computer Science here at the United States Military Academy (West Point) for seven years and it seems that your pedagogical approach is aligning with mine. I think you have grown from "informational" videos to "educational" videos, of which the latter is much better for my style of learning and instruction.
Another good video. Thanks Sean. A couple of suggestions: 1. It's recommended to use 'lazy var' instead of 'let' when declaring properties in a UIViewController. This allows the system to instantiate the viewController as quickly as possible, delaying the creation of UI elements until the system really needs them. This can become significant when pre-building viewControllers for, say, a series of screens for use with a PageViewController, for on-boarding etc. Also, it allows us to use a closure that references self. e.g. lazy var loginButton: SomeButton = { let button = SomeButton() button.titleLabel?.text = self.conjugateTheVerb("to go") return button }() 2. You can use an availability check to prevent unwanted init() methods from being used at all, and preventing them from appearing in code completion: @available(*, unavailable) required public init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } 3. A small thing... when setting a UIFont property, you don't have to provide the type. e.g. myLabel.font = .systemFont(ofSize: 16) Cheers, and keep up the great work. You're one of the best Apple dev RUclipsrs around.
Thanks for the feedback and kind words! I have nuanced thoughts on the lazy var stuff, but way too much to type out in a comment 😀. To sum it up, I agree with you when it comes to "heavy" UI situations, but I don't like to use that method for all UI.
Hey Sean, thanks for this contribution. I was wondering though. Why can you not just use the first initialiser to do the same thing? init(_ frame: CGRect, title: String). I might of missed why the convenience keyword benefits this strategy.
Is there a way, or would there even be a use case for, multiple convenience initializers? Maybe like initializing a color with RGB or hex? Wondering about namespace issues.
Great video man , I have a doubt what is required init?(coder:NSCoder){} , and what is that '?' after the function name can functions be optional too ??
Hey Sean great video, In case of storyboard based apps, you can override awakeFromNib and do the basic setup there and for different style buttons you can inject enum case and configure accordingly, this way, for most of the cases, assigning class (SAButton in your case) and button title in the storyboard works fine.
5:45 honestly don't think using convenience init was that much better. Just looks more advanced and fancier. And it seems it can't be used on xibs, have to use awakeFromNib only for the outlets.
best swift channel on youtube
change my mind
keep it up Sean
Appreciate that
Great explanation, Sean. I have been watching your videos for over a year now and i have to say, you have REALLY stepped up your game regarding the quality of your instruction, not to say the "old" videos are bad, just that your latest ones are that much better. Well done.
Thanks for the kind words, Tom. I like to think I'm getting better as well. At least I'd hope so after 3+ years of making video tutorials 😀
@@seanallen I taught Computer Science here at the United States Military Academy (West Point) for seven years and it seems that your pedagogical approach is aligning with mine. I think you have grown from "informational" videos to "educational" videos, of which the latter is much better for my style of learning and instruction.
Your tutorials quality is improving over time!
Glad you think so!
“We’re not web developers, we’re iOS developers.”
Ha! I love that! I’m so sick of everybody just assuming developer == web developer.
Clear, simple , easy to understand. Thanks you , AGAIN!
You are welcome!
the number of subscribers grows exponentially. I'm with you from 35_000.
Thanks for the long time support!
@@seanallen thanks for keeping enlightening folks.
Great tutorial as always Sean!
Everyone: "String"
Sean Allen: "Shhhtring"
I tried to pronounce it like him while watching it! 😂
I like my strings to be quiet 🤷🏻♂️
Typical Sean Allen explainer video: Excellent. Will share around.
Much appreciated!
yet another simple , clean , and powerful tutorial for a scalable code !
Thank you
Glad it helped!
Thanks Sean. A great example of how to make the code more flexible.
thanks for the great explanation!
Glad it was helpful, Anthony.
Awesome explanation. I never understood this. Now I do. Thanks.
Glad you liked it!
Great example, Sean
Another good video. Thanks Sean.
A couple of suggestions:
1. It's recommended to use 'lazy var' instead of 'let' when declaring properties in a UIViewController. This allows the system to instantiate the viewController as quickly as possible, delaying the creation of UI elements until the system really needs them. This can become significant when pre-building viewControllers for, say, a series of screens for use with a PageViewController, for on-boarding etc. Also, it allows us to use a closure that references self. e.g.
lazy var loginButton: SomeButton = {
let button = SomeButton()
button.titleLabel?.text = self.conjugateTheVerb("to go")
return button
}()
2. You can use an availability check to prevent unwanted init() methods from being used at all, and preventing them from appearing in code completion:
@available(*, unavailable)
required public init?(coder: NSCoder)
{
fatalError("init(coder:) has not been implemented")
}
3. A small thing... when setting a UIFont property, you don't have to provide the type. e.g.
myLabel.font = .systemFont(ofSize: 16)
Cheers, and keep up the great work. You're one of the best Apple dev RUclipsrs around.
Thanks for the feedback and kind words! I have nuanced thoughts on the lazy var stuff, but way too much to type out in a comment 😀. To sum it up, I agree with you when it comes to "heavy" UI situations, but I don't like to use that method for all UI.
That was simple but very helpful, thank you
Glad it helped!
Slick, nicely explained.
Thanks!
Hey Sean, thanks for this contribution. I was wondering though. Why can you not just use the first initialiser to do the same thing? init(_ frame: CGRect, title: String). I might of missed why the convenience keyword benefits this strategy.
Super helpful for a mostly SwiftUI person
Very “convenient” lol.
Nice tut as always thanks for the quality , simpleness, and effort on your teaching.
Glad you think so!
Keep it up man, all the best
Thanks, you too!
Very easy to understand, thanks so much!
Very nicely explained..👌👌🙏
Happy to help!
Hi Sean thank you for this tutorial. Is there a way to make this work with storyboard ?
I use them a lot in CoreData
Is there a way, or would there even be a use case for, multiple convenience initializers? Maybe like initializing a color with RGB or hex? Wondering about namespace issues.
Yes, it's common to have multiple convenience initializers for different use cases.
Great video man , I have a doubt what is required init?(coder:NSCoder){} , and what is that '?' after the function name can functions be optional too ??
you are a saviour! 👍✌️
Happy to help!
Sean quick question: what's the difference between the convenience init and creating a custom one?
Why use the keyword convenience in a custom init versus not using it in a custom init?
The same result we could get by passing button Color to the design init setting up default value, couldn’t we?
Thankyou so much for making my life easy as iOS dev #seanIsBest
Happy to help!
Can we extend base uikit classes with convinience init?
Hey Sean great video, In case of storyboard based apps, you can override awakeFromNib and do the basic setup there and for different style buttons you can inject enum case and configure accordingly, this way, for most of the cases, assigning class (SAButton in your case) and button title in the storyboard works fine.
Hi Sean, based on your usage of convenience initializers in the video. Are they primarily used for programmatically created buttons and UI objects?
I used them mostly with my custom objects. Doesn't necessarily have to be UI objects. Can be model objects as well.
@@seanallen Thanks! I was just wondering if I could make use of them since most of my objects are from the storyboard.
5:45 honestly don't think using convenience init was that much better. Just looks more advanced and fancier. And it seems it can't be used on xibs, have to use awakeFromNib only for the outlets.
Can't we just use a setter, instead of creating secondary init like this??
Is it not possible to write new designated init which calls super.init and do the same thing?
You can, but it's not as flexible.
@@seanallen thanks for reply
plz teach me how design MVVM Pattern 100% programming thk
how constraints works without { translatesAutoresizingMaskIntoConstraints = false } ?
good work.. saw a few videos and you have 5 haters for sure. ;) :D
Haha, it's the internet. Can't please everyone...