Swift: VIPER Design Pattern (Architecture, 2023, Xcode 14, Swift 5) - iOS Development
HTML-код
- Опубликовано: 8 сен 2024
- In this video we will learn about the VIPER design/architecture pattern for Swift 5 and iOS. This is a common pattern for large apps to properly isolate objects and their responsibility.
👉🏼 Connect (personal LinkedIn) / afraz-siddiqui
🚀 Follow on LinkedIn / ios-academy
#swift #designpattern #ios
** Like my teaching style? Check out some of my most popular courses!
courses.iosaca...
Join this channel to get access to perks, code, groups, and more:
Building Instagram: courses.iosaca...
Building TikTok: / @iosacademy
SwiftUI for Beginners: ios-academy.te...
Join the iOS Academy Community: iosacademy.io/
** Get Skillshare free for 2 Months and learn iOS
www.skillshare...
** Manage all your investments from app earnings on Betterment!
bit.ly/3eBwlI9
** Grow your own RUclips tech channel with TubeBuddy:
www.tubebuddy....
Thanks for creating this video! It's pretty easy to understand. But I would like to point out that in your code, there are a few retain cycles with view, presenter, router and interactor. One option you can do is to make those protocols conforms to AnyObject, and mark these references as "weak":
1. router's ref to presenter
2. router's ref to view
3. presenter's ref to view
4. interactor's ref to presenter
Eventually your object relationship will look like this in the memory, where -> means a strong reference
router
^
|
window -> View Controller -> Presenter -> Interactor
Correct me if I'm wrong.
Although slightly dangerous, I think `unowned` would be acceptable also so we can assert that our objects that should exist do exist. The alternative would be a completely unresponsive app that people would have to kill and restart themselves anyway so I guess you pick your problems :)
I have the same question Interactor has a strong reference of the presenter and the presenter has strong reference of the interactor. It will create retain cycle.
That tells a lot about the iOS academy
circular reference can be fixed by replacing one of the strong references with a weak or unowned reference.
I started a new job and they use VIPER. I'd never used it before and I struggled to get through some explanations of VIPER (ADHD).
This explanation was so concise and easy to understand. Thank you so much, man! ❤
They all connect by strong reference between each other? Where are the weak references?
A great intro to VIPER. Actually, go ahead and watch it!
Thanks
Viper is a little bit confusing, but we can isolate the modules, functionalities, I think it was easier to test. Thank you so much for the great lesson! (:
Youre welcome
it would be nice if you extend this tutorial for navigation on multiple screens, delegates, callbacks and how to handle this in VIPER appropriate. And yeah, thanks for video. Cleanest explanation of VIPER ever I see 👍
Great suggestion!
THANK U SO MUCH!!!
IT REALY USEFUL!!!
FROM RUSSIA WITH LOVE ❤️❤️❤️
Youre welcome
I’m don’t really like VIPER. To much classes. Most of classes knowing about other ones. View layer contacts with models. My preference to Data Driven MVVM + Coordinator (for routing) + Builder (factory to create units) + proxy pattern for fetching data from web or storage. Any way it’s a great video to understand this pattern. Thank you!
I agree
@@iOSAcademy Could you make an app for us demonstrating all of those ? It would be very valuable to see a "best practices" app with them rolled into one, and we could use it as a template for our future apps. Thanks for your great work !!!
Totally agree. Looks like the VIPER is an upgrade for MVP. However, MVP itself is not a perfect architecture due to the dependencies between the presenter and views. In the VIPER, it introduced a new dependency between interactor and presenter, which is a terrible thing. Meanwhile, the too many protocols make it hard to maintain if there's new business logic which requires a new parameter in a protocol, which needs to modify all the implementations of it. MVVM is a perfect architecture since it decouples the dependency of view and view model. The view model no longer needs to hold a reference of view. In Android, we can use live data or data binding to update the view, in iOS we can use RxSwift or things like that.
@@noodles7240 yes, that’s true. But I’m usually use closures to bind vm and view.
I was trying to learn VIPER but seems confusing, this video is so simple and easy to understand.
Thanks!
I have been trying to learn this from a long time. Finally i found this hands on tutorial instead of those redundant concepts articles. Thank you
Good video explaining basics. I would like to see some more informations about coordination between modules. I use approach of adding Coordinator pattern into VIPER. Also, Router should be responsible only for routing not building a module - here is good to use some Module builder by using fabric pattern. This way we use SOLID principles. There is also questionable for me conforming to UITableViewDelegate and UITableViewDataSource in UIViewController component. What do you think about using Presenter to conform to that protocol - then we keep responsibility of proper presentation on the side of Presenter (view shouldn't convert DTO to ViewModel). I am also curious about automation for it. I created Xcode template which creates entire module with 1-click, but I am still researching for making it better - that's why I am looking for more opinions :) . Thank you for your work and I am waiting for part 2 with advanced part.
Whenever I search for Swift/ iOS, I ended up with this channel :)
I'll just search in this channel first next time lol
And finally i understood the VIPER, thanks a lot man
Youre welcome
Pretty neat & clean. Clear thought process.
I have basic understanding of VIPER & this video has been quite helpful.
Thanks 🙏
-
Request: Please make an extended version where there is a card view that appears from the bottom & can have a link that presents another screen.
+ like a reusable component that shows up from different screens, example from 2 different tabs.
It wud be interesting to see VIPER tackle such a scenario.
Basically its the Router part of VIPER that is fascinating me lately.
Thanks
Great content👍, I love when u start project without storyboard. VIPER is one of the design pattern that I want master but always fail. Hope with this tutorial I’ll get proper understanding.
Көп қолданылады ма VIPER Қазақстанда?
@@flutterswift7278 Банктерде колданылады
What I do is that presenter will have reference to View, Interactor and router but only the View will have reference to the presenter. Interactor and Router does not need to have a reference of the Presenter. With using async and await the presenter will wait for interactor to do the network calls and return the data. Its also a good practice to have a separate helper class for the network calls instead of writing them completely in the interactor.
Couldn't manage to *destroy* that like button. It still works.
Haha nice
Finally! Was waiting for that
Get pumped
You are doing very good content! At this time I'm exploring all your videos. Keep going 😁
Thanks!
This is really helpful and clear for me to understand. Thank you!
Youre welcome
Thanks, very nice video! My question is, wouldn't it be better to create an AnyEntity protocol, conform the User entity to it, and instead of the update with users method you could write a more generic update with data anyentity function?
Hi! great learnings in your video and understood VIPER easily because of your video. I have a question that does your code produces retain cycles in router class where interactor, presenter, view contains each other references ?
Thanks
I think maybe the pattern is a bit convoluted... I can’t see myself using it, to be honest. But great video, I learned a lot! Thank you a bunch!!
I can't thank you enough. Keep the good work!
Youre welcome
Excellent tutorial
Thanks!
22:38
“let” was pronounced very sensually :))
p.s. Thanks for lesson!
I think which pattern to use it's depends on project what you are working on. If it's small app then you can use only MVC. But, of course Viper, MVP and so on need to know :)
Yep, i completely agree
Great Explanation helps a lot . 🙌🏻
Glad to hear that!
Thanks for the tutorial. I have question about the code written to create table, label etc. It is a function right, doesnt it get called everytime table or label is accessed and keeps creating new instance of table or label?
Thank you! VIPER has been so overrated. It is so clear now. Can you share the source code for this kind of tutorial?
Youre welcome
Hi do you have git for this? It would be better if also inspect on code to learn better
Awesome vid
Thanks
why does the interactor had to have a reference to presenter? doesn't it better if the interactor just return a result? hence it did not know anything about the caller = less coupled
Good overall I think, I skipped around a bit. I'm already familiar with VIPER and PRESIDIO (RIB architecture) and I've used both extensively but I like to get other perspectives on these things because I feel like there's always something I can do better.
One major problem here though is that you added some specific use case functionality to your core Any* protocols. These functions should really be in separate protocols that extend the Any* protocols and then our concrete classes would implement those.
For example `AnyPresenter` shouldn't be calling for user lists (unless all of your presenters would do that, which still seems like a fundamental flaw) but rather you'd have perhaps an
`AnyUserPresenter`, then your `UserPresenter` would implement that protocol.
It adds another layer of protocols which can be convoluted for an example but the good side of this is that you can now mock out these objects easily in test or swap implementations and do cool things with experimentation in production that would allow you, for example, to switch to a different type of UserView on the fly, with maybe a different UserPresenter that would give a different view into the same data more or less.
I *think* you did this intentionally to water down the number of protocols and make the arch less overwhelming to pick up on, but good overview all around. nice work :)
one more thing, the `start()` method name I think is a bit misleading, but this looks more like a `bootstrap` or `build` factory method, I would expect `start` to be a type of lifecycle method that fires on `viewDidLoad` for example
I am a Korean developer studying viper.
Thanks for the detailed explanation. Then, is it better to inherit the two protocols by describing common tasks in Any* protocol and user-related tasks in User* protocol?
@@eaststone that’s right! That’s what I would do. I would extract all common behavior for your Any* protocols and then make more specific use cases for each scenario like in a User* protocol.
You can implement as many protocols as you want and you can separate them in swift using extensions and even put the extensions in separate files. With the caveat that extensions can’t have stored properties. So you’d have to declare those in the main class. This would probably only be used to keep your file sizes smaller once they get too large.
Happy coding!
@@sexypekk Thank you!!! 👍
@@sexypekk Sorry, but I have one more question.
I think protocols are meaningful for bundling repetitive code into blueprints. So, why implement a function for User as a protocol? This seems to be something used only in User *Class. Is there a big difference between implementing a function for User as a protocol versus implementing it inline?
Great video! Thank you a lot!
You are welcome!
Great content, very good explanation
Thanks!
Thanks for the great video and explanation. Is there a github link to take a look at this sample project code?
Thanks - code available through iosacademy.io/resources
Thanks for this great tutorial, however, I still don't understand why entity (users) has to be in view! I think it would be better if it was in the interactor. also why we should have an API call in the router?! it also should be in the Interactor 🤔
Great example! The only question left is why is the users array inside the view object? View doesn't need to know anything directly about the entity.
have you found the answer yet? I found another viper example also did the same.
Great video as always! Would you mind explaining how to design an app that will run on “small” devices such as iPhone 7 and on “bigger’s” such as iPhone 12 Pro Max?
Thanks and keep up the good work
Waiting for the Clean architecture implementation. Can be Clean VIPER, Clean MVVM,...
FYI- the "Any" prefix is intended to refer to a type erased opaque type that conforms to the protocol.
yep!
Thanks for video, where can I get the source code?
I understand that this is just for learning purposes, but I am guess there is a cyclic dependency that gets created here.
The view has a reference to presenter and the presenter has a reference to view.
Thanks bro
Youre welcome
protocol is declared as AnyInteractor , AnyPresenter etc, but the methods like getUsers, didfetchusers inside protocols are confusing, i think they should be generic.protocols should not be concrete.
It is got to solve the retain cycle.
Yep
Please make a video using VIP architecture pattern for Swift 5
hey, excellent video! and channel, to be honest. but i have a question: why is the router aware of the view? as i understand it, thats not compatible with the diagram of VIPER at the beginning of the video.. shouldnt it interact with it through the presenter? i think its more tedious, but cleaner.
Good call out. Ive seen both approaches
My most favourite part of the video: 02:49
Haha thanks
Lots of bad practices detected! But in general good introduction into the pattern itself
amazing job!
Uuumm... I'll stick to MVVM. Thank you.
Can we use viper and combine together ?
Yes
I want to learn Viper but, I stuck how to implement uitabbarcontroller in viper. Can you show it how next time?
"Main storyboard file base name" doesnt show in my plist file but when I try to run the app it seems it is still there. Is there a chance it is hidden somehow?
What to to next? If I wanna tap the cell to get a network request and push to another Controller? Where and how I should write the codes?
You would use the router to move to the next screen
Can you send a link to the project please?
I don't know, maybe because I'm just a beginner I'm thinking it's a little too much setup, and really I can't get what are the benefits viper brings.
It is a lot but with huge projects it is a clean design
@@iOSAcademy By huge you mean, FANG level of hugeness correct, or am I missing something? Anything less than that I can use MVC or MVVM?
Eh, its subjective. Like airbnb isnt fang but uses it. And othrs too
@@gasparfreak I work in a smaller company than FANG, ain't that big of an app and we use it too. It's good when you have a lot of business logic inside your app. If an app is heavily based on networking, I don't think Viper would be the best, MVC or MVVM is probably better
Oh my god😭👍👍👍
Haha thanks
How you navigate so quickly without using touchpad?
Command shift O
Is the source code for the same is available?
Yes, for channel members
where to put validation code and how to pass data from one viewcontroller to other ?
You can use the router for that, since it is the router's responsibility to contain the logic for the flow of screens. This VIPER tutorial is good, but Viper is not really adequate for one screen apps, but rather for large apps with a lot of business logic in it. Validation code in what sense?
Don’t think it is appropriate to make reference to User in the protocol definitions, should be generic to work across modules. Also an example of routing would be useful.
Wow, this is so fast! Did you practice this 3 or 4 times before recording this video? I'll have to watch it 2 or 3 times to fully inject it into my head but it seems to make sense. Personally, I think VIPER is overkill. Why take something simple and make it so complicated? I hate when things are over-engineered. It just seems like someone is trying to provide job security for themselves. There are no comments in this code. I would hate to have to try and figure this out. I would be cursing the developer and wondering "why, why, why" so many times. I seriously don't understand the point of it, but my new employer wants it probably because some manager heard it was new.
Do you really need the "{ get set }" stuff?
Near the end, when you were not getting any data showing up, I thought it might have been because you were missing that annoying "Allow arbitrary loads" setting in your info.plist file but for some reason, you didn't need that. Not sure why.
Haha thanks - no, just experience
If you have such a good pattern, use it yourself. When people understand patterns, they become the ability to make patterns.
Do not deprive them of the opportunity to develop the ability to design optimal patterns by themselves trying to understand the patterns you have made. Any pattern is very boring and boring.
This isnt my pattern. Its common across industry
2:48 'insert sponser'
Can we have source code
Coming soon
Very fast-paced video and hard to understand. You got to the implementation so fast and confused me about where to put all these protocols and connections
Thanks for the feedback
600 th like
Thanks!
ok i was following until 21:25 then you lost me, you shouldn't be calling an api inside the initialiser
yeah I thought the same. This can cause a race condition.
why don't you ever share the code source ughhh
It would have been cool if the actual View/Interactor/Presenter actually take their references in the initializer, that way we wouldn't need to declare them as { get set } in the actual protocol, just { get }.
protocol AnyView {
var presenter: AnyPresenter { get }
}
class ViewController: UIViewController, AnyView {
weak var presenter: AnyPresenter? // avoid retain cycle
init(presenter: AnyPresenter) {
self.presenter = presenter
}
}
// etc.
Thanks for video, where can I get the source code?