Reprise du message précédent :
J'aimerai bien trouver du temps, mais c'est pas encore ça, peut être qu'à partir de septembre ça ira mieux

/* Alerte */

Bon, je commence à mieux gérer VS du coup j'ai passé plus de temps à regarder le code et à analyser la logique de l'app
J'ai pu regarder de plus près ce que je pensais être un soucis d'identification, en fait c'est un peu plus complexe que ça

Déjà il y avait un bug qui faisait que la BDD sqlite qui gère les comptes était jamais initialisée.

Ensuite il y a un soucis de logique ou de conception sur ce qui se passe au lancement de l'app :

Au premier lancement : BDD - cookie
Chargement de l'app, pas de bdd, pas de compte > écran de login > le forum valide les identifiants (le cookie est enregistré) > chargement/affichage des flags (la bdd est créé et mise à jour avec les infos).
Résultat :

Deuxième lancement : BDD - cookie
Chargement de l'app, bdd ok, compte ok > donc pas d'écran de login mais l'appli lance quand même une identification sur le forum (!) Problème comme le cookie est déjà là, le forum retourne une erreur > l'app considère qu'on est pas identifié > aucun affichage des flags.
Résultat :

(avant le dernier test je vais supprimer manuellement le cookie)

Troisème lancement : BDD - cookie
Chargement de l'app, bdd ok, compte ok > donc pas d'écran de login mais l'appli lance quand même une identification sur le forum (!) Mais cette fois comme le cookie n'est plus là, tout est bon pour le forum > l'app considère qu'on est identifié > chargement/affichage des flags.
Résultat :

Le problème vient du fait que l'appli va tenter de s'identifier sur le forum quoi qu'il arrive, perso sur HFR+ je fais ça de manière "optimiste" (comme disent les ricains ) : une fois que la personne est identifiée une première fois, je considère qu'elle le reste tant que le forum ne me retourne pas un message m'indiquant le contraire (par exemple sur la page des MP: "Désolé, vous ne faites pas partie des membres ayant accès à cette catégorie" et sur les flags "Aucun sujet que vous avez lu n'est connu", bon faut pas se baser sur le texte en lui-même mais sur le fait qu'il affiche un message d'erreur)

Donc je charge les flags quoi qu'il arrive au lancement de l'app, et redirection vers l'écran de login/identification seulement s'il y a autre chose qu'une liste de topic sur la page en question.
(si je teste en retournant toujours "true" sur la méthode qui gère l'identification > plus de soucis, sauf évidemment si tu rentres pas le bon mot de passe, là t'es baisé   )

Enfin, concernant la gestion multi-compte, j'ai l'impression qu'il manque pas grand chose pour que ça marche :
- faudrait enregistrer la chaine du cookie directement dans la BDD pour la réutiliser à la volée.
- si possible trouver un moyen d'enregistrer le MDP de manière sécurisée (là c'est en clair, gloops)
- s'assurer que toutes les requetes utilisent bien le cookie qu'on passe en paramètre et pas celui qui est enregistré sur le disque dur, parce que en l'état j'ai l'impression que ça sert à rien, si je commente la ligne ça marche aussi (il utilise le cookie dispo dans <user>\AppData\...)

Une fois qu'on aura réglé ces soucis je pense que l'appli fonctionnera au poil, manquera plus qu'à terminer l'interface et la navigation.

/* Fin de l'alerte */

Je m'y mettrais bien aussi sur l'appli si vous avez besoin d'un dev' supplémentaire
 
Je m'en sers quotidiennement en l'état de cette appli. La base est bonne et je pense quelle mérite d'être terminée

thefolken: merci pour le retour
2 choses:
1. sqlite ne fonctionnait pas encore sur Windows Universal au moment où j'ai commencé le dev de l'app donc effectivement j'ai fait ça à l'aveugle et j'ai fini par mettre en pause cette partie. Maintenant sqlite fonctionne donc si tu veux terminer l'implem feel free
2. les cookie ne sont pas sérializable en WinRT, faut donc le sérialiser soi même, si tu sais faire (ça doit pas être compliqué mais groooosse flemme), fais le aussi. Du coup en l'état, l'app perds son cookie dès que la RAM est vidée, vu qu'elle n'est conservée qu'en RAM.

