Overhead due to disconnected Service

[CollegeDev]

Hey,
good to know that you recognized it that the service sometimes is disconnecting itself. First, the pSetMan won't be "null" at any time, so you don't have to check if it is available or not (i did it in the past, just to be sure :-D). Second, you've added so much code in ALL privacy related classes for checking these two things. Why you don't implemented an central "reconnector" which will solve this directly inside the privacySettingsManager? I've done it in this way and you need only 2 methods.
Tested with hammering and flooding and it works like a charm. In my opion, it is a better way because you now you get a stable connection whenever you want to interact with the service.
What do you think about? Less work and more central implementation or do you prefer your solution?

[wsot]

I totally agree that the handling of pSetMan/checking the service/responding to problem needs to be improved. For this first pass, I was more concerned with adding deny-on-fail functionality, knowing that I'd need to clean it up.

The basic structure I was thinking is this:
byte privacyOutcome;
PrivacySettings pSet;
if (pSetMan == null) {
//create new pSetMan
}
try {
//get the privacy settings, etc
//inside the functions checking the service connection etc, add re-connecting to the service
//get the appropriate privacy settings
} catch (PrivacyServiceException e) {
//deny access
privacyOutcome = PrivacySettings.ERROR;
}

switch (privacyOutcome) {
case REAL:
//do the real thing
break;
case ERROR:
//do the error thing;
break;
...
}

The reason the 'pSetMan == null' check is necessary is because reflection can be used to destroy the pSetMan object.
Also, we still need the PrivacyServiceException to handle if something goes bad actually getting the data from the service (vs returning null in error conditions).
The reason for using a switch is because that way multiple error conditions can be handled together if necessary. If there are not multiple error conditions then the privacyOutcome thing isn't necessary, and the producing of results can be mixed into the try-catch code above.

Is that pretty similar to what you were thinking?

[CollegeDev]

Just have a look at my new patches. You can find my solution in the class: PrivacySettingsManager.java

[wsot]

Sorry, I'm not sure where your new patches are. I don't see them in Github, and the first post of the XDA thread doesn't seem to have a modified version.
Sorry it has taken me ages to get back to you - I've only just had my internet reconnected (I moved house).