Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.
Talk:How to manage long running Periodic Tasks
Vinayppatil - Title
As always i am still confused with article title. If anybody can think of a better one please suggest.
13:13, 17 April 2013 (EEST)
Mfabiop - Thanks
Thanks for the article! This is a real problem and your solution is nice. I was just implementing a background task yesterday and I'm going to use your article to control the 25 available seconds.
About the article name, I don't know if it's a good choice to use slashes in the article name; It looks like a folder hierarchy; It could be something like 'How to manage the 25 seconds available of a periodic background task'.
PS: Your solution doesn't work on Windows Phone 7? It's really simple. I don't know why it wouldn't work on WP7.
17:27, 17 April 2013 (EEST)
Vinayppatil - Glad it helped
Glad it helped you.
Changed title also added support for windows phone 7.
17:51, 17 April 2013 (EEST)
Hamishwillee - Discussion boarddiscussion board post from which this article originates ongoing. I'm adding link because my eventual comments will depend on final results.
04:07, 19 April 2013 (EEST)
Didn't knew the discussion is alive again.:P Will see them.
07:25, 19 April 2013 (EEST)
Hamishwillee - Well, its not "very alive"
Just FYI, I get hundreds of notifications from the wiki each day and I can't check all of them. If you see I don't respond then feel free to email or message me directly.
The discussion has stalled. The problem i have here is that anecdotally you can't rely on the time being 25 seconds - this could be cut short or not be run at all. So hard coding to 25 seconds is not trustworthy.
This means that you can NEVER be sure to call NotifyComplete(); in time - which from other indications is a problem. Do we know that it is for sure a problem?
Not sure then what advice to provide, but I know this advice is flawed. I'd also suggest that given you can't rely on the time, then the important approach is something described by Joao - completely fault tolerant.
10:32, 25 April 2013 (EEST)
Vinayppatil - Clarifications
After reading the discussion post i created a sample periodic task app and deployed it on my Lumia 820 last week. According to logs i got, Periodic task ran almost every 20-30 minutes for 25 seconds. Even when - Battery was low(less than 20%). - Power saver mode was on. - Phone was heavily loaded(While playing Real Football 2013).
And it is not just a development device which i use only for testing apps. It's my primary personal phone, so it has loads of games/apps installed in it and it goes through the whole life cycle of a normal phone.
Regarding the 25 seconds issue, the essence of periodic task lies in those critical 25 seconds. Which itself are less to do something in background and that's exactly why this article is been written for. If we can't even be sure of having 25 seconds, does periodic task make some usefulness?
And regarding Joao 's solution are you pointing to this post? If yes, its been already taken care of. Real World Scenario section explains two approaches, both of which makes sure data loss never occurs.
Please correct if i am mistaken.
11:55, 25 April 2013 (EEST)
Hamishwillee - Solution that doesn't make assumptions is the one that should be presented
Sorry for the delay in responding. To summarise my feelings, the title and first option/introduction you've explained assume 25 seconds and reliable scheduling. While this is likely to be given based on your testing, the solution should not state that you'll get it or rely on it, or should make very clear what will happen if you don't get it so that users know the cost of using the solution if it does get cut short. Given that your option 2 does NOT make any assumptions about this limitation and is hence more robust I think that this should be your "main implementation" against which other discussions should be compared.
My more rambling response below. Thanks so much for your patience, and of course you are allowed to disagree :-0
We know there is flexibility in the scheduling time. Some use cases will require that the task fires every time on time, some will be able to take the delay. The important thing here is that we make it clear the solution has these limitations outside your control so people can see if it suits their needs. I think you've done that to some extent, but worth adding your test results because it gives users a better understanding of how likely the code will be to work on their use case. Also it might help people decide what packet sizes to send etc based on type of information and reliability.
If we can't even be sure of having 25 seconds, does periodic task make some usefulness?
Yes - there are plenty of tasks where amount of time you get doesn't matter - particularly if it is "mostly reliable". For example, if the periodic task is 25 seconds "mostly" and it doesn't matter if you miss one or two - like in a non-urgent notification.
However this brings me to the second point. You cannot guarantee that you will get the 25 seconds or that it will be useful to you - for example it might be that you're away from all network access. Some use cases will cope with this an some won't. In either case your code needs to be rock solid if you don't get the required time. This could mean just that you have a server that can drop resent packets (works for both your 1 and 2 I think).
Looking at your code I like option "2" For the following reasons:
- It is robust - at any point you know that your storage contains only those items not sent and acknowledged. At most you will resend one wrong package - in the event of finishing time before the acknowledgement (server needs to be able to drop already received packages)
- It always uses all the time - the other solution could potentially waste time by cutting short operations time in order to do saving.
- If the time WP gives you shrinks, this code will still work provided your packet size isn't too "many seconds long"
- I would modify it a bit so that you load the whole command list but still delete items from the isolated storage - reduces file reads.
- Yes reading/writing is slow, but not particularly compared to setting up a connection and the time potentially lost to having to stop for "save time".
Solution 1 is OK too though if you don't get savetime for whatever failure reason your server will have to drop more packets next time you resend. Also you will always be wasting a bit of send time and if the total time shrinks then eventually you might never get to save your data.
Upshot is that I would modify it as follows
- Add your test results as a section (maybe title "How reliable is the periodic task"). Cover device used, how you tested, what sorts of deviations you saw in both scheduling and time). Remember to note that this isn't tested under all circumstances and Microsoft has said there can be deviations.
- Change it so that option 2 (the more robust solution) is the one explained in the implementation
- You can still explain option 1 if you think its trade-offs are good - but have it in a separate section and explain where you'd use it
- Explain when to call NotifyComplete. This should be called when the operation is really complete - so in option 1 when you've sent all the data, and in option 2 when the save time is complete.
- Perhaps some comment about how to select the packet size/time - bigger or larger and tradeoffs to each
- Example code
I can do this if you want, but would need more information about your test results.
07:57, 1 May 2013 (EEST)
Vinayppatil - I am okay with the changes
Improvements are always welcome. It will be nice if you do the changes. I will mail you the log file which spans from 09 April to 18 April.
Just wanted to mention according to logs, the case where PeriodicTask is terminated before 25 seconds is very rare. So if you ask me, first approach seems better, as it will utilize the time more efficiently. Isn't it okay to send few commands twice to server once in fifty times. You are atleast making best use of remaining 49 attempts. Also you are never loosing your data, its just sending few commands twice.
I am happy with your other changes.
12:37, 1 May 2013 (EEST)
Hamishwillee - Thank Vinay
I understand your points re the task being terminated early - as I said both approaches are robust provided the server drops resent packets and provided Microsoft doesn't change the time allotted. I question whether it is more efficient though given that you're always wasting at least some time on the "save time" where you could be sending data, and I think the code would be slightly simpler for option 1.
Thank so much for the logs. If you feel inclined you might even want to add your test app to this.
02:00, 2 May 2013 (EEST)
Vinayppatil - nice presentation
I liked the way you are presenting the topic. It seems much more understandable now. I made few changes, see that you are happy with those. And regarding example code i formatted my system last night without taking backup of Visual Studio projects directory.:P Hope to see complete article very soon.
07:44, 8 May 2013 (EEST)
Hamishwillee - Thanks
Thanks - sorry it is taking so long to finish. Trying to fit it in among a number of other tasks. There isn't actually that much more to do since it isn't actually all that reasonable to have code implementation here unless a server is also provided ... so mostly it will be deletion.
It has given me an appreciation of how hard it must have been to write what you had in!
I was also thinking of creating and linking to a complete doc on "How reliable is PeriodicTask" which includes test example and explanation, and place where people can post their own results. Might put that on hold if I can't get your code :-0
05:12, 9 May 2013 (EEST)