J'ai une application qui enregistre dans un fichier les données des capteurs mais quand l'écran passe en mode paysage la sauvegarde est arrêté. Je me dis que tourner l écran fait redémarrer l'application mais c'est pas logique ?
De memoire, quand une activite change de format, son contenu est perdu. Il faut le sauvegarder. Mais je n'ai pas fait d'Android serieusement depuis quelques annees.
Je confirme.
Au changement d'orientation, Android détruit l'activité (et les fragments qu'elle contient) puis les recrée.
Il faut donc sauvegarder l'état et le restaurer.
Je te suggère de lire la documentation Android puisque tout y est expliqué => https://developer.android.com/guide/topics/resources/runtime-changes
Cela va de pair avec le cycle de vie d'une activité => https://developer.android.com/guide/components/activities/activity-lifecycle
Ps : _Pytchoun, si c'est bien le même que sur le serveur Discord "Code FR", j'attends de toi que tu n'aies pas la mentalité de consommateur qui te caractérise.
De plus, si tu es la même personne, ça doit être la 3ème fois que je te dis de lire la documentation. Elle ne te mordra pas, tu sais ;)
Coucou,
J'ai désactivé le mode paysage.
Je fais une application pour enregistrer l'accéléromètre, le gyroscope et le magnétomètre du téléphone.
Malheureusement, j'ai un problème avec la sauvegarde.
Il est sensé faire une sauvegarde toutes les 100ms accordé par mon timer cependant j'ai des grosse pertes. En vérifiant avec timestamp je vois bien que j'ai mes mesures avec un écart de 100ms plus ou moins mais certaines peuvent aller jusqu'a 50 secondes...du coup que se passe t il pendent ce temps sur le téléphone ? Aucune idée d'ou ca peut venir.
Comment est ce que tu decides qu'il est temps de prendre une mesure?
public void saveFile(){
timeStamp = timeStamp / 1000000;
String fileContents = timeStamp + ";" + (String.format("%f", accelerometerVector[0])) + ";" + (String.format("%f", accelerometerVector[1])) + ";" + (String.format("%f", accelerometerVector[2])) + ";" + acceleroAccuracy + ";" + (String.format("%f", gyroVector[0])) + ";" + (String.format("%f", gyroVector[1])) + ";" + (String.format("%f", gyroVector[2])) + ";" + gyroAccuracy + ";" + (String.format("%f", magneticVector[0])) + ";" + (String.format("%f", magneticVector[1])) + ";" + (String.format("%f", magneticVector[2])) + ";" + magnetoAccuracy + ";" + (String.format("%f", pressure)) + ";" + pressureAccuracy;
String separator = System.getProperty("line.separator");
if (fullFile == null){
fullFile = fileContents + separator;
} else {
fullFile = fullFile + fileContents + separator;
}
}
public void closeFile(){
try {
fileOutputStream = new FileOutputStream(myFile, true);
fileOutputStream.write(fullFile.getBytes());
fileOutputStream.flush();
fileOutputStream.close();
} catch (Exception e) {
e.printStackTrace();
}
//stop the timer, if it's not already null
if (timer != null) {
timer.cancel();
timer = null;
}
}
public void startTimer() {
//set a new Timer
timer = new Timer();
//initialize the TimerTask's job
initializeTimerTask();
//schedule the timer, after the first 100ms the TimerTask will run every 100ms
timer.schedule(timerTask, 100, 100);
}
public void initializeTimerTask() {
timerTask = new TimerTask() {
public void run() {
saveFile();
}
};
}
je crois avoir trouvé une erreur dans logcat mais alors pour la solution...
[1:Operation not permitted]
linux_qmi_qmux_io_wake_unlock: Err in writing wakelock=qmuxd_port_wl_0, error
Personne ne saurait ?
Comment est ce que timeatamp est obtenu?
D'apres https://developer.android.com/reference/java/util/Timer si tu as un evenement quo prend plua longtempa que prevu, ca peut mettre le timer dans les chou et provoquer une succession d'evenement a la suite. Est ce que c'est ca que tu observes?
Note que l'utilisation de l'additipn de string cause la creation de plein d'objet, ca pourrait declencher le gc prematurement et cauaer un decalage peut etre. Note que je ne fais pas assez de java quotidiennement pour etre sur de ca.
Le 02 juillet 2018 à 01:38:34 godrik a écrit :
Comment est ce que timeatamp est obtenu?D'apres https://developer.android.com/reference/java/util/Timer si tu as un evenement quo prend plua longtempa que prevu, ca peut mettre le timer dans les chou et provoquer une succession d'evenement a la suite. Est ce que c'est ca que tu observes?
Note que l'utilisation de l'additipn de string cause la creation de plein d'objet, ca pourrait declencher le gc prematurement et cauaer un decalage peut etre. Note que je ne fais pas assez de java quotidiennement pour etre sur de ca.
C'est le timestamp du sensors mais j'ai try aussi avec un timestamp au moment du timer mais comme dit ca marche avec d'autre appareils donc je comprends pas ce qu'il faut faire avec le Nexus :s
Note que tu n'as pas repondu a ma question. Comment est la distribution de timestamp apres la longue pause? Eat ce qie le timestamp du senseur est synchronose avec la date d'android?
Le 02 juillet 2018 à 05:38:54 godrik a écrit :
Note que tu n'as pas repondu a ma question. Comment est la distribution de timestamp apres la longue pause? Eat ce qie le timestamp du senseur est synchronose avec la date d'android?
Je ne sais pas.
tu ne peux pas verifier? Tu n'as pas le twelephone pour lequel ca ne marche pas sous la main?
Le 02 juillet 2018 à 17:13:46 godrik a écrit :
tu ne peux pas verifier? Tu n'as pas le twelephone pour lequel ca ne marche pas sous la main?
SI mais je vois pas comment faire. Mais le timestamp peut pas être erroné y a bien des temps d'attente importants.
Et a quoi ressemble la disrribution apres le delai?
Le 02 juillet 2018 à 22:08:28 godrik a écrit :
Et a quoi ressemble la disrribution apres le delai?
Comment ca ?
La distribution de timestamp.
Il n'y a pas 50 possibilites.
1. Le timer ne tourne pas du tout. Pour verifier ca, fout un message de debuggage dans les logs des que le timertask s'active.
2. Le timer tourne mais le temps de calcul est tres long. Soit le gc s'active, soit l'io prend beaucoup plus de temps que prevu. Tu peux savoir ca en comparant les temps au debut et a la fin du timertask. Tu peux aussi savoir ca en regardant la disribution de timestamp a la sortie. La doc indique tu devrais avoir un ratrappage dans ces cas la.
3. les timers sont a jour et ca n'est pas refletter dans le fichiers. Comparer un log au fichier te dira ca.
Ce que je comprends pas c'est qu'avec d'autre modèle de téléphone ca marche et qu'avec une appli du market ca marche bien là. Du coup je vois pas ou ca foire dans mon code...
Le GC?
Je mets mon code ici : https://pastebin.com/MpYGKV9V
J'ai ca dans logcat aussi:
07-01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 34% free, 38MB/58MB, paused 1.195ms total 87.219ms
Des trucs du genre.
log plus de chose. GC: garbage collector.
Pourquoi tu stocke tout dans fullfile?
Pourquoi ne pas ecrire directement?