EXPERIMENTS

#056 ReSTRUCTure
    Exploration
by Anupam, 03/22/23

Context

Sharing some in progress work - no download link this week!

Overview

This (shorter) week, I had two big goals:

  1. Continue Dub Code Restructuring
  2. Testing Data Persistence / Remove Optionals

And while #1 has been taking a considerable amount longer than I thought, #2 (removing the series of optional chaining) is seemingly impossible. But, we push forward!

With #1, this week I’ve been focused on creating structs (hence the naming of this week’s post) for Profiles and Spaces - creating a flexible interface for us to dynamically create groups of wallets, groups of tabs, and groups of history - to map them together in new and interesting ways that might create some exciting future features.

The Dub code restructuring has been… slow. I’ve had to make and toss code decisions more frequently than I expected, resulting in a two steps forward one step back kind of progress. So far, I’ve been focused on moving TabManager, WalletManager, and HistoryManager into a more flexible Spaces and Profiles menu. I’m pretty close to clearing this all up, but realized that exploring goal #2 might solve some of the problems. Read on below for more👇

Process

As I’ve been migrating tabs, wallets, and history into a more flexible spaces and profiles menu (see Experiment 48), I’ve run into a couple issues with how tabs are accessed and retrieved.

Since everything was previously structured as the child of a tab manager, function calls were able to move up in the tree to access the list of relevant tabs; without this structure, every function call becomes much more complicated (everything has to go through Dub store).

To simplify this, I was hoping to pass around the TabManager itself (instead of an ID - also removing the issue with having optionals across the app). But, this causes potential issues for data persistence (as it might end up duplicating the stored data). I started experimenting with this to come up with a potential solution and… no luck. But it’s still interesting to show!

I spun up an Xcode project with the same basic data model as our app - just, a lot simpler.

Data Persistence Test

And, I tried a bunch of stuff to properly serialize the data to disk WITHOUT duplicating data. Forcing classes to print as references, structs,

But, consistently ended up with output like this:

{"spaces":[{"profile":{"history":{"test":5},"wallet":{"test":"test"}}}],"profiles":[{"history":{"test":5},"wallet":{"test":"test"}}]}

If you look above, you’ll notice that the “profile” data is duplicated; and unfortunately, the only workaround is using UUID (universal unique identifiers) to simply reference the objects rather than store them.

…which is what we were already doing. No luck :(

Next Steps

Because of my experimentation, I now have a much better grasp on implementing data persistence for Dub store with our new structure - which I should have hopefully wrapped up in the next week or so.

So, for the coming sprint:

I’m also excited to poke a bit more around our data collection / analytics strategy.

More to come soon. See everyone next week! 👋