1
0
mirror of https://codeberg.org/Freeyourgadget/Gadgetbridge synced 2024-07-02 01:36:23 +02:00
Commit Graph

5 Commits

Author SHA1 Message Date
cpfeiffer
c407ed1a76 Last refactoring for now: BluetoothCommunicationService
- rename to DeviceCommunicationService
- move all bluetooth related bits into separate DeviceSupportFactory
  class
2015-08-04 01:01:14 +02:00
cpfeiffer
7c597b325a Big refactoring: move classes and packages around to get a better structure
- 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
2015-08-03 23:09:49 +02:00
Daniele Gobbetti
900511760c further improvements:
- 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 :)
2015-06-30 06:40:46 +02:00
Daniele Gobbetti
dc3ed1659c use parcelable for passing alarms around 2015-06-30 06:40:46 +02:00
Daniele Gobbetti
1caca1439a Initial implementation of setting alarms to the Mi Band.
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
* ...
2015-06-30 06:40:14 +02:00