You can test the changes on this Pull Request by downloading the APK here.

👋 @malinajirka !

It's been almost 3 years already, I know... 😅 But, let me ask you this coroutines related question below, just in case you still remember the answer. 🤞

As part of this Compile Warnings PR, that I am currently working on, I was trying to resolve the @Synchronized annotation related warning. To that end, I ended-up suppressing this warning instead, at least until I discuss it with you first (see here). In this commit you will also notice that I added a couple of links as resources to help us figure out how to properly solve this warning:

• Kotlin Issue: Forbid @synchronized annotation on suspend functions
• Blog Post: Coroutines and Java Synchronization Don't Mix

To that end, and as far as you aware and remember, do you think we could/should resolve this @Synchronized annotation related warning, maybe by using the something like this recommended Mutex solution, or, do you think that we should just ignore that altogether, suppressing it as I did and only touch that piece of logic again, when and if need be in the distant future. Wdyt? 🤔

@ParaskP7 I do remember this code and convo relatively well considering how long it has been - time flies :).

1. I'm wondering how come you pinged me even though I'm not mentioned on this PR at all :D? Just out of curiosity.
2. We were originally using the solution with a Mutex, but refactored it in this PR because it was crashing on Samsung devices with Android 5. Since we do not support Android 5 anymore, I believe it is safe to revert this change and start using mutex again.
3. I'd personally vote for fixing this issue, since if the code doesn't work with coroutines it might lead to race conditions which might result in double-uploads of posts and such - these kind of issues might be there without us knowing about them. However, that doesn't mean we shouldn't fix them. Moreover, I believe the fix is relatively simple and the code is tested for most parts.

Let me know if I can provide some further context.

@malinajirka time flies indeed! 🛸

1. I just annotated this line on AS and it showed your name. Then, I copied the revision number (d5b9948) which pointed to this PR. From the 3 commits included in this PR, I am seeing you being involved in the main first one as well. 🧙
2. Thank you so much for the extra clarification on that. Yes, I agree, we can revert this change and start using Mutex again, especially since we do not need to support Android 5 anymore (API Level 21). PS: Out current minimum SDK version is the 24 (Android 7).
3. I am voting on fixing this issue as well. It indeed seems a bit dangerous to have this kind of race conditions sitting there, waiting to bite us when we would least expect it, and even worse, as you said, having them there without us even knowing about them.

Moreover, I believe the fix is relatively simple and the code is tested for most parts.

👍 🌟 🤞

Let me know if I can provide some further context.

Not only you provided all the context I needed, you also did it at the speed of light, thank you for that, so much appreciated! 🙇

FYI: I'll proceed with updating my PR and revert this change to Mutex again. 💯