Add synchronous method to determine if there are known updates

Bug #1370586 reported by Ken VanDine
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu system image
Fix Released
High
Barry Warsaw

Bug Description

There are times when auto-checking of updates occurs outside of system-settings, which could add an emblem to the system-settings launcher icon indicating available updates. However, when launching system-settings we have no way of determining if there are already updates that system-image-dbus knows about before calling CheckForUpdates(). This causes a delay in toggling visibility of the updates available entry in system-settings, which shifts the UI around after start. See bug #1355803

We need a synchronous method to call when system-settings starts that returns a boolean if there are known updates, which we can use to determine visibility of the entry at start time.

Related branches

Barry Warsaw (barry)
tags: added: client
Changed in ubuntu-system-image:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Barry Warsaw (barry)
milestone: none → 2.5
importance: High → Undecided
importance: Undecided → High
tags: added: rtm14 touch-2014-09-25 usability
Revision history for this message
Barry Warsaw (barry) wrote :

See also LP: #1355803 for the UX impetus behind this request.

Revision history for this message
Barry Warsaw (barry) wrote :

We can probably do this without a new API. We have the synchronous method Information() which returns a mapping. We could add a new key to this mapping called 'target_build_number' (or available_build_number, or new_build_number, or something else). If the value is a number > the current_build_number, you know that si-dbus knows there's an update available. If the value is "none" or 0 (or missing?) then you know that si-dbus doesn't know whether an update is available or not, in which case, you'd have to call CheckForUpdate().

Does this seem reasonable?

Revision history for this message
Ken VanDine (ken-vandine) wrote :

That sounds good to me!

Revision history for this message
Barry Warsaw (barry) wrote :

<barry> kenvandine: thanks. my big question is what to do in the
        "we-don't-know" case. should the target_build_number key just be
        missing? should it return a non-number like "none", or should it
        return a nonsense number like -1 (or 0?). my initial preference would
        be to omit the key, but i don't know how much trouble the different
        options would cause the client
<kenvandine> barry, i think i'd prefer -1

Barry Warsaw (barry)
Changed in ubuntu-system-image:
status: Triaged → In Progress
Revision history for this message
Barry Warsaw (barry) wrote :

One other thing: If we know there is no update available, what should the value be? The obvious choices would be 0 or current_build_number. With the latter, you'd just check info['current_build_number'] == info['target_build_number']. If that's true, there's no update available. I think I prefer that.

Revision history for this message
Ken VanDine (ken-vandine) wrote :

info['current_build_number'] == info['target_build_number'] is fine with me

Barry Warsaw (barry)
Changed in ubuntu-system-image:
status: In Progress → Fix Committed
Revision history for this message
Ken VanDine (ken-vandine) wrote :

This works for me, thanks!

Barry Warsaw (barry)
Changed in ubuntu-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.