Design

OVERVIEW

The original Magic Mirror, created by GitHub user MichMich, is an application intended to work in joint with a Raspberry Pi and an LCD screen to create a smart mirror. A user will be able to see not only themselves in the mirror, but also the weather, the day's date, news, or any other information that a developer wishes to create.

Our goal is to create a new Calendar module that can be enabled to replace the default Calendar module, which by default only shows enabled ICal calendars - in this case, only US holidays. The new module, gCalendar, will display a mix of upcoming ICal and the user's Google Calendar events, with minimal user hassle (not having to constantly sign in).

environment

The original Magic Mirror is written in the JavaScript scripting language for Node.js - an open source JavaScript runtime environment for developing a diverse variety of server tools and applications. The Magic Mirror is output via Electron, a framework for developing and displaying GUI. We will be testing on Mac (OSX Sierra v10.12.3, ) and Windows 10.

Program control flow

Modules

• Default modules, included in inherited code base
  • Clock
  • Current Weather
  • Weather Forecast
  • News Feed
  • Compliments
  • Hello World
  • Alert
• Developed by us, not part of original code base:
  • gCalendar - an updated version of the default calendar module. This module will allow the user to
    • Retrieve ICal events
    • Retrieve user's private Google Calendar events
    • Display a mix of ICal and Google Calendar events, in chronological order, from closest event to furthest event
    • Maintain Oauth2 tokens in order to minimize the number of user sign-ins
• Previous semester's MagicMirror Maintenance Documentation can be seen below

user screen

user scenarios

• The user must first obtain Oauth 2.0 credentials from the Google API Console
• The information received above is placed into a credentials variable in the gCalendar code (or perhaps the config file) and that is used to obtain an access token from the Google Authorization Server.
• The access token is used to gain access to the Google Calendar API and the user's Google Calendar information is received.
• Because access tokens have a limited lifespan and we wish to have a minimal amount of sign-ins necessary for users, we will obtain a refresh token, which will be used to get a new access token once the previous token's lifetime has expired. If these tokens are maintained properly, the user should not have to interact with this interface again.

design considerations

Ease of use for the user is one of our top priorities, as requested by the customer, so this is the most essential consideration. After retrieving the initial Oauth 2.0 credential from the Google API Console and placing it at the designated place in the code (which will, of course, be very clear in the documentation), the user should not have to sign in at any time in the future, assuming nothing changes with the way that Google APIs handle authorization.

We are considering using Passport to manage Google sign-ins and Oauth 2.0 tokens, but this comes with a couple of potential problems:

• Users would have to install Passport successfully, and thus far, only one of us has been able to get all necessary packages and libraries installed. This would probably also be a problem for users, but we are still investigating this as an option.
• Using Passport would require us to learn to use yet another tool, when there are already plenty of moving parts to this project.

sizing estimates

We are estimating that approximately 150 lines of code will need to be added to the default Calendar module and/or config file in order to meet our requirements.

• 5 lines of code in the config file designating where to retrieve Google Calendar information and a Google icon
• 80 lines of code for retrieving Google Calendar and maintaining Oauth 2.0 tokens
• 65 lines of code to parse Google Calendar API return, place it in the calendar array and sort it