Oh, right, there was all the code. I only saw those 2 files on the first post and tought the rest was missing, and I was confused about the .layout extension. That's the layout file (main.xml), there's also the AndroidManifest.xml one in the root of the project that defines that PongTime activity is the activity that will be used when launching the app (action MAIN, category LAUNCHER).

You can define classes anywhere you want to, and even if there are "good practices" it never is so simple as "this is the best solution in any project". At the end the only right answer that always work is "it depends", since what is better also depends on a lot of stuff. In this case PongThread is inteded to be used only inside PongTimeView, so for the writer the best place to put that code was inside PongTimeView.

About getHolder... That's not an Android weird thing, you can call methods without specifing the object in java. In this case, "getHolder" is a method of SurfaceView, a class from the Android API:http://developer.android.com/reference/android/view/SurfaceView.html#getHolder%28%29

Since PongTimeView extends SurfaceView, that line is calling the getHolder() method of the PongTimeView object that was inherited from SurfaceView. If you write a call to a function without specifying and object, the compiler always uses this rule:

1 - If "this" has a method that matches that call (considering also inherited methods), the line is interpreted as this.method(). If not...

2 - If the class has a static method that matches, the line is interpreted as Class.method().

If those checks fail the code doesn't compile. In Java you don't have global functions, you have static methods on classes, but to access a static method from another class you must import that class and write NameOfThatClass.method().

You can define classes anywhere you want to, and even if there are "good practices" it never is so simple as "this is the best solution in any project". At the end the only right answer that always work is "it depends", since what is better also depends on a lot of stuff. In this case PongThread is inteded to be used only inside PongTimeView, so for the writer the best place to put that code was inside PongTimeView.

About getHolder... That's not an Android weird thing, you can call methods without specifing the object in java. In this case, "getHolder" is a method of SurfaceView, a class from the Android API:http://developer.android.com/reference/android/view/SurfaceView.html#getHolder%28%29

Since PongTimeView extends SurfaceView, that line is calling the getHolder() method of the PongTimeView object that was inherited from SurfaceView. If you write a call to a function without specifying and object, the compiler always uses this rule:

1 - If "this" has a method that matches that call (considering also inherited methods), the line is interpreted as this.method(). If not...

2 - If the class has a static method that matches, the line is interpreted as Class.method().

If those checks fail the code doesn't compile. In Java you don't have global functions, you have static methods on classes, but to access a static method from another class you must import that class and write NameOfThatClass.method().

Alright the second was a little confusing as it looked as something like global method, but now i see

as to embeddong pong thread - will it be much difference if pongthread would be defined in third java file?

for me it seems that almost nothing will change, (though I am not sure) because visibility depends more on passed pointers not where definition lies

If it would lay in seperate file

1) acces from pong thread to pong view would be harder?

or

2) from pong view to pong thread would be harder?

would there be a need to revrite something?

as it shows the embedded pong thread is also accessible

just they use

import com.tinkerlog.android.pongtime.PongTimeView.PongThread;

