Autocognita - Literacy Mobile Application API 1

Challenge Objectives
The purpose of this challenge is to implement the 1st set of the API for an Android app, please follow the details in the architecture to implement all the specified endpoints in this challenge.
 
Project Background

• This is a mobile Android app that aims to help millions of low-literacy adults acquire basic reading skills needed to lead a fulfilling life.
• Users will learn anytime, anywhere with this mobile app.
• The app is similar to Duolingo in nature, but with a focus on literacy.
• The whole system consists of two parts: an admin web portal and an Android app:
  • The web portal is used by admins to manage courses
  • The Android app is used by normal users to learn, the Android app will need to pull course data created by admins

 
Users Roles
This Android app can be used by any user.
The Admin web portal can only be used by admins.
 
User Workflow
Below is a high level workflow of the Android app, make sure you read the more detailed screen logic document which contains screenshots to better understand the details.
Workflow Step #Description
Step 1The user launches the mobile app and Signs Up / Login
Step 2For first time login, show video instruction, and let user complete placement test and show placement result
Step 3User sees the home screen (menu). User can click the current Unit to see Unit Intro, and choose to either test out or continue lesson.
For test out: user may fail or pass. In case of failure the user will see a list of lessons, and the user can choose an available lesson to continue (this is the same as continue lesson) . In case of success user will be taken back to home screen with the next unit unlocked.
For continue lesson: the user will see a list of lessons, and the user can choose an available lesson to continue.
Step 4User enters a lesson and sees a series of different questions, presented one at a time. For example: questions may be image+text, text only, image only, or audio based. Answers may be image, text or audio.
 
Admin Workflow
Admins will provide username and password to login to the admin web portal, and then be able to update course data which once published can be consumed by the Android app.
 
Challenge Scope
For this challenge, you need to cover the following endpoints:

1. /admin/login, /logout, /me
2. all endpoints in Master group
3. all endpoints in File group
4. Audio generate work queue (see swagger document)
5. Scheduler job (see swagger document, cleaning the files which aren't referenced)
6. AWS S3 (presigned url), google text to speech integrate

 
Please make sure you check all the details in the ADS and the swagger file, and make sure you go through the data structure excel template file to make sure you understand how the data should be used in the system.
 
Features (Reference Only)
There are some features that are not obvious in the app but need to be done properly:

1. In the admin app we can upload audio (mp3) file for any content that requires such data. But instead of requiring an uploading of audio files, the backend system should also try to do this automatically: use a cloud-based TTS API (e.g. Google Text to Speech) to generate the audio for the text, and automatically save that audio clip as a file using the supplied filename as specified in the database. Therefore, what we are doing is to pre-load automatically generated TTS as audio files and store them in advance, instead of calling these API in real time. This saves the content contributor to go through the trouble of having to record everything and upload them to the system.  However, some kinds of audio cannot be correctly generated by TTS (e.g. phonic sounds or word parts) and therefore requires a manual audio upload.  There is a bulk upload function to upload multiple audio files at once.
2. In the admin app we can upload images (png) file for any content that requires such data.  There is a bulk upload function to upload multiple image files at once.
3. For content management, upload excel to build import data is the key, please carefully check the data structure document and admin portal specs to understand the details / logic.
4. The admin portal manages a list of sponsor images, the Android app will randomly display one of the images at the end of each lesson / unit / level.
5. Certificates: the user can earn certificates based on successful completion of all units within a specific level.
6. Badges: the user can earn badges based on specific behavior patterns.  These are determined based on usage data collected.  The criteria for how to earn specific badges are shown in the Badges tab of the Data Structure spreadsheet.
7. Social Sharing: the certificate and badges will be automatically generated based on a pre-configured template image and text will be generated on-the-fly with the lesson completion information and the user's name. Then that image can be shared by the Android app.
8. The android app needs to send usage data such as session times, lesson / unit / level completions, and #correct answers in a lesson, other auxiliary data such as date/time, unit ID, lesson ID to the server. Some other parts of the system (like badges / certificates) will depend on such data)
9. We would also like to save, within each lesson screen, all click actions. This includes which buttons has been clicked and in what sequence (with a timestamp), prior to the user submitting the answer choice. This information is used to analyze the user's learning behavior so that we could possibly develop some personalization functions if needed. The app should record each click event (that is, a click that results in something happening; clicking on a blank part of the screen doesn't count). I assume this can be done with Google Analytics SDK.
10. Android app needs to be able to work offline so it needs to download content data from the server when WIFI is available.
11. Android app needs to be able to update the local data when a new version is detected.
12. Android app needs to be able to send its local learning data to the server.

 
Important Notes
Please make sure your submission covers the following:

1. Backend should be implemented using Java 11 + Springboot
2. Use the specified database in the architecture
3. Make sure your code is fully documented and follows Java best programing practices
4. Use maven for building / packaging the solution
5. Provide postman collection file(s) to test the endpoints
6. Provide test data to test the endpoints (you may have to modify the data structure file to make sure it’s valid)

 
Technology Stack
The following technology stack will be used as part of this challenge:

• Java 11
• TextToSpeech
• JSON
• Sprintboot
• MongoDB
• Maven
• REST

Final Submission Guidelines

1. Full code that implements all the specified endpoints
2. A detailed readme in markdown format that states how to configure, build and test your code
3. Postman collection file(s) to test your api implementation
4. Test data to test your api implementation