Error on refresh and crash on opening preferences
0-5-0 opened this issue · comments
I'm suddenly getting an error on refresh with Open-Meteo selected, if I switch to Meteo France or OpenWeatherMap it's fine. If I click Preferences from any of them then the app crashes entirely, map and font scale open fine. Maybe an issue with querying Open-Meteo which would also affect preferences since it fetches the model list?
Error: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String
I've cleared app cache, restarted the phone, it worked fine earlier, issue started at 4:45PM WET (GMT +01:00) 02-25-2024.
I uninstalled the app, re-installed and everything is fine until I try to set an Open-Meteo Model that isn't "Best match", then it starts crashing again. Cleared the app data, set my location again, went to preferences, set it to GEM Global, DWD Icon seamless, ECMWF, they all crash.
Attached crash dump... click to expand
type: crash osVersion: google/bluejay/bluejay:14 package: [com.akylas.weather:95](https://com.akylas.weather:95/) process: [com.akylas.weather](https://com.akylas.weather/) processUptime: 33005 + 171 ms installer: [com.android](https://com.android/).packageinstallercom.tns.NativeScriptException: Calling js method onBindViewHolder failed
Error: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String
at com.tns.Runtime.callJSMethodNative(Native Method)
at com.tns.Runtime.dispatchCallJSMethodNative(SourceFile:1)
at com.tns.Runtime.callJSMethodImpl(Unknown Source:100)
at com.tns.Runtime.callJSMethod(SourceFile:1)
at com.tns.Runtime.callJSMethod(SourceFile:2)
at com.tns.Runtime.callJSMethod(SourceFile:3)
at com.tns.gen.com.nativescript.collectionview.AdapterInterface.onBindViewHolder(Unknown Source:17)
at com.nativescript.collectionview.Adapter.onBindViewHolder(SourceFile:2)
at com.nativescript.collectionview.Adapter.onBindViewHolder(SourceFile:1)
at androidx.recyclerview.widget.RecyclerView$Adapter.onBindViewHolder(SourceFile:1)
at androidx.recyclerview.widget.RecyclerView$Adapter.bindViewHolder(Unknown Source:148)
at androidx.recyclerview.widget.RecyclerView$Recycler.u(SourceFile:1)
at androidx.recyclerview.widget.RecyclerView$Recycler.v(SourceFile:61)
at androidx.recyclerview.widget.RecyclerView$Recycler.i(SourceFile:1)
at androidx.recyclerview.widget.GridLayoutManager.I(SourceFile:107)
at androidx.recyclerview.widget.LinearLayoutManager.y(SourceFile:61)
at androidx.recyclerview.widget.LinearLayoutManager.onLayoutChildren(Unknown Source:341)
at androidx.recyclerview.widget.GridLayoutManager.onLayoutChildren(Unknown Source:9)
at androidx.recyclerview.widget.RecyclerView.z(SourceFile:1)
at androidx.recyclerview.widget.RecyclerView.x(SourceFile:1)
at androidx.recyclerview.widget.RecyclerView.s(SourceFile:1)
at d.w.run(SourceFile:138)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1343)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1352)
at android.view.Choreographer.doCallbacks(Choreographer.java:952)
at android.view.Choreographer.doFrame(Choreographer.java:878)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1326)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8279)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ExecInit.main(ExecInit.java:49)
at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:359)
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String
at android.app.SharedPreferencesImpl.getString(SharedPreferencesImpl.java:325)
... 37 more
@0-5-0 thanks a lot for the report. Saw some reports on my sentry (used with play store builds). Thanks for the detailed explanation will help me fix it
@0-5-0 fixed in latest version
It's working great again, thank you :)
@farfromrefug is Sentry opt-in or enabled by default? My scanner just reported it with today's update. I vaguely remember having checked that before and it should just have been enabled for test builds, it was not in the APK here then. So now it is, and I'll have to raise the Tracking anti-feature – at least until clarified.
@IzzySoft not it is not for fdroid builds. Only playstore builds. Something must gone wrong with cleanup and the native deps might have been added even if the code is not activated within the app.
Will make a new release without it. Sorry about this
Happens, thanks for the fast response! Just to make sure we talk about the same APK: I'm taking the one from… uh? there are two now? Uh-oh… so my updater will take a random one from releases here. So while on it, shall I pin the updater to the arm64 one for consistency – or leave it at "random luck" so older (32bit-only) devices get a chance for updates, too? 🤪 Do both have the same versionCode?
@IzzySoft you mean there are 2 with armv7 and armv8?
yes I dont publish universal because I think it useless to have all users download much bigger apps (in my case most of the app size is in so libs sadly)
Izzy always picked up armv7 (alphabetically ?) until now. I have a few friends which thus cant download from izzy. but did not really get other reports (they might simply not see the app :))
and yes they have the same version code. would it solve it to have different version code ?
you mean there are 2 with armv7 and armv8?
No, just 2 APKs altogether – one with armeabi and one with arm64. Usually my config here then specifies which to pick, but it does not. So it's not guaranteed which one will be picked – this depends on which order the Github API returns them then.
I think it useless to have all users download much bigger apps
I totally agree there!
and yes they have the same version code. would it solve it to have different version code ?
No, I was just asking because of the "random pick". So shall I pin it to the armeabi then to make sure it's consistent? We can always switch later if you wish (e.g. when the last 32bit-only devices are "gone" – I also own some of those, though only one of them is still in "active duty" as a phone, the other is just a night stand.
@IzzySoft ok so i guess you can filter and only pick arm64. This is how it is right now so wont change thing.
pick arm64. This is how it is right now
Hm, just in your comment before you wrote:
Izzy always picked up armv7
which is the other one. So, switch to arm64, pin armv7, or leave as-is?
I mixes up it does always pick up arm64! sorry
OK, pinned to /arm64-v8a/i.