Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Firstly, I would generally recommend against the use of an intermediary singleton for the sole purpose of passing data between two classes. Especially when there is already a built in method which was made solely for that very purpose. Having a static class for maintaining data in your application is very useful, but as a rule of thumb, don't put data there unless it has to be accessible from multiple points in your application. </p> <p>To address your concurrency question, as long as the Service is setting the data before sending the message, and the data is only accessed after the message is received, then you won't have a race condition. Note though that there are a lot of implicit assumptions you are building into your code, which again, isn't a good thing. If someone else were to look at your code, how would they know that you aren't allowed to access the data until after the message is received?</p> <p>A more general solution to your problem is to use locks. In this case, when a thread accesses your data variable, it will be granted sole access to it until the thread releases the lock. This will block any other threads from accessing the data until the original thread has released it's lock. Note though that this blocking could cause your application to stutter or stop (Android not responding) if the blocked thread is the UI thread. This is just another reason why you should pass the data through intents. </p> <p>Having said that, I think it's great you've reimplemented data handling in so many ways as it should give you a valuable perspective into the different options available.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload