-
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
Allow a post to be marked as sticky #15351
Allow a post to be marked as sticky #15351
Conversation
For now, it's still a dummy switch (due to FluxC needing to be updated). We're updating its value when all the views are updated.
This depends on an update of the FluxC library (PR pending).
Added "Allow users to mark Posts as sticky [wordpress-mobile#15351]"
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
You can test the changes on this Pull Request by downloading the APKs: |
WordPress/src/main/java/org/wordpress/android/ui/posts/EditPostSettingsFragment.java
Outdated
Show resolved
Hide resolved
WordPress/src/main/java/org/wordpress/android/ui/posts/EditPostSettingsFragment.java
Outdated
Show resolved
Hide resolved
Generated by 🚫 dangerJS |
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.
The FluxC component of this PR has been merged in. A FluxC artifact is being built on FluxC's develop
wordpress-mobile/WordPress-FluxC-Android@e20192c
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.
@dnalves while testing and comparing both platforms I noticed that on iOS we are showing a Sticky
label on the Posts List Cell
as seen below in the screenshot. This was not included in the design specs that were attached to the issue. Nonetheless, in the name of platform synchronicity, we could make both Posts Lists Item States
represent the same behavior when a post is sticky. What do you think?
Just a note here, from a design standpoint, if you agree with proceeding we could replicate this design approach i.e putting the label in a separate row within the |
Nice catch @jd-alexander, it makes total sense for the behavior to be similar. From what I noticed, the "Sticky" label is concatenated with the other labels at the bottom. We can replicate it. What do you think?
|
I agree!
Good observation! Sounds like an optimal approach that adheres to the current design specifications of the Posts List Item! I will check it out. |
@@ -3,6 +3,7 @@ package org.wordpress.android.viewmodel.posts | |||
import org.apache.commons.text.StringEscapeUtils | |||
import org.wordpress.android.BuildConfig | |||
import org.wordpress.android.R | |||
import org.wordpress.android.R.string |
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.
I am not sure if we should be making this change 🤔 I know it is used in other places within the codebase but it seems unrelated to the task at hand here. If it's a case where the CI is failing due to it then I guess it's fine to proceed as it might be a new rule I am not aware of. Let me know your thoughts.
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.
Android Studio function extraction did this and I didn't notice. When I read your comment I was surprised by it as well. I'm fixing this!
} | ||
} | ||
|
||
@Suppress("LongParameterList") |
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.
I know this solution works. I have seen it in usage elsewhere but I know we are not fond of doing suppressions. Part of me feels it would be better if we simply pass the PostModel
here and create these values within the function to lessen the parameters substantially. Do you have any thoughts on this discourse?
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.
I'm not a fan as well, to be honest. I added here because I assumed in this case the long parameter list wasn't making the function more complex or harder to understand (given that the parameters were well named).
But I like your solution 😄 I'll pass the PostModel
instead of a few parameters.
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.
Thanks! I remember one of the concerns for passing around thePostModel
is that it's quite a big object that contains so much information about the post that we may not require. To ensure we are making the best decision here, I am going to loop in another Android developer who has worked with these kind of decisions.
Hi @ParaskP7 I remember us making a decision about @Suppress("LongParameterList")
in one of my PRs a few months back. In this case, we were opting to remove it and pass in a PostModel
to represent several parameters that were extracted from it. However, we know the PostModel
is quite a large object. Do you have any thoughts on this? Let me know. Thank you.
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.
I remember one of the concerns for passing around thePostModel is that it's quite a big object that contains so much information about the post that we may not require.
In this case, we were opting to remove it and pass in a PostModel to represent several parameters that were extracted from it. However, we know the PostModel is quite a large object.
Thanks for looping me in to this conversation Joel. I would personally go with passing the whole PostModel
and thus resolving the LongParameterList
warning. My reasoning would be:
- The
PostModel
is already in memory, so I am not sure if it being a large object would degrade performance or cause any trouble. I haven't looked at the code extensively, but are you having concerns about passing this object between screens, thus having is unnecessarily being serialized and deserialised, or is it just being passed from one class/method to another? - I am not sure how big could potentially the
PostModel
end up being, thus I might be totally off here, but I would not try to optimize performance preemptively by sending individual properties of this object. However, this is my personal rule of thump, which might very well not apply here, so please take it with a grain of salt.
Let me know if I can further help here or whether I am missing some more context. 🙏
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.
Thanks for the quick response on this matter 😄 I agree with your points. About your question:
[...] are you having concerns about passing this object between screens, thus having is unnecessarily being serialized and deserialised, or is it just being passed from one class/method to another?
This is just from one method to another, so no serialization occurring in this case.
@jd-alexander: I made those changes in 982bd0f, already resolving the LongParameterList
😄
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.
The PostModel is already in memory, so I am not sure if it being a large object would degrade performance or cause any trouble. I haven't looked at the code extensively, but are you having concerns about passing this object between screens, thus having is unnecessarily being serialized and deserialised, or is it just being passed from one class/method to another?
It's just being passed to another method and yes it is already in memory :)
I am not sure how big could potentially the PostModel end up being, thus I might be totally off here, but I would not try to optimize performance preemptively by sending individual properties of this object. However, this is my personal rule of thumb, which might very well not apply here, so please take it with a grain of salt.
Let me know if I can further help here or whether I am missing some more context. 🙏
The thoughts you shared were spot on. You picked up the context quite quickly, just like an Android API using requireContext()
😄 😆
Thanks for chiming in @ParaskP7 . I think the current approach here is fine!
Change which import we're using for R.string. Remove a detekt supression and fix the LongParameterList issue
@dnalves I was doing some more testing and I noticed something.
|
@dnalves since there were some new changes in FluxC we can use the latest |
hasUnhandledConflicts: Boolean, | ||
hasAutoSave: Boolean | ||
): List<UiString> { | ||
val labels: MutableList<UiString> = getErrorAndProgressStatuses( |
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.
Isn't the type of labels inferred by the compiler? Let me know what you think.
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.
Oh, nice catch! Android Studio method extraction tool made this and I missed it, thanks for pointing it out :D
985ed1f#diff-2238863dfadc135bc1b6359a21a855541d2dcf3d8cd2742d2fa91a81ea03e701L288
You're totally right! I missed this because I was testing only with private posts (which makes all the labels yellow). I added the "sticky" label to the list of "info" labels, which are colored yellow. |
Thanks for these changes @dnalves Could you please update the tests to represent this behavior as well. When modifying files in WP Android, it's always best to check if there are associated tests ( which you have done previously 😎 , so I am just noting here as a general reminder.) 👍🏾 I normally Command-click a class to verify if tests are associated or not. |
😱 |
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.
Thanks for these changes @dnalves LGTM 🚢
Fixes #7953
This is still in progress, please don't merge
Description
We wanna allow the users to mark a post as sticky from the Android app. This is already present in iOS and Web.
A blocker for this PR is the approval of wordpress-mobile/WordPress-FluxC-Android#2124 and an update of the FluxC library (which will add the "sticky" field to the
PostModel
).Work done
A switch was added to Post Settings screen. This is loaded and updated in the
PostModel
(from FluxC), which syncs it to the Wordpress servers.This switch only appears for Posts, so it is hidden for Pages.
Screenshot
To be done
To test:
Regression Notes
Potential unintended areas of impact
None
What I did to test those areas of impact (or what existing automated tests I relied on)
Manual tests
What automated tests I added (or what prevented me from doing so)
There are no tests surrounding that Fragment. And any unit tests added will be testing the FluxC library.
PR submission checklist:
RELEASE-NOTES.txt
if necessary.