Commit Graph

15 Commits (a566a6656c75f4e4cb3f026e06cbfe88bae4db9d)

Author SHA1 Message Date
cpfeiffer ba7d13fa5d Disable smart alarms for Mi2
Closes #471
2017-01-26 21:09:49 +01:00
cpfeiffer e35ce978bd Remove now unused imports + fix one more SharedPreferences usage 2016-04-25 23:43:19 +02:00
cpfeiffer 0704915a88 Move parsing of preference strings to int values to Prefs 2016-04-25 23:39:03 +02:00
cpfeiffer 0c715a2669 Wrap access to SharedPreferences with "Prefs"
(to centralize quirk handling)
2016-04-25 23:18:55 +02:00
Andreas Shimokawa 4bcebca744 Work towards dark theme, remove -v21 specific theme definition 2016-04-14 15:21:25 +02:00
Lem Dulfo 70ed14243f Remove all getActionBar occurences, temporary fix for overlap 2016-04-10 21:11:52 +02:00
Daniele Gobbetti 78cd11ad93 Hide the last N reserved alarm slots from the Alarm activity.
The original values remain stored in the preferences, they are just not available to the user anymore, further they are not sent to the device.
2015-12-17 17:02:00 +01:00
cpfeiffer 4e0fed8857 Improvements to how and when alarms are sent to the device
They are now sent whenever the Alarms activity is finished.
Display "All alarms disabled" when no alarm is enabled.

Unrelated: pass exceptions to GB.toast() where applicable.
2015-10-18 23:52:59 +02:00
Andreas Shimokawa 1d41f2f8e4 Refactoring
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.
2015-09-24 14:45:21 +02:00
cpfeiffer a1cb246e27 Add and use a "client interface" for the actions of the service
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.
2015-08-21 01:03:57 +02:00
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