I'm not seeing anything about conditional requests in the schema-update code.
This should use standard conditional HTTP requests. When bundling a version of the schema, the ETag should be stored somehow (perhaps as a property that's added to the JSON?), being careful to use the same Accept-Encoding: gzip header that's (hopefully) used later. Later requests should send the ETag in If-None-Match, such that, most of the time, clients shouldn't ever get anything other than a 302, even in a new installation. If a new remote version is ever available, the ETag should be stored again.
I would recommend against using the group id as the primary identifier, with -1 for personal. It's not guaranteed that there won't be multiple personal libraries in the future, and there could be non-group library types we'll want to support later. (E.g., in the client we have feed libraries.) Not sure how Realm works, but if it should be an integer of performance, I would assign a local auto-incrementing library id, which is what we do in client and server. If the DB uses some other internal integer regardless, it could be something like L1 (for personal library) and G1234, where 1234 is the remote group id. [That's a dumb idea. Don't do that]
Along the right-hand edge of the table view, as in the iOS contacts view and various other apps.
Not sure if there's a standard or popular open-source control for this, but ideally it would also be able to handle other field formats so that we could use it if, say, you were sorting by date. (I feel like I've seen that on iOS, but not sure where. I think I've seen it with years shown in the control, but with a month overlay in the middle of the screen as you move through the dates.)
Right now trying to open a PDF that fails to download (e.g., because it's not available online) still opens the PDF reader. It should just show an alert that says the PDF isn't available. Not quite this, but same idea:
Before opening this up, we'll need to add an AGPLv3 license file and note in every file that it's AGPL licensed. (In the meantime, there's no need to add "All rights reserved", which doesn't mean anything anyway.)
Right now, if you scroll down to the middle of the items list while new items are being pulled down, the list will start to jump all around as items are added.
There's no perfect solution here, since the items you're looking at may not remain contiguous, but we could maintain the position of the first fully visible item in the current view, which should generally result in a fairly anchored view. If that item is removed from the view, we'd have to go with the next item in the list, which would take its place.
When I start the app, I'm in My Library, but I still see the library list in the left pane. It should instead show collections for the current library.
Do we want to show a sync progress anywhere? Where and what do we want to show if yes. Where do we want to show the sync button with the ability to start new sync or cancel current sync.
Currently, the items list isn't refreshed until the whole sync process is done. We should refresh throughout the sync, though we have to balance responsiveness and performance.
In the client, I increase the refresh batch size as the sync goes on for a smoother start:
So the first 10 items appear immediately, and then batches of 5 up to 50 items, and so on. We don't have to do exactly that here, but we should make sure there's immediate feedback as new items (and collections, for people with thousands of collections) come in.
Maybe we already have this, but if not, we need to make sure that a 5xx response for any HTTP request always retries on a backoff schedule — otherwise we'll end up DDoSing ourselves as more and more clients fail.
(I noticed this in the retryInterval in SchemaController. In the desktop client, the API client automatically retries after 5xx errors on a backoff schedule, such that the calling code doesn't have any knowledge of the 5xx unless a maximum number of retries is reached. Since a 4xx should fail permanently and a 5xx should be retried automatically, the calling code shouldn't need to bother with a retry interval.)
Since we're following a similar offline-first model as in the desktop client, we probably want both a sync indicator and the ability to cancel syncs. This isn't a priority, but cancelling might have an effect on sync architecture, so worth keeping in mind. (In the client, I just set a cancellation flag when the cancel button is clicked and check for the flag at various points during the sync — beginning of each object download batch, etc.)
I'm not sure whether we care about sync progress. In the client we can show progress info on sync button hover, so if we want that here we'd have to use a different sort of indicator, but that might be unnecessary.
It looks like we're supporting Dynamic Type in some components (e.g., the collections tree) but not others (e.g., items tree). We should make sure we're supporting it everywhere.
Render notes as HTML and extract plaintext through either the first newline or some number of chars (whatever a reasonable max might be in landscape), and then store in a separate column for display and sorting.
Search conditions have a fixed order that needs to be maintained on edit. Unless I'm just missing it in Realm Browser, it doesn't seem like an order is currently being stored.