Develop Reference

Android compare to a time to current time continuously

I am making an app which need to compare two date and time continuously.
I just saw some example which just compare once. I think I can use timer to repeat a method but it seem not very efficient. Anyone did this before?

Maybe you can use postDelayed like below.
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
#Override
public void run() {
compareTime();
}
}, 5000);
replace 5000 with your own interval milliseconds.

It is easy, you can use handler; When the first time to check time send the normal message like this
mHandler.sendMessage(mHandler.obtainMessage(CHECK_TIME);
Afterwards sendDelayedMessage from inside the handler.
private final Handler handler = new Handler() {
public void handleMessage(Message msg) {
switch (msg.what) {
case CHECK_TIME:
// Your compare time code here
// ....
// Send the delayed message to handler to check time again
mHandler.sendMessageDelayed(mHandler.obtainMessage(CHECK_TIME),
DELAY_CHECK_TIME_INTERVAL);
break;
}
}
}

Create new Thread or re-use it using Handler?

I want to optimize my code. I can see in my sample camera app, I am creating thread for takePicture. Something like:
WAY 1
private void takePicture() {
mTakePictureThread = new Thread() {
run() {
camera.takePicture(cb, cb, ..);
}
}
mTakePictureThread.start();
}
Now I can do same thing with Handler too as below:
WAY 2
//consider mTakePictureThread is started in onCreate()
//and mTakePictureHandler is global variable
private void takePicture() {
mTakePictureHandler.sendMessage(1);
}
private class TakePictureThread extends Thread {
#override
public void run() {
Looper.prepare();
mTakePictureHandler = new Handler() {
public void handlerMessage(Message msg) {
int what = msg.what;
switch(what) {
case 1:
camera.takePicture(...);
break;
default:
break;
}
}
}
Looper.loop();
}
}
Considering takePicture is called many times. So in case 1, new thread will be created as many time as takePicture is called means every time new thread will be created.
But in second case, I can always hold one handler and call takePicture just by passing a message through handler.
So my query is, which one is better considering I am calling takePicture many time. In terms of performance and memory.
I have seen people using WAY 1 always(couldn't get satisfied reply why). So can anyone explain Pros and Cons of both approach and when should I follow which approach?

The second way queries your messages and will only use one thread to take the pictures. So if your camera.takePicture(..) is not a blocking call this will result in unneccessary waiting times for your threads.
The first way can handle different query counts in the same time if your camera can broadcast the actual image.
You can find a good explanation of loopers in the answer on this question looper purpose. A looper is better if you want one thread to handle messages in a sequential manner.

How to return to main thread Android

I have a simple Activity with two buttons "On" and "Off". I want start changing color of background in cycle with button "On" and stop this with button "Off". Also I need to have red color by click on "Off" button. I have wrote simple programm and everything is fine, but I can't understand one thing. Why the last color not always red? If I use code in main threads cycle
Thread.sleep(100);
or
Thread.sleep(1000);
I always have red color, but if I set
Thread.sleep(10);
I have random last color. Why??
Thank you !!
I have this code:
public class MyActivity extends Activity {
final Handler myHandler = new Handler();
private int randColor;
final Runnable updateColor = new Runnable() {
public void run() {
final Random random = new Random();
randColor = Color.rgb(random.nextInt (255), random.nextInt (255), random.nextInt (255));
mRelativeLayout.setBackgroundColor(randColor);
}
};
private ColorChanger myThread;
class ColorChanger extends Thread {
private volatile boolean mIsStopped = false;
#Override
public void run() {
super.run();
do
{
if (!Thread.interrupted()) {
myHandler.post(updateColor);
}
else
{
return;
}
try{
Thread.sleep(100);
}catch(InterruptedException e){
return;
}
}
while(true);
}
public void stopThis() {
this.interrupt();
}
}
private RelativeLayout mRelativeLayout;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_my);
mRelativeLayout = (RelativeLayout)findViewById(R.id.relativeLayout);
}
public void onflagClick(View view) {
myThread = new ColorChanger();
myThread.start();
}
public void onflagoffClick(View view) throws InterruptedException {
myThread.interrupt();
if(myThread.isAlive())
{
try {
myThread.join();
} catch(InterruptedException e){
}
}
else
{
mRelativeLayout.setBackgroundColor(getResources().getColor(R.color.redColor));
}
mRelativeLayout.setBackgroundColor(getResources().getColor(R.color.redColor));
}
}

