air-dex / reyn-tweets Goto Github PK

Ne pas se limiter au français.

Régler le problème d'encodage, traditionnel avec Qt.

Veiller à tout mettre en UTF-8.

Dans le Twitter Communicator, les requêtes HTTP sont gérées bizarrement 
(champ "request" initialisé dans prepareRequest(), pas de getter). Améliorer 
cette gestion.

Et si les ArgsMap étaient crées avec la méthode de sérialisation en 
sérialisant les requesters ?

Le débugger QML ne se charge pas car l'application ne serait pas paramétrée 
pour ça.

Intégrer la connexion à Twitter derrière un proxy.

Un jour, faire une fenêtre de connexion au lieu de cette page Web. Il faudra 
toutefois pouvoir récupérer le paramètre secret du formulaire.

Faut-il vraiment les virer de la map finale ?

Valable pour requestToken() et (POST)authorize(). Obligatoire pour 
accessToken() car il faut les transmettre à la configuration.

Les 2 paramètres ayant résolu l'issue 9 ont-ils leur place dans 
l'AuthenticationRequester ou dans l'OAuthRequester ?

Penser à faire le cas où finalement on n'a pas de réseau pour gagner du 
temps dans le Twitter Communicator.

Actuellement, les requêtes pour des Request Credentials d'OAuth sont gérés 
comme un cas particulier avec un booléen. Il faudrait trouver une meilleure 
gestion de ces requêtes.

Faire des tests unitaires

L'interface Web de Twitter est limitée (absence d'édition de retweets).
Sur Windows et Linux, pas de bons clients Twitter sans Adobe AIR, ce qui est 
dommage car Adobe AIR est abandonné sur Linux.
Sur Symbian et le N8, il n'y a pas de client Twitter gratuit qui soit à la 
fois stable comme TwimGo et qui puisse proposer de regarder des vieux tweets 
d'il y a plusieurs pages sur sa timeline (Different Tack) à la fois tout en 
proposant des fonctionnalités intéressantes. Sur mobile en général, on ne 
peut pas également voir tout ce qu'on voudrait à cause d'une mauvaise UX 
Internet, ce qui fait qu'on est obligé de passer à côté de certains 
contenus (vidéos dont l'abandon de Flash n'arrangera rien par exemple).

Plus de réponse aux requêtes

Est-ce la cause de la mise en variable locale de la reply ?

Dans la RTConf, l'userAccount n'est pas sérialisé.

Revoir la classe IndexBounds vis à vis du processus de sérialisation

Quand doit-on vraiment mettre les tokens en clair ? Quand un getter les demande 
? Au moment de leur utilisation seulement ?

NB : utilisation = création de l'Authorize Header pour OAuth, donc que dans 
l'OAuthManager a priori.

L'étude est en cours pendant la programmation du lancement  car il est 
important d'avoir les bons tokens au bons moments.

Voir comment intégrer la connexion des signaux du QNAM avec les slots du 
Twitter Communicator. Cela pourrait amener à une meilleure intégration des 
requêtes authorize() dans l'architecture du programme (issue 22).

Séparer le purement visuel et ce qui est dû aux erreurs dans les hautes 
couches de l'OAuth Authentication Flow, càd entre l'OAuth Process et l'OAuth 
Widget.

Actuellement, les fichiers de conf sont au format JSON, pratique pour charger 
les objets.

Un format de conf + std serait plus avisé, avec notamment l'utilisation de la 
classe QSettings.

Quid de cette fusion qui permettrait de gagner de la mémoire et de la 
simplicité dans le code ?

Les requêtes ne s'effacent pas quand elles sont finies mais tout à la fin.

Pour le voir, lancer un process OAuth dans le cadre de l'issue 36.

Etudier l'interêt d'utiliser une liste de MediaSize (et les structures 
sous-jacentes de Reyn Tweets) plutôt qu'une classe MediaSizes.

Lors du lancement de Reyn Tweets (UI de test), un crash se produit. C'est 
apparu juste après la refonte des résultats des requêtes (RequestResult).

Ceci semble être dû au ResultWrapper et au RequestResult. À voir.

Le traitement des résultats des requêtes peut commencer avant la fin de la 
requête.

Reproduction en enchaînant directement l'exécution de la requête et la 
récupération de la réponse dans son buffer.

Gérer la destruction des requêtes avec un deleteLater().

