[Feature] Show overview of activities

[sthewissen]

What

• [x] User should see an overview of their community activities
• [x] They should be ordered descending by activity date.
• [x] ~Should be grouped by current / previous award period.~ Not possible through the API.
• [x] Each item should show category, title and date.
• [x] ~An image should be shown if the URL is filled and we can get one from the page through OpenGraph.~
• [x] Tapping an item opens the read item view.
• [x] Tapping a button shows the add item wizard modally.
• [x] Load an initial amount of items (25?) and load more as you scroll further down.
• [x] ~Show an icon of the contribution type if we cannot get a picture from the web?~
• [x] Reload data when edit/add happened.

[sthewissen]

Updated the specs on this one.

[sthewissen]

Challenge here is to grab all the OpenGraph images for the entire backlog of activities. It's quite an intensive operation to run, so it probably needs to run in the background (maybe through something like Shiny?). Parts of the backlog will probably never change anymore since they are activities from outside of the current approval window. They will also probably need to be cached because we don't want to grab this data every time the overview is loaded. Both the image itself and the URL should be cached.

One caveat is that the URL could change for an item from outside of the app (e.g. through the web portal), making the cache stale. This means that there needs to be some sort of trigger to represent that OR we simply ignore that scenario and have the user edit the thing (without changing anything) to trigger a save and grab the new image.

[sthewissen]

Additional challenge We want to load these contributions progressively since there are people with decades worth of MVP contributions. My last experience with CollectionView and the Threshold functionality wasn't a glorious one though. @Depechie has an implementation that might work better, so keeping that in here for reference.

[Depechie]

If you are referring to my POC for the data loading/caching, it just uses the CollectionView threshold too :/ What are the issues you ran into in previous tries when using it?

And I do agree, somehow we should have more options, instead of what the API can brings us now. Not sure how communicative the API builders at Microsoft are? You mailed them before I guess?

[sthewissen]

Oh boy. I wish I could say something nice about them, but they are pretty much non-responsive. I think it's also built externally (which is odd to me but heck). Just no response whatsoever, even when going through internal MS channels so the odds of something changing on that end are close to zero.

What I had with CollectionView thresholding was that I saw items duplicating and seemingly the same API call being done a few times (which I couldn't quite explain yet).

[sthewissen]

Ok, looking at this issue once more, I scrapped a few features based on lacking API things:

• No possibilities to separate between the current award period and previous (editable or not) because it's not provided through the API.
• Not sure yet if loading on scroll should still be a thing. At some point, it's just grabbing data that will never ever change.
• I'm ditching the images thing.

Caching of stale data

The biggest issue I still have is grabbing all the data and caching it locally. Ideally, I want to have all the contributions stored locally and only ping the API sporadically when needed. There is a cutoff point (April 1st of each year I believe) after which everything before it is not editable anymore. This data should never be coming from the API anymore after an initial load.

However, creating some sort of caching mechanism that merges those two sets of potentially editable and uneditable activities is what is kind of boggling my mind right now. Especially as it's a shifting set as the next April 1st a new batch of things gets smacked into the "uneditable" bin.

[sthewissen]

So, verdict: There will be no caching of contributions. We will always poll the API for the latest set and progressively load more as the user scrolls. Managing a cache and keeping that in sync is just too much of a hassle for something that should be fairly simple and straightforward.