View.getContext(): Returns the context the view is currently running in. Usually the currently active Activity.
Activity.getApplicationContext(): Returns the context for the entire application (the process all the Activities are running inside of). Use this instead of the current Activity context if you need a context tied to the lifecycle of the entire application, not just the current Activity.
ContextWrapper.getBaseContext(): If you need access to a Context from within another context, you use a ContextWrapper. The Context referred to from inside that ContextWrapper is accessed via getBaseContext().
You can find a full listing of all system resources in the android package.
Every time I want to do something on Android I check to see if there’s a system resource that covers what I want to do. It is helpful to import the Android source code (in particular, their /res/ folder) when searching for already-implemented resources that you might want, so you can see their specific implementation.
Personally, I find myself most often using:
Built-in Android layouts for standard tasks, such as spinner dropdowns.
Android ids (android.R.id), because you are often required to use these if you want to use some of Android’s widgets (for example, TabHost/TabWidget requires you to use “android:id/tabhost”, “android:id/tabs” and “android:id/tabcontent” if you want to implement an XML layout).
Built-in colors, especially android.R.color.transparent.
Android’s built-in fade-in and fade-out animations in android.R.anim
In your example, you could call it as any of the following:
myMethod(); // Likely useless, but possible
myMethod("one", "two", "three");
myMethod("solo");
myMethod(new String[]{"a", "b", "c"});
Important Note: The argument(s) passed in this way is always an array – even if there’s just one. Make sure you treat it that way in the method body.
Important Note 2: The argument that gets the ... must be the last in the method signature. So, myMethod(int i, String... strings) is okay, but myMethod(String... strings, int i) is not okay.
Thanks to Vash for the clarifications in his comment.
I am currently studying Java and have recently been stumped by what does <> means?
public class Pool<T>{
public interface PoolFactory<T>{
public T createObject();
}
this.freeObjects= new ArrayList<T>(maxsize)
What does the <T> mean? Does it means that I can create an object of type T?
answer
<T> is a generic and can usually be read as “of type T”. It depends on the type to the left of the <> what it actually means.
I don’t know what a Pool or PoolFactory is, but you also mention ArrayList<T>, which is a standard Java class, so I’ll talk to that.
Usually, you won’t see “T” in there, you’ll see another type. So if you see ArrayList<Integer>for example, that means “An ArrayList of Integers.” Many classes use generics to constrain the type of the elements in a container, for example. Another example is HashMap<String, Integer>, which means “a map with String keys and Integer values.”
Your Pool example is a bit different, because there you are defining a class. So in that case, you are creating a class that somebody else could instantiate with a particular type in place of T. For example, I could create an object of type Pool<String> using your class definition. That would mean two things:
My Pool<String> would have an interface PoolFactory<String> with a createObjectmethod that returns Strings.
Internally, the Pool<String> would contain an ArrayList of Strings.
This is great news, because at another time, I could come along and create a Pool<Integer>which would use the same code, but have Integer wherever you see T in the source.
A Surface is an object holding pixels that are being composited to the screen. Every window you see on the screen (a dialog, your full-screen activity, the status bar) has its own surface that it draws in to, and Surface Flinger renders these to the final display in their correct Z-order. A surface typically has more than one buffer (usually two) to do double-buffered rendering: the application can be drawing its next UI state while the surface flinger is compositing the screen using the last buffer, without needing to wait for the application to finish drawing.
A window is basically like you think of a window on the desktop. It has a single Surface in which the contents of the window is rendered. An application interacts with the Window Manager to create windows; the Window Manager creates a Surface for each window and gives it to the application for drawing. The application can draw whatever it wants in the Surface; to the Window Manager it is just an opaque rectangle.
A View is an interactive UI element inside of a window. A window has a single view hierarchy attached to it, which provides all of the behavior of the window. Whenever the window needs to be redrawn (such as because a view has invalidated itself), this is done into the window’s Surface. The Surface is locked, which returns a Canvas that can be used to draw into it. A draw traversal is done down the hierarchy, handing the Canvas down for each view to draw its part of the UI. Once done, the Surface is unlocked and posted so that the just drawn buffer is swapped to the foreground to then be composited to the screen by Surface Flinger.
A SurfaceView is a special implementation of View that also creates its own dedicated Surface for the application to directly draw into (outside of the normal view hierarchy, which otherwise must share the single Surface for the window). The way this works is simpler than you may expect – all SurfaceView does is ask the window manager to create a new window, telling it to Z-order that window either immediately behind or in front of the SurfaceView’s window, and positioning it to match where the SurfaceView appears in the containing window. If the surface is being placed behind the main window (in Z order), SurfaceView also fills its part of the main window with transparency so that the surface can be seen.
A Bitmap is just an interface to some pixel data. The pixels may be allocated by Bitmap itself when you are directly creating one, or it may be pointing to pixels it doesn’t own such as what internally happens to hook a Canvas up to a Surface for drawing. (A Bitmap is created and pointed to the current drawing buffer of the Surface.)
Also please keep in mind that, as this implies, a SurfaceView is a pretty heavy-weight object. If you have multiple SurfaceViews in a particular UI, stop and think about whether this is really needed. If you have more than two, you almost certainly have too many.