Mieux intégrer les requêtes authorize() dans l'architecture du programme.

Faire un TwitterCommunicator spécial pour l'authentification : 
AuthenticationTwitterCommunicator.

Build avec la révision 59 : Au debug, l'exe quitte avec le code -1073741819. 
Après le lancement d'un debug, il semble que cela soit dû à l'initialisation 
des Reyn Tweets Calls.

Une requête en erreur != une requête finie. Il faut donc revoir la remontée 
des réponses de Twitter dans la couche connexion.

Première idée : créer un chemin pour quand c'est OK et un autre pour quand 
ça ne l'est pas.

Après une authentification, le fichier de sauvegarde ne se met pas à jour. La 
ReynTweetsConfiguration qu'il contient est toujours aussi vide. :(

Lors de l'exécution de la requête, mieux différencier les cas ou on utilise 
les méthodes get() ou post() du QNAM. Pour l'instant, on se base sur le fait 
que la requête et en POST ou en GET mais ce n'est pas ça dans la réalité.

Mettre un timeout aux requêtes faites à Twitter

Quand l'appli se ferme avec la croix de fermeture (pas d'autre moyens pour le 
moment de toute façons), on a un message d'ereur :

Le programme s'est terminé subitement.
C:\...\ReynTweets\trunk\ReynTweets-build-desktop\debug\ReynTweets.exe a quitté 
avec le code -1073741819

Suite à la résolution de l'issue 6, est-ce bien nécessaire d'avoir deux 
entités RequestResult et RequestWrapper pour la gestion des réponses ? Idem 
pour l'attribut requester des ReynTwitterCalls.

Le lancement avec authentification est bon jusqu'au moment à la fin où ça 
plante.

Nouveau gros bug après l'issue 26 et l'issue 36 ?

Le Twitter Communicator pourrait être améliorée au niveau du browser en 
utilisant une QWebPage au lieu d'une QWebView. À voir.

Faire une classe RequesterManager qui hériterait de QMap<QUuid, 
GeneralRequester *> (pattern adapter) chargée de gérer les requesters en 
cours de requêtes. Cette classe gèrerait la recherche de requesters, leur 
ajout et leur suppression. Un RequesterManager serait présent dans les 
ReynTwitterCalls.

Ajouter un paramètre avec le message d'erreur à remonter dans la réponse. Sa 
valeur est TwitterCommunicator::reply->errorString() (ou qqch dans ce genre)

Revoir comment on sérialise les listes de ReynTweetsSerializable

Reyn Tweets plante à la fin d'un processus d'authentification avec un message 
de ce tonneau :

"Exception at 0x194ee5a, code: 0xc0000005: read access violation at: 0x0, 
flags=0x0"

Ca le fait à 2 moments :
 - Fin d'un processus.
 - Quand le processus recommence.

Au moment du linkage final (moc_*.obj pour le .exe), il y a des problèmes 
d'inclusions multiples. Tous ciblent des variables situées dans des namespaces 
(ReynTweetsSettings et TwitterRequestURL). Ci-joint le rapport de compilation.

Quelle st l'utilité de l'OAuthWidget, si ce n'est appeler l'OAuthProcess et 
transmettre les desideratas de la LoginWidget ?

De plus, un widget invisible, c'est suspect, non ?

Possibilité d'être plusMVC compliant.

L'issue 11 a révélé des problèmes concernant les inclusions multiples et 
les namespaces. Cela a été résolu a l'aide du mot clé "extern" (cf. 
commentaires).

Vérifier si ce mot ne pose pas problème lors du portage sur Symbian.

Dans le Twitter Communicator, où préparer la requête ? Dans le constructeur 
où juste avant l'exécution ?

Voir ce que dit Doxygen pour les templates (cf. l'executeRequest des 
ReynTweetsCalls).

Simplifier le code du parsage de données non JSON (typiquement les demandes de 
tokens). Peut-être factoriser dans des méthodes annexes.

Mettre l'icône dans un pseudo-squircle blanc afin d'avoir une icône carée et 
qui soit "Nokia Compliant".

Faire aussi une version "pour le développement" avec une clé et un tournevis 
en dessous.

Lorsqu'on lance plussieurs requêtes, on a à chaque fois 2x plus de retours.

Mettre des qDebug() un peu partout pour ne pas avoir à les refaire à chaque 
test de fonctionnalité.