Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic dark mode based on ambient light #6756

Closed
wants to merge 3 commits into from

Conversation

fercarcedo
Copy link

// FREEBIE

First time contributor checklist

Contributor checklist

  • Nexus 5, Android 7.1.2
  • Virtual device Pixel, Android 7.0.0
  • Virtual device Pixel XL, Android O
  • Virtual device Nexus 5X, Android 4.2
  • My contribution is fully baked and ready to be merged as is
  • I ensure that all the open issues my contribution fixes are mentioned in the commit message of my first commit using the Fixes #1234 syntax
  • I have made the choice whether I want the BitHub reward or not by omitting or adding the word FREEBIE in the commit message of my first commit

Description

This pull request enables Signal to automatically change to dark theme based on the current ambient light condition, like many other apps do.
I have tested this pull request in both emulators (setting manually the number of lux), as well as on my Nexus 5, going from outdoors to a dark room indoors, and in the night outside.

private Activity activity;

public AutoDarkModeManager(Activity activity) {
this.activity = activity;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think this is a memory leak waiting to happen

}

public void listenForCurrentActivityIfNecessary() {
if (!activity.getClass().getSimpleName().equals(lastActivityName)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels a little gross on two levels, first using the textual representation of a class name to track activity rather than identity, and then having potentially multiple instances of this class but only one listening

showDarkTheme = lux <= MAX_LUX_FOR_DARK_THEME;
if (previousShowDarkTheme != showDarkTheme)
ActivityUtil.recreateActivity(activity);
stopListening();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels racey to me

@@ -0,0 +1,51 @@
/*
* Copyright (C) 2017 Fernando Garcia Alvarez
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would need to be copyright OWS with GPLv3 headers for me to merge

@fercarcedo
Copy link
Author

I have fixed the problems you mentioned. Please let me now of any problems.
Thank you.

Activity currentActivity = activity.get();
if (previousShowDarkTheme != showDarkTheme && currentActivity != null)
ActivityUtil.recreateActivity(currentActivity);
stopListening();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this is the only place you ever unregister a listener. It looks like that means that every time you enter an activity, you get a new instance of this class and a new listener. They stack up forever, unless there's a sensor event.

On the other hand, as soon as a sensor change comes in, whether it's below the threshold or not, it gets unregistered. From what I can understand, this behavior is both a memory leak and breaks the functionality?


}

private synchronized void parseAmbientLightValue(SensorEvent event) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this method synchronized? If the idea is that it can be called off the UI thread, then it seems like all the values that it accesses would also need synchronized access from their writes on the UI thread.


@Override
public void onSensorChanged(SensorEvent event) {
parseAmbientLightValue(event);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Private methods might read instance state if necessary, but they should not have the side effect of modifying instance state unless they're initializer methods. The method you're calling is named "parseAmbientLightValue," but it does much more than parsing an argument -- it modifies instance state, updates listeners, even potentially destroys an activity.

@fercarcedo
Copy link
Author

fercarcedo commented Jul 10, 2017

I have refactored AutoDarkModeManager to be cleaner, and also now the sensor gets unregistered as soon as onPause is called. The behavior of unregistering the sensor after the first value is found is correct, I did that in order to preserve battery life and also to avoid annoying the user, since for example if the user is typing a message and then it becomes necessary to switch to the dark theme based on ambient light, the user will get annoyed due to the activity being restart while typing the message, but if you want another behavior, let me know.

@fercarcedo
Copy link
Author

I've also made a rebase to the pull request to update it to the new changes of Signal (and test it with the new 4.8.0 version)

@FeuRenard
Copy link
Contributor

This PR currently includes some commits from master. Seems like something went wrong during rebase.

Fixes #751.

@fercarcedo fercarcedo force-pushed the autodarkmodeambient branch from 42a310e to 1678038 Compare August 11, 2017 19:03
@fercarcedo
Copy link
Author

I have removed the merge commit from the PR, which was causing some master commits to appear here. Sorry, that's my first time doing a PR

@stale
Copy link

stale bot commented Jan 26, 2022

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the wontfix label Jan 26, 2022
@stale stale bot closed this Feb 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

3 participants