EOFException when restarting my app on Android
up vote
1
down vote
favorite
I loose values in Preferences (CN1Preferences) in particular scenario of using my application on Android.
When I launch my app the first time, I save some values in Preferences. If I close my app (from background task) and then I sleep my tablet, when I relaunch the app, values save in Preferences are lost. This is the log I obtain after the relaunch :
CliniScore: [EDT] 0:0:0,4 - Exception: java.io.EOFException - null
05-04 16:32:40.667 10618-10978/? W/System.err: java.io.EOFException
05-04 16:32:40.667 10618-10978/? W/System.err: at java.io.DataInputStream.readBoolean(DataInputStream.java:69)
05-04 16:32:40.667 10618-10618/? D/SecWifiDisplayUtil: Metadata value : SecSettings2
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:541)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:638)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Storage.readObject(Storage.java:261)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:83)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:298)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneImplementation.initEDT(CodenameOneImplementation.java:235)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.Display.mainEDTLoop(Display.java:952)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneThread$1.run(CodenameOneThread.java:60)
05-04 16:32:40.667 10618-10978/? W/System.err: at java.lang.Thread.run(Thread.java:818)
If I force close my app only (without sleep my tablet), there is no problem with my preferences values.
This problem doesn't occurs in iOS/Simulator/Emulator(Android). I've only noticed it on a Samsung Galaxy Tab A running Android 6.0.1
Thanks in advance.
codenameone
|
show 5 more comments
up vote
1
down vote
favorite
I loose values in Preferences (CN1Preferences) in particular scenario of using my application on Android.
When I launch my app the first time, I save some values in Preferences. If I close my app (from background task) and then I sleep my tablet, when I relaunch the app, values save in Preferences are lost. This is the log I obtain after the relaunch :
CliniScore: [EDT] 0:0:0,4 - Exception: java.io.EOFException - null
05-04 16:32:40.667 10618-10978/? W/System.err: java.io.EOFException
05-04 16:32:40.667 10618-10978/? W/System.err: at java.io.DataInputStream.readBoolean(DataInputStream.java:69)
05-04 16:32:40.667 10618-10618/? D/SecWifiDisplayUtil: Metadata value : SecSettings2
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:541)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:638)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Storage.readObject(Storage.java:261)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:83)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:298)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneImplementation.initEDT(CodenameOneImplementation.java:235)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.Display.mainEDTLoop(Display.java:952)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneThread$1.run(CodenameOneThread.java:60)
05-04 16:32:40.667 10618-10978/? W/System.err: at java.lang.Thread.run(Thread.java:818)
If I force close my app only (without sleep my tablet), there is no problem with my preferences values.
This problem doesn't occurs in iOS/Simulator/Emulator(Android). I've only noticed it on a Samsung Galaxy Tab A running Android 6.0.1
Thanks in advance.
codenameone
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22
|
show 5 more comments
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I loose values in Preferences (CN1Preferences) in particular scenario of using my application on Android.
When I launch my app the first time, I save some values in Preferences. If I close my app (from background task) and then I sleep my tablet, when I relaunch the app, values save in Preferences are lost. This is the log I obtain after the relaunch :
CliniScore: [EDT] 0:0:0,4 - Exception: java.io.EOFException - null
05-04 16:32:40.667 10618-10978/? W/System.err: java.io.EOFException
05-04 16:32:40.667 10618-10978/? W/System.err: at java.io.DataInputStream.readBoolean(DataInputStream.java:69)
05-04 16:32:40.667 10618-10618/? D/SecWifiDisplayUtil: Metadata value : SecSettings2
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:541)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:638)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Storage.readObject(Storage.java:261)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:83)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:298)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneImplementation.initEDT(CodenameOneImplementation.java:235)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.Display.mainEDTLoop(Display.java:952)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneThread$1.run(CodenameOneThread.java:60)
05-04 16:32:40.667 10618-10978/? W/System.err: at java.lang.Thread.run(Thread.java:818)
If I force close my app only (without sleep my tablet), there is no problem with my preferences values.
This problem doesn't occurs in iOS/Simulator/Emulator(Android). I've only noticed it on a Samsung Galaxy Tab A running Android 6.0.1
Thanks in advance.
codenameone
I loose values in Preferences (CN1Preferences) in particular scenario of using my application on Android.
When I launch my app the first time, I save some values in Preferences. If I close my app (from background task) and then I sleep my tablet, when I relaunch the app, values save in Preferences are lost. This is the log I obtain after the relaunch :
CliniScore: [EDT] 0:0:0,4 - Exception: java.io.EOFException - null
05-04 16:32:40.667 10618-10978/? W/System.err: java.io.EOFException
05-04 16:32:40.667 10618-10978/? W/System.err: at java.io.DataInputStream.readBoolean(DataInputStream.java:69)
05-04 16:32:40.667 10618-10618/? D/SecWifiDisplayUtil: Metadata value : SecSettings2
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:541)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Util.readObject(Util.java:638)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Storage.readObject(Storage.java:261)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:83)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.io.Preferences.get(Preferences.java:298)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneImplementation.initEDT(CodenameOneImplementation.java:235)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.Display.mainEDTLoop(Display.java:952)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120)
05-04 16:32:40.667 10618-10978/? W/System.err: at com.codename1.impl.CodenameOneThread$1.run(CodenameOneThread.java:60)
05-04 16:32:40.667 10618-10978/? W/System.err: at java.lang.Thread.run(Thread.java:818)
If I force close my app only (without sleep my tablet), there is no problem with my preferences values.
This problem doesn't occurs in iOS/Simulator/Emulator(Android). I've only noticed it on a Samsung Galaxy Tab A running Android 6.0.1
Thanks in advance.
codenameone
codenameone
asked May 4 '17 at 14:51
Jérémy MARQUER
966
966
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22
|
show 5 more comments
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22
|
show 5 more comments
2 Answers
2
active
oldest
votes
up vote
1
down vote
It's possible that this relates to threaded access to the preferences which should be legal. I've made the two potentially disruptive methods synchronized in today's update and hopefully this would resolve that issue.
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
|
show 5 more comments
up vote
0
down vote
In my case, I copied a working project to start a new one. And I left the file
keystore.jks
(keystore to upload to Google Play) empty, so when I compiled I got this exception.
I just removed the signingConfig line in android/buildTypes
section in the application level build.gradle
, and it worked.
May be you had a problem of this kind, an empty forgotten file that shouldnt be empty.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
It's possible that this relates to threaded access to the preferences which should be legal. I've made the two potentially disruptive methods synchronized in today's update and hopefully this would resolve that issue.
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
|
show 5 more comments
up vote
1
down vote
It's possible that this relates to threaded access to the preferences which should be legal. I've made the two potentially disruptive methods synchronized in today's update and hopefully this would resolve that issue.
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
|
show 5 more comments
up vote
1
down vote
up vote
1
down vote
It's possible that this relates to threaded access to the preferences which should be legal. I've made the two potentially disruptive methods synchronized in today's update and hopefully this would resolve that issue.
It's possible that this relates to threaded access to the preferences which should be legal. I've made the two potentially disruptive methods synchronized in today's update and hopefully this would resolve that issue.
answered May 12 '17 at 4:05
Shai Almog
39.3k52553
39.3k52553
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
|
show 5 more comments
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
I didn't notice any change
– Jérémy MARQUER
May 15 '17 at 13:06
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
Then I doubt it's a race condition
– Shai Almog
May 16 '17 at 5:14
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
I didn't find the commit in github containing your modification. Could you give me the link ?
– Jérémy MARQUER
May 16 '17 at 8:12
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
It seems git lost my changes F*CK!!! I'm trying to get a sense of what else I committed that was lost and see no record of several different changes!
– Shai Almog
May 17 '17 at 5:48
1
1
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
Destroy is a very problematic method. You should avoid it whenever possible. We considered not including it at all when we initially created the lifecycle mapping and that might have been a better choice...
– Shai Almog
Jun 24 '17 at 4:30
|
show 5 more comments
up vote
0
down vote
In my case, I copied a working project to start a new one. And I left the file
keystore.jks
(keystore to upload to Google Play) empty, so when I compiled I got this exception.
I just removed the signingConfig line in android/buildTypes
section in the application level build.gradle
, and it worked.
May be you had a problem of this kind, an empty forgotten file that shouldnt be empty.
add a comment |
up vote
0
down vote
In my case, I copied a working project to start a new one. And I left the file
keystore.jks
(keystore to upload to Google Play) empty, so when I compiled I got this exception.
I just removed the signingConfig line in android/buildTypes
section in the application level build.gradle
, and it worked.
May be you had a problem of this kind, an empty forgotten file that shouldnt be empty.
add a comment |
up vote
0
down vote
up vote
0
down vote
In my case, I copied a working project to start a new one. And I left the file
keystore.jks
(keystore to upload to Google Play) empty, so when I compiled I got this exception.
I just removed the signingConfig line in android/buildTypes
section in the application level build.gradle
, and it worked.
May be you had a problem of this kind, an empty forgotten file that shouldnt be empty.
In my case, I copied a working project to start a new one. And I left the file
keystore.jks
(keystore to upload to Google Play) empty, so when I compiled I got this exception.
I just removed the signingConfig line in android/buildTypes
section in the application level build.gradle
, and it worked.
May be you had a problem of this kind, an empty forgotten file that shouldnt be empty.
edited Nov 11 at 16:37
answered Sep 7 at 17:14
Tincho825
33027
33027
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f43786254%2feofexception-when-restarting-my-app-on-android%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It looks like you placed an object into preferences that implemented externalizable incorrectly is that possible?
– Shai Almog
May 5 '17 at 4:01
No, I've only primitive types in preferences. I've an object that implement externalizable, but it's placed in another file and it seems correct
– Jérémy MARQUER
May 5 '17 at 7:50
Did you do something else like encrypted storage or anything? Did you write to the cn1preferences file? Did you change the path of the preferences file?
– Shai Almog
May 6 '17 at 5:32
I manually encrypted some String in the preferences file (with my own algorithm AES). Yes I write to the CN1Preferences file and didn't change the path
– Jérémy MARQUER
May 9 '17 at 8:53
I read comments of this article : codenameone.com/blog/preferences-location-popup-order.html It seems that Peng encountered same behavior. One difference is I don't use at all EncryptedStorage...
– Jérémy MARQUER
May 9 '17 at 12:22