-
-
Notifications
You must be signed in to change notification settings - Fork 764
Simplified the StartsActivity by reducing the number of parameters through POJO class #579
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
Conversation
Simplified the StartsActivity by reducing the number of parameters through the POJO class.
Could someone please explain why the CI build has failed? |
@SrinivasanTarget : Kindly help me what I'm supposed to fix in the build error. |
@email2vimalraj you have styling issues. Please fix them https://travis-ci.org/appium/java-client/builds/204062313#L1987 you can ignore the warnings |
@email2vimalraj Hey buddy sorry just checked your note. please fix the errors to review. |
* | ||
* @param appPackage The package containing the activity. [Required] |
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.
@email2vimalraj I'm against this change as it is. Please mark these methods Deprecated
and with the description to use new ones
/** | ||
* This is a simple POJO class to support the {@link StartsActivity}. | ||
*/ | ||
public class Activity { |
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 this this POJO should have 2 mandatory parameteres: package and activity. Please add the constructor with these parameters.
* | ||
* @param appPackage The app package value. | ||
*/ | ||
public void setAppPackage(String appPackage) { |
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 like the idea behind this but have few things to be discussed here,
Is there a way to remove getters & setters? May be we need to come up with either custom annotation or something like https://github.com/rzwitserloot/lombok. May be not necessarily in this PR but subjective to discussion if there is any scope of improvement.
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.
Read the user review who was using the lombok for more than a year: http://stackoverflow.com/a/12807937/1505987
I would recommend to stay away from lombok, even though I never used it personally. My justification would be obviously a javadoc and everytime we will have to generate the code.
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 also don't recommend lombock. But i liked their way of using annotations.
The CI is still pending from long time. Could someone look into it? |
Have restarted travisCI job lets see. Anyways we need to wait for Codacy to complete. |
Seems some issue with Travis, it keeps the job in queue, but not running it up. |
Yes checking |
Any updates on CI? |
@SrinivasanTarget @TikhomirovSergey : Can any one of you please help on the Travis issue? Seems the travis doesn't like to run my PR :( |
@email2vimalraj I'll check with @imurchie and see if we could do something. |
Seems Travis finally ran my PR and this time build passed. :) https://travis-ci.org/appium/java-client/builds/204446236#L1990 |
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.
Otherwise LGTM
@@ -118,7 +119,10 @@ StartsActivity startsActivity = new StartsActivity() { | |||
} | |||
}; | |||
|
|||
StartsActivity startsActivity.startActivity("your.package.name", ".ActivityName"); | |||
Activity activity = new Activity(); | |||
activity.setAppPackage("your.package.name"); |
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.
@email2vimalraj Can you update here too.
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.
@email2vimalraj ping
@SrinivasanTarget : Fixed, kindly have a look |
* @param appPackage The value for the app package. | ||
* @param appActivity The value for the app activity. | ||
*/ | ||
public Activity(String appPackage, String appActivity) { |
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.
@email2vimalraj Could you provide these checkings:
import static com.google.common.base.Preconditions.checkArgument;
import static org.apache.commons.lang3.StringUtils.isBlank;
...
public Activity(String appPackage, String appActivity) {
checkArgument(!isBlank(appPackage), "App package should be defined as not empty or null string");
checkArgument(!isBlank(appActivity), "App activity should be defined as not empty or null string");
...
}
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 catch 👍
* | ||
* @param appActivity The app activity value. | ||
*/ | ||
public void setAppActivity(String appActivity) { |
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'm not sure that it is necessary to keep this method. Maybe it is more senseful to keep only getter for activity and make this field final. @SrinivasanTarget What is your opinion?
* | ||
* @param appPackage The app package value. | ||
*/ | ||
public void setAppPackage(String appPackage) { |
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'm not sure that it is necessary to keep this method. Maybe it is more senseful to keep only getter for package and make this field final. @SrinivasanTarget What is your opinion?
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.
+1 - Making this final would be a better option 👍
@email2vimalraj I have finished the reviewing. It is almost ok. @email2vimalraj Could you read comments and make some improvenents? ping @SrinivasanTarget |
…Also made the mandatory parameters final and removed setters.
@TikhomirovSergey and @SrinivasanTarget : Done the changes as recommended |
@email2vimalraj I have approved these changes. @SrinivasanTarget ? |
@email2vimalraj It's a merge away. Waiting for Codacy to be happy. |
Thanks @email2vimalraj 👍 |
Simplified the StartsActivity by reducing the number of parameters through POJO class
Change list
Currently the number of
startActivity
methods are unnecessary which can be solved by one single method with single parameter. So introduced the simple POJO class which in future can be expanded with any number of parameters.Types of changes
What types of changes are you proposing/introducing to Java client?
Details
The sample usage of new implementation is as follows: