summaryrefslogtreecommitdiffstats
path: root/src/com/android/incallui/AnswerPresenter.java
diff options
context:
space:
mode:
authorSantos Cordon <santoscordon@google.com>2013-09-05 13:22:07 -0700
committerSantos Cordon <santoscordon@google.com>2013-09-09 12:18:12 -0700
commitb0d08a16da088e01f416f52a7b74ee9630c1493a (patch)
tree0ac149b9c44f1a997c4794086f6efe2760b1f2ff /src/com/android/incallui/AnswerPresenter.java
parentfb45d1c9d044916f3449592fca500a9ec0da116c (diff)
downloadpackages_apps_InCallUI-b0d08a16da088e01f416f52a7b74ee9630c1493a.tar.gz
packages_apps_InCallUI-b0d08a16da088e01f416f52a7b74ee9630c1493a.tar.bz2
packages_apps_InCallUI-b0d08a16da088e01f416f52a7b74ee9630c1493a.zip
Improve lifecycle ordering for InCallUI
This CL rearranges startup and teardown of InCallUI to reduce the number of race conditions resulting in runtime exceptions and app crashes. At a high level this CL fixes the following: - TeleService should be able to unbind and rebind at any time without causing problems in the UI. (Fixes to InCallPresenter) - On weird occasions we were seeing secondary UIs pop up if we rebound while the older UI was still up and one of the UIs would be orphaned on the foreground. - call notifications can be sent during (1) activity startup, (2) activity lifetime, (3) activity destruction, (4) no activity...and nothing should crash. - Lots of crashes when notifications came during destruction and startup. (Fixed setup in InCallActivity + presenters, and startup/teardown ordering in InCallPresenter) Details: (1) InCallPresenter handed out instances of member classes to the UI classes, but upon unbinding and rebinding, the classes were recreated. This meant that the activity which was potentially still up had stale versions of AudioModeProvider and ProximitySensor. - Classes created/used by CallHandlerService are now singletons so that they do not change from one bind to the other. If the service tries to initialize InCallPresenter while the activity is still up (and so we haven't yet torn down) we reuse the reuse the previous initialization since there is no need to recreate them, and classes in the Activity dont ever become stale. (2) We were recreating new copies of InCallActivity on updates that occur while tearing down the previous activity. This caused weird errors where second emptier activities were up after all calls ended. - Solution to this was to ignore all updates while we are finishing the activity. When the activity is finally finished, we check if we should bring up a new activity in case some update came while we were finishing. (3) We set listeners on presenters from a parent class that wasn't aware of UI transitions. - All Presenters are not responsible for setting and unsetting their listeners. This allows them to unset them before their UI goes away. + renamed HIDDEN to NO_CALLS as hidden was confusing to developers which associated the term with foreground/backgroundness of the app. + Improved some logging bug:10573125 Change-Id: I2d1af6a6e972b3b3bd93af839054e879f0b74b4f
Diffstat (limited to 'src/com/android/incallui/AnswerPresenter.java')
-rw-r--r--src/com/android/incallui/AnswerPresenter.java2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/com/android/incallui/AnswerPresenter.java b/src/com/android/incallui/AnswerPresenter.java
index 7f27133e..607e966d 100644
--- a/src/com/android/incallui/AnswerPresenter.java
+++ b/src/com/android/incallui/AnswerPresenter.java
@@ -48,6 +48,7 @@ public class AnswerPresenter extends Presenter<AnswerPresenter.AnswerUi>
@Override
public void onUiUnready(AnswerUi ui) {
super.onUiUnready(ui);
+
CallList.getInstance().removeListener(this);
// This is necessary because the activity can be destroyed while an incoming call exists.
@@ -55,6 +56,7 @@ public class AnswerPresenter extends Presenter<AnswerPresenter.AnswerUi>
if (mCallId != Call.INVALID_CALL_ID) {
CallList.getInstance().removeCallUpdateListener(mCallId, this);
}
+
}
@Override