-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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 a workaround for a possible null offset ID. #5067
Add a workaround for a possible null offset ID. #5067
Conversation
Debug builds always work (I tried this one as well just to be certain) so I need a release build to test, remember? |
Right, my bad. I'll upload one now. |
Works! Fixed for real this time! (Hopefully xD ) |
Maybe you could report the bug here? |
It could be a bug in LineageOS 16. |
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 feel like a bug fix like this, which which does not contain any UI stuff, should be covered by a unit tests.
When the underlying bug is fixed and the workaround is not needed anymore, it provides an easy way to verify that it still behaves as expected.
@@ -328,7 +328,7 @@ public static String relativeTime(final Calendar calendarTime) { | |||
// This method is a modified version of GregorianCalendar.from(ZonedDateTime). | |||
// Math.addExact() and Math.multiplyExact() are desugared even though lint displays a warning. | |||
@SuppressWarnings("NewApi") | |||
private static GregorianCalendar fromUTC(final OffsetDateTime offsetDateTime) { | |||
public static GregorianCalendar fromUTC(final OffsetDateTime offsetDateTime) { |
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.
Don't make a private method public for the sake of testing.
Instead you should test the methods thats using the private method or extract the method into it's own class (not 100% sure on the second part myself yet)
In this case i would write tests for public static String relativeTime(final OffsetDateTime offsetDateTime)
. If done this way you will provide the value of having regression test for when the workaround is removed. Because currently your tests will need to be removed, when the workaround ist removed.
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 tried creating an instrumented test, but attempting to run it results in an error message saying that the test class cannot be found.
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'll open an pr to your branch tonight/tomorrow with what i mean. Maybe i missed something, that makes what i mean not possible.
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.
No, I get that you want to test Localization.relativeTime()
directly, but I can't run the instrumented test, so I tested PrettyTime manually.
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.
Ok, now i understand why you need an instrumented test. The dependency are direcly accessed and not injected. This would need some major refactoring, which can be done in another PR.
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 created a PR with Dagger, so I could add a commit for DI with Localization
there.
eeee9ef
to
6c7a216
Compare
@@ -314,13 +318,33 @@ private static void initPrettyTime(final Context context) { | |||
} | |||
|
|||
public static String relativeTime(final OffsetDateTime offsetDateTime) { | |||
return relativeTime(GregorianCalendar.from(offsetDateTime.toZonedDateTime())); | |||
return relativeTime(fromUTC(offsetDateTime)); |
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.
The tests are not covering the bug that you fixed. I can change back this line and your tests still pass successfully
nvm, i realised my mistake.
That's because it seems to be specific to @opusforlife2's device. On my device, for instance, `GregorianCalendar.from()` works fine.
…On Fri, Dec 4, 2020, 10:50 PM XiangRongLin ***@***.***> wrote:
***@***.**** requested changes on this pull request.
------------------------------
In app/src/main/java/org/schabi/newpipe/util/Localization.java
<#5067 (comment)>:
> @@ -314,13 +318,33 @@ private static void initPrettyTime(final Context context) {
}
public static String relativeTime(final OffsetDateTime offsetDateTime) {
- return relativeTime(GregorianCalendar.from(offsetDateTime.toZonedDateTime()));
+ return relativeTime(fromUTC(offsetDateTime));
The tests are not covering the bug that you fixed. I can change back this
line and your tests still pass successfully
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5067 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHMXFEWPDAJL624PK3YA5KTSTEK5NANCNFSM4UJ5YORA>
.
|
b9138bc
to
ca30c7a
Compare
@opusforlife2 could you test the new APK? I moved the workaround to |
ca30c7a
to
c0d6c8a
Compare
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.
thanks again
@Isira-Seneviratne 0.20.6 works perfectly fine, so your modification seems to be okay. |
What is it?
Description of the changes in your PR
ZoneOffset
might be null (even though its documentation explicitly says that aZoneId
's ID value is not null).APK testing
app-release.zip
Due diligence