-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async media: Scroll to failed post from error notifications #6424
Async media: Scroll to failed post from error notifications #6424
Conversation
Agreed. I'm starting to think we should also add an outline of the posts w/ their associated alert color (error = red, alert = yellow, etc), but let's obviously hold on that idea. |
@iamthomasbishop updated to display the post is at the top of the list instead: |
one thing that I'm not sure about here is that when you tap the notification and you're shown the list of posts, with the error one being the first one shown, it looks like that is actually the absolute first in the list. We do have the subtle hint that it is not because the scrollbar appears and disappears on the right, but still wondering if we could maybe not make it the top most item but center it in the screen, or maybe just show a little offset so the item above it shows a bit, to hint the user there's more stuff up there? Just thinking aloud here, what do you think @iamthomasbishop ? |
@mzorz I very much agree. If we could have the post before it hang 10-20dp off the top there, that'd be helpful. Another option - start at the top of the list when the page loads, and smooth scroll quickly to that post. |
What if we leave it as is, but make an animation on the alpha highlighting the item to bring the user's attention? |
@mzorz I'm okay with that! |
@iamthomasbishop @mzorz I did two options, the smooth scroll (can be made slower than this), and the alpha highlight. The alpha one is maybe going to be a bit more error prone as it had to be done in a somewhat hacky way. Smooth scroll:Alpha highlight/blink: |
The alpha one feels almost like a glitch to me, not a highlight. The scrolling one seems solid. |
LGTM @iamthomasbishop if you agree I'll merge 🙇 |
@aforcier @mzorz That's much better! Very small request - Can we make the post before the error'd one hang off the top of the screen 10-20dp? Very rough sketch for reference: https://cloudup.com/c3hjt8YwZhD |
@iamthomasbishop sure! Here are |
I like 20dp the best |
@iamthomasbishop asked to bump the offset a bit to Design review is done @mzorz, ready for a new code pass 🎉 |
PostsListFragment oldFragment = mPostList; | ||
mPostList = PostsListFragment.newInstance(mSite, mIsPage); | ||
mPostList = PostsListFragment.newInstance(mSite, mIsPage, targetPost); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PostsListFragment.newInstance()
only uses targetPost
to obtain it's id
and set a parcelable argument. Later on that id
will be properly used to retrieve the actual PostModel
from the db when it is actually needed.
Also, the only reason why PostStore
is imported and injected here is to be able to get the PostModel.
Why don't we just remove the use of mPostStore
in PostsListActivity altogether, and pass the ID here as well?
This would also be in line with the decision taken on trying to avoid this kind of PostModel
passing around because of potential OOM problems, like in this PR here #5856
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case we're passing the PostModel
directly to a method, it's not being parceled, so #5856 shouldn't apply.
I decided to use the model for two reasons:
- We won't create a new instance of the
PostsListFragment
if the post has since been deleted (since it would have a non-0 id, but thePostModel
obtained from the store would benull
) - This avoids
PostsListFragment.newInstance()
taking an int id argument, which is error-prone and the main case for using models over ids
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case we're passing the PostModel directly to a method, it's not being parceled, so #5856 shouldn't apply.
Forgive me, I wasn't clear: I was trying to acknowledge how the same treatment to this case is given within the fragment by using the ID instead of the PostModel. I should have said something like "it's great to see we're using this in the same way here".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having discussed these 2 points in Slack, and acknowledging point 1 is better kept as is as per the advantage of keeping fragments, and leaving point 2 for a longer discussion elsewhere, here's one minor thing users could benefit from:
If the user taps on an error notification for which the referred PostModel
doesn’t exist anymore (i.e. has been deleted) we should do something else then, maybe show a Toast or something, indicating the Post wasn’t found.
To test:
- start draft
- make it fail
- delete draft
- tap on notification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added toast in fece2bf.
@@ -21,13 +21,14 @@ | |||
|
|||
public class PostsListActivity extends AppCompatActivity { | |||
public static final String EXTRA_VIEW_PAGES = "viewPages"; | |||
public static final String EXTRA_ERROR_MSG = "errorMessage"; | |||
public static final String EXTRA_TARGET_POST_ID = "targetPostId"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we rename this to EXTRA_TARGET_POST_LOCAL_ID
- I'd be happier :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ yes, good catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 3e0b6f6.
Ready for another pass I believe @mzorz. |
final int position = mPostsListAdapter.getPositionForPost(mTargetPost); | ||
if (position > -1) { | ||
RecyclerView.SmoothScroller smoothScroller = new LinearSmoothScroller(getActivity()) { | ||
private static final int SCROLL_OFFSET_DP = 23; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a comment here explaining why we are moving this offset? maybe something like // we're showing just a bit of the item above to hint the user they can navigate up
(feel free to re-write to something better worded than this)
There's one thing I found: if you rotate the device the List is always scrolled to the top. So, say the problematic post is somewhere in the middle, it fails, you tap on the error Notification and are correctly scrolled to it, but then rotate the screen, the list loses its position and the first item is shown. To test:
|
I confirmed this is happening in |
LGTM |
Addresses a suggestion from @iamthomasbishop (marked in the to-do list here).
#6420 should be merged before merging this PR.
When tapping a notification for a failed post upload, the post list is opened. Instead of showing a dialog, the list will now scroll down to the post that failed, and a dialog is no longer shown.
@iamthomasbishop it looks to me like it would be better to scroll a bit more, so that the post appears at the top of the list (rather than scroll just enough to reveal it at the bottom as in the demo above). I can change that but waiting for any more feedback on that you might have before diving in.
cc @mzorz