I created a wiki article explaining to achieve the task. Follow http://www.developer.nokia.com/Commu..._Windows_Phone for details.
Feel free to improve it.
and it's possible that the device cant run the background agent (low memory, or exceeded the background agents number limit).
I think I'm being dim, but I think what you're suggesting is a solution that will work if they push the clock forward, but will then stop working when they move back to proper time and penalise them in "proper time" for having tried this approach. It relies on the fact that they can move forward but once they have done so when they next move back they will be blocked and for more than double the time. Is that correct? If so, you're a devious man.
The problem I see with this is if it is essential that the app never work if spoofed - for example if moving the time to the future then grants access to credit card details.
Sorry for the late response and thank you for creating the document - pretty good but some suggestions below
Firstly, the solution I suggested does have the limitations that Yassine suggested. Secondly it might have others - for example you can't do things like display the "time to unlock". I also wonder if the notification will occur even after the app is turned off then on again, and whether it is impacted by the system time too. I should read up on that. Assuming all things are equal I think for some applications this degree of tolerance might be fine and the ease of implementation would make it an acceptable trade off. However for others it might not be. Point is that if you're documenting a solution these trade-offs should be visible to the user.
Secondly, given that we have no single great implementation that we can package for reuse by others, it makes sense to outline all the solutions, not just one (as an aside, if we do cover just one solution of many in an article then it is best to use a specific title that matches the particular solution covered so users know what specific option we're presenting - hope that makes sense).
Lastly, we need to decide if the article is about system independent timers, or it is about making time "unattractive to spoof" which is what Joaos solution is about ... and set the title appropriately. As an aside, is there a tickcount on WP? This would be easiest mechanism as long as we don't care about "device off" time.
So I will do some edits to this but I am wondering if:
* you can create real code for the solution you have implemented in a downloadable zip.
* You can also update to include some of the other solutions, and if not, can the "authors" of these solutions add to them?
regarding Joaocardoso solution, it could be added in the end of the article as a bonus/extension.
and Yes there is a tickcount => System.Environment.TickCount
Thanks guys. Yassine, if you read the article after I made this post then probably I confused you - since I pulled it into pieces but didn't yet put it back together.
Vinay, the reason the pseudo code is confusing is that you cover a bunch of methods here - network checks, timers etc. What I would do is have section on Network check where you just show (real) code that might be used to check the network time. In this section you cover the fact that network time is something you can't rely on due to the user being able to turn it off, or possibly being out of range. Then cover the "pros" - ie completely reliable if you can get it.
You'd have the another section for each possible solution e.g. System.Environment.TickCount - again covering pros like the fact that changing the system time won't affect it and the limitations that tick count is reset when the OS restarts. Presumably this means that when your app is closed you'd save the elapsed tick count and the current tc. When the app restarts you'd check if stored tc>current tc indicating restart and then calculate time elapsed from zero ticks. If current TC>stored tc you assume that the device hasn't been restarted - sure you might be wrong but in most cases they would still only have to wait half an hour. I like this mechanism probably best of all because you can provide a count down timer.
The pseudo code still has a use - you'd have this at the end in its own section explaining this particular solution uses networking etc etc and why you like it. We might similarly have "Joao"s implementation at the end.
Anyway I will try find time to have another look at this today or Tomorrow and create a "standard structure" for the sections. Then we can share the load.
Sorry guys didn't have much time to edit, I did some code on the wikipage now if you could review it (it's TBC).
need to add a feature in the snippet :
- if there is no connection block complety the UI and ask the user to get a internet connection to continue
also there was a crazy bug, it erased all my edits after validation, Fortunately I saved them in a file.
I didn't get back to it yet but the structure is there. IMO the way to handle this is to have separate sections for each option for getting time "e.g. Network Time" and in those sections explain how to do it (in code) and advantages and disadvantages and workarounds/options (like blocking UI until network restored and it can be tested).
Then we can still have a pseudo code section which shows how we pull the whole thing together and explain why we think this is a good balance of the tradeoffs.