android gcs
Alternatively see instructions on how to use the Android app.
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.
See architectural notes here
###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) Controller Logging Alarms
When possible, it is better to write a fragment to provide functionality than a full activity. This allows flexibly combining multiple components on larger screens.
The fragments have similar aspects to their life cycle as activities. Specifically adding an onConnected and onDisconnected cycle to indicate when a connection is made or broken to the UAV. This is typically a time to schedule for periodic updates from various UAVOs.
An issue that keeps arising is that the connection and the actual being visible can happen independently of each other, so we need to behave properly in all combinations of those two. For this reason I will expand the objectUpdate method into two - objectUpdateUI and objectUpdate. The former will only be called when the Fragment is visible. The later will be called whenever the fragment is not stopped.
####Examples
- Map
- PFD
- Alarms
- Note that also some of these use custom views to actually provide a reusable graphical element. The core difference between a fragment and a view is the view and no ability to schedule getting updates and new information - so that must always be provided by an activity or fragment. The PFD utilizes this model heavily.
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.