-
Notifications
You must be signed in to change notification settings - Fork 288
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
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
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. |
There was a problem hiding this 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() |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unneccessary import?
There was a problem hiding this comment.
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; | ||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea
Sorry for my late review, things have been extremely hectic |
Any chance you could have a look at my comments? |
Yes, sorry, I'm a little busy right now but I'll try to look it by next week. |
I think I considered all your remarks. |
What's wrong with this PL ? |
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