Add synchronous method to determine if there are known updates

Bug #1370586 reported by Ken VanDine on 2014-09-17
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu system image
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) on 2014-09-17
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
Barry Warsaw (barry) wrote :

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

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?

Ken VanDine (ken-vandine) wrote :

That sounds good to me!

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) on 2014-09-25
Changed in ubuntu-system-image:
status: Triaged → In Progress
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.

Ken VanDine (ken-vandine) wrote :

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

Barry Warsaw (barry) on 2014-09-25
Changed in ubuntu-system-image:
status: In Progress → Fix Committed
Ken VanDine (ken-vandine) wrote :

This works for me, thanks!

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

Other bug subscribers