Today I have uninstalled the Dropbox app from my Mac. I’ve been an early Dropbox user and invited friends until I got up to 10 GiB, which was a ton of storage back in the day. But the native apps gets more and more annoying; they have a history of faking system standard dialogs to “trick” you into installing the kernel extension with root privileges; and resource consumption was at times confusingly high. Stuff like that made me tired of the app.
Continue reading …
Found a very detailed article about how a team implemented VIPER in their iOS project written by Michał Wojtysiak & Bartłomiej Woronin.
They discuss general project architecture, using tools to generate module files, and how passing data from one Wireframe to another works in their app.
I haven’t used VIPER in an iOS app, yet, but I used the concept in the Word Counter. There, nothing’s disposed after setup, so I have all Wireframes and their components setup once upon launch. The authors use Wireframes as factories for view controllers.
A Note about Syncing Changes: Where to Handle Sync Events
Further down, under “How to deal with listening changes from backend?”, the authors show how synchronization changes take effect.
- The
SynchronizerService merges changes into the Core Data stack,
- the Core Data Stack sends a notification,
- the Interactor receives the notification,
- and changes are then pushed through the Presenter to the View.
This works, but I find the decision to be weird. Now the Interactor prepares data when requested and pushes changes upon synchronization events.
Usually, the Presenter is created in such a way that it both presents data to the view and handles events from the view. You can split this into two objects, let’s say Presenter and EventHandler. Then it becomes clear that the EventHandler can deal with events both from UI interaction and from syncing. It’s the best fit to translate any event into a command for the Interactor so it does its job.