Closed XanderLeaDaren closed 2 years ago
Non-repeating alarms will be pretty easy. It just requires a bit of UI.
Repeating alarms are more challenging. It requires that Suntimes Alarms somehow know how to schedule these "roman hour events" (preferably without hardcoding that into the alarm clock itself).
I think I've found a pattern that can make this work.. Add-ons could provide their own custom events by implementing an interface (ContentProvider), and advertise that as part of their manifest. It should supply two methods; one that returns a list of event names, and another that returns the next timestamp for a given event. Suntimes Alarms would then scan for implementations when it starts and show any custom events in the alarm dialog. Internally it would continue to store the event name (no changes to the database), which could be extended to encode the ContentProvider uri. Later when a repeating alarm needs to be (re)scheduled and one of these uri's is encountered, the next timestamp could be queried - the scheduling is delegated to the addon (vs running an algorithm directly).
Something similar was done in the latest Suntimes Calendars implementation, where addons can now advertise a "calendar provider" in their manifest, which is then queried to create the list of available calendars. That allows the SolunarPeriods app to provide a "hunting and fishing" calendar.
Anyhow, thinking aloud.. This is probably some uninteresting detail, but it helps me to talk it through.
Nice and elegant way of integrating the event names and timestamps!
The alarms branch can now do this, when used with a version of Suntimes from the alarm-addon branch. Its necessary to rebuild both apps.
The plan is to release Suntimes v0.14.0
some time in January, and then Natural Hour v0.2.0
with the alarm feature after that.
Thank you for this, setting and launching alarms on times related to roman hours is working. 👍🏽
Out of interest: İ have 39 subdivisions for every day-hours and night-hours even if they are not as long. How is the calculation done?
These are 'moments', similar to minutes, except 40 to an "hour", with variable length. I think I remember reading this was a medieval thing. The hour is divided into quarters, and then each quarter divided into ten. It is basically just a fraction though (20/40 is half past), and I was considering simplifying it.
How is the calculation done?
In case you were actually asking about code.. The scheduling algorithm
basically reduces the moment to a float [0,1], then calls this function
which multiplies it by the length of the hour (day-hour vs night-hour), and adds to it. It basically boils down to..
Calendar calendar = Calendar.getInstance();
float hourLength = (hourNum >= 12) ? (naturalHours[13] - naturalHours[12]) : (naturalHours[1] - naturalHours[0]);
long momentMillis = (long)(hourLength * moments);
calendar.setTimeInMillis(naturalHours[hourNum] + momentMillis);
where naturalHours[]
contains timestamps (milliseconds) for each hour, previously assigned by
Thank you for these detailed answers! 🙂
It would be nice to have the ability to combine NaturalHour and Suntimes Alarms to set alarms depending on Roman hours.
The only drawback I foresee is due to the (as far as I know) non-existence of subdivisions of these unequal hours, so it would be limited to setting a alarm for the beginning/middle/end of a specific Roman hour.
What do you think?