Cool!
On va avoir une belle team !

 
Pour SQlite je me suit dis qu'il devait y avoir une histoire comme ça mais après avoir posté mon pavé du coup flemme d'éditer
 
Après pour le multi compte est-ce qu'il serait pas plus simple d'avoir une gestion comme le font les Firefox ou chrome, différents répertoires et un paramètre au lancement de l'app pour savoir quel profil utiliser, ça permet d'avoir plusieurs profils utilisés en même temps, différents raccourcis dans la barre des tâches etc. et en interne ça doit être plus simple à gérer. Faudrait simplement pouvoir contrôler le répertoire dans lequel il va stocker/chercher les différents cookies, je vais regarder la doc.
 
Et ça réglerait le deuxième point, on aurait plus du tout à s'occuper des cookies dans le code.

Ce serait bien qu'on puisse changer a chaud de comptes, donc avoir un AccountProvider qui possede un CurrentAccount, et tous les comptes dans une Liste
t'as matte AccountAmanger.cs?
le code est crappy mais je crois que y'a ce qu'on veut dedans, a peu pres

Sur fx/chrome tu peux changer à chaud, sauf que ça t'ouvres une autre instance de l'appli, et tu peux du coup utiliser les deux en même temps.

Enfin faudrait trouver quelqu'un qui utilise régulièrement plusieurs comptes pour cerner le besoin.

Perso le seul multi que j'ai, je l'utilise pour faire des tests pour l'appli iOS et j'utilise un deuxième navigateur pour m'identifier avec.

Là ça ressemble plus à la solution Gmail où quand tu as configuré plusieurs comptes, sur chaque mail il te file une liste de tous tes comptes et tu peux changer à la volée. C'est une feature pro-Troll ça

C'est en effet une feature pro troll XD

Est-ce que le multi ne peut pas être comblé (au moins au départ) par les multi sessions de Windows (c'est comme ça que je fait avec la T100 de ma femme, ça se passe très bien )

Comment ça se passe en pratique ?

Tu as 2 sessions Windows, complétement indépendantes. Le truc classique quoi. Ton appli gère l'identification, c'est Windows qui stocke dans le profil utilisateur Windows (il y a une histoire d'IsolatedStorage)

Tu utilises le "Run As" de Windows ou faut que l'application gère le truc? Tu t'en sers avec quoi comme soft ?

Ah bah grosso modo si j'ai tapé dans les bons fichiers de sauvegarde, oui, une session utilisateur = une session HFR

Pour le fichier SQLite tu fais un appel système pour chopper le bon répertoire donc là c'est OK. Pour les cookies utilisé par httpclient (plus certain du nom) là c'est un répertoire standard donc si jamais on peut lui spécifier un répertoire custom ça serait l'idéal, un répertoire par "multi" et à chaque requête on spécifie le bon répertoire.

tu te sens de le faire? Je suppose que tu l'as déjà fait dans les autres apps

Si on peut utiliser les variables d'environnement, ça devrait être bon.

Le soucis c'est que j'ai pas l'impression qu'on puisse lui dire de les stocker où on veut... Mais comme je galère pas mal avec la doc    
 
Sur iOS j'ai jamais géré quoi que ce soit par rapport aux cookies, et pas de multi compte donc c'était plus simple
 
Là je sens déjà que c'est une source à emmerdes.

La BDD SQLite perso je la met dans le localfolder d'une application. Question déterminante : peut on sérialiser le cookie d'un compte dans une (grande) string ?
Si oui alors c'est trivial

C'est cool en tous cas que des devs s'intéressent au projet! C'est très motivant et ça me redonne moi même envie de toucher à ce code:-)

Je viens de regarder apparement on peut serialiser le cookieContainer et donc le stocker dans la bdd. Je vais regarder ça ce soir.
 
Sinon question moins technique, tu penses que ça serait pas plus propre de repartir sur un projet from scratch quand le SDK RTM sera dispo ? Quitte à récupérer du code au cas par cas  évidemment (parsing etc.). Là c'est le projet WP8 que tu as mis à jour ou bien t'étais déjà reparti de 0 ?

le localfolder, c'est lié au compte, donc c'est bon pour le multi compte via les multi sessions Windows. Pour le cookie, je ne vois pas pourquoi on ne pourrait pas le sérialiser dans un string quelle que soit sa taille.

Oui, dès que j'ai Windows 10 sur ma machine perso (j'attends la livraison par voie officielle) et que j'ai un SSD, j'installe VS2015 (c'est bien celui là qu'il faut ?)

Bon, résultats du soir :

- sérialisation des infos du cookie  
- sauvegarde en base  
- récupération puis injection dans les requêtes GET

Seul soucis à chaque fois qu'on fait un GET il va remettre un cookie.txt dans le répertoire de l'app et ce cookie sur le disque à la priorité par rapport à celui que je spécifie dans la requête...

Deux solutions: soit on trouve un moyen de supprimer le cookie du disque après chaque requête, soit on arrive a faire comprendre à la lib qu'elle ne doit pas en tenir compte.

- Suppression du cookie enregistré sur le HDD après chaque requête  

Bilan: changement à la main de la bdd = changement de compte sans avoir à s'identifier une nouvelle fois (la méthode qui s'en occupe est shuntée, et j'ai invalidé les MDP dans les BDD histoire d'être sûr   )

