I noted that our app does, on average, 16 pushes (technically 16 tiles plus 16 corresponding toasts) each year, but forgot to add info on our periodic task.
In our app, if the user enables it, the task runs every half hour to download fresh data used to update between zero and a lot of tiles. The sample below shows the main app tile, the tile for a specific class, the schedule tile (we're in week 11 of the term), and the all courses tile (this student has only one course with recent activity, which happens to be the one above it in the picture). Other tiles provide the balance on our "DragonCard", counts of upcoming job interviews, etc. There's lots to update, but not much never every half hour.
We had to restructure things twice and switch our data serialization library twice to get the task to run in 11MB. (I mentioned 20MB above, but that's for 1 GB phones. We stuck with the 11MB limit used for 512MB phones to support more of our students.) The restructuring reduced both memory usage and cellular data used. By only sending the app data when there's a change (i.e., if a student adds or drops a class, the new class list is sent to the phone, otherwise, the server sends back a null list to tell the app to keep using the one already on the phone) the background task generally has less updating work to do, which helps us stay within the memory limits.
We also built in logic so that it a task dies or is killed, the next time that it runs, it finishes updating any remaining tiles using the data retrieved the last time. In such cases, the tiles may be an hour out of date, but at least it keeps the task running. If the app does die twice in a row such that the OS drops the periodic task from the list of enabled apps, we let the user know that and provide why the task was unscheduled (memory, speed, blocked by user via Settings, etc).
In our app, if the user enables it, the task runs every half hour to download fresh data used to update between zero and a lot of tiles. The sample below shows the main app tile, the tile for a specific class, the schedule tile (we're in week 11 of the term), and the all courses tile (this student has only one course with recent activity, which happens to be the one above it in the picture). Other tiles provide the balance on our "DragonCard", counts of upcoming job interviews, etc. There's lots to update, but not much never every half hour.
We had to restructure things twice and switch our data serialization library twice to get the task to run in 11MB. (I mentioned 20MB above, but that's for 1 GB phones. We stuck with the 11MB limit used for 512MB phones to support more of our students.) The restructuring reduced both memory usage and cellular data used. By only sending the app data when there's a change (i.e., if a student adds or drops a class, the new class list is sent to the phone, otherwise, the server sends back a null list to tell the app to keep using the one already on the phone) the background task generally has less updating work to do, which helps us stay within the memory limits.
We also built in logic so that it a task dies or is killed, the next time that it runs, it finishes updating any remaining tiles using the data retrieved the last time. In such cases, the tiles may be an hour out of date, but at least it keeps the task running. If the app does die twice in a row such that the OS drops the periodic task from the list of enabled apps, we let the user know that and provide why the task was unscheduled (memory, speed, blocked by user via Settings, etc).
Attachments
Last edited:
Facebook
Twitter
Instagram