I am not really sure what change if its embedded (if some acceses are easier or harder and which one

I am not really sure what change if its embedded (if some acceses are easier or harder and which one

In this example, I think the difference would be minimal.

One advantage of inner classes is access to private fields of the containing class, so you could potentially write less lines of code.

I'm not a fan of huge inner classes like the one in the example though, makes the code harder to overview, that one maybe should have been a separate file IMO.

If it only should be accessed within the view, it could be made private in the package, and you could only use it from within other classes in the same package. (though I don't think this is a huge issue?)

But for small classes that need access to private stuff of your class, and should not be used from outside, then inner classes are very useful.

As noted, its all convention and preference, nothing cut in stone.

That's an Android game, so you must know a little about Android activities to fully understand it: http://developer.android.com/guide/components/activities.html#Lifecycle

When an Android application is started an Activity is created and started. Which activity is created is specified in the Android manifest (an XML file that's not present there, but should be present in any Android project), but only one of those is an activity so it's the only option for a starting point. I'm not saying that Android assumes that, the activity MUST be specified in the manifest.

Activities on Android have a lot of functions that you have to implement for different events. When the activity is created "onCreate" is called, so that's the first thing that will be executed. That function creates all the components that will be displayed.

Android has "layouts" to control the screens, those layouts are composed by components and one component is SurfaceView. When the layout is loaded in the onCreate method, a PongTimeVIew component is created and the method surfaceCreated from PongTimeView is called and the thread is started.

Alright took a little time and now i see it ..now its much more clear to me..

There is yet a confusion what surface is - What view is I probably

understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards) where you could present graphics (and also manage this views just like paper cards )

- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?

Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?

Yet one strange thing - it seem to me that i noticed that in some conf files this app is setted to android 3 and above, regardless that it is easy (basic GDI like, as i could call it with my win32 experience) and probably should run in older androids too (at home I gos old HTC wildfire phone, and it has 2.4 or 2.6 android

(i dont remember), does it seem 1) that it will not work when trying to download it from android market 2)if i will just change in confs expected android to 2.4 and compile it myself to device then it will work? Why the man putted 3 here?

There is yet a confusion what surface is - What view is I probably
understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards) where you could present graphics (and also manage this views just like paper cards )
- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?
Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?

Yes, you've got views right, they are higher level, used to layout content, and implement callbacks from buttons and such.

Surface is a handle to the buffer where the actual drawing takes place, and you draw to it using a canvas.

SurfaceView is a special view that help you do lowish level drawing onto the surface. (lower level would be direct pixel access).

Its not a strict 1:1 relationship, in a "standard" UI app you have a hierarchy of views defined in xml which layout pictures, text and buttons, and the framework makes sure to draw them into the surface for you, and you don't have to worry about the surface at all.

Yet one strange thing - it seem to me that i noticed that in some conf files this app is setted to android 3 and above

Probably not much thought behind it, you'd have to go through everything used to know for sure, but that example looks like it would run on a pretty low version indeed. You should be able to just change it. If you use eclipse, I think it will warn you if you try set the version too low.

There is yet a confusion what surface is - What view is I probably
understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards) where you could present graphics (and also manage this views just like paper cards )
- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?
Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?

Yes, you've got views right, they are higher level, used to layout content, and implement callbacks from buttons and such.

Surface is a handle to the buffer where the actual drawing takes place, and you draw to it using a canvas.

SurfaceView is a special view that help you do lowish level drawing onto the surface. (lower level would be direct pixel access).

Its not a strict 1:1 relationship, in a "standard" UI app you have a hierarchy of views defined in xml which layout pictures, text and buttons, and the framework makes sure to draw them into the surface for you, and you don't have to worry about the surface at all.

this more confuses than explains, is the surface 1:1 to a views or it is something more related to one physical screen device ?

I looked somewhat in android docs api but do not manage to understand it

You could say it's one step away from the screen. Its a buffer that is managed by the screen compositor, which is responsible for composing any visible surfaces onto the screen.

You won't be allowed closer to the screen then that, as an app

Usually you have only one fullscreen surface in your activity, and then all your views in that activity (as defined in the xml-file, or created and added in code) are drawn onto the same surface.

But you could have multiple layes of surfaces. Content like video and non-fullscreen gl will be drawn to their own surfaces and composed by the screen compositor.

SurfaceView is special, it the only view that has its own surface, and is the one you use if you need to implement views that need their own surface... Most views don't.

Hope that clears it up a bit

SurfaceView extends View. All SurfaceView's instances are also Views, but more classes extend View, so it's not a 1:1. Any of the next classes are also Views:

A View is a rectangular component that can display something and detects user input. SurfaceView extends a View, so it does the same things and more. It means a SurfaceView is also a rectangular component that can display something and detects user input, but it provides methods to manipulate what is being drawn.

Do you know about inheritance? It looks like you get lost in basic concepts every time. I'll keep recomending you to learn more concepts and more about Android before reading that code (or from any other finished game). You can learn all those stuff a lot quickier with tutorials and guides, it doesn't make sense you try to guess things. Code is not a puzzle or a riddle, it's not a mathematical problem or a logic problem that you can "decipher" or "solve", it's more like a recipe that the computer follows.