This helps clearing up a cluttered alarms list on devices like the Mi Band 4
Difference between disabling and setting to usused:
Unsused alarms cant be enabled from the Band, disabled can.
Closes#1747
This allows to construct per-device settings by device type very easily
device coordinators just do the following to declare which setting they support,
the settings activity is then composed at runtime.
@Override
public int[] getSupportedDeviceSpecificSettings(GBDevice device) {
return new int[]{
R.xml.devicesettings_miband3,
R.xml.devicesettings_swipeunlock,
R.xml.devicesettings_pairingkey
};
}
When connecting to a new device, a random key gets generated, which can be
looked up from the device specific settings (accessible via the gear icon in
the device card in the main activity). Old devices keep their 0123456789@ABCDE
key, they have to be re-paired to change that.
During pairing, long-pressing the device candidate in the discovery activity
will also start the device specific settings activity, where the auth key
can be set manually priror to pairing. This is usefull to keep the ability to
pair one device with multiple android devices.
Fixes#1308
Go to notification blacklist, allow an app if blacklisted, than configure it's behavior with the menu icon on the right hand side.
Should be pretty much self explanatory.
Database Scheme raised to 20
TODO:
- Fix alarm widget (how can we get the deviceId?)
- Get rid of GBAlarm in favour of DAO generated Alarm class
- Find better defaults
- Bonus: migrate old preferece based shared settings
This removes misuse of testNewFunctionality() and support fetching GPS data and debug logs
Fetching debug logs (Amazfit Bip/Cor) is now accessible in the debug activity
Fetching GPS data can be done by swiping in the list activity.
TODO: actually refresh list when fetching data is done :P
Also fix some android studio warnings on the go...
As requested in #736, this adds an entry in the settings menu that allows to blacklist certain calendars.
To avoid confusion, all the former blacklist methods and fields have been renamed to apps_blacklist. The new entries are called calendars_blacklist.
Importing the settings has not been tested with the current changes.
Closes#736
Future improvements TODO: The new setting lives in the Pebble section, i believe in the future the blackslist functionality should be centralized and put in the sidebar.
- rename the layout file of the alarm item to better organize the files
- add a color selector for the item view, this replicates the old behavior of using the color to highlight enabled days
- remove the nested linearlayouts in the alarm details activity layout and use CheckedTextView instead
- allow dragging by using a drag handler (as per best practice)
- remove the custom draglistview dependency
- update to the latest android support libraries
Close drawer before launching activities (feels sloow).
Implement device deletion (untested).
Add app-management icon, remove tap-connected-device-for-primary-activity, hidden (not removed) text hint.
Use level-list for device icon.
Use the new control center when tapping GB notifications.
Added icons to the legacy control center context menu, perhaps it can be embedded in the card?
Added lost-device icon and action, added background to buttons.
Overflow reveal is now animated inside the card.
Bind connect and disconnect actions to device-icon (short press to connect/launch default activity; long press to disconnect).
- disconnect by long-pressing device icon (temporary)
- use level-list to show battery level + charging
- remove padding around cards list
- use style colors for action icons (supports dark theme)
- add secondary text to the themes, even though the color is the same
- replace the info icon with three vertical dots
- grab icon to move apps
- cache can be sorted but nothing will be send to watch
- if sorting apps or watchfaces, order will be sent to watch
- we try to keep track of what is installed and what not
Firmware 2.x is currently not working properly
The notfification APIs now use NotificationSpec as their only parameter, which
contains all information (required and optional ones).
We no longer have separate methods and actions for SMS/EMAIL/GENERIC anymore.
The type of notification is important now, not how we received them technically.
- append a string on the control center when the device is charging
- battery status string is no more, welcome battery state enum
- the notification will not be shown when the device is charging, even if the level is below threshold
Previously, the DeviceCommunicationService was invoked directly,
via
Intent intent = new Intent(foo, bar);
intent.setExtra(EXTRA_BAZ, baz);
startService(...);
and this was scattered throughout GadgetBridge.
Now there is a "frontend" available, so that you can call
the service more easily, like
GBApplication.deviceService().connect();
For a start, this client interface (DeviceService) actually
implements the same interface (EventHandler) as the receiving side
(DeviceSupport). This may change in the future.
This will also make testing much easier, because we can use
this client interface to invoke the test service as well.
- model package contains mostly shared interfaces (UI+service), not named GB*
- impl package contains implementations of those interfaces, named GB*
the impl classes should not be used by the service (not completely done)
- the service classes should mostly use classes inside the service and deviceevents
packages (tbd)
Every device now has two packages:
- devices/[device name] for UI related functionality
- service[device name] for lowlevel communication
- the day of week are evenly spread across the screen in the alarms detail activity
- the alarms are stored in a single shared preference (as a set) NB: you'll have to reset your alarms if you used a previous version (and also manually clean the shared preferences, but this is not needed)
- the list of alarms gets correctly updated after editing a specific alarm
- the actionbar back button saves the alarm status, the device back button doesn't. I'm not sure if it's a bug or a feature :)
The code basically works, but there a lot of things to fix / improve.
* The alarms are stored to and read from the Shared Preferences, but there is no persistence within the app (basically they are read and stored at every access)
* The alarm list is not updated when coming back from the alarm detail view (probably related to the point above), but the actual alarm is
* The alarms preference names is sometimes built by concatenating strings, which is not really safe
* There is no check in the alarm constructor whether the stored string is a valid alarm representation
* Even though only 3 alarms can be stored on the device, we could have more in the app and let the user choose which to sync
* In the alarm detail view XML some material* drawables are used, it's possible that these break on android version < 5
* ...
