Analytics Engine

[Tornquist]

Summary

• Introduce analytics engine to accept queries, evaluate them and return the results
• The query engine will monitor the store and cache rough analysis for faster execution
• Added total and byCategory operations to replace widget and landing screen analysis

Details

• Introduce Analyzer to alias queries and hold actual analysis/caches/etc
• Introduce AnalysisCache to cache EntryAnalysis results by day and allow fast retrieval
• Introduce Split to analyze Entries over their full range and generate calendar-aligned durations
• Expand DateHelper and add TimePeriod/TimeRange for easy to communicate rolling and fixed durations

Analysis Details

• Entry analysis is aligned with the calendar that a given entry was recorded in. If an entry started at 8am local time, it was started at 8am all time. This alignment allows for consistent comparison of days and durations from the perspective of the individual that lived it, instead of shifting all times should you move, or query the data from a different time zone.
  • If you are analyzing a decade of data, and move in the middle. You don't want to see a shift of start time of 1 hour if for the entire decade you started working at "9 am." The point is not for GMT analysis, but for user-focused perspective analysis.
• The date slicing (week, month, year) query is performed from a global calendar. This can (and will) default to the local device calendar from app usage, but also can be explicitly set. In most cases it won't matter, but it does mean that "last week" results will roll at midnight from the perspective of the query's calendar, regardless of the event calendar.

Concerns

Calendar interface and API expectations

• Using the default calendar is clean and consistent from the SDK user's perspective. Passing a calendar through the entire stack is less so. Calendars are passed or created:
  • In Split when analyzing a single entry (this is good)
  • In AnalysisCache when orienting start/end times. This isn't super ideal, but is important to evaluate final day orientation when times can cause a day to shift. Originally I used Calendar.current, but that made test stability tricky. AnalysisCache in actual usage will be hidden from external use. It's an implementation detail for performance.
  • In Analyzer when evaluating by time range (will default to current or use provided)
    • This will allow all external app usage to just save "give me a rolling week" and it'll be from the perspective of the caller. This is my optimal use case
  • In Analyzer when evaluating directly a calendar must be provided

This means that there is a default calendar only when passing by relative range.

[codecov]

Codecov Report

Merging #27 (b6fe88a) into master (15beeca) will increase coverage by 0.37%.
The diff coverage is 93.11%.

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
+ Coverage   91.46%   91.84%   +0.37%     
==========================================
  Files          16       22       +6     
  Lines        1676     2010     +334     
==========================================
+ Hits         1533     1846     +313     
- Misses        143      164      +21     

Impacted Files	Coverage Δ
Shared/Interface/Time.swift	76.92% <66.66%> (-0.42%)	⬇️
Shared/Interface/Analyzer.swift	87.76% <87.76%> (ø)
Shared/Analytics/Split.swift	93.44% <93.44%> (ø)
Shared/Analytics/AnalysisCache.swift	98.71% <98.71%> (ø)
Shared/Analytics/EntryAnalysis.swift	100.00% <100.00%> (ø)
Shared/Analytics/TimePeriod.swift	100.00% <100.00%> (ø)
Shared/Helpers/DateHelper.swift	100.00% <100.00%> (ø)
Shared/Interface/TimeNotification.swift	100.00% <100.00%> (ø)
... and 5 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 15beeca...b6fe88a. Read the comment docs.

[Tornquist]

💚