readying for re-release checklist (iOS)

[falquaddoomi]

(This is a duplicate of issue #18, but specifically for iOS users rather than Android users.)

Before we re-release, we should verify that the following items are addressed:

Regular App Usage (Searching, Viewing, and Following):

Home and search screens:

• [ ] homescreen shows search box, which triggers a search when filled and submitted
• [ ] search screen shows results for the query
• [ ] when search box is defocused, onscreen keyboard should disappear
• [ ] scrolling through more than a screen's height of search results should display a "scroll to top" indicator in the bottom-right corner
• [ ] the "scroll to top" indicator should return to the top of the list
• [ ] pressing the "legend" button should display a full-screen modal
• [ ] the "legend" modal should appear correctly regardless of screen size/orientation, and be scrollable if it clips off the bottom of the screen
• [ ] the "legend" modal should be dismissable by clicking anywhere on the screen, including the "close" button (CHANGED: legend modal is now dismissable only via the "close" button, to allow the user to scroll it.)

Details view:

• [ ] pressing a search result should display its "Details" screen
• [ ] On the "Details" screen, pressing the "open in browser" button (top right corner) should open a browser to the variant's information on brcaexchange.org.
• [ ] Links that appear in the details should be blue, underlined, and clickable, opening the browser to the link's target.
• [ ] Version history should appear at the bottom.

Results list icons:

• [ ] the follow status of the selected variant should be indicated by the "follow" button (green "following" if currently followed, gray if not; pressing should toggle its status)
• [ ] the pathogenicity icon should correspond to the text status (legend available on search screen)
• [ ] upon returning to list after following a variant, the "following" bookmark icon should be filled for that entry
• [ ] pathogenicity icons in the results list should correspond to their pathogenicities on the "Details" screen
• [ ] On the "Followed Variants" screen (accessible from the sidebar), variants you follow should appear in the list

Help/resources:

(Items below are accessible from the drawer.)

• [ ] "About This App" should display appropriate information about the app (check for weird references to the site or otherwise). Link should be clickable and open a browser to brcaexchange.org.
• [ ] "User Guide" should be a placeholder with a clickable link to brcaexchange.org.

Notifications

Notify Log

Instructions on testing notifications can be found here: Debugging Notifications. The below assumes that you're following "c.956a>c" and enabled the mock server with quicker refreshes.

• [ ] On the "Notify Log" screen, verify that pulling down on the list causes it to display a loading spinner.
• [ ] Verify that, when the refresh completes, it produces the text "Refreshed!" or "Already up to date!"
• [ ] If an entry appears, the "unread" icon (the dot on the right side of the entry), should be blue to indicate that it's unread.
• [ ] Pressing the entry should navigate to the details screen for the listed variant. (Note that if you're using the mock server the pathogenicity on the details screen won't correspond to the notification, since the details are loaded from the production server.)
• [ ] On returning to the Notify Log, the clicked entry's "unread" icon should now be gray.
• [ ] After refreshing in ten minutes or so to produce a new entry, the new entry's "unread" icon should be blue whereas the old entry should remain gray.
• [ ] Pressing "Mark as Read" should, after a prompt, convert any unread entry's icons to the gray "read".
• [ ] Pressing the "Mark as Read" button if there are no unread items should do nothing.
• [ ] Pressing "Archive" should, after a prompt, clear the list.
• [ ] Both the "Mark as Read" button and the "Archive" button should become gray if there are no applicable items in the list.
• [ ] scrolling through more than a screen's height of notification results should display a "scroll to top" indicator in the bottom-right corner
• [ ] the "scroll to top" indicator should return to the top of the list

Background notifications

For these tests, you should leave your phone idle and then check on it later.

• [ ] Within 30 minutes, you should see a notification for c.956a>c.
• [ ] Pressing this notification should open the "Notify Log", displaying the new version.

Possible scenarios in which to test the background task:

• [ ] App not in the foreground, but potentially still memory-resident.
• [ ] App likely no longer memory-resident (usually after a few hours of phone usage without activating the app).
• [ ] App explicitly evicted (on recent Android/iOS versions, by swiping it off the app switcher)
• [ ] Phone rebooted

[melissacline]

On my iPhone 5C, I'm getting everything except this:

On the "Details" screen, pressing the "open in browser" button (top right corner) should open a browser to the variant's information on brcaexchange.org.

When I downloaded the app during the day on Nov 15 and followed c.956A>C, I didn't receive any notifications until late that night. Now, I seem to be receiving notifications regularly.

[falquaddoomi]

Good catch regarding the missing link button; incidentally the button does render in the debug build, but not in release. I've worked on it a bit since you reported it, and it appears that it's now rendering in release as well, but I'll release a build in a few minutes to make sure.

Here's what it looks like in debug, for reference:

(Details for the curious: the button was the only absolutely-positioned child inside a View, which apparently is getting optimized away in release since it just holds a single View. Unfortunately culling the View affects its children's positioning on the page, since Views are relatively positioned by default, but the View's parent is a flexbox. I switched out the containing View for a Component, which never gets rendered anyway, and that seems to sidestep the culling issue.)

[falquaddoomi]

Regarding the late refresh, it's hard to say why it didn't run until the evening. My assumption is that the task had a chance to run once without the "Quicker Refresh Interval" option enabled, which would set its backoff timer to 12-24 hours. Unfortunately changing the refresh interval only effects the backoff timer the next time the task runs to completion (although I'm strongly considering changing that behavior now). It's also possible that the OS just didn't find an opportunity to schedule it until the evening, although that seems unlikely.

EDIT: actually, I'm going to include resetting the refresh timer when "Quicker Refresh Interval" is enabled in the build I'll be releasing in a minute.