Nice catch @malinajirka ! Will check and test later 👍

Btw I was also thinking about adding something like this

             // firstly check if the post which is currently being uploaded 
            // isn't equal to the post we are about to enqueue
            if (sCurrentUploadingPost != null
                && sCurrentUploadingPost.getId() == post.getId()
                && sCurrentUploadingPost.equals(post)
            ) {
                AppLog.i(T.POSTS, "Equal post is currently being uploaded - skipping.");
                return;
            }

here.

However, the posts aren't equal - they have different dateLocallyChanged field. I want to think about it for a bit before I make the necessary changes. Let me know if you have any thoughts about it;). Thanks

However, the posts aren't equals - they have different dateLocallyChanged field.

For the sake of comparing, I think you could just check for sCurrentUploadingPost.getId() == post.getId() and forget about equality of other fields.

However, at that point, if another post with same id is currently being uploaded then it makes sense to enqueue the Post being passed as parameter now (as the latest version / modification should be coming in anyway). Wdyt?

For the sake of comparing, I think you could just check for sCurrentUploadingPost.getId() == post.getId() and forget about equality of other fields.
However, at that point, if another post with same id is currently being uploaded then it makes sense to enqueue the Post being passed as parameter now (as the latest version / modification should be coming in anyway). Wdyt?

If you follow the test scenario #1, an identical version of the post is enqueue twice - in steps 4 and 5. I would like to prevent the second upload as it's pointless. However, I actually need to do "full" comparison as otherwise the test scenario #2 wouldn't work -> we wouldn't update the post with "1234".

If you follow the test scenario #1, an identical version of the post is enqueue twice - in steps 4 and 5. I would like to prevent the second upload as it's pointless. However, I actually need to do "full" comparison as otherwise the test scenario #2 wouldn't work -> we wouldn't update the post with "1234".

Oh that's right, I see that now. It may be worth it to check every other field except dateLocallyChanged . If every other field is equal, then while technically these are not the same, their relevant properties are, hence in practice it doesn't make sense to update the Post with properties that are of identical state. Wdyt?

Thanks @mzorz for the review!;)

It may be worth it to check every other field except dateLocallyChanged . If every other field is equal, then while technically these are not the same, their relevant properties are

I agree, but comparing them manually seems a bit clumsy + if we ever add a new field, we might not remember to update this comparison. We could create a second equals in the PostModel, but it just doesn't seem right to me. I'd probably vote for keeping the current behavior. The double-upload won't happen that often and the only downside is that we upload the post twice. I believe it's not such a big deal. Wdyt?

The double-upload won't happen that often and the only downside is that we upload the post twice. I believe it's not such a big deal. Wdyt?

Agreed, that's a reasonable trade off 👍