New Device Workflow
- User enters own UserID and API Key and location in computer for the purpose of syncing IVLE files
- Client supplies device UID for the purpose of uniquely identifying this machine and proceeds with the registration of this device against the user's account
- All these information are saved to the local disk for reuse on subsequent startups
- Application goes into background mode to quietly synchronize the latest files from IVLE to the local folder
Workflow on subsequent iterations (after a polling interval of at least 1 hour)
- Application automatically goes into background mode to quietly synchronize the latest files from IVLE to the local folder using the entered information
Workflow on change of API Key
- User goes into client to update to the new API Key and system will proceed to check and get the latest IVLE files
When can sync ids (access tokens) be rendered invalid or expire?
The situations which come to my mind are (this is not an exhaustive list) -
- When the user deauthorizes our application/device via ivlefilesync.sgcloudapp.net.
- The user leaves NUS
Points to note
- Implementation does not require login to IVLE, it depends on the user keeping the API key secret
- If user goes to IVLE to download the file before the system polls IVLE, this file will not be available for sync
- System does not track the files which are deleted from the workbin or ereserves, so the files are always appended and never deleted
- Adding a new device will sync all the files beginning from when they first register for this service (we will have to address this in future versions)
- If user deletes/appends/renames any file on the local file system, that is the user's personal decision and so the application will only append the files which are newly added in IVLE and not monitor the contents of the user's local repository.
The part related to sync id (or access token as I like to call it) might seem to be confusing if you are not familiar with this type of workflow. If this indeed is the case, I strongly suggest you to give a read to this page which explains it very clearly - https://developers.facebook.com/docs/authentication/. Though the page relates to Facebook API, it will give you a very good idea about this whole authentication business.
Another excellent read closely related to this - https://developers.facebook.com/blog/post/500/