You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
85 lines
4.0 KiB
85 lines
4.0 KiB
Implementation Details for SdkControllerApp |
|
------------------------------------------- |
|
|
|
---- 2012-03-22 |
|
App is in the namespace com.android.tools.sdkcontroller. |
|
|
|
This is an app that has a minSdkVersion of 7 (Eclair) |
|
and a targetSdkVersion of 15 (ICS). The target version |
|
means the app is forbidden under ICS from doing any network |
|
communication on its main thread. |
|
|
|
The overall design: |
|
- A background service is started by the app. It handles the connection |
|
to the emulator and provides a number of "handlers". Handlers can be |
|
though as being separate tasks that the user wants to achieve, for example |
|
sending sensor data, sending multi-touch events, receiving screen updates, |
|
sending a camera feed, etc. |
|
- All the handlers are started when the service starts and shutdown with it. |
|
They basically stay there as long as the app is running, and its up to the |
|
handler to deal with emulator connections starts/stopping. Some handlers |
|
will run in the background (e.g. sending sensor data) whereas other might |
|
need an activity to connect to them first. |
|
- The app has a number of activities which connect to existing handlers. |
|
|
|
Another way to see it is that the app handles a number of tasks which are |
|
composed of a background handler (that consumes data form the emulator and |
|
can send data to the emulator) and an optional activity for UI (that displays |
|
or controls the handler's state.) |
|
|
|
|
|
Here's a quick overview of the classes in the application: |
|
|
|
|
|
The main UI is in activities.MainActivity. |
|
There are 2 tasks activities: SensorActivity and MultiTouchActivity. |
|
|
|
These all derive from BaseBindingActivity which provides a few convenient common features |
|
- in onResume this will bind to the service, creating and starting it if necessary. |
|
- in onPause, this will unbind from the service, but does not stop it. |
|
|
|
Note however that due to the asynchronous nature of the bind operation, the activity |
|
must not attempt to use the service from onResume. Instead there are 2 callbacks to use: |
|
- onServiceConnected when the bind succeeded. |
|
- onServiceDisconnected as the reverse operation. |
|
|
|
When the activity is connected to the service, it can then use getServiceBinder() |
|
to get an interface to talk to the service. |
|
|
|
In the other direction, the activity provides a listener for the service to notify |
|
the application: ControllerListener createControllerListener(). |
|
|
|
The activity can then access the handler: |
|
handler = getServiceBinder().getHandler(HandlerType....) |
|
|
|
and then the activity wants to provide a listener to get notified by the handler: |
|
handler.addUiHandler(new android.os.Handler(this)); |
|
|
|
The emulator connection is separated in the "lib" subpackage: |
|
- EmulatorConnection abstracts a connection to the emulator. |
|
- Object is first created by giving a non-null EmulatorListener. |
|
- then connect(port) is called to initiate the connection. |
|
- The EmulatorConnection is always created in SYNC mode. |
|
- EmulatorListener is a callback: the emulator connection uses it to indicate |
|
when the connection is actually connected or disconnected. |
|
|
|
In the end we have the following workflow describing who controls what (-->): |
|
|
|
|
|
Emulator |
|
^ ^ |
|
| | EmuCnxHandler |
|
sendEventToEmulator| | (EmulatorListener) |
|
| +-------------+ |
|
| | |
|
handlers.BaseHandler | v |
|
Activity ------------------------> Handler <---- ControllerService |
|
UI <------------------------ | ^ |
|
android.os.Handler | | |
|
| ^ | | |
|
| | ControllerListener | | |
|
| +--------------------------------------------------+ | |
|
+-----------------------------------------------------------+ |
|
ControllerBinder |
|
|
|
----
|
|
|