refresh button doesn't work

[xxv]

cb7ae11 breaks the refresh button in most cases. Perhaps the SyncStatusObserver isn't working out properly?

[piacentecristian]

Right now the status enabled/disabled of the refresh button is binded to the state of the synchronization status, so you can ask a refresh only after the sync process is ended.

[piacentecristian]

the first time a synchronization is executed the button is disabled for a lot of time, but that's because the synchronization takes that long, in the meanwhile the text in the list now tells the user that data is being loaded

[xxv]

I think it would make even more sense if the sync button only was disabled / animated when it's syncing the current item. Any thoughts on making that go?

[piacentecristian]

I don't know how we can do that, I will try to find a solution hoping that the sync framework allows to do it.

[xxv]

Well, the syncing is currently single-threaded, so there's always only one item that's being sync'd. That could get added to the sync engine to update the sticky broadcast.

[piacentecristian]

actually right now no sticky broadcast is used to handle notification, because now the SyncStatusObserver is used, however we could make the refresh button status change using sticky broadcast, but the question is how do we handle bulk updates? And can we issue another synchronization while we are already synchronizing something in the background?

[xxv]

Yeah, it would probably make more sense to listen to the broadcasts as the SyncStatusObserver is really broken in my experience.

In terms of bulk updates, there's a part in the sync code where the local URI of the item being sync'd is known, so we could easily update the broadcast there. I don't know how much of a performance issue it would be, however. Another possibility would be to have it so that it looks for updates of itself (if it's an item) as well as its parent. If it's a list of items, then it would only look for updates to its list.

[piacentecristian]

The SyncStatusObserver works properly, at least in all the tests i did, but there are some image cache errors in the log, i suppose they slow down the synchronization process that so remains pending for a while.

[xxv]

Interesting. I'll look into it. The image cache errors should be fairly isolated - they're fairly independent of the data and synchronization process.

The issue I was having with SyncStatusObserver is that the numerical code wasn't useful. It would sometimes end in a 4 or sometimes in an 8 (which is an undocumented code).

[piacentecristian]

It's true the code is undocumented, but that event in the observer is used to trigger a check of the current status of the account synchronization.