In windows phone store, there are have an app named TimeMe Tile, it can update current time on Tile every 1 minute, I am very curious how it is implemented, as far as know, the period of background task is 30 minutes.
Here is this app's link:
http://www.windowsphone.com/zh-cn/store/app/timeme-tile/ef6099f2-41dd-4bad-9fa1-8f4143386194
Thank you.
If you have predictable tile information (like the time) then you can schedule the tile notifications ahead of time with the ScheduledTileNotification class. Scheduled notifications will fire even if the app itself is not running. The app only needs to run (in the foreground or as a background task) to schedule the notification.
You can schedule a tile to update every minute for the next hour something like the following:
int min = 0;
for(min=0;min<60;min++)
{
// Create a tile template with whatever we want to show
XmlDocument tileXml = GenerateTileTemplate(min);
// Schedule it for min minutes from now
DateTime dueTime = DateTime.Now.AddMinutes(min);
ScheduledTileNotification scheduledTile = new ScheduledTileNotification(tileXml, dueTime);
TileUpdateManager.createTileUpdaterForApplication().AddToSchedule(scheduledTile);
}
For a fuller example see How to schedule a tile notification.
If the tile needs to have more timely data that can't be predicted then you'd need to push a notification from off-system to include that information more often than the app can get CPU time.
Related
In a Cesium CZML Model, I'd like to define multiple clocks, each one with its own time interval and multiplier, something like:
clock: {
interval: "2019-06-01T16:00:00Z/2019-06-01T16:10:00Z",
currentTime: "2019-06-01T16:00:00Z",
multiplier: 60,
range: "UNBOUNDED",
step: "SYSTEM_CLOCK_MULTIPLIER",
},
clock: {
interval: "2019-06-01T16:10:00Z/2019-06-01T16:20:00Z",
currentTime: "2019-06-01T16:10:00Z",
multiplier: 80,
range: "UNBOUNDED",
step: "SYSTEM_CLOCK_MULTIPLIER",
},
but this is not possible, because clock would be a duplicate key.
Is there a way to define consecutive time intervals, each one with its own clock multiplier?
Unfortunately I think the answer is "no", at least within a single CZML document. However, Cesium Viewer supports loading multiple DataSources at the same time, so you may load multiple CZML documents concurrently, and each will have its own clock settings.
Cesium.Viewer has a constructor option called automaticallyTrackDataSourceClocks that will cause it to update its own clock settings whenever a new dataSource (separate CZML file) is added, and when the active dataSource is removed. It also has a field, viewer.clockTrackedDataSource that is read/write, and can be used to set which dataSource is currently in charge of the viewer's clock settings.
But, you would need to write your own UI to show a list of available dataSources, and select which one controls the clock settings, if that's what's needed here. Cesium will not automatically jump from the end of one clock range to the start of the next, unless you write code to make this happen.
The viewer will always try to show objects from all dataSources that have "availability" during the current time range, even if the clock is tracking a range from another dataSource. When the time ranges overlap, users will see all objects from multiple dataSources together in the scene. When time ranges don't overlap, expired objects won't be shown, but some "permanent" objects such as stationary points may have infinite availability, and so continue to be shown outside of their parent dataSource's clock range. This can be controlled from within a CZML document by limiting such entities to have availability only within their own file's clock ranges.
I am new to AWS IoT. I am using "AWSIotDevice" as super class of my virtual device.
By using below, i am able to update shadow on AWS IoT. But my concern is, it is updating shadow every 3 seconds. I don't require it. Shadow should update only after setting new values in my virtual device. It can be after 10 seconds or 30 seconds. I tried using "setKeepAliveInterval" to 30 seconds, but still it is updating shadow every 3 seconds.
Please suggest how to disable it or increase the interval for longer time say 10 minutes or so?
AWSIotMqttClient awsIotClient = new AWSIotMqttClient(clientEndpoint,
clientId, pair.keyStore, pair.keyPassword);
awsIotClient.setKeepAliveInterval(30000);
AWSIotDevice awsIotDevice = new MyAWSIotDevice(thingName);
awsIotClient.attach(awsIotDevice);
awsIotClient.connect(10000);
Really appreciate your help.
Regards,
Krishan
You haven't explicitly said, but that looks like the Java SDK.
That being the case, you need to change the DEVICE_REPORT_INTERVAL, which, as you've notice, defaults to 3000ms.
To do this on AWSIotDevice you should use setReportInterval.
I have an application that updates every 30 seconds, in which a bunch of variables and startingTime is sent which I use in charting - this is done repeatedly every 30 seconds so I have a kind of live updates. I want to re-factor this such that the first startingTime received will be used for period of one hour during which subsequent startingTime will be discarded. The whole essence is to prevent the chart being redrawn every 30s but other parameter will be used to update the chart.
How to i do this in Flex builder?
Since the dataProvider will be array collection / array based you can remove the old values on the list and add new values at the end list(basically a Queue implementation of ArrayCollection).
Now after you have done this, you will do a ArrayCollection(chart.dataprovider).refresh();
if you have the array collection binded to the chart, when you modify the arraycollection, this will be automatically reflected in the chart, so, the whole chart wont be repainted.
I developed a flash game in AS3, similar to Music Challenge on Facebook, where you need to guess from a selection of songs, wich one is the one playing, score is based on how many did you guess in 30 seconds, this timeout, is handled by an instance of Timer.
Everything works good, but someone pointed out that by reducing cpu performance, timer goes slower, allowing users to play longer, guess more songs and ultimately get a higher score, then I did some research, and read that to prevent this, I need to use systems time, the problem is, I don't know how to do this.
Any help is very much appreciated.
You could have a repeating timer with a short interval, 100ms or so, and check new Date().getTime() on each tick. By default, a new Date has the current system time, and getTime() gives you the time in milliseconds for a simpler comparison. Compare that with a start time and end the game once at least 30 seconds have passed. Something like:
import flash.utils.Timer;
import flash.events.TimerEvent;
var ticker:Timer = new Timer(100, 0);
ticker.addEventListener(TimerEvent.TIMER, checkElapsedTime);
var startTime:Number = new Date().getTime();
ticker.start();
function checkElapsedTime(e:TimerEvent):void {
var now:Number = new Date().getTime();
if (now - startTime >= 30 * 1000) {
// End the game and stop the ticker.
ticker.stop();
ticker.removeEventListener(TimerEvent.TIMER, checkElapsedTime);
}
}
There is obviously still some slight lag if the timer is very slow, so just in case I would run the same check when an answer is submitted and ignore it if it was after the deadline.
Finally, to check if a user has changed their system clock you could store the previous now and make sure the new now is always larger.
I'm having a silly-yet-serious case of coder's block. Please help me work through it so my brain stops hurting and refusing to answer my questions.
I want to fire a timer at intervals up to a final time. For example, if t = 0, my goal is 100, and my interval is 20, I want to fire at 0, 20, 40, 60, 80, and 100.
The timer is not precise, and may fire early or late. If it first fires at 22, I want to fire again in 18. If it first fires at 19, I want to fire in 21. All I know when the timer fires is the current time, goal time, and firing interval. What do I do?
Edit: Sorry, I wasn't too specific about what the heck I'm actually asking. I'm trying to figure out what kind of math (probably involving taking the modulus of something) needs to be done to calculate the delay until the next firing. Ideally, I also want the timer to by matched to the end time — so if I start the timer initially at 47, it schedules itself to fire at 60 and not at 67, so the last firing will still be at 100.
If the primitive functionality you have is "schedule X to fire once at time T", then your procedure handling X should know the time T0 at which it was supposed to fire (the time T1 at which it actually fired is not needed) as well as the desired firing interval DT and schedule itself for time T0+DT. If the primitive is "fire D from now", then it should schedule for D = T0+DT-T1 (if that's negative then it needs to schedule itself immediately again but record that the scheduled time and the "was supposed to fire at" time are different so it can keep compensating on following firings).
Somebody already mentioned that .NET's Timer does this for you; so does Python's sched stdlib module; so, I'm sure, do many other languages / frameworks / libraries. But in the end you can build it if needed on top of either of the single-scheduling primitives above (one for an absolute time or one for a relative delta from now) as long as you keep track of desired as well as actual firing times!_)
I would use the system clock to check your interval. For example if you know that your interval is every 20 minutes, fire off the first interval, check what the time was, and adjust the next interval start time.
If your language/platform's underlying timers don't do what you want, then it's usually best to implement timers in terms of "target times", which means the absolute time at which you want the timer to fire next. If you platform asks for an "absolute time", then you give it the target time. If it asks for a "relative time" (or, like sleep, a duration), then it is of course target_time - current_time.
The quick way to calculate each target time in turn is:
When you first set up the timer, calculate the "interval" (which might have to be a floating-point value, assuming that won't cripple performance) and also the "target time" of the first timer fire (again, you might need fractions). Record both, and set your underlying timer mechanism, whatever that is.
When the timer fires, work out the next target time by adding the interval to the previous target time.
The problem with that approach is that you might get some very tiny accumulating errors as you add the interval to the target time (or not so tiny, if you haven't used floats).
So the longer and more accurate way is to store the very first start time, the target finishing time, and the number of firings (n). Then you recalculate the target time for each new firing in turn, which makes sure that you don't get cumulative rounding errors. The formula for that is:
target(k) = start + ((target_end - start) * k) / n
Of if you prefer:
target(k) = (k/n) * end + (1-k/n) * start
Where the firings of the timer are k=1, 2, 3, ... n. I was going to make it 0-based, then realised that was daft ;-)
The last thing you have to wrestle with when implementing timers is the difference between "wall clock" time, and real elapsed time as measured by your hardware clock. Wall clock time can suddenly jump forwards or backwards (either by an hour if your wall clock is affected by daylight savings, or by any amount if the system's clock is adjusted or corrected). Real time always increases (as long as it doesn't wrap). Which you want your timer to respect depends on the intended purpose. If you want to know when your last bus leaves, you want a timer firing daily according to wall clock time, but most commonly you care about real time elapsed. A good timer API has options for these kinds of things.
Build a table listing the desired fire times, say 10:00, 10:20, 10:40, 11:00, and 11:20.
If your timer function takes an absolute time, the rest is trivial. Set it to fire at each of the desired times. If for whatever reason you can only set one timer at a time, okay, set it to fire at the first desired time. When that event happens, set it to fire again at the next time in the table, without regard to what time it is now. Each time through, pick up the next time until you're done.
If your timer function only accepts an interval, no big deal either. Find the difference between the desired time and the current time, and set it to fire at that interval. Like if the first time is 10:00 and it's now 9:23, set it to fire in 10:00 minus 9:23 equal 37 minutes. Then when that happens, set the interval to the next desired time minus the current time. If it really fired at 10:02, then the interval is 10:20 minus 10:02 equals 18 minutes. Etc.
You probably should check for the possibility that the next fire time has already passed. If the process can take longer than the interval you might run past it, and even if not, the system might have been down. If a fire time is missed, you may want to do catch up runs, or just skip it and go to the next desired time, depending on the details of your app.
If you can't keep the entire table -- like it goes on to infinity -- then just keep the next fire time. Each time through the process, add a fixed amount to the next fire time, without regard to when the current process ran. Then calculate the interval based on the current time. Like if you have a desired interval of 20 minutes going on forever starting at 10:00, and it's now 9:23, you set the first interval to 37 minutes. Say that actually happens at 9:59. You set the next fire time to 10:00 plus 20 minutes equals 10:20, i.e. base it on the goal time rather than the actual time. Then calculate the interval to the next fire time based on the current time, i.e. 10:20 minus 9:59 equals 21 minutes. Etc.