Optional initialization

[vandadnp]

This PR addresses #586

These are breaking changes in that they return optional values from initializers instead of explicitly unwrapping the model objects. We should test these properly!

[yarodevuci]

@3lvis Please approve this

[vandadnp]

We should perhaps bump the version number to 7.0.0 to indicate a major and breaking change 💡

[vandadnp]

@3lvis any updates on this please? thank you in advance

[3lvis]

Hi, sorry, I haven't been focusing on iOS apps for the last couple of years so my replies are usually slower than when I started the project.

I think this has a lot of correct but I get the feeling that this might not be the right approach. I still see some forced unwrapping so I get the feeling that we are moving the problem somewhere else.

[vandadnp]

@3lvis thanks for your response

All the explicitly unwrapped optionals that you can see in this PR are in the tests. The reasons I didn't optionally unwrap them in the tests is that if the situation arrises that the test suite cannot create a data stack, then the tests crash and fail. And that's the expected behavior from a test suite that it fails if it cannot proceed.

[vandadnp]

@3lvis regarding Sync and its future now that you're not focusing much on iOS development. Should there be a discussion in the Issues section about stewardship and the future of Sync? I think if this project is not going to be maintained by anybody, it's only fair to mention that right out in the README.md file so that projects out there like ours using Sync can start migrating to something else. What are your thoughts?

[3lvis]

@vandadnp that sounds sensible, I tried archiving all my projects but some people asked me to unarchive them since it was working for them.

[3lvis]

Had a second look at this, the principal challenge to fix this properly is Objective-C support. I can make a throwable initalizer that checks for the creation of the persistence coordinator which has a lot of try's inside but if I remove Objective-C we have to rewrite chunks of Sync since there's some Objective-C in here.

[3lvis]

Your solution on making it an optional initializer might be our best short term option.

[3lvis]

Doesn't seem like there's a way to reopen this issue.

First of all, I want to apologize for a lack of proper follow up. I have considered the possible cases of doing this as an optional, for example the fact that you wouldn't have been able to see that this was a lack of memory error.

If we go the optional initializer route the crashes will be avoided but the potential downside will be worse since your users won't be able to know what the problem was.

[3lvis]

I have updated the repository marking that it's no longer maintained, and I will reconsider archiving it.