project: Moodle app
summary: Offline improvements in the Mobile app
description: An interesting feature would be to have a queue of WS requests that failed because the device was offline or we couldnt connect to the server. This would allow the user to perform in offline things like sending messages, adding posts to forums or play a SCORM. If the calls failed because the device was offline we could re-try them when the device goes online, but what happens if the requests failed because the server was down or something? Maybe we should re-try them every certain time as long as the device is connected. Also, Juan suggests that the user should be able to see the queue, force a re-try and also delete some requests from the queue. In the case of messages it would be nice if they could be seen in the conversation as long as theyre in the queue, and allow the user deleting them from there like it happens with WhatsApp.

1.summary: Delete devices (when a site is deleted offline)
description: If a site is deleted offline, we must delete the devices from the site
2.summary: Support offline messages
description: It will be interesting supporting offline messages, so the user may send several messages and they are sent one the user is connected back
3.summary: Synchronization process
description: The current synchronization process doesnt work very well because uses the same thread that the app, so sometimes the UI freezes We need to start using web workers, this is currently only supported in Android 4.3 and iOs6 but the benefits are huge
4.summary: Create an app notices feature
description: While developing the SCORM addon we thought it would be nice to have a "Notices" feature where you can see some messages that happened (generated in the app). This would be useful for synchronization and background processes, since failure messages and warnings would be added to this section. This new option should be added to the side menu. We would have to differentiate between read and unread messages, and show a bubble with the number of new messages so the user sees it in the side menu.
5.summary: Execute sync hooks using cron delegate when the user clicks to sync a site
description: Right now, when the user clicks to synchronize a site we only invalidate the downloaded data so its redownloaded the next time he accesses the module. As the name "synchonize" implies, we should also execute the synchronization processes only for that site. Since we are executing a partial synchronization (only one site), the last execution time shouldnt be affected so its possible that the app executes the site sync and the "all sites" sync at the same time. Some things to take into account: The documentation of the cron delegate already specifies that it can pass a siteId to the execute function. SCORM and quiz sync functions already support both options, all sites or single site, so they can be used as an example. We should show a spinner or something similar until all the processes are done. Right now we block the user using mmUtilshowLoading, we shouldnt do that. Should this skip the queue of cron processes?
6.summary: Start discussions and reply posts offline
description: Allot to post when the user is offline and then synchronize
7.summary: Add notes offline
description: Allow teachers to add notes when they are offline
8.summary: Take choices offline
description: Allow users to take choices offline and then synchronize
9.summary: Take surveys offline
description: Allow users to take surveys offline
10.summary: Create wiki pages offline
description: Allow users to create new pages when they are offline. Edit pages or sections should be done in .
11.summary: Allow assignment submissions offline
description: Users should be able to submit text or files offline (and then synchronize)
12.summary: Create common synchronisation functions and helpers.
description: Most modules will have some common functions to implement syncing. To reduce code they can be put together in a library.
13.summary: Offline sync consistency
description: We must be sure that the synchronization button (like the choice one) is consistent in the rest of modules (forum, scorm, quiz, survey) and functionalities like notes.

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle app
summary: Offline improvements in the Mobile app
description: An interesting feature would be to have a queue of WS requests that failed because the device was offline or we couldnt connect to the server. This would allow the user to perform in offline things like sending messages, adding posts to forums or play a SCORM. If the calls failed because the device was offline we could re-try them when the device goes online, but what happens if the requests failed because the server was down or something? Maybe we should re-try them every certain time as long as the device is connected. Also, Juan suggests that the user should be able to see the queue, force a re-try and also delete some requests from the queue. In the case of messages it would be nice if they could be seen in the conversation as long as theyre in the queue, and allow the user deleting them from there like it happens with WhatsApp.

### Response:
1.summary: Delete devices (when a site is deleted offline)
description: If a site is deleted offline, we must delete the devices from the site
2.summary: Support offline messages
description: It will be interesting supporting offline messages, so the user may send several messages and they are sent one the user is connected back
3.summary: Synchronization process
description: The current synchronization process doesnt work very well because uses the same thread that the app, so sometimes the UI freezes We need to start using web workers, this is currently only supported in Android 4.3 and iOs6 but the benefits are huge
4.summary: Create an app notices feature
description: While developing the SCORM addon we thought it would be nice to have a "Notices" feature where you can see some messages that happened (generated in the app). This would be useful for synchronization and background processes, since failure messages and warnings would be added to this section. This new option should be added to the side menu. We would have to differentiate between read and unread messages, and show a bubble with the number of new messages so the user sees it in the side menu.
5.summary: Execute sync hooks using cron delegate when the user clicks to sync a site
description: Right now, when the user clicks to synchronize a site we only invalidate the downloaded data so its redownloaded the next time he accesses the module. As the name "synchonize" implies, we should also execute the synchronization processes only for that site. Since we are executing a partial synchronization (only one site), the last execution time shouldnt be affected so its possible that the app executes the site sync and the "all sites" sync at the same time. Some things to take into account: The documentation of the cron delegate already specifies that it can pass a siteId to the execute function. SCORM and quiz sync functions already support both options, all sites or single site, so they can be used as an example. We should show a spinner or something similar until all the processes are done. Right now we block the user using mmUtilshowLoading, we shouldnt do that. Should this skip the queue of cron processes?
6.summary: Start discussions and reply posts offline
description: Allot to post when the user is offline and then synchronize
7.summary: Add notes offline
description: Allow teachers to add notes when they are offline
8.summary: Take choices offline
description: Allow users to take choices offline and then synchronize
9.summary: Take surveys offline
description: Allow users to take surveys offline
10.summary: Create wiki pages offline
description: Allow users to create new pages when they are offline. Edit pages or sections should be done in .
11.summary: Allow assignment submissions offline
description: Users should be able to submit text or files offline (and then synchronize)
12.summary: Create common synchronisation functions and helpers.
description: Most modules will have some common functions to implement syncing. To reduce code they can be put together in a library.
13.summary: Offline sync consistency
description: We must be sure that the synchronization button (like the choice one) is consistent in the rest of modules (forum, scorm, quiz, survey) and functionalities like notes.
