ClockKit, extend vs reloadTimelineForComplication

Hi,


I use complication timeline : current, before and after entries.

At statup, i call reloadTimeline and the extention delegate receive getTimelineStartDateForComplication and getTimelineEndDateForComplication and others getTimelineEntriesForComplication for current, after and before entries and all is working.


When the system call requestedUpdateDidBegin i do extendTimelineForComplication.

Again, entries are added via getTimelineEntriesForComplication after and before a date.


But, getTimelineStartDateForComplication and getTimelineEndDateForComplication aren't called in the update sequence.

So, even if entries are good for the current display, after time, the after/before timeline isn't shown (complications are black when the crown turns)


If i use reloadTimelineForComplication instead of extendTimelineForComplication all the process is recreated and it's ok


But reload all entries for each update doesn't look a good practice, especially if there are many entries


Maybe extendTimeline is not to do what i expect, or maybe i miss something


What do you think ?

Thanks for advice

GB

Replies

Hi GB,


I have exactly the same issue. Haven't found any other workaround than always using reloadTimelineForComplication which is not a good solution.


Best,

Armin H.

I think getTimelineStartDateForComplication and getTimelineEndDateForComplication are only used on initial population, afterwards you can just provide the data to the the update methods, along with their relevent time stamps. It doesn't seem to be well documented though.

Hi,


Unfortunately in that case, the timeline behavior (i mean : when you turn the crown and select time +/-) do not display the complication's entries after the first "EndDate" ; even if entries are added after this "EndDate" when you extend timeline.


GB

Yes, I see the problem also. One option is to set end time to 24 hours ahead, then not return entries past when you have data. This seems to work for today, but then breaks the next day when you hit the end date. This seems like a bug to me. I thought this worked in earlier watchos, but I don't think I looked at timelines farther in the future, so maybe I just didn't test future time enough.