Re-evaluate Data persistence Layer

[shayneptorres]

Right now, it looks like the personal contact info is being stored separately as a name and a number in UserDefaults. While this works I believe that there is a better way to persist this information which will make querying it much easier, manageable, and safe.

Some suggestions are: 1.) Model the personal contact info in a Codable class that can be serialized/deserialized into UserDefaults, that way we don't have to check the individual keys (ie "name1", "number1"). This will also allow the user to store an arbitrary number of personal contacts, instead of the hard limit that we are setting 2.) Model the personal contact info in CoreData. If we don't want to rely on UserDefaults we can turn to CoreData to model and manage the persistence of our personal contact info 3.) Model the personal contact info with Realm. This is another Database tool that I use in all of my projects. It is much easier to setup and user (in my opinion) than CoreData. Setting it up in Realm will help if there are things in the future that we want to persist.

There are pros and cons to each, but let me know what you think.

[eddielement]

Agreed! I feel like this could apply for all elements of the safety plan (which are all in UserDefaults), not just personal contacts. Could you dive into the pros and cons of each? Out of the 3 options you listed, I've only ever worked with Realm before.

[shayneptorres]

User Defaults Pros:

• Lightweight: Does not require much setup or overhead that comes from importing a database layer

Cons:

• No way to clearly/strictly model data, we have to manage it through keys
• Not great at querying/filtering data.
• Modeled data is not what User Defaults was made for

Core Data Pros:

• Supported by Apple: Since core data is supported by Apple, the updates are taken care of whenever there is an update. No waiting for 3rd party developers
• Is the default implementation for many different apps
• Versioning/migrations is simple
• We can assume core data will be around for as long as iOS development is around

Cons:

• If not imported into the app from the start, it can be bit tricky to setup the persistence containers

Realm Pro:

• Very easy to setup
• Versioning/migrations are simple
• Realm works for Android too, so both platforms can use the same database layer
• Very easy to model relationships

Cons:

• It is not thread-safe so extra precautions must take place if we want to implement asynchronous features with Realm
• It is a big library, the biggest of the three options.

As a disclaimer, I have only used Core Data for a number of projects so I am not incredibly familiar with everything it has to offer. I use Realm in all of my personal projects and and my work projects. My vote would go towards using Realm but I am willing to be persuaded.

[eddielement]

I wonder if @prolefeed has any thoughts here? (Since he's planning to work on rewriting the Android app into Kotlin.)

[shayneptorres]

@eddielement As we are finishing up the Swift conversions, I believe that this issue would be an important one to implement. Did you have any further thoughts? I would throw my vote in for using Realm but wanted to get your thoughts

[eddielement]

I would vote for Realm too! Let's do it! @shayneptorres

[shayneptorres]

Sounds good, I will begin working on the implementation of Realm for the data persistence layer. I will create a new Issue specifically for the Realm implementation.

[shayneptorres]

Work for this issue will be tracked in Issue-19