Commit Graph

3 Commits

Author SHA1 Message Date
Jake Hamby
436b29e68e Refactor Bluetooth settings for readability and performance.
Major refactoring of Bluetooth settings classes.
- Moved all functionality from LocalBluetoothManager into new
  LocalBluetoothAdapter and LocalBluetoothPreferences, and into
  existing classes.
- Refactored functionality from BluetoothEventRedirector into new
  BluetoothEventManager class, deleting the original version. New
  version uses a HashMap from action Strings to implementers of the
  BluetoothEventManager.Handler interface.
- Created new BluetoothDiscoveryReceiver to update shared preferences
  timestamp for Bluetooth discovery start/finish. This is the only event
  handling we need to do when the settings app is not visible, so it has
  its own receiver entry in AndroidManifest.xml. Edits are written using
  QueuedWork.singleThreadExecutor(), which BroadcastReceiver knows about
  and will wait for completion, eliminating the need for PendingResult.
- Miscellaneous cleanups to code style and logic for readability.
- Pulled some large switch statement code blocks into new methods.
- Changed all Bluetooth state references to the new BluetoothProfile
  constants.
- Changed use of deprecated Notification constructor in
  BluetoothPairingRequest to use Notification.Builder.
- Moved Utf8ByteLengthFilter helper function from BluetoothNamePreference
  into its own class, and moved test cases into the same package.
- Moved all LocalBluetoothProfileManager functionality related to
  specific profiles into new top-level classes (A2dpProfile, etc.), all
  implementing the LocalBluetoothProfile interface.
- Moved all UI-related methods from CachedBluetoothDevice into the class
  that uses the method, or into the static Utils class for shared methods.

Change-Id: I6d49b7f4ae0c7d7dcf62551ee40b51ecb5fe4f47
2011-03-01 18:44:36 -08:00
Amith Yamasani
d79934731c Refactor settings top level activities to use fragments.
Added a base class SettingsPreferenceFragment from which the settings activities should
be derived so that they can behave like fragments. It contains some commonly called
utility methods and dialog conversion to DialogFragment.

Some of the top-level activities can be launched directly without the left pane.
Settings.java acts as a proxy activity that contains just that settings fragment without
the left pane.

There are still a lot of second and third level activities that need to be fragmentized.
This is just the first pass to test the 2-pane layout.
2010-08-18 22:59:33 -07:00
Anders Hammar1
b2dd90383b Settings: Add a hook for operator or vendor specific settings.
The Settings application now provides a hook that can be used by an
operator or a vendor specific application to add an activity of choice
in the settings menu.

Change-Id: Id55da9fd4262bbfc6a5abf863799c747b0d75b24
2010-06-11 14:27:29 +02:00