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

Add button to toggle flash on/off #59

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

Didier116
Copy link

  • This will allow the user to activate flash when recording by adding a flash toggle button on the top left (See the screenshot below).

screenshot_20180203-182804

  • The developer can also hide flash toggle using builder.noFlashToggle(); while creating CaptureConfiguration. By default, flash toggle switch is visible and off.

It's my first pull request, so I must admit that I was very inspired by Kevalpatel's work done on the front and rear facing camera switch and on his PR message ;)

Refs Pull#34 and Issue#13

@codecov-io
Copy link

codecov-io commented Feb 2, 2018

Codecov Report

Merging #59 into master will decrease coverage by 2.39%.
The diff coverage is 41.17%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master      #59     +/-   ##
===========================================
- Coverage     71.05%   68.66%   -2.4%     
- Complexity      127      131      +4     
===========================================
  Files            15       15             
  Lines           722      785     +63     
  Branches         49       64     +15     
===========================================
+ Hits            513      539     +26     
- Misses          184      214     +30     
- Partials         25       32      +7
Impacted Files Coverage Δ Complexity Δ
...ile/landscapevideocapture/camera/NativeCamera.java 6.25% <0%> (-1.6%) 1 <0> (ø)
...le/landscapevideocapture/camera/CameraWrapper.java 68% <0%> (-1.39%) 19 <0> (ø)
.../landscapevideocapture/recorder/VideoRecorder.java 95.27% <100%> (+0.03%) 26 <1> (ø) ⬇️
.../landscapevideocapture/preview/CapturePreview.java 96.61% <100%> (+0.05%) 12 <1> (+1) ⬆️
...configuration/PredefinedCaptureConfigurations.java 96.29% <100%> (+0.29%) 1 <0> (ø) ⬇️
...le/landscapevideocapture/VideoCaptureActivity.java 27.52% <22.22%> (+0.33%) 10 <1> (ø) ⬇️
...e/landscapevideocapture/view/VideoCaptureView.java 60.18% <23.52%> (-6.85%) 14 <1> (+1)
...deocapture/configuration/CaptureConfiguration.java 85.07% <76.19%> (-1.66%) 22 <2> (+2)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5c90229...45736ab. Read the comment docs.

@kheirus
Copy link

kheirus commented Feb 4, 2018

Good job guy @Didier116 , hope that will be validate soon, it will be nice that we can use this feature without re-implement it from scratch.
Thank u for your implication anyway ;)

Copy link
Owner

@JeroenMols JeroenMols left a comment

Choose a reason for hiding this comment

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

Looks good, please have a look at the comments.

Build is failing because of timeout on Android emulators in Travis, let's wait for a rebuild (and get lucky) or else I'll fix it structurally


// name attribute is optional, provide an unique name for test
// multiple parameters, uses Collection<Object[]>
@Parameterized.Parameters()
Copy link
Owner

Choose a reason for hiding this comment

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

This is overkill, there is no need to check that every interaction with the recorder uses the right value for the flash. Better just to always pass in false, and to add one extra test that validates that true is properly propagated. (or multiple ones if there are different propagations)

Doing it this way basically defocusses every existing test and adds an extra thing for them to implicitly test. That is what I want to avoid: every test should only test for exactly one thing.

So remove parametrized, always use flash = false and add one (or more) tests to only check if a true value is properly propagated,

CaptureConfiguration configuration = new Builder(MOCK_RESOLUTION, MOCK_QUALITY).setFlashOption(PredefinedCaptureConfigurations.FlashOption.HIDE).build();

assertThat(configuration.getAllowFlashToggle()).isFalse();
assertThat(configuration.getIfFlashStartOn()).isFalse();
Copy link
Owner

Choose a reason for hiding this comment

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

Please split each and every one of those tests in two. Every test should only have exactly one assertion/verification.

Reason is that with multiple asserts: tests can fail for more than one reason. So if they fail you need to actually do an investigation to see what went wrong. With only one assert the root cause for failure is crystal clear (especially if you gave the test a great name). Second benefit is that the tests stops running after the first failure which could be annoying if you actually fixed bug number 1, but there is still a second one.

import com.jmolsmobile.landscapevideocapture.configuration.PredefinedCaptureConfigurations.CaptureResolution;

import org.junit.Test;
import org.junit.runner.RunWith;

import android.support.test.runner.AndroidJUnit4;
Copy link
Owner

Choose a reason for hiding this comment

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

Unneccessary import?

Copy link
Author

Choose a reason for hiding this comment

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

I think it's on other " committing reformatting changes" error.

public class VideoCaptureActivity extends Activity implements RecordingButtonInterface, VideoRecorderInterface {

public static final int RESULT_ERROR = 753245;

Copy link
Owner

Choose a reason for hiding this comment

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

General tip: please avoid committing reformatting changes, they clutter you PR and make it harder to review + they clutter your git history.

You don't have to change this here

Copy link
Author

Choose a reason for hiding this comment

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

My bad, I did not pay enough attention. Sorry for that


public void setFlash(boolean isFlashOn){

if(camera != null) {
Copy link
Owner

Choose a reason for hiding this comment

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

When setFlash() is being called the camera should already be open (camera != null) and params should already be accessed before (params != null) hence it doesn't make any sense to check for this.

I prefer to program offensively: if something happens that you didn't expect your code should crash so you are aware of that. (otherwise it fails silently) In this case a consumer of setFlash() could call it and expect it to work, but internally the method would fail. Not checking for null, makes the contract more strict and enforces a single way to use this api.

Please remove null check for camera and params, the null check for flashmodes is valid

Copy link
Author

Choose a reason for hiding this comment

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

Very interesting remark, I thought to do well, I take note and correct.

@@ -155,6 +158,20 @@ public boolean getAllowFrontFacingCamera() {
return allowFrontFacingCamera;
}

/**
* @return If front flash toggle must be displayed before capturing video
Copy link
Owner

Choose a reason for hiding this comment

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

Does "front" need to be here? Flash also works for back camera, right?

Copy link
Author

@Didier116 Didier116 Apr 13, 2018

Choose a reason for hiding this comment

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

Right!...

}

/**
* @return If front flash must be start on
Copy link
Owner

Choose a reason for hiding this comment

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

Does "front" need to be here? Flash also works for back camera, right?

Copy link
Author

Choose a reason for hiding this comment

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

...voiceless...

@@ -103,4 +103,9 @@ public int getBitrate(CaptureQuality quality) {
}

}

public enum FlashOption {
HIDE,HIDE_ON, START_OFF, START_ON;
Copy link
Owner

Choose a reason for hiding this comment

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

Wouldn't it be better to call: FlashOption: NO_FLASH, ALWAYS_ON, START_OFF, START_ON

Copy link
Author

Choose a reason for hiding this comment

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

Good idea

@JeroenMols
Copy link
Owner

Sorry for my late review, things have been extremely hectic

@JeroenMols
Copy link
Owner

Any chance you could have a look at my comments?

@Didier116
Copy link
Author

Yes, sorry, I'm a little busy right now but I'll try to look it by next week.

@Didier116
Copy link
Author

I think I considered all your remarks.
So, what's the next step? Is there anything I've forgotten or can I do more?

@Didier116
Copy link
Author

What's wrong with this PL ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants