Skip to content
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

Conversation

dnalves
Copy link
Contributor

@dnalves dnalves commented Sep 18, 2021

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

  • Identify any regression areas
  • Localize strings
  • Add details to the release-notes

To test:

  1. Open a site with posts in it
  2. Open a post to edit it
  3. Tap to edit "Post settings"
  4. Toggle the switch "Stick post to the front page"
  5. Update the post with the changes (sync it)
  6. Check on Web or iOS that the changes were applied
  7. Revert the change on Web or iOS
  8. Check on Android that the change is reflected there

Regression Notes

  1. Potential unintended areas of impact
    None

  2. What I did to test those areas of impact (or what existing automated tests I relied on)
    Manual tests

  3. 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:

  • I have completed the Regression Notes.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

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).
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Sep 21, 2021

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Sep 21, 2021

You can test the changes on this Pull Request by downloading the APKs:

@dnalves dnalves changed the title [WIP] Allow a post to be marked as sticky [DON'T MERGE] Allow a post to be marked as sticky Sep 21, 2021
@dnalves dnalves marked this pull request as ready for review September 21, 2021 10:31
@peril-wordpress-mobile
Copy link

Warnings
⚠️ PR is not assigned to a milestone.

Generated by 🚫 dangerJS

Copy link
Contributor

@jd-alexander jd-alexander left a 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

Copy link
Contributor

@jd-alexander jd-alexander left a 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?

@jd-alexander
Copy link
Contributor

@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 Posts List Item as a first pass while we inquire about design feedback.

@dnalves
Copy link
Contributor Author

dnalves commented Sep 21, 2021

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?

Android iOS

@jd-alexander
Copy link
Contributor

Nice catch @jd-alexander, it makes total sense for the behavior to be similar.

I agree!

From what I noticed, the "Sticky" label is concatenated with the other labels at the bottom. We can replicate it. What do you think?

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
Copy link
Contributor

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.

Copy link
Contributor Author

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")
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 @jd-alexander @dnalves !

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:

  1. 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?
  2. 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. 🙏

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 @ParaskP7

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 😄

Copy link
Contributor

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
@jd-alexander
Copy link
Contributor

jd-alexander commented Sep 23, 2021

@dnalves I was doing some more testing and I noticed something.

  1. If you create a post and you mark it as Sticky the list item displays Sticky in black color.
  2. If you create a post and you mark it as Sticky and Private, the list item displays it in yellow color. If you remove the Private status, it causes an inconsistency because the Sticky label still remains yellow and others look black. What do you think about making it yellow by default? I think all labels have a color on Android that is not black.

@jd-alexander
Copy link
Contributor

@dnalves since there were some new changes in FluxC we can use the latest develop hash before merging these changes. The changes made there are related to WooCommerce, so WP Android would be fine. Normally, we can merge both PRs when both are approved but it's also fine that it was merged in before since it doesn't cause any breaking changes if it were FluxC were to be updated in WP Android with another PR. Just noting that here :)

hasUnhandledConflicts: Boolean,
hasAutoSave: Boolean
): List<UiString> {
val labels: MutableList<UiString> = getErrorAndProgressStatuses(
Copy link
Contributor

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.

Copy link
Contributor Author

@dnalves dnalves Sep 24, 2021

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

@dnalves
Copy link
Contributor Author

dnalves commented Sep 24, 2021

@dnalves I was doing some more testing and I noticed something.

  1. If you create a post and you mark it as Sticky the list item displays Sticky in black color.
  2. If you create a post and you mark it as Sticky and Private, the list item displays it in yellow color. If you remove the Private status, it causes an inconsistency because the Sticky label still remains yellow and others look black. What do you think about making it yellow by default? I think all labels have a color on Android that is not black.

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.

9f8175b

@jd-alexander
Copy link
Contributor

jd-alexander commented Sep 24, 2021

@dnalves I was doing some more testing and I noticed something.

  1. If you create a post and you mark it as Sticky the list item displays Sticky in black color.
  2. If you create a post and you mark it as Sticky and Private, the list item displays it in yellow color. If you remove the Private status, it causes an inconsistency because the Sticky label still remains yellow and others look black. What do you think about making it yellow by default? I think all labels have a color on Android that is not black.

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.

9f8175b

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.

tests

@dnalves
Copy link
Contributor Author

dnalves commented Sep 24, 2021

@dnalves I was doing some more testing and I noticed something.

  1. If you create a post and you mark it as Sticky the list item displays Sticky in black color.
  2. If you create a post and you mark it as Sticky and Private, the list item displays it in yellow color. If you remove the Private status, it causes an inconsistency because the Sticky label still remains yellow and others look black. What do you think about making it yellow by default? I think all labels have a color on Android that is not black.

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.
9f8175b

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.

tests

😱
Thanks for letting me know, my bad.
I added the tests here: ff5191b

Copy link
Contributor

@jd-alexander jd-alexander left a 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 🚢

@jd-alexander jd-alexander merged commit f3519d9 into wordpress-mobile:develop Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Android: “Mark as sticky” is not available in the app
3 participants