Skip to content
James Cotton edited this page Nov 26, 2012 · 3 revisions

Android GCS

The android GCS was originally modeled heavily on the Qt GCS to allow a lot of the core code to be used unchanged. Other things like signals were implemented with an Observer pattern to allow some of the design patterns to me mimiced.

These notes are as much rereading the code as much as anything, right now.

Activities

###ObjectManagerActivity Base class for general activities. This takes care of all the work binding to the telemetry service and has a handle to the objMngr to use (currently this is sometimes null if there is no telemetry, needs to be fixed).

** registerObjectUpdates(UAVObject) - used to take care of all the behind the scenes parts of installing an observer and running the callbacks through a handler to put them in the same thread that can manipulate the UI. If you only want to manipulate data in the Activity then it might be faster to bypass this or have a thread unsafe version if performance becomes an issue. objectUpdated(UAVObject) - called whenever that object is updated Provides registerObjectUpdates which causes the objectUpdated() method to be called accordingly in the UI thread.

##Examples Browser (pops up Editor which is a standalone activity) Map PFD Controller Logging Alarms Some of these should be reimplemented as Fragments (possibly parts as views) and be dropped into other top level activities

Known Bugs

Activities crash when started without telemetry as objMngr is null all over the place Occasionally causes a hard lockup without any message. Deadlock? Retrieving objects at the initial connection fails at the first NAK A lot of things are done in onOPConnected like it's a constructor because that's when objMngr is around, but that's flawed (probably) since right now we don't undo all those things when we run opDisconnected so some signals are stacked consistently consider that the object manager is reset when disconnected and make sure this is true (best) or use them persistently (worst). The benefit of the former is that if we can start to load the right set of UAVOs based on the firmwareIAP we might be able to have a minimal set to establish connection (GCSTelemetryStats, FirmwareTelemetryStats, FirmwareIAPObj) and then run the object initialize afterwards.

[AndroidOSG](/Android OSG/) [AndroidTelem](/Android Telemetry/) [AndroidDev](/Android Development Environment/)

Clone this wiki locally