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

Nullability and javadocs #293

Merged
merged 16 commits into from
Aug 4, 2017
Merged

Conversation

AllanWang
Copy link
Contributor

@AllanWang AllanWang commented Jul 31, 2017

This is to add some annotations and update some old or inexisting javadocs.

Nullable and nonnull annotations help a lot for Kotlin users, where types allowing null values are distinguished.

The ones I've added are in public methods where I tracked down a possible null response. Other parts may need your input.

I also wanted to clarify some methods, so I added some javadocs and todos. I gave more comments directly on the respective lines.

A check is also added to sonatypeRepo so that devs who fork the project and compile it

@@ -69,9 +70,9 @@ uploadArchives {
repositories.mavenDeployer {
beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }

repository(url: sonatypeRepo) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

sonatypeRepo is not found when building. If this is in a properties file that is gitignore, maybe add a check so other users can compile their forks

Copy link
Collaborator

Choose a reason for hiding this comment

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

I ran into the same issue. I end up keeping this in git stash and undoing it when I push a PR. Would be great if the build file were updated to allow others to build without needing to do that.

Copy link
Member

Choose a reason for hiding this comment

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

Create a gradle.properties file and put a blank value there

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@serggl if this is in your gradle property file, how about I just add a check to see if the value is defined? It'll be something along the lines of

if property file exists or variable exists in System.env (for travis), then execute the call

Copy link
Member

Choose a reason for hiding this comment

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

True. Can you add it?:)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@serggl done. It looks like you also added fake properties in the travis yml, so I removed those as it won't be necessary

@@ -610,6 +615,7 @@ private boolean purchase(Activity activity, List<String> oldProductIds, String p
purchaseType,
purchasePayload);
}
//todo check if null check should be removed or if else should be removed
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This will always be nonnull given the if statement above

Copy link
Member

Choose a reason for hiding this comment

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

yep. A remove candidate

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I take it you mean that the null check if unnecessary. Resolved here 329c287

* Attempt to fetch purchases from the server and update our cache if successful
* @return {@code true} if retrieval occurs, {@code false} otherwise
* todo check if loading should return true if response code isn't successful
*/
public boolean loadOwnedPurchasesFromGoogle()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently, the load methods return true so long as a response is received, regardless of whether the response was successful or not. I also removed the first isInitialized call as it is called in both load methods. It therefore doesn't need to be verified a third time beforehand

@@ -49,11 +50,11 @@
*/
public interface IBillingHandler
{
void onProductPurchased(String productId, TransactionDetails details);
void onProductPurchased(String productId, @Nullable TransactionDetails details);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Check if productId is nullable. As of now I don't think it is

Copy link
Collaborator

@autonomousapps autonomousapps left a comment

Choose a reason for hiding this comment

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

I'm in favor of this idea! What do you think, @serggl ?

@@ -35,6 +35,7 @@ android {
dependencies {
androidTestCompile 'com.android.support.test:runner:0.5'
androidTestCompile 'com.android.support.test:rules:0.5'
compile 'com.android.support:support-annotations:25.3.1'
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am personally very much in support of adding nullability annotations. Useful for us Java users, too!

@@ -69,9 +70,9 @@ uploadArchives {
repositories.mavenDeployer {
beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }

repository(url: sonatypeRepo) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I ran into the same issue. I end up keeping this in git stash and undoing it when I push a PR. Would be great if the build file were updated to allow others to build without needing to do that.

private static final Date DATE_MERCHANT_LIMIT_1 = new Date(2012, 12, 5); //5th December 2012
private static final Date DATE_MERCHANT_LIMIT_2 = new Date(2015, 7, 20); //21st July 2015
private static final Date DATE_MERCHANT_LIMIT_1 = new Date(1354694400000L); //5th December 2012
private static final Date DATE_MERCHANT_LIMIT_2 = new Date(1437375600000L); //21st July 2015
Copy link
Contributor Author

@AllanWang AllanWang Jul 31, 2017

Choose a reason for hiding this comment

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

Replace with millis, since using the original notation may not produce expected results. See stack overflow. Based on PST

Copy link
Member

Choose a reason for hiding this comment

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

Are there any other options as a replacement? This is a bit less readable code

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@serggl see latest commit. I'm 99% sure that that is how calendars are used, so it should be good. The date will likely vary based on timezones, but it shouldn't be off by more than a day.

/**
* Attempt to fetch purchases from the server and update our cache if successful
* @return {@code true} if retrieval occurs, {@code false} otherwise
* todo check if loading should return true if response code isn't successful
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@serggl I'm referring to this line where return true occurs after the if statement that checks if the response is ok. Is that expected behaviour?

Copy link
Member

@serggl serggl Aug 1, 2017

Choose a reason for hiding this comment

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

oh, right. Should return false here if response was not successful

Copy link
Contributor Author

@AllanWang AllanWang Aug 1, 2017

Choose a reason for hiding this comment

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

Resolved b281e51

@serggl
Copy link
Member

serggl commented Aug 1, 2017

👍

@AllanWang
Copy link
Contributor Author

Currently, this is ready to be merged. However, there may be more things I'd like to clarify/annotate, so you can choose to wait for those or to merge this for now.

@AllanWang
Copy link
Contributor Author

Oh one last thing. May not be suited for this PR, but you may consider updating the sdk to 26. It's out of beta now.

@serggl
Copy link
Member

serggl commented Aug 1, 2017

let me know when you decide it is ready to be merged. Thank you!

@AllanWang
Copy link
Contributor Author

In the billing base class, commit is used, but I think it can be replaced with apply. You may want to look into that

@@ -108,4 +113,15 @@ public PurchaseInfo createFromParcel(Parcel source)
return new PurchaseInfo[size];
}
};

@Override
public boolean equals(Object o)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Check if this is good for equals or if other values should be checked. I replaced the test above to use equals rather than checking individual attributes.

@AllanWang
Copy link
Contributor Author

After the comments above are addressed, this PR is ready for merging

@serggl
Copy link
Member

serggl commented Aug 4, 2017

only one small question on dates left

@AllanWang
Copy link
Contributor Author

@serggl if any of you can, consider posting whatever formatting rules you use for Android Studio. Mine is different (braces are after if statements rather than on the next line etc). So I'm unable to format the code

@serggl
Copy link
Member

serggl commented Aug 4, 2017

@AllanWang I guess Im using default rules. However there are still classes which are formatted based on Eclipse rules

@serggl serggl merged commit b04db8d into anjlab:master Aug 4, 2017
serggl added a commit that referenced this pull request Aug 7, 2017
showdpro pushed a commit to showdpro/android-inapp-billing-v3 that referenced this pull request Jul 13, 2021
* Add annotations and some javadocs fixes

* Add more nullables

* Update loadOwnedPurchasesFromGoogle

* Add check for sonatypeRepo var

* Replace date

* Remove extra import

* Ensure load purchase only returns true on successful response

* Remove unnecessary null check

* Add more annotations

* Remove uses of deprecated methods in library

* Fix lint

* Remove unused throw exception

* Add this comparison

* Optimize imports

* Test locally and fix errors

* Use calendar rather than date
showdpro pushed a commit to showdpro/android-inapp-billing-v3 that referenced this pull request Jul 13, 2021
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.

3 participants