summaryrefslogtreecommitdiff
path: root/java/com/android/dialer/phonelookup
diff options
context:
space:
mode:
authorzachh <zachh@google.com>2018-01-17 15:07:44 -0800
committerCopybara-Service <copybara-piper@google.com>2018-01-17 16:35:09 -0800
commit73c65793a6fc191d5124739d7b37c41d5f61c671 (patch)
treebd84298b0e64deac9b58882c750e3d04a286abbe /java/com/android/dialer/phonelookup
parent4e7284d6cef414f17580993658059a373c82a936 (diff)
Show existing CP2 information for invalid numbers even if out of date.
This is an optimization to reduce popping in the new call log. Currently when Cp2LocalPhoneLookup determines a number to be "incomplete" (because it is an invalid number and there are too many invalid numbers in the call log to efficiently bulk update) we clear the existing data, which has been populated in PhoneLookupHistory (for example, from InCallUi). This means that we will show the number initially when displaying the call log, and then when the query completes we will "pop in" the new information. This change makes it so that we don't clear the existing data from PhoneLookupHistory, and just add the "incomplete" bit. The result of this is that we immediately display the available information when initially displaying the call log (even though it may be out of date). When the query completes, the row will be updated with the most recent information; in most cases this is likely to be the same as the information used to initially display the row, and no update will need to be applied. Additoinal changes to support this functionality: -RealtimeRowProcessor is now just responsible for returning an updated row, and NewCallLogView holder will compare the result to the originally displayed row and only update the UI if there are differences. -NewCallLogFragment now calls clears the RealtimeRowProcessor's cache and notifies data set changed during onResume. This is to account for the fact that AnnotatedCallLog no longer contains the complete set of information necessary to show the call log; there may be changes we need to show which can't be detected by the cursor loader. We now show those potential changes in onResume. Additional notes: -If there is real-time data that changes after onResume it won't be detected but there shouldn't be such cases; changes made to contact information from dialer are always done through contact cards which pause the fragment. -This change has the effect that whatever information was written to PhoneLookupHistory during the previous invocation of InCallUi will always be (initially) shown. For example, if the contact name for number "123" is "Joe" when the call comes in, we'll write "Joe" to PhoneLookupHistory. If the user changes Joe's name to "Jane", the UI will pop from "Joe" to "Jane" until PhoneLookupHistory is updated (which is currently only done from InCallUi). If this turns out to be a problem it could be mitigated by writing updated results to PhoneLookupHistory from the UI. Test: unit, manual PiperOrigin-RevId: 182277145 Change-Id: I3d9916b7747390ff956f399fe84b26d578e5a07f
Diffstat (limited to 'java/com/android/dialer/phonelookup')
-rw-r--r--java/com/android/dialer/phonelookup/cp2/Cp2LocalPhoneLookup.java7
1 files changed, 5 insertions, 2 deletions
diff --git a/java/com/android/dialer/phonelookup/cp2/Cp2LocalPhoneLookup.java b/java/com/android/dialer/phonelookup/cp2/Cp2LocalPhoneLookup.java
index c6e7f5aa3..995950d0e 100644
--- a/java/com/android/dialer/phonelookup/cp2/Cp2LocalPhoneLookup.java
+++ b/java/com/android/dialer/phonelookup/cp2/Cp2LocalPhoneLookup.java
@@ -140,7 +140,7 @@ public final class Cp2LocalPhoneLookup implements PhoneLookup<Cp2Info> {
try (Cursor cursor =
queryPhoneLookup(Cp2Projections.getProjectionForPhoneLookupTable(), rawNumber)) {
if (cursor == null) {
- LogUtil.w("Cp2LocalPhoneLookup.lookup", "null cursor");
+ LogUtil.w("Cp2LocalPhoneLookup.lookupByNumber", "null cursor");
return Cp2Info.getDefaultInstance();
}
while (cursor.moveToNext()) {
@@ -511,7 +511,10 @@ public final class Cp2LocalPhoneLookup implements PhoneLookup<Cp2Info> {
} else if (deletedPhoneNumbers.contains(dialerPhoneNumber)) {
infoBuilder.clear();
} else if (unprocessableNumbers.contains(dialerPhoneNumber)) {
- infoBuilder.clear().setIsIncomplete(true);
+ // Don't clear the existing info when the number is unprocessable. It's
+ // likely that the existing info is up-to-date so keep it in place so that
+ // the UI doesn't pop when the query is completed at display time.
+ infoBuilder.setIsIncomplete(true);
}
// If the DialerPhoneNumber didn't change, add the unchanged existing info.