COMPRESSER SES SAUVEGARDES SMSBACKUPRESTORE (ANDROID) EN C AVEC SMSCOMPRESS

Signaler
Messages postés
140
Date d'inscription
samedi 1 novembre 2003
Statut
Membre
Dernière intervention
30 septembre 2009
-
Messages postés
239
Date d'inscription
vendredi 20 octobre 2006
Statut
Membre
Dernière intervention
20 avril 2009
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/52787-compresser-ses-sauvegardes-smsbackuprestore-android-en-c-avec-smscompress

Messages postés
239
Date d'inscription
vendredi 20 octobre 2006
Statut
Membre
Dernière intervention
20 avril 2009

Bonjour,

Je persiste a penser que quelque chose cloche dans ton usage de strncmp (et aussi que tu devrais utiliser atoi() plutot que chartoint() :o) ).

Pour le PS1, je crois que je n'ai vraiment pas compris a quoi te sert SEND_SMS.
Pour le PS2, je vois que nous sommes d'accord.
Pour le PS3, mefies-toi: Si tu as importe des SMSes depuis ton vieux telephone via la carte SIM, et que ton vieux telephone contenait des SMSes de plus de 160 caracteres, ils vont etre recus comme plusieurs SMSes avec exactement la meme date (ca m'est arrive. J'ai corrige ca en les exportant avec SMSBackuupRestore, editant le fichier XML et en le reimportant).
Donc si tu ignores des dates deja vues, tu va perdre des bouts de message.
Messages postés
2
Date d'inscription
vendredi 4 février 2011
Statut
Membre
Dernière intervention
14 mars 2011

Bonsoir Eric,

Pour ton PS1 :
Je ne vois pas ce que tu veux dire pour SMSes. Il indique le nombre de SMS sauvegardé dans le fichier XML, pour le programme ce n'est pas utile de s'en servir dans la mesure on attend EOF. A la fin du programme le nombre d'SMS traité, donnera le nombre d'SMS max contenu (SMSes) dans le nouveau fichier XML.

Pour ton PS2 :
Dans ce cas utiliser une hypothétique taille de SMS est problématique. Il faut une taille dynamique pour le buffer.

Pour ton PS3 :
C'est une bonne remarque, mais dans le cas du programme, ça ne change rien. Il ne fait que lire les dates et pour le reste il recopie entièrement (et bêtement) ce qui est comprit entre les balises sms. Le vrai problème pourrait être si les dates contenaient des espaces, lettres ou autres, dans ce cas la fonction chartoint retournerait -1 ce qui entraînerait bien sûr la non mémorisation du SMS.

De manière général il ne mémorisera pas le SMS si :
- Il n'a pas eu confirmation que le fichier est un XML(via l'extension),
- Il n'a pas croisé la balise smses,
- Il n'a pas croisé la balise sms,
- La date est invalide ou déjà vu dans dateorder.

Thal-Lab.
Messages postés
239
Date d'inscription
vendredi 20 octobre 2006
Statut
Membre
Dernière intervention
20 avril 2009

Hum, j'ai du mal a te suivre : strncmp ne modifie aucun de ses arguments (http://en.wikipedia.org/wiki/Strncmp).
Que la fonction soit appelee dans une boucle ou pas ne change rien a ceci...

Je pense que tu as du faire une autre erreur lorsque tu as teste.

Eric

PS: Pour le nombre de SMSes, tu peux le trouver dans l'entete XML du fichier de sauvegarde si tu ne veux pas de taille dynamiques.

PS2: Si par "Telephones HTC" tu veux dire "Telephones Android", je te confirme qu'ils n'ont pas cette limitation du tout. Il est possible qu'il y ai une limite de taille de quelques kilos (j'ai jamais ecrit de SMS de plus de 4 Ko) mais ce n'est pas garanti qu'elle existe toujours... Je te conseille donc dans ce cas de considerer que le SMS peut avoir n'importe quelle taille.

PS3: J'ai remarque dans les fichiers generes par SMSBackupRestore que des fois les numeros de tels etaient inconsistants (certains avec des espaces, d'autres sans). Est-ce que tu geres ca ?
Messages postés
2
Date d'inscription
vendredi 4 février 2011
Statut
Membre
Dernière intervention
14 mars 2011

Bonjour Eric et _Jonathan,

Pourquoi ne pas avoir utilisé de parseur XML me demandez-vous ? simplement pour proposer une autre solution, serte peut-être pas parfaite, mais un autre point de vue.

C'est vrai que certains mobiles peuvent envoyer des SMS plus grand que 160 caractères, mais dans mon cas, la problématique s'appliquait seulement aux téléphones HTC et je ne sais pas si eux ont cette limite. Le SEND_SMS est un nombre hypothétique de SMS maximum envoyé, pour palier à ça je pourrais aisément faire une allocation dynamique et supprimer toutes ces variables, c'est prévue prochainement ça évitera d'avoir des nombres hypothétiques.

Pour le cmp_b, je vais pas vraiment appeler ça un bug, ce mot n'était pas judicieux, je m'explique, quand tu places un strncmp dans une boucle il se produit quelque chose d'assez problématique. Exemple :
Si ton contenu est "abcdefghijkl" et que ton strncmp a tourné 5 fois dans la boucle, ta variable sera resté sur "fghijkl". Je n'ai pas vraiment trouvé de solution plus rapide que de réécrire strncmp et d'y inclure une partie de retour arrière, manque peut-être de temps et de recherche.

Merci pour vos commentaires.
Afficher les 6 commentaires