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

Fix crash with unknown notification type #1123

Merged
merged 3 commits into from
Mar 16, 2019

Conversation

kyori19
Copy link
Contributor

@kyori19 kyori19 commented Mar 13, 2019

Fix part of #1102 .

If there's "Your poll has ended." notification in user's notification list, app crashes.
This is a fatal problem because once app started to crash, we can't even switch account.
So I fixed not to crash app for now.

@charlag
Copy link
Collaborator

charlag commented Mar 13, 2019

I'm still grumpy about Mastodon just breaking clients. If we're sure that it will stay the same in stable (very likely) I propose to merge this before the stable release.

@@ -136,6 +136,7 @@ public void onBindViewHolder(@NonNull RecyclerView.ViewHolder viewHolder, int po
(NotificationViewData.Concrete) notification;
Notification.Type type = concreteNotificaton.getType();
switch (type) {
default:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Huh? I don't get it, default is a mention?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When type is null, switch statement returns NullPointerException.
This seems to be a Java's specification.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Indeed it is and indeed it does throw. I just don't understand how "default" changes that:
https://ideone.com/I82Z5B

@@ -59,7 +59,7 @@ public Concrete(Notification.Type type, String id, Account account,
}

public Notification.Type getType() {
return type;
return type == null ? Notification.Type.UNKNOWN : type;
Copy link
Collaborator

Choose a reason for hiding this comment

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

New notification does not have a type at all? Why it's null?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

New notification type poll is not defined in Notification.Type so type will be null.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, I see. Maybe more correct would be to alter parser code so that it returns UNKNOWN if it doesn't match any.
Right now it makes a really confusing API in the data layer (we can have both null and UNKNOWN).
We could mark type field as @JsonAdapter and write our adapter (I can help with that). It could take 10 more minutes but it will be future-proof IMO.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think its even possible without a JsonAdapter, have a look how we handle Visibility in Status.kt

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When I passed instance original visibility unleakable, app crashed with same error.
So I think we need JsonAdapter...

2019-03-15 16:50:24.068 2655-2655/com.keylesspalace.tusky E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.keylesspalace.tusky, PID: 2655
    java.lang.NullPointerException: Attempt to invoke virtual method 'int com.keylesspalace.tusky.entity.Status$Visibility.ordinal()' on a null object reference

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added NotificationTypeAdapter and anotated Notification.Type by JsonAdapter.
Please check whether it works correctly.

@charlag
Copy link
Collaborator

charlag commented Mar 15, 2019

Looks fine. We don't need @SerializedName now I guess.

@kyori19
Copy link
Contributor Author

kyori19 commented Mar 16, 2019

@charlag It's true. Removed @SerializedName from Notifiaction.Type.

@connyduck
Copy link
Collaborator

Poll notifications now look like I mentioned myself. But better than crashing I guess. And it hopefully wont stay this way for long.

@connyduck connyduck merged commit d0f7f6f into tuskyapp:master Mar 16, 2019
@kyori19 kyori19 deleted the fix-poll-notification branch March 16, 2019 13:43
@charlag charlag mentioned this pull request Mar 21, 2019
1 task
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