This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
android:agtek_lib_location_manager_architecture [2012/10/10 16:50] 127.0.0.1 external edit |
android:agtek_lib_location_manager_architecture [2019/10/21 16:00] (current) timm |
||
---|---|---|---|
Line 18: | Line 18: | ||
===== Extending the framework ===== | ===== Extending the framework ===== | ||
- | Adding new devices is relatively straight forward. For each new device you must write a new class to be the LocationDevice and write a new class to be the LocationProvider. It is up to the Device to perform detection and verification of the ohysical device, while the Provider is to provide the normalized location updates when they are made available via the physical device. | + | Adding new devices is relatively straight forward. For each new device you must write a new class to be the LocationDevice and write a new class to be the LocationProvider. It is up to the Device to perform detection and verification of the physical device, while the Provider is to provide the normalized location updates when they are made available via the physical device. |
If the instrument being added is a Bluetooth device, the you should extend com.agtek.location.bluetooth.AbstractBluetoothDevice instead of the normal LocationDevice and the Provider should extend com.agtek.location.bluetooth.AbstractBluetoothProvider. These classes serve to combine common Bluetooth functionality and data needed across all Bluetooth devices. | If the instrument being added is a Bluetooth device, the you should extend com.agtek.location.bluetooth.AbstractBluetoothDevice instead of the normal LocationDevice and the Provider should extend com.agtek.location.bluetooth.AbstractBluetoothProvider. These classes serve to combine common Bluetooth functionality and data needed across all Bluetooth devices. | ||
Line 68: | Line 68: | ||
Note that this example doesn't show how to handle errors, parse the data, etc. Please note that **m_runnning** is set by the AbstractBluetoothProvider class in response to stop and starting events from the LocationManager. You must respond to this variable in your inner run loop. This is the signal tell you to continue, or exit the loop. | Note that this example doesn't show how to handle errors, parse the data, etc. Please note that **m_runnning** is set by the AbstractBluetoothProvider class in response to stop and starting events from the LocationManager. You must respond to this variable in your inner run loop. This is the signal tell you to continue, or exit the loop. | ||
+ | ===== Leica ICG60 Structure ===== | ||
+ | This diagram illustrates the coarse structure of the Leica ICG60 Provider. Because of how Bluetooth IO works in Android, the Java code must read the socket and pass the information to the native Leica SDK. After processing the native code calls some Agtek call backs (e.g. position updates, etc.) which in turn call back into the Java code to deliver results to the application. | ||
+ | |||
+ | {{:android:leica_icg60_structure.jpg?400|}} | ||
+ | |||
+ | ===== NMEA Providers ===== | ||
+ | |||
+ | The location manaher provides a basic NMEA provider which allows the system to read and parse location sentences (typically $GPGGA). This provider doesn't do much more than connect to the device, enable position streaming, parse, and deliver the results. The generic NMEA provider is suitable for providing basic location services to applications. | ||
+ | |||
+ | The provider provides extension capabilities allowing subclasses the ability to add additional NMEA sentence parsers for extended capability. The structure of the provider also allows sub classes the send device type specific initialization commands to the instrument as needed. | ||
+ | |||
+ | An example of the extended NMEA capabilities are part of the [[android:tracker:TrackReaderStories|Track Reader]] project enabling track download and initialization of specific features for the QStar series of instruments. |