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

0 files changed, 0 insertions, 0 deletions