I agree with the previous answer-ers, but propose a different solution.
First let me say that I recommend you stop using Runnables. In general posting a Runnable to a Handler is less efficient then sending a Message, although there are very rare exceptions to this rule.
Now, if we send Messages, what should we do? What we basically want to do is keep doing whatever we're doing until a condition is hit. A great way to do this is to write a Message Handler that receives a Message, does our work (setting the color), checks if we should keep going, and if so schedules a new Message in the future to do more work. Let's see how we might do this.
Assume the code below is inside an Activity.
private static final int MSG_UPDATE_COLOR = 1;
private static final int DELAY = 10; //10 millis
private final Object mLock = new Object();
private boolean mContinue = true;
Handler mHandler = new Handler() {
#Override
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_UPDATE_COLOR:
synchronized (mLock) {
if (mContinue) {
setColor(Color.rgb(random.nextInt (255), random.nextInt (255), random.nextInt (255)));
mHandler.sendEmptyMessageDelayed(MSG_UPDATE_COLOR, DELAY);
} else {
setColor(Color.RED);
}
}
break;
}
}
}
}
public void onflagClick(View view) {
mHandler.sendEmptyMessage(MSG_UPDATE_COLOR);
}
public void onflagoffClick(View view) throws InterruptedException {
synchronized (mLock) {
mContinue = false;
}
// cancel any pending update
mHandler.removeMessages(MSG_UPDATE_COLOR);
// schedule an immediate update
mHandler.sendEmptyMessage(MSG_UPDATE_COLOR);
}
Okay, so, what is happening here. We've created a Handler that will do all the color updates. We kick that off when our start event happens. Then the Message schedules a new message (and therefore color update) in ten milliseconds. When the stop event happens we reset a flag that the message handler reads to determine if a new update should be scheduled. We then unschedule all update messages because it might be scheduled for several milliseconds in the future and instead send an immediate message that does the final color update.
For bonus points we eliminate the use of a second thread which saves resources. Looking carefully I've used synchronized blocks, but these are actually unnecessary because everything is happening on the main thread. I included these just in case someone was changing mContinue from a background thread. Another great point of this strategy is that all color updates happen in one place in the code so it is easier to understand.

When you post to Handler, it will run your Runnable at some given time in the future. It is not immediate. It also works in a queue so the more times you post to Handler you are going to stack up the commands that will all get executed in order eventually.
You're facing a race condition because with Thread.sleep(10), the program is most likely stacking up a lot of Runnables to execute. They will run regardless of whether or not your Thread is running because they've been queued up to run on the main thread. Thread.sleep(100) or Thread.sleep(1000) doesn't have this issue simply because you're giving the system enough time to execute all color commands. However, it is still possible to have this issue if you pressed the off button at just the right time.

As DeeV told you, Handler sends Runnables to a Looper that is basically a Thread looping inside processing messages or runnables in each loop. You are queuing messaged to the main Looper and then you are sleeping your worker Thread. Its possible that you are sending for example 2 runnables in a row between each loop of your worker thread, but the main looper has only executed the last one so you cannot see each color as you want.
If you want a simple solution to make it work, you can use an Object or a CountDownLatch to synchronize your main Looperwith your worker Thread.
For example: Just before you will sleep your worker Thread you can do the next thing myLockObject.wait()
Then, you should change post(Runnable) to sendMessage(Message). In handleMessage from your Handler you can do myLockObject.notify() (Keep in mind that handleMessage will be executed inside the Looper that you have created your Handler or you can specify any Looper you want explicity). To obtain a new Message you should use myHandler.obtainMessage().
This will make your worker Thread wait your main Looperto process your runnable just before you wait X time until you post next color. Obviously you should create your new Object as a field of your Activity for example:
private myLockObject = new Object()

Android: one handler for all runnables?

Can I use one handler in my Activity for all runnables or should I have multiple instances of Handler, each for one runnable?

You can use only one handler and to specify from where your are coming use different message.
handler.sendEmptyMessage(messagevalue); //use this to send message from different place
Now handle message
private Handler handler=new Handler(){
#Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//specify msg value
if(msg.what==10){
//do this
}else if(msg.what==20){
// do this
}else{
//so on....
}
}
};

I would say, that you should have one handler per thread (not per runnable), unless you do not need completely different behavior for different kinds of runnables.

Android - Using Handlers?

Is there any problem with using multiple Handlers in the same Activity.
I noticed that in all samples provided in android official website they use a single handler and detect different actions depending on the value of "what", is this because of memory management, and high amount of memory used by the Handler? Or should I call it "bad code" and do it the clean way (Multiple handlers each responsible for a specific task)
Handler handler = new Handler()
{
#Override
public void handleMessage(Message msg) {
if (msg.what == 0){
// do something
}
else if (msg.what == 1){
// do something else
}
}
}
OR
Handler taskHandlerA = new Handler()
{
#Override
public void handleMessage(Message msg) {
// do something
}
}
Handler taskHandlerB = new Handler()
{
#Override
public void handleMessage(Message msg) {
// do something else
}
}

No there isn't such a limit (a Handler is just a message receiver), but if you want to do such a thing the more common approach is to have one Handler that you post Runnable objects to.

Here is some good reading on Loopers and Handlers.
When a Handler is created, it is automatically registered with its' Thread's Looper. This makes me think that you do not need multiple Handler's for a single thread. An Activity, specifically, one that uses multiple Thread's, could use multiple Handler's though.