There is no good reason for disallowing TDD retrieval while the Combo
is suspended - the TDD history screens are accessible, and TDD retrieval
does not cause any insulin delivery to take place.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
That text shows contents that are different to that of warning screens.
Instead of extending the interpretation logic to cover such contents as
well, just use a generic ERROR_TEXT AlertScreenState. That text won't
be interpreted by any program logic anyway, since error screens are
never dismissed automatically.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
Some TBR percentage screens like the Lithuanian one show a % symbol
right after the text. Add an optional symbol parser to handle it.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
* Check if the alert screen is the confirm or snooze screen, and press
the CHECK button once or twice accordingly. This avoids fringe cases
where the amount of button presses is incorrect.
* In rare cases, more alert screens may show up after dismissing the
current one. Add code to keep observing remaining alerts and redo
the dismissing logic after a while if necessary.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
When delivering extended and multiwave boluses through the command mode,
the boluses are marked as "automatic" by the Combo, and use different IDs
compared to extended/multiwave boluses that were initiated through the
remote terminal mode. Add support for these IDs, and extend the
CMDHistoryEventDetail subclasses for extended and multiwave boluses with
a field that specifies whether the bolus was manual or automatic.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
To support extended and multiwave boluses in the future, it is necessary
to properly parse the main screen when it shows extended/multiwave
content. This requires some rework. Most notably, the code needs to be
changed to no longer throw ExtendedOrMultiwaveBolusActiveException.
One problem with extended/multiwave content on the main screen is that
it does not show TBR details (percentage & remaining duration). For this
reason, it is necessary to actually navigate to the TBR percentage screen
and read those value there. This means that the setTbr() call is slower
when an extended/multiwave bolus is ongoing, but better to be slower than
to omit post-setTbr checks that may catch rare errors.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
This name is less confusing, especially if another enum class for the
bolus delivery is about to be introduced.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
The previous behavior was reading the profile correctly, but the progress
report was off by one factor. Also, blinking screens were considered as
separate ones, causing the short button press based fallback to kick in
unnecessarily often because that blinking screen behavior caused the
main long button press based reading loop to miss the last profile factor.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
* device is unpaired while discovery is ongoing" does not happen because
discovery only occurs if no device is paired.
* Using the second offered BluetoothDevice works reliably on all tested
phones so far.
* AndroidBluetoothDevice throws a BluetoothException if all of its
internal connect attempts fail.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
When exiting the basal profile screens by pressing CHECK twice, a
vibration happens. This can be avoided by instead pressing BACK until
the main screen is reached.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
* Don't set a fake 100% TBR again if the current fake 100% TBR
is finished within 15 minutes (reduces number of TBR operations
and allows the Combo to return to a non-TBR state).
* If the expected TBR percentage was a non-100% one, but not we see
a non-TBR main screen, check if the expected TBR duration was <= 2
minutes. This covers the edge case when the TBR ends at the same
time when we run this check.
* Inform callers about the exact outcome of the setTbr() call. It could
be that it set the TBR normally. Or, it might have set a fake 100% TBR
(if the user requested a 100% TBR and force100Percent was set to false),
and so on.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
After a long button press, short button presses may be necessary to
fix "overshoots". An alert screen may appear during those short button
presses, so look at the screens to make sure alerts are not missed.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
The code in adjustQuantityOnScreen() needs an current quantity. This is
determined during the long button press. If no such long button press
happens, get the quantity by explicitly receiving parsed frames. But
don't read those parsed frames if a long button press happened; this
is redundant and just slows down the function.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
