Closed timarnold closed 10 months ago
Similar to your question #9 — this is for two reasons: (A) threading reasons. The init
code may not run on the thread that the SyncCoordinator
should use. Secondly, an explicit call to setup
allows us to create the SyncCoordinator
, do additional configuration (e.g. setting a delegate) and only then trigger the setup
. In the trivial example code that's not needed, but we still wanted to show that pattern.
It’s probably overwhelming, but you may want to take a look at https://github.com/wireapp/zmessaging-cocoa — it uses a similar architecture.
Does the Moody sample app actually require that the setup methods be called on the sync MOC's thread (using performGroupedBlock
), or is this again just an illustration of a best practice?
Thanks for your answers --- I had the vague idea it was "for doing things safer while using multiple threads", but I just haven't yet found a resource that has allowed me to understand what the specific dangers are and when one encounters them. For example, in the case that my app only ever has one SyncCoordinator
, is all of this a bit overkill, demonstrating best multi-threaded practices but not actually necessary? Do I only need to worry about this sort of stuff if I have less control over how my SyncCoordinator
is used?
Why not just perform these operations in the
init
method? I'm not sure I see the utility of this pattern. Is this simply to protect against someone initializing aSyncCoordinator
at the same time on separate threads?