Understand VIPER in iOS for good & stop using template solutions

Understand VIPER in iOS for good & stop using template solutions | iOS Dev Live Mentoring

Рет қаралды 25,406

Күн бұрын

If you want to become a complete Senior iOS Developer, you need to learn how to make solid architectural decisions instead of blindly following templates.
This includes VIPER templates that, when followed blindly, can lead to messy, buggy, and over complicated codebases.
So watch this mentoring session now and learn how to make solid architectural decisions and best use the ideas in VIPER.
Join the iOS Lead Essentials program iosleadessentials.com
Like and share this content with someone that you believe will benefit from it. See you in the next episode.
---
How to Build iOS Apps with Swift, TDD & Clean Architecture series↴
www.essentialdeveloper.com/pr...
Caio & Mike's Book Suggestions ↴
www.essentialdeveloper.com/bo...
---
Subscribe to our channel ↴
kzfaq.info...
You can also find us on ↴
Twitter ☛ / essentialdevcom
Facebook ☛ / essentialdeveloper
Instagram ☛ / essentialdeveloper
LinkedIn ☛ / essentialdeveloper
Caio ↴
Twitter ☛ / caiozullo
LinkedIn ☛ / caiozullo
Mike ↴
Twitter ☛ / mrmichael
LinkedIn ☛ / mapostolakis
Join the iOS Lead Essentials program ↴
iosleadessentials.com
Visit our website ↴
essentialdeveloper.com

Пікірлер: 12

@tifoaudi9241 2 жыл бұрын

hello, may I know about what is your app that you used to draw the diagram in the video? thanks

@EssentialDeveloper 2 жыл бұрын

Hello! We used draw.io ✅

@ChristopherCricketWallace 2 жыл бұрын

I think the important thing is understand the philosophical goal of a pattern--what problems is the pattern trying to address? I understand that for MVC and MVVM; but I don't fully get it for VIPER. WHY does it exists? All I see is heavy use of protocols and separation of concerns for easier composition and dependency injection (and inversion?). But you can/should do that with ANY pattern, right?

@EssentialDeveloper 2 жыл бұрын

That's it, Christopher! You can achieve any good separation, as need, with any of those patterns. But following a template blindly may lead to suboptimal solutions. That's why we don't recommend following templates. Instead, we need to focus on solving our own problems rather than trying to fit our problems into a pre-defined template ✅

@karmiris0721 2 жыл бұрын

From my personal opinion, I just think that the basic elements described by VIPER exist in pretty much any other pattern and it's just that VIPER provided a name for them to make it easier for devs to identify them.

@nikk6578 2 жыл бұрын

Hello Caio and Mike. Thank you for video and sharing your knoledge. Could you answer please about organization of repositories: If we have only CoreData that's easy to define in AbstractRepository return needed type of entity. But when a concrete repository requests data from network then will be asynchronous response with callback/observer/promise. So my question - what is the best solution to handle it? As I see there are only two ways: 1st: define async in repository abstraction, for example return type as "Observable" 2nd: transform async call into sync via "DispatchGroup enter()/wait()" to conform But both looks to me a bit ugly. Dont know why, probably because never saw same decisions :) What do you think about suggested appoaches, is there another way to handle it, probably better? Thanks

@EssentialDeveloper 2 жыл бұрын

Hi Nik! That's a great topic for a mentoring session. Sign up here for a free session with us: www.essentialdeveloper.com/mentoring - but hurry up because we have only a few slots available!

@ardaonat8257 2 жыл бұрын

Hello, thank you for the video. How do you create mocks, spys, fakes for unit tests if you don't use protocols for each layer? Do you subclass them?

@EssentialDeveloper 2 жыл бұрын

Hello! It depends on which layer you're referring to. By decoupling UI and Presentation from API and DB details, for example, you avoid having to mock those dependencies at all. You can test each layer in isolation. And you drastically reduce the number of protocols you have to create ✅

@ardaonat8257 2 жыл бұрын

@@EssentialDeveloper Thank you. What if we use the approach where we want to develop each feature in different teams and because of that we need all the layers in the same module? Do you prefer using the protocol approach?

@EssentialDeveloper 2 жыл бұрын

Hi! We're not against protocols. You should use them when needed as we described in the video. But you don't solve all problems with protocols. In this case, each feature team should work independently. So they shouldn't have to share any interfaces/protocols. Feature teams ideally shouldn't depend on other feature teams directly, otherwise they won't be able to move fast (there can be a lot of coordination). Each feature team can work on their features in separate modules/frameworks and later compose the whole app in the main app target composition root.