COMPRESSER SES SAUVEGARDES SMSBACKUPRESTORE (ANDROID) EN C AVEC SMSCOMPRESS
s@ldon
Messages postés
140
Date d'inscription
samedi 1 novembre 2003
Statut
Membre
Dernière intervention
30 septembre 2009
-
2 mars 2011 à 16:59
LeFauve42 Messages postés 239 Date d'inscription vendredi 20 octobre 2006 Statut Membre Dernière intervention 20 avril 2009 - 15 mars 2011 à 09:33
LeFauve42 Messages postés 239 Date d'inscription vendredi 20 octobre 2006 Statut Membre Dernière intervention 20 avril 2009 - 15 mars 2011 à 09:33
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
https://codes-sources.commentcamarche.net/source/52787-compresser-ses-sauvegardes-smsbackuprestore-android-en-c-avec-smscompress
15 mars 2011 à 09:33
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.
14 mars 2011 à 20:12
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.
14 mars 2011 à 19:03
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 ?
14 mars 2011 à 12:56
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.
14 mars 2011 à 12:30
Je trouve ton code un peu long pour ce qu'il fait. En effet un parseur XML aurait pu rendre le tout plus lisible/compact, mais il y a quelques maladresses. Par exemple la fonction int chartoint(int charint). As-tu entendu parler de la fonction atoi() ?
Si vraiement tu veux prendre un char en entree, tu peux faire un truc bien plus court, genre :
int chartoint(int charint)
{
return (charint>='0' && charint<='9')?charint-'0':-1;
}
De plus les SMS ne sont pas forcement limites a 160 caracteres. Je veux dire, oui ils le sont, mais la plupart des telephones modernes sont capable si tu tapes un sms de 300 caracteres de l'envoyer en deux fois, et lors de la reception de ces deux SMSes de les recoller et le presenter a l'utilisateur comme un seul SMS (c'est le cas des telephones Android sur lesquels tournent l'excellent SMSBackupRestore dont tu parles).
J'ai du mal a comprendre ta limite a 50 SMS envoyes (SEND_SMS). Je ne vois pas exactement a quoi elle correspond, mais on peut rapidement avoir plus de 50 SMS dans un telephone (meme pour un seul contact).
Je n'ai pas tout lu en detail, mais encore un dernier probleme :
Ta fonction int cmp_b(const char *s1, const char *s2, int sizechar) me parrait bien compliquee pour un simple strncmp (et en plus, elle ne fonctionne pas si les deux chaines ont plus de sizechar caracteres identiques).
De plus tu parles de corriger un bug de la fonction strncmp... Je serais curieux de savoir quel bug tu as trouve dans une fonction codee pour la premiere fois il y a 40 ans et qui n'aurait pas ete corrige depuis.
Eric
2 mars 2011 à 16:59
Une bonne partie de ton code aurait pu être simplifiée en utilisant un parseur XML. Non ?