We Keep Coding

Java, what do you call this? and why )};

I am going through Hello Android (Android PDF/tutorial) and have now seen this syntax a couple of times. Can someone please explain to me what Java syntax is used when run Runnable is defined?
private class AndroidBridge {
public void callAndroid(final String arg) { // must be final
handler.post(new Runnable() {
public void run() {
Log.d(TAG, "callAndroid(" + arg + ")" );
textView.setText(arg);
}
...
Is the code defining a Runnable object and overriding it's run method?

As Dave Newton indicated, this is an anonymous inner class implementing the Runnable interface.
As to why one would want to use this, it could be thought of as syntactic sugar of sorts. You'll notice that in your example, the code in run() has access to the same scope as where the anonymous inner class itself is defined.
This simplifies access to those members, as if you defined the class externally, you'd have to pass in a reference to any object whose members you wanted to invoke/use.
In fact, IIRC, this is actually what happens when Java compiles the anonymous inner class; if there are references to the outer containing class, the compiler will create a constructor that passes in a reference to the outer containing class.

The .post method expects a Runnable object, which in your code sample is declared anonymously and passed as the argument.
That will start a new thread for some long-running process.
The thread constructor needs a Runnable object, which has a run method that's called when the thread is ready.
When many Java apps start, all of the operations pile up on one thread, including the UI. I mainly use threads to avoid freezing up the UI if I'm doing something "heavy".
You've seen this happen when you click "execute" or something, and the UI suddenly is less than responsive. This is because the current thread doesn't have enough resources to build the UI and do whatever "execute" is asking.
So, sometimes that's done elsewhere, on a different thread, which needs a Runnable object.
It's worth noting that multithreading (where you make more than one thread on purpose) is notoriously difficult to work with, for debugging reasons mostly, IMO. But it is a useful tool, of course.

The code is defining an anonymous inner class that implements the Runnable interface, and implementing the run method to perform the appropriate actions.

questions on implementing Runnable [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: “implements Runnable” vs. “extends Thread”
I have two questions about multithreaded programming. I read a few answers on the internet, but still I can't find a satisfying answer.
Implementing the Runnable is preferred over extending the thread class. Why?
How is it that we are able to get away with overriding just the run() method?
According to 'The Complete Reference to Java' by Herbert Schildt, If we are not overriding any methods of Thread class other than run(), it's better we implement Runnable.
My 2nd question might sound a bit silly, but I seem to be missing something and I'm not sure about how the whole thing works.

1: Implementing the Runnable is preferred over extending the thread class. why?
Because it allows your class to extend another class if it wants to instead of being forced to extend Thread.
2: How is it that we are able to get away with over-ridding just the run() method?
You can certainly override other methods but the Thread object will call the run() method when the thread is started. That's how it works. The default Thread.run() method is:
public void run() {
if (target != null) {
target.run();
}
}
If you call the Thread constructor with a Runnable then that is what the target is set to. If you instead extend Thread and #Override the run() method then that is the method that will be called when the thread object is started.
That's how the Thread class works.
2: How is it that we are able to get away with over-ridding just the run() method?
You may have misspoke here and were instead asking why we only need to implement the run() method in Runnable().
Runnable is an interface with a single run() method that you must implement.
Thread is a concrete class that you are extending. You can override any methods in a concrete class unless the class is final or the method is final.
Make sure you use proper Java terminology and don't mixup implement and override.

Three fundamentals before you delve deeper.
A class can only extend one class.
A class can implement any number of interfaces.
An interface can extend any number of interfaces.
Additionally, an abstract class is a class. So it behaves like a class and you can't implement it. You only extend it.

There are a number of traps which can occur if you extend Thread which you don't get with implementing Runnable.
public static String getName() {
return "My Test Application";
}
public static void stop() {
System.out.println("Shutting down");
}
public static void main(String... args) {
new Thread() {
#Override
public void run() {
System.out.println(getName());
stop();
}
}.run();
System.out.println("Bye now.");
}
prints
Thread-0
Bye now.
See how many bugs you can spot.

Unnecessary inheritance is generally a bad idea. You might hear "prefer composition over inheritance" often enough. I'm sure google can pull up enough links for you. The general issue is that inheritance bring tight, unnecessary coupling between classes.
Same goes for GUI components, btw.

How does this threadExample work?

I wanted to write multiple threads under one class and found one way of doing it.
public class ThreadExample {
public static void main(String[] arg)
{
Thread one = new Thread() {
public void run() {
try {
Thread.sleep(2000);
} catch(InterruptedException e) {
e.printStackTrace();
}
System.out.println("One");
}
};
Thread two = new Thread() {
public void run() {
System.out.println("Two");
}
};
one.start();
two.start();
}
}
Thing I don't get here is, I am neither extending the Thread class nor am I implementing the Runnable interface. How do I understand this?
And If the answer is, "I am just creating the object of the Thread class and using it, then why not always do this rather than doing the things mentioned above?

Technically, what you are doing is extending Thread. You are extending it on the fly with something called an anonymous inner class - to learn more about what that is, start here and read this page plus the next two.
What this means is you are creating temporary inline subclasses that have no name, and whose definitions survive only until the method finishes. Why do this rather than create a named subclass of Thread or implementation of Runnable? It makes sense when the body of run() is as simple as the examples above - there's less typing and fewer .java files to keep track of. One-off simple tasks like these are good candidates for anonymous inner class extension of Thread. For major program logic, you probably want to do a full named class implementation in a separate file.
In addition, once you've gotten good experience with Thread, I would encourage you to check out the java.util.concurrent package.

Ah, but you are extending the Thread class... anonymously.
When using the new Class() {} syntax, you are creating an anonymous class that is a sub-class (ie effectively extends) of the named class.
In this case, you have overridden the Thread.run() method.
This approach, while it works, it not considered "good design", because you are extending Thread, but you are not creating a new kind of Thread. It is better to pass a Runnable into the constructor:
new Thread( new Runnable() {
public void run() {
// do something
}
}).start();

Bohemian answered your first question so I'll answer your second one: "I am just creating the object of the Thread class and using it, then why not always do this rather than doing the things mentioned above?"
If you always do it the way you did in your question then you can't separate the logic that performs the task from the way the task is run. Implementing runnable lets you bundle the logic that performs your task separately from the code that manages how your task is run.
If you use runnables you are able to run your task in a new thread, run your task in the calling thread, run your task after some delay or run it in some other fashion without modifying the code in the runnable.
When working with threads you'll generally want to use an ExecutorService instead of using the thread class directly. Executor services provide facilities for limiting the numbers of threads, handling failed executions, determining when a runnable completes, getting return values from tasks run in other threads and so on.

Threads from a class with constructor with multiple arguments

Having a problem here, I have been learning about threading in java i understand if you are extending a thread you would create a thread in the main as follows.
Card thread1 = new Card("Ace");
This would be coming from a class called thread with a constructor
public thread(String n);
But i have given the constructor with a multiple argument:
public Person(int PersonID, Direction direction, StairLock stairLock)
And asked to create a thread for each of 4 people with two people going UP and 2 going DOWN and a lock for the stair, im unsure how to do this any help or direction would be helpful

There are multiple issues with your question.
Any class which extends thread, in its constructor, can call super(String) to pass the thread name to the superclass thread. So in your constructor for Person, you can call this constructor for Thread immediately with the name you want for the thread. It is a good practice to always name your threads for debugging identification.
You refer to the class thread, but you should know this is different from Thread. Classes in Java should always start with uppercase letters. If you made your own thread class, you are not actually making a thread.
I'm not sure why a Card or a Person class should need to extend Thread. Unless you're just picking random names for this example, these classes sound more like data objects rather than threads. If this is the case, you might want to consider having a separate class be the Thread which handles the movement up and down the stairs, and give each thread its own Person class instance to handle.
Given all of this, if you were asked to make a thread for each Person to handle its movement, I would recommend creating a separate class from Person to do this. Either extend Thread or implement Runnable and take a Person in the constructor. Both classes use a .run() method that you have to implement to do the workload of the thread. With a Thread, you can just instantiate it and call .start(). With a Runnable, you have to create a new Thread and pass the Runnable as an argument to the constructor, then call .start() on the Thread.
Many people prefer to use the Runnable approach, but the results are pretty much the same either way. If you're handling threads, you should be familiar with both ways of doing it.

Thread vs Runnable
You should probably not extend thread.
Implement Runnable and start a new thread with your Runnable.
Reason: If you extend Thread, you interfere with working infrastructure code. You should only do that if you need to change how things work. In 90% of cases, you only need to specify what needs to be executed, not how. That's why the Runnable approach is more elegant: you separate the what from the how.
From the Runnable docs:
In most cases, the Runnable interface
should be used if you are only
planning to override the run() method
and no other Thread methods. This is
important because classes should not
be subclassed unless the programmer
intends on modifying or enhancing the
fundamental behavior of the class.
Sample Code
Try something like this:
public void startThread(final int personID,
final Direction direction,
final StairLock stairLock){
new Thread(new Runnable(){
#Override
public void run(){
System.out.println("Person " + personID + " runs in direction "
+ direction
+ "and I have no idea what a Stairlock is, but here it is "
+ stairLock);
}
}).start();
}
OOP Design
In General, be careful how you model objects.
If I understand you right, Card is-a Thread in your concept. That's awful! A Card can have-a thread, but it should never be one!
In good OOP design, a class has exactly one purpose, this is called Cohesion. Also, different kinds of functionality should be loosely coupled, i.e. Domain Classes should never contain infrastructure code.

Firstly, welcome to the world of learning Threads. Sure, you can extend Thread, just call the constructors with right signatures. Or, you could implement the Runnable interface, too. The two implements below (A and B) are equivalent in terms of functionality. Now, Mr. Floyd told us not to extend Thread. Lets explore why (I do not disagree, just trying to help you understand a design issue in Java).
Class extension is Java's implementation of inheritance, a basic OO paradigm. When you extend Thread directly, you are saying "My class (Person) 'is a' Thread", and that is perfectly acceptable. The reason most people do not extend Thread in this manner is Java's lack of multiple inheritance. Now don't quote me on that, I have no statistics to back it up and it is also possible that their IDE's do not allow it or supervisors do not like it. But here is the issue:
Without debating whether multiple inheritance is good or bad, we can see that it is not there and safely assume that it aint gonna be there in the near future. This means that if your class extends Thread, it cannot extend anything else. This puts you in a bind. However, java allows your class to implement multiple interfaces, and Runnable can be just one of them. This gives you more degrees of freedom as the object designer, as you can pick from (extend) a variety of well established classes to suit your design goals and still have the multithreading functionality.
Hope that helps. Regards, - M.S.
// A
public class Person extends Thread {
public Person (int PersonID, Direction direction, StairLock stairLock) {
super();
// Other stuff for constructor
}
public void run () {
// Whatever you want to do with the thread
}
public static void main (String[] args) {
for (int i = 0 ; i < names.length ; i++) {
Person ace = new Person (names[i], xxx, xxx);
ace.start();
}
}
}
////////////////////////////////////////////////////////////
// B
public class Person implements Runnable {
public Person (int PersonID, Direction direction, StairLock stairLock) {
// Other stuff for constructor
}
public void run () {
// Whatever you want to do with the thread
}
public static void main (String[] args) {
for (int i = 0 ; i < names.length ; i++) {
Person ace = new Person (names[i], xxx, xxx);
new Thread (ace).start();
}
}
}

How much logic is it "right" to put in a Callable?

I'm using callables quite often , and I've stubled upon a question that irritates me:
Lets say that to run function foo() , one needs to do a couple of checks first.
Should you
1. Insert the checks as part of the Callable :
class A implements Callable<Long> {
...
public Long call() {
check1();
check2();
return (run());
}
OR , insert all this logic into another class (ALogic) and use the Callable a mere shell for the executor?
class A implements Callable {
...
public Long call() {
ALogic aLogic = new ALogic();
return (aLogic.run());
}
What do you think are the pro's and con's? What do you usually prefer?

My general advice when implementing callback [Java keyword] interfaces is concentrate on making the [non-Java keyword] interface appropriate for the called type. There generally shouldn't be that much in the anonymous inner class (or whatever), but more than just forwarding call.
Also, it's generally not good to have an object that is constructed and then only has a single method called on it. Make it a static method (which may, perhaps, in turn create an object through a private constructor and run that).

Which do you feel is simpler or clearer?
I suggest you do that.

I usually prefer to simply forward the callback to a private method on the enclosing class. This eliminates the "this" reference that simply points to the anonymous inner class, which is pretty useless.