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

[Bug] Crash when trying to edit contact #9

Closed
hontogit opened this issue Oct 24, 2020 · 5 comments
Closed

[Bug] Crash when trying to edit contact #9

hontogit opened this issue Oct 24, 2020 · 5 comments

Comments

@hontogit
Copy link

Description of the bug
After update to Version 1.1.3 from fdroid, the app crashes when I try to open two specific saved contacts from 5 and 4 days ago. All other saved contacts and events are fine.

I catched this with logcat:

ClassLoader referenced unknown path: /data/app/com.apozas.contactdiary-1/lib/arm

FATAL EXCEPTION: main
Process: com.apozas.contactdiary, PID: 13761
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.apozas.contactdiary/com.apozas.contactdiary.EditContactActivity}: java.lang.NullPointerException: null cannot be cast to non-null type android.widget.RadioButton
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2699)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2766)
	at android.app.ActivityThread.-wrap12(ActivityThread.java)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1507)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:154)
	at android.app.ActivityThread.main(ActivityThread.java:6236)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:891)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:781)
Caused by: java.lang.NullPointerException: null cannot be cast to non-null type android.widget.RadioButton
	at com.apozas.contactdiary.EditContactActivity.onCreate(EditContactActivity.kt:74)
	at android.app.Activity.performCreate(Activity.java:6684)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1119)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2652)
	... 9 more

  Force finishing activity com.apozas.contactdiary/.EditContactActivity

  Force finishing activity com.apozas.contactdiary/.MainActivity

To Reproduce
Steps to reproduce the behavior:
Unfortunately I can't remember what I saved in these two contacts. They were not special or different to the others, I would say.
And since the app crashes immediately, I can't see what was saved.

Expected behavior
I open the app, tap on the saved contact and can review and edit the previously saved data.

System information (please complete the following information):

  • Device: HTC One
  • Android version: 7.1.2
  • App version: 1.1.3
@apozas
Copy link
Owner

apozas commented Oct 24, 2020

Hi,

Thanks for reaching out, and apologies for the inconveniences this is causing.

By any chance, do you happen to have your phone rooted? If so, would you mind accessing the database (in data/data/com.apozas.contactdiary/databases/ContactDiary.db) and let me know which are the values of the fields Relative, CloseContact and EncounterType?

Thank you very much, and sorry for the hassle.

@hontogit
Copy link
Author

Thanks to you for quick response and app. 😃

I was able to read the file and both contacts have the value -1 in Relative, and a 3 in CloseContact and EncounterType. I have no idea how the negative value sneaked in there.

@apozas
Copy link
Owner

apozas commented Oct 25, 2020

Well, thank you for taking the time to help debug this. I was finding very difficult to replicate the conditions that were giving rise to this bug. As you may check by the activity in the repo, there has recently been an issue with how the information in the RadioButtons was handled, all because of this commit. My guess is that your failing contacts were created with the answer No in the Relative or close Friend question in v<1.0.5, later opened with v1.0.5 and saved in order to "confirm" that the RadioButtons were not properly saved. Since EditContactActivity.kt does not do an empty-field check for the RadioGroups (there is a reason for this: there is no way to have all the RadioButtons in a RadioGroup unchecked after one has been checked, and EditContactActivity.kt does not expect an empty RadioGroup because of the checks done before saving in NewContactActivity.kt), this was allowing a -1 to be saved.

In short, the issue appears with some (not all) contacts saved in v<1.0.5, opened and re-saved in v1.0.5, while trying to open them in v>1.0.5. This issue should not appear when saving contacts in v1.0.5. Thus, the quickest fix for you will be to read the entries in the database by hand, and insert them again manually in the app.

I will think how to best deal with this issue and release a fix in the next version.

Thanks a lot!

@igor-cali
Copy link
Contributor

I still experience this issue in v1.1.3 from F-droid.
I cannot read data/data/com.apozas.contactdiary/databases/ContactDiary.db since my device is not rooted.
Anyway, I assume the same root cause of -1 values affects my installation as well.

Proposal: set to default values in case -1 is read. E.g.

  • Relative: No
  • EncounterType: Outdoor
  • CloseContact: Unsure

@apozas
Copy link
Owner

apozas commented Nov 1, 2020

Commit 41c4788 should finally fix this problem. It implements @igor-cali's proposal, which is the most sensible given that the error appeared when saving in v1.0.5 a contact where the last RadioButton in any of the RadioGroups was chosen.

In the meantime, I discovered the marvels of Android Studio's Database Inspector to change fields of the database on-the-fly. This will prevent having this many partial fixes again. Thank you for your patience. I will keep the issue open a few days to see if anyone encounters a problem in this regard.

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

No branches or pull requests

3 participants