• Refresh more often when blocks are expected to change
  • In the prior and post 5 minutes during expected block change
• Do not stall web requests during refreshing
  • Right now it stalls all web requests and runs the jar multiple times, this is not good
• Be comparable with future web hooks
  • Webhooks will be in a future ticket, but ensure the refresh / cache system still works when we eventually migrate to that
• Ensure it is tolerant of user-specific requests
  • Right now it accepts a username and password post parameter, ensure the user specific stuff is still not cached

The Api currently always returns true for isClassInSession and C block for the current block. I know that you already know about this, but it would be nice to have it fixed.
Also, no I can't do that because I have no idea how ScheduleCheck even works.

In order to dynamically update timers, it would be useful to have a field in the schedule endpoint that gives start and end times for each block. Just returning timestamps like it has in the picture would be fine, but it would be best to return a formatted date object whether that is in a string or a number of seconds or milliseconds in order to reduce complication on the front end.

For formatting, a possibility would be
"blockTimes": [{"block": "A", "start": "1514001963005", "end": "1514001979926"},...]
This would allow for easy access to both the block letter and timing information as well as opening possibilities for additional fields to be added to each block without breaking existing applications.

A reference to a student Id would be helpful for getting a unique identifier.