Push helpers should invalidate scope results

[Ted Gould]

Push messages that include various pieces of data should also invalidate the scope results so that, if the scope is shown, it will get refreshed and show the updated results. This can be done by calling the invalidate results method on the dash with the AppID of the scope.

/com/canonical/unity/scopes com.canonical.unity.scopes.InvalidateResults $id

By calling that it'll get marked dirty.

[Michał Karnicki (karni)]

This would require significant work, mostly because the push client of Telegram simply shows notifications, but does not fetch all metadata for those messages from the server. All this data is actually fetched when the app is launched. Therefore, the push client would have to instantiate the API client, connect, fetch all differences, store them, and disconnect. I'm afraid whether this would fit in the allowed time for push client (sometimes you can get 1k+ messages on busy group chats). However, while previous sentence is not an argument against implementing this, I think the worst part is there's barely sufficient cycles for regular maintenance, so with all honesty I'll say this change will most probably not happen (unless there's a developer full time on the app), even though I'd like that, too.

[Ted Gould (ted)]

Michał, I'm not sure why the push helper would have to do all this. It
seems that the push helper would just have to mark the results as
dirty, and then the scope could do the update. It has a longer
lifecycle exactly for purposes like that, so it seems appropriate to do
the work there. The work wouldn't get done if the user wasn't using the
scope or didn't look at scopes at all. Instead it would only be needed
if the user was actively using the scope or an aggregator that it is
shown in.

[Michał Karnicki (karni)]

Hi Ted. Ah, I see. So it'd be the scope to do the work, that makes more sense, yes. Long story short, the scope only does some reads (no writes) and is not tightly integrated with the app, so that'll make it challenging. To my best knowledge, there are currently other priorities (and critical bugs) to be handled, but I suppose someone could eventually look into that. I'll flip the status back. I do agree that's the way it should be, I'm just afraid there's nobody to do it - but hey, maybe someone from the community would make a contribution on that front :)