Closed
Bug 605341
Opened 15 years ago
Closed 15 years ago
remote orientation api for android
Categories
(Core Graveyard :: Widget: Android, defect)
Tracking
(fennec2.0b3+)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b3+ | --- |
People
(Reporter: blassey, Assigned: blassey)
References
Details
Attachments
(1 file, 4 obsolete files)
9.71 KB,
patch
|
dougt
:
review+
|
Details | Diff | Splinter Review |
AndroidBridge isn't available in the content process
Assignee | ||
Comment 1•15 years ago
|
||
Assignee: nobody → blassey.bugs
Attachment #484245 -
Flags: review?(doug.turner)
Comment 2•15 years ago
|
||
Comment on attachment 484245 [details] [diff] [review]
patch
>+#ifdef ANDROID
>+#include "../system/android/nsAccelerometerSystem.h"
>+extern nsAccelerometerSystem *gAccel;
>+#endif
how about static nsAccelerometerSystem::AccelerationChanged() instead of exposing a pointer. This allows you to do the null check (or even allocate inside of nsAccelerometerSystem.
>@@ -56,10 +57,14 @@ void nsAccelerometerSystem::Startup()
> {
> if (AndroidBridge::Bridge())
> AndroidBridge::Bridge()->EnableAccelerometer(true);
>+ else
>+ mozilla::dom::ContentChild::GetSingleton()->SendEnableAccelerometer(true);
> }
Hide this in the bridge?
>
> void nsAccelerometerSystem::Shutdown()
> {
> if (AndroidBridge::Bridge())
> AndroidBridge::Bridge()->EnableAccelerometer(false);
>+ else
>+ mozilla::dom::ContentChild::GetSingleton()->SendEnableAccelerometer(false);
> }
same. can we hide this in the bridge?
>diff --git a/widget/src/android/nsAppShell.cpp b/widget/src/android/nsAppShell.cpp
>--- a/widget/src/android/nsAppShell.cpp
>+++ b/widget/src/android/nsAppShell.cpp
>@@ -36,6 +36,7 @@
> *
> * ***** END LICENSE BLOCK ***** */
>
>+#include "mozilla/dom/ContentParent.h"
> #include "nsAppShell.h"
> #include "nsWindow.h"
> #include "nsThreadUtils.h"
>@@ -222,7 +223,10 @@ nsAppShell::ProcessNextNativeEvent(PRBoo
> break;
>
> case AndroidGeckoEvent::SENSOR_EVENT:
>- gAccel->AccelerationChanged(-curEvent->X(), curEvent->Y(), curEvent->Z());
>+ if (gAccel)
>+ gAccel->AccelerationChanged(-curEvent->X(), curEvent->Y(), curEvent->Z());
>+ mozilla::dom::ContentParent::GetSingleton()->
>+ SendAccelerationChanged(-curEvent->X(), curEvent->Y(), curEvent->Z());
> break;
Just do the SendAccelerationChanged call inside of nsAccelerometerSystem
Attachment #484245 -
Flags: review?(doug.turner) → review-
Assignee | ||
Comment 3•15 years ago
|
||
Attachment #484245 -
Attachment is obsolete: true
Attachment #484586 -
Flags: review?(doug.turner)
Comment 4•15 years ago
|
||
Comment on attachment 484586 [details] [diff] [review]
patch
Lets try this. I think you should do this similar to what we did for geo. Add an AccelerationUpdate() message (instead of AccelerationChanged) to be consistent.
Instead of:
+ async AddAccelerometerListener();
+ async RemoveAccelerometerListener();
Just add:
AccelerometerStart();
AccelerometerStop();
Similar to Geo. Extra points to just pass a flag (like on/off) and convert the geo ones to use a flag.
Then make the content parent just be a listener, like you are doing -- but you don't have to have specific calls in the pidl (just start and stop)
You can follow what I did in ContentParent and ContentChild classes to give you a better idea of what I am asking for.
Attachment #484586 -
Flags: review?(doug.turner) → review-
Assignee | ||
Comment 5•15 years ago
|
||
Attachment #484586 -
Attachment is obsolete: true
Attachment #485137 -
Flags: review?(doug.turner)
Comment 6•15 years ago
|
||
Comment on attachment 485137 [details] [diff] [review]
patch
>+ nsCOMPtr<nsIAccelerometer> iac =
>+ do_GetService(NS_ACCELEROMETER_CONTRACTID);
>+ nsCOMPtr<nsAccelerometer> ac = do_QueryInterface(iac);
>+ if (ac)
>+ ac->AccelerationChanged(x, y, z);
I am surprised this works at all.
I'd rather you add a new interface.
> class nsAcceleration : public nsIAcceleration
> {
>@@ -156,7 +158,11 @@ nsAccelerometer::TimeoutHandler(nsITimer
>
> // what about listeners that don't clean up properly? they will leak
> if (self->mListeners.Count() == 0 && self->mWindowListeners.Count() == 0) {
>- self->Shutdown();
>+ if (XRE_GetProcessType() == GeckoProcessType_Default)
>+ self->Shutdown();
>+ else
>+ mozilla::dom::ContentChild::GetSingleton()->
>+ SendRemoveAccelerometerListener();
would it make sense to just put the |SendRemoveAccelerometerListener| in Shutdown()?
> mNewListener = PR_TRUE;
>- Startup();
>+
>+ if (XRE_GetProcessType() == GeckoProcessType_Default)
>+ Startup();
>+ else
>+ mozilla::dom::ContentChild::GetSingleton()->
>+ SendAddAccelerometerListener();
Same idea here -- move SendAddAccelerometerListener into Startup()
Attachment #485137 -
Flags: review?(doug.turner) → review-
Assignee | ||
Comment 7•15 years ago
|
||
(In reply to comment #6)
> Comment on attachment 485137 [details] [diff] [review]
> patch
>
>
>
> >+ nsCOMPtr<nsIAccelerometer> iac =
> >+ do_GetService(NS_ACCELEROMETER_CONTRACTID);
> >+ nsCOMPtr<nsAccelerometer> ac = do_QueryInterface(iac);
> >+ if (ac)
> >+ ac->AccelerationChanged(x, y, z);
>
> I am surprised this works at all.
>
> I'd rather you add a new interface.
>
>
> > class nsAcceleration : public nsIAcceleration
> > {
> >@@ -156,7 +158,11 @@ nsAccelerometer::TimeoutHandler(nsITimer
> >
> > // what about listeners that don't clean up properly? they will leak
> > if (self->mListeners.Count() == 0 && self->mWindowListeners.Count() == 0) {
> >- self->Shutdown();
> >+ if (XRE_GetProcessType() == GeckoProcessType_Default)
> >+ self->Shutdown();
> >+ else
> >+ mozilla::dom::ContentChild::GetSingleton()->
> >+ SendRemoveAccelerometerListener();
>
>
> would it make sense to just put the |SendRemoveAccelerometerListener| in
> Shutdown()?
>
>
> > mNewListener = PR_TRUE;
> >- Startup();
> >+
> >+ if (XRE_GetProcessType() == GeckoProcessType_Default)
> >+ Startup();
> >+ else
> >+ mozilla::dom::ContentChild::GetSingleton()->
> >+ SendAddAccelerometerListener();
>
>
> Same idea here -- move SendAddAccelerometerListener into Startup()
Startup() and Shutdown() are implemented in 7 different places. Wouldn't it make sense to centralize this? Or do you want this to only be remoted for android?
Assignee | ||
Comment 8•15 years ago
|
||
Attachment #485137 -
Attachment is obsolete: true
Attachment #486268 -
Flags: review?(doug.turner)
Assignee | ||
Comment 9•15 years ago
|
||
Attachment #486268 -
Attachment is obsolete: true
Attachment #486289 -
Flags: review?(doug.turner)
Attachment #486268 -
Flags: review?(doug.turner)
Updated•15 years ago
|
Attachment #486289 -
Flags: review?(doug.turner) → review+
Updated•15 years ago
|
tracking-fennec: --- → ?
Updated•15 years ago
|
OS: Linux → Android
Hardware: x86_64 → All
Assignee | ||
Updated•15 years ago
|
Whiteboard: [fennec-checkin-postb2]
Assignee | ||
Updated•15 years ago
|
tracking-fennec: ? → 2.0b3+
Assignee | ||
Updated•15 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fennec-checkin-postb2]
Updated•4 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•