Closed Bug 742216 Opened 12 years ago Closed 12 years ago

Move the code to enable/disable Android services to onApplicationPause/onApplicationResume

Categories

(Firefox for Android Graveyard :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(blocking-fennec1.0 soft)

RESOLVED FIXED
Firefox 14
Tracking Status
blocking-fennec1.0 --- soft

People

(Reporter: mfinkle, Assigned: sriram)

Details

Attachments

(3 files)

We have code in GeckoApp.onPause / onResume to disable/enable some Android services, like network monitoring and screen orientation. These will fire too frequently now that onApplicationXxx methods are used to handle "application" background/foreground control.

We should move the code.
blocking-fennec1.0: ? → soft
This patch moves the code to onApplicationPause() and Resume()
Attachment #612345 - Flags: review?(mark.finkle)
Because of first patch, onPause() became redundant. This can be removed now.
Attachment #612347 - Flags: review?(mark.finkle)
Some cleanup on Battery sensor in the similar lines of GeckoConnectivityReceiver.
Attachment #612349 - Flags: review?(mark.finkle)
Comment on attachment 612345 [details] [diff] [review]
Patch (1/3): Disable/Enable sensors in onApplicationPause()/Resume()

>+        mConnectivityReceiver = new GeckoConnectivityReceiver();
>+        mConnectivityReceiver.registerFor(mAppContext);
>+
>         GeckoNetworkManager.getInstance().init();
>+        GeckoNetworkManager.getInstance().start();
>+
>+        GeckoScreenOrientationListener.getInstance().start();

What affect does this have on startup time?

>-        mMainHandler.post(new Runnable() {
>-            public void run() {
>-                mConnectivityReceiver.registerFor(mAppContext);
>-                GeckoNetworkManager.getInstance().start();
>-                GeckoScreenOrientationListener.getInstance().start();
>-            }
>-        });

This was put in a runnable to try to avoid any startup time costs. If you can show that startup is not affected (using Try server and the logging times) we could think about avoiding the runnable.

r- until we are sure about the startup time data
Attachment #612345 - Flags: review?(mark.finkle) → review-
Attachment #612347 - Flags: review?(mark.finkle) → review+
Comment on attachment 612349 [details] [diff] [review]
Patch (3/3): Battery sensor cleanup.

This code my exist in embedding/android too, but I don't think we need to move the cleanup there too.
Attachment #612349 - Flags: review?(mark.finkle) → review+
> 
> What affect does this have on startup time?
> 
> >-        mMainHandler.post(new Runnable() {
> >-            public void run() {
> >-                mConnectivityReceiver.registerFor(mAppContext);
> >-                GeckoNetworkManager.getInstance().start();
> >-                GeckoScreenOrientationListener.getInstance().start();
> >-            }
> >-        });
> 
> This was put in a runnable to try to avoid any startup time costs. If you
> can show that startup is not affected (using Try server and the logging
> times) we could think about avoiding the runnable.
> 
> r- until we are sure about the startup time data

This particular piece of code was in onResume(), ideally executing "after" intialize() is done. I've moved this "into" intialize() to the end of it. Also, initialize() is run on UI thread, hence a Runnable is not needed there. I don't feel there would be any regression on startup time.
Comment on attachment 612345 [details] [diff] [review]
Patch (1/3): Disable/Enable sensors in onApplicationPause()/Resume()

r+, thanks for the bit of detail. Also, you need to keep an eye on Ts when this lands on inbound to make sure nothig was regressed. You could push the Try first and check it there too.
Attachment #612345 - Flags: review- → review+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: