I'd like to conditionally reload my active complication in the requestedUpdateDidBegin function or actually tell ClockKit to set the next check 15 minutes before the end of the current timeline entry, but how can I do that without knowing what's in the current complication?
Here's what I'm trying to do:
if let complications = CLKComplicationServer.sharedInstance().activeComplications {
for item in complications {
// Get timeline entry and template used?
}
}
For the current complication, I can only get the family, but no other info like timeline date or template used. Is there a way to get this?
The complication server requests data from your complication controller, but it's not designed to provide its timeline data to you. All you can find out from the server are the earliest and latest time travel dates.
You'd have to get timeline details from the original data you used to create the timeline entries in the first place.
As for scheduling your update 15 minutes before the end of the last entry, you can very easily schedule that as part of the previous reload request. The very last thing the complication server requests (after reloading or extending the timeline) is the next update date.
Since the complication server has just asked you for the future timeline entries in getTimelineEntriesForComplication:afterDate:, you can make note of the last timeline entry's date, offset it by 15 minutes, then return that new date once getNextRequestedUpdateDateWithHandler momentarily gets called.
Related
I'm trying to create a logic app around a query that checks if user stories have been updated in the last 24 hours and notify user otherwise, but if I use the state as my clause, anything contributes to the state and it wont be accurate to TRUE updates (e.g. comments).
How should I approach this? Is "ChangedDate" the best field to check for updated stories and then remind the user to update the story after 24 hours have passed? Or is there a better condition I can use that checks for legitimate user story updates?
ChangedDate is enough.
ChangedDate can filter out all changed work items including state change and comments add records. it can achieve your requirement.
E.G:
Created Date >= #StartOfDay - 1
To remind users to update user stories regularly, we can try to install extensions like Scheduled Work Item Query, then create a pipeline using the extension task to send the query result to team members. We can Configure schedules for pipelines to trigger the pipeline based on your requirement, for example every 24 hours.
I am deleting row from a sheet, On a sheet I have daily job which needs to recognize the deleted records, I need a way to recognize them using smartsheet api or sdk..
Thanks in advance..
I don't believe this scenario (identifying deleted rows) is explicitly supported by the API at this time. Seems like you could still use the API to achieve your goal though, with a bit more work (code) on your part.
Your code would have to get the sheet data (i.e., all sheet rows) at a regular interval and save that data somewhere -- then each time job runs, get the sheet data again and compare that data to the data you saved the previous time the job ran (to identify any rows that had been deleted).
Edit 9/26: Added Webhooks info
Note that with the approach I've described above, any rows that had been added AND deleted during the interval between job runs would not be detected. If it's important to identify each and every time a row is deleted, a better (and much more efficient) approach would be to use Webhooks. By using webhooks, your application subscribes to notifications for a specified sheet, and then would receive a callback (HTTP POST) from Smartsheet any time the sheet changes. Your application would need to inspect the information in each callback it receives to identify 'deleted row' events (eventType = deleted and objectType = row).
A simple way to do this is to add a column with a checkmark named "delete" or something similar, then with automation you can move the row to another sheet when the flag is detected, the row will be removed from the original sheet, but you will have a record of the deleted row in a different sheet that you can read or do what ever you need to do, this will also prevent deletions by mistake and you can even restore the row back if you need to. I don't think you need much code to implement this solution.
in my app I'm displaying a list of EKEvents and I would like to display all events of a month in a UITableView, each section containing the respective days. Well, this works and I get all the data, I need, but the fetch is very slow.
The problem consists in events, which spread across multiple days.
Let's say I'm going on vacation from 10th of November until 17th of November.
My search predicate has a startDate with 1st of November and an endDate with 30th of November.
I do an enumerateEventsMatchingPredicate or eventsMatchingPredicate, whatever, both are slow.
I get an array in return with all events taking place in November, as well as my vacation.
But my vacation is just one EKEvent object. So if I want to display a monthly list view of events it would only appear once, on 10th of November, but for reasons of clarity I would to show it on every day it takes place, 10th, 11th, ... 17th.
So what I do is, iterate over each day in a month and do a fetch :-/ This way I get the correct amount of events that take place on a specific day, but ... it feels so complicated.
I already put the fetch into a dispatch_async, so the fetch doesn't block the UI and after the fetch is finished the tableView gets reloaded and cells redrawn. But it still takes time. No userfriendly time.
How do you perform those searches? Do you have any tips on how to speed up the search, maybe a little code snippet or can point me in the right direction!?
Is my question clear? :-/
Thanks,
-Martin.
Fetches are slow especially if there is a lot of recurring events. What I did in my app, is to fetch only once, and parse whole-day-multiple-spanning-day-events to chunks. I abstracted events: I create "date" class, which has NSString properties usable as section titles in table view, and one of its ivars is array with matching "events". "events" are not EKEvents, but my class, to which I copy needed properties from EKEvents. From multiple day spanning single whole day EKEvent I create corresponding "events". Parsing is quite quick - the slowdown is when getting properties from fetched recurring EKEvents.
I'm building an iPhone app which uses your current location to get a series of results from a WCF Service. I then store the data returned by the WCF using Core Data and then populate a TableView.
What I'd like to do is store the results for around 30 minutes then each time the view loads, check whether I need to refresh the data. I would also be watching the users' location so that if they move a considerable distance, the data will also update.
My problem is that I'm not sure what the best approach would be to monitor the age of the data.
Should I store an insert date with the Core Data Entity. Alternatively I could create a new entity to store a global 'last retrieved' date. Or I could just store a value in the plist.
I'm not sure which of my above suggestions would be the best, or even there are any better ones. Any help with this is much appreciated!
An insertDate attribute would probably be the best bet. Whenever your app becomes loads, you can check the change in time versus that attribute's value. If the time is over 30 minutes, you can fire your reload method, else you can take the remaining time and set up a scheduled NSTimer event that will fire the method when the time runs up. Just be sure to reset the insertDate value once you reload your data
Contrived example:
{
productName: 'Lost Series 67 DVD',
availableFrom: '19/May/2011',
availableTo: '19/Sep/2011'
}
View storeFront/currentlyAvailableProducts basically checks if current datetime is within availableFrom - availableTo and emits the doc.
I would like to force a view to regenerate at 1am every night, i.e. process/map all docs.
At first I had a simple python script scheduled via crontab that touched each document hence causing a new revision and the view to update,however since couchdb is append only this wasnt very efficient - i.e. loads of unnecessary IO and disk space usage followed by compaction, very resource wasteful on all fronts.
Second solution was to push the view definition again via couchapp push however this meant the view was unavailable (or partially unavailable) for several minutes which was also unacceptable.
Is there any other solutions?
Will's answer is great; but just to get the consensus viewpoint represented here:
Keep one view, and query it differently every day
Determine your time-slice size, for example one day.
Next, for each document, you emit once for every time slice (day) that it is available. So if a document is available from 19 May to 21 May (inclusive), your emit keys would be:
"2011-05-19"
"2011-05-20"
"2011-05-21"
Once that is computed for every document, to find docs available on a certain day, just query the view with (e.g. today) ?key="2011-05-18".
You never have to update or re-run your views.
If you must never change your query URL for some reason, you might be able to use a _show function to 302 (temporary) redirect to today's correct query.
So your view is not being updated automatically I take it?
New and changed documents are not being added on the fly?
Oh I see, you're cheating. You're using "out of document" information (i.e. the current date) during view creation.
There's no view renaming, but if you were desperate you could use url rewriting.
Simply create a design document "each day": /db/_design/today05172011
Then use some url rewriting to change: GET /db/_design/today/_view/yourview
to: GET /db/_design/today051711/_view/yourview
Create the view at 11pm server time (tweak it so that "now" is "tomorrow", or whatever).
Then add some more clean up code to later delete the older views.
This way your view builds each night as you like.
Obviously you'll need to front Couch with some other web server/proxy to pull this off.
It's elegant, and inelegant, at the same time.