Android Stuff
Fundamentals (Notes and Musings)
Android Fundamentals - Putting the mental in fundamentals.
An .apk file is the deployed application file.
Application has its own JVM in a Linux process.
There is no direct entry function call for the invocation of an application. In this respect the application could be thought of as an extension library that exposes callbacks to the real process driver. These callbacks are the different components that compose the application.
Component Types:
- Activity - User interface component
- Service - Background thread process
- Broadcast Receiver - Event reactor for system/application events
- Content Provider - Application services
Intents are events that manage the component types Activity, Service, and Broadcast Receiver.
The application is composed of the different component types. However these components need to be explicitly defined as part of the AndroidManifest.xml. This manifest lays out the component structure for the construction of the .apk file as well as which Intents (events) can target particular components. Read More
Activity components from different applications can invoke each other with properly constructed Intents and create a cohesive user experience.
An Activity has three states
- Running
- Paused
- Stopped
State Transitions
onCreate()
onStart(),onRestart()
onResume()
onPause()
onStop()
onDestroy()
User Interface
The Android user interface consists of a hierarchy of windows, "windows" here in the sense of Win32 windows. These are graphical sections that also have their own event dispatch propagation, most likely, frame buffers (or "surface" via abstractions... but we'll get to that later).
In Android these windows are all derived from the base class View. The overall hierarchy is comprised of:
- View - Base class component for visual components.
- ViewGroup - Container implementation derived from
View, allows the hierarchy - Widgets - User interface components derived from
View
The View hierarchy is set for screen rendering using the setContentView() method on the Activity.
Layouts
Layouts are derived from ViewGroup and manage the positioning and sizing of visual components. A layout can be defined using a DOM structure written in XML.
Events
The View has a standard set of event handlers set for the event dispatch. These can either be overridden if the View has been subclassed to a client class or listeners can be set using callback registration methods like setOnClickListener().
Menus
On Android the menu is a standard part of the application interface at all times due to the fact that the menu concept is built into the device itself. Usually there is a menu button right beneath the screen that is as ubiquitous as the power button. Because of this they have a special status that requires that they are built separately from the standard interface using the onCreateOptionsMenu()
Resources
Android applications may include external resources like images, audio files, layouts, text strings, etc.
There are two resource directory structures
res/- Contains easily accessible external resources like the ones listed aboveassets/- less oft used raw byte storage
The usefulness of the res/ directory is the automatic compilation of the R class which is available to the application codebase.
Data Storage
All application data is private specifically to that application, hence the need for Content Provider services.
Preferences
Android applications has a built in map that allows for ini-file/registry type user preferences settings to be stored. Context.getSharedPreferences() and Activity.getPreferences().
File Storage
Context.openFileInput() and Context.openFileOutput() are used to create FileInputStream and FileOutputStream objects, respectively.
Resources.openRawResource(R.raw.myDataFile) can be used for packaged resources.
Database (SQLite)
Android environment offers the SQLite database system.
Read More - SQLiteDatabase
Read More - Content Providers (examples)
Read More - SQLiteOpenHelper
Graphics
Android supports two types of graphics modes. The 2D Canvas drawing and the OpenGL ES platform.
There are mainly two methods of graphics drawing depending on the activity and real-time update requirements of the graphics.
View Drawing
View callback drawing is the normal way of displaying static graphics that may be part of the normal user interface.
Canvas Drawing
Canvas drawing using the draw() or draw<Object>() methods.
Drawing graphics directly onto the Canvas. The Canvas is a high level graphics object that allows for normal drawing routines that would be found for graphical commands (e.g. drawLine, drawEllipse, drawText, etc.).
There are two methods of doing animated Canvas drawing. One is where the onDraw() callback is called regularly via responses to invalidate() calls.
protected void onDraw(Canvas canvas) {
if (x < 10)
direction = FORWARD;
else if (x > 20)
direction = BACKWARD;
x += direction;
setPosition();
drawable.draw(canvas);
this.invalidate();
}
Or by using an uninhibited drawing thread that has a handle to a SurfaceView object. In order to access the canvas the SurfaceHolder.lockCanvas() method must be used. The return value of lockCanvas() is the Canvas reference itself or a NULL reference if the surface has not been created. The surface represents an internal structure for managing the framebuffer. In order to manage access to the Canvas the Callback.surfaceCreated callback interface needs to be implemented. Usually when the callback method for the surface-ready event is fired the main graphics loop is then released.
Canvas objects are always comprised of pixel data buffers (a.k.a. Bitmap). When creating a canvas a Bitmap must be created first and sent to the Canvas constructor.
Common Drawables may exist that allow for more complex graphical components beyond what draw<Object>() methods may exist on the Canvas object itself.
Notes on threading.
Since only Activity objects are defined as part of Android applications, this means that the normal Game Loop invoked from a main() function that processes UI events alongside the game-state and graphics pipeline is not a viable approach. The Game Loop must live inside a separately spawned thread and the UI events must be sent via some communications channel to the true Game Loop.
Lunar Lander Lessons
Created a new Thread for the sole purpose of running the game loop. The game loop is a constant loop (rather than a timer loop or an invalidate() loop).
The thread only starts when the Surface is created. Found via the surface callback interface. The surface callback is implemented in the view class.
A surface in the Android world seems to be much like the DirectX world. It is an abstraction of a raw graphical buffer that is the data substrate of drawing contexts.
Game Loops Game Loops
Common Tasks
Common Tasks
Audio & Video
MediaPlayer
Supported Media Formats