Maintenant je vais aller m'acheter un bouquin C#/.net/VS, là c'est tendu

C'est bon ca
Perso je m'en cogne j'ai pasde multi mais c'est interessant pour les autres  
 
Vivement les news en terme de fonctions et design

 
Ouai ouai le "c'est pas pour moi c'est pour un ami" on connait    

Excellent! Tu gères thefolken
 
Sinon, non on repartira pas from scratch. Le code est bien orienté W10 ici, et hormis 3/4 APIs qui ont changé depuis le premier SDK W10, la RTM sera à peu près pareille.

l'appli sera Windows 10 only ou 8.1 en plus ?
 
Il faut VS2015 ou 2013 suffit ?

 
Si sdk 10 ca sera w10 only

Concrètement ça n'aurait aucun intérêt en plus non?

Sur mobile il y a déjà une app qui fonctionne sur 8 donc les éventuels appareils qui n'auront pas la maj (soit pas éligible, soit opérateur reloud) seront pas laissé à l'abandon.
Et sur desktop/tablette tout le monde va passer sur 10.
Le seul cas problématique ce sont les gens qui ont des tablettes sous Windows RT, mais bon, ils l'ont bien cherché  

@Constell yep, je demandais surtout ça par rapport à du code éventuel qui trainerait depuis W8 mais si j'ai bien compris t'étais déjà reparti de 0 à l'arrivée de 10 donc effectivement ça devrait le faire.

 
Et encore sur Windows rt la version actuelle du store fonctionne  
 
A mon sens ajd et sur un "nouveau" projet faut partir sur du 10

 
Franchement, ça m'arrange, mais bon, c'est pas moi qui décide

T'es dans quel scénario ? Tu as une machine pro qui ne va pas passer sous 10 ?

ça m'arrange que ce soit Windows 10 only, pardon si j'ai pas été clair. Ma machine pro qui ne passera pas en Windows 10 de suite, de toute façon aura IE pour accéder au forum

Par contre le code du parsing des pages ce serait bien de voir si on peut le refaire.

Perso je vais regarder la xaml histoire de rendre l'appli un peu plus fonctionnelle. Pour le parsing, je serais d'avis de se garder ça pour la fin (à moins qu'on soit plusieurs devs en même temps évidemment), c'est de la pure optimisation.

Voilà.
 
Aussi, faudrait se faire une roadmap:
A quoi on touche d'abord?
 
Je vote pour commencer par faire un support de:
- liste des drapeaux
- affichage correct des topics (parsing html + css)
 
puis
- envoyer un message
- fonctionnalités par rapport à un post : citer
 
Ce sera déjà une bonne base.
Qu'en pensez vous?

Pour le design et les fonctionnalites y'avait eu pas mal de discussion et proposition sur le topic

Bon le SDK RTM oukilé ?
 
Ils disent de regarder ici : https://dev.windows.com/en-us/downloads mais faut avoir un compte (payant) donc
 
@Constell, sur la version actuelle il y a une version basique pour répondre ou pas du tout? (je suis pas allé plus loin que le chargement des flags )

Tu peux répondre