Reeder prépare l'après-Google Reader [MàJ]

Nicolas Furno |
Google arrêtera Reader son service dédié à la lecture et la synchronisation des flux RSS au premier juillet 2013. Tous les logiciels de lecture de flux basés sur ce service doivent ainsi trouver une solution pour ne pas disparaître à cette date et Reeder [1.2 – US – 4,49 € – Silvio Rizzi] fait partie de ceux-ci. Son éditeur avait déjà annoncé qu’il ne comptait pas abandonner son logiciel, on en sait un petit peu plus sur son avenir.

Depuis sa dernière mise à jour, Reeder [3.0.6 – US – 2,69 € – Silvio Rizzi] dédié aux iPhone et iPod touch gère Fever, un service concurrent de Google Reader qui a la particularité d’être hébergé sur votre serveur. Vous restez ainsi maître de vos données, mais cette solution payante (30 $) nécessite quelques connaissances techniques et il faut payer un hébergeur ou mettre en place son propre serveur. Reste que les versions OS X et iPad du logiciel prendront elles aussi en charge cette fonction à l’occasion de la prochaine mise à jour.

Pour les utilisateurs qui ne veulent pas s’ennuyer avec des problèmes techniques, Reeder va aussi gérer un autre service concurrent de Google Reader et qui fonctionne sans aucun prérequis technique : Feedbin. Ce service est très récent, puisqu’il a ouvert deux jours seulement avant l’annonce de la fermeture de Google Reader, il y a un petit peu plus de deux semaines donc. Une ouverture récente qui explique certains problèmes de jeunesse dans la version actuelle, mais ce lecteur de flux fonctionne déjà assez bien et son interface minimaliste est agréable à utiliser, sur un ordinateur comme sur un smartphone.



Le point fort de Feedbin, c’est aussi la présence d’une API qui permet à n’importe quel développeur d’accéder aux données depuis son application. C’est justement cette possibilité qui a manifestement séduit le développeur de Reeder : adapter son logiciel à ce service était sans doute assez simple. Reste un problème de taille pour les utilisateurs : ce service est payant, à hauteur de 2 $ par mois.

Ce n’est pas énorme, certes, mais ce tarif risque de décourager de nombreux utilisateurs du logiciel. Espérons que d’ici la fin de Google Reader, son concepteur annonce l’intégration d’un autre service gratuit, comme le populaire Feedly.

[MàJ 28/03/2013@16h33] : on s'en doutait, mais c'est mieux quand c'est officiel. Reeder ne va pas gérer que ce service payant, mais l'utilisateur aura au contraire le choix, comme l'explique son développeur sur Twitter. Dans le lot, on imagine que des services gratuits seront proposés.
avatar SonnicProject | 
J'ai découvert FEEDLY suite à l'annonce de la fin de google reader ! Avant j'utilisé REEDER ... Franchement feedly a un coté cool qui me pouse a y allé plus souvent en plus c'est gratuit
avatar graloof | 
C'est un peu décourageant quand même, je veux pas faire le radin pour le prix que m'a coûté la version iPad. Il serait pas plus simple d'héberger la liste des flux sur iCloud et/ou Dropbox, plutôt que de s'enregistrer sur autre site, qui plus est propose déjà une appli dans le cas de Feedly?
avatar LossId | 
Et quand est il de Selfoss ou Leed, pourquoi les app ne peuvent elles pas se connecter à ce genre d'outils ?
avatar USB09 | 
Il n'y a pas moyen d'utiliser Drobox ou encore iCloud ? Beaucoup d'application le font.
avatar USB09 | 
Pu en côté récupérer les signet de safari.
avatar oomu | 
@graloof [28/03/2013 12:09] "C'est un peu décourageant quand même, je veux pas faire le radin pour le prix que m'a coûté la version iPad. Il serait pas plus simple d'héberger la liste des flux sur iCloud et/ou Dropbox, plutôt que de s'enregistrer sur autre site, qui plus est propose déjà une appli dans le cas de Feedly?" si vous utilisiez icloud ou dropbox pour cela, les performances seraient abominables et les bugs légions. Dropbox pense FICHIER ! c'est à dire un tas d'octet linéaire pour par exemple une image jpeg ou un document pdf écrit en une fois. pour votre logiciel de RSS, il s'agit pas simplement de copier les fichiers "rss" et dormir dessus. Il s'agit de maintenir une base de donnée stockant ce que vous avez lu, quel dernier appareil a lu (pour transmettre aux autre le nouvel état de l'article) etc etc. Bref de la synchro de BASE de donnée, un fichier NON linéaire en quelque sorte. Et ça dropbox est notoirement pas adapté - Icloud a 2 FACES. (3 si on compte les services tels que messagerie que apple a mis dans le même panier) pour la "synchro", on va dire que icloud a deux aspects : - celui qui marche La synchronisation de documents tels Pages, Keynote, Images. Ici, icloud fonctionne bien, quand un document est modifié sur un appareil, icloud est notifié de la modification et fait écraser sur les autres appareils le document avec la nouvelle modification. Un tel système de transaction pour des fichiers monolithiques, ça va. Synchroniser des dossiers par contre, c'est NAON. Ce n'est PAS adapté pour un programme comme REEDER.
avatar oomu | 
- l'autre aspect celui qui NE marche PAS et que les gens hurlent à mort devant le mausolée de Steve la synchronisation de base de donnée (Core Data). Ca ne marche PAS ! Tous les dévellopeurs qui ont tenté d'utiliser l'API core data avec icloud sur ios 5 et 6 ont échoué et Apple n'a qu'une réponse : AUCUNE. ("parle à ma main" en jargon apple) On va dire que c'est presque par design que c'est absolument difficile à faire marcher. Le système doit être tolérant à la panne, l'intégrité de la base de donnée doit être maintenue absolument, faut pas rater une seule transaction, faut gérer des cas difficiles (et si l'utilisateur change de compte icloud entre le moment où il lance le programme, et quand ce dernier va provoquer une mise à jour ?) etc etc. avec des fichiers genre images, typiquement restreint en taille, enregistré d'un coup, lu rarement; ça va. Avec une base de donnée où on image des accès multiples, des accès concurrentiels (votre mac, ipad, iphone en meme temps), la sophistication du format du/DES fichiers qui constituent la base, ici Core data n'a pas pu être adapté par dessus icloud sans provoquer une tonne de bugs et sources de panne (internet n'est PAS stable, votre connexion wifi n'est PAS stable, et icloud a pas que ça a fiche de répondre VITE à votre transaction de base de donnée) bref, pas bon. Dropbox et iCloud ne sont pas adaptés à la synchronisation de base de donnée qu'ont besoin les logiciels comme Reeder. Vous pouvez vérifier que nombre de logiciels ayant besoin d'une base de donnée ont abandonné icloud ou carrément pas tenté. - Point amusant que j'ai lu récemment: y a l'axiome de Tim Cook "nous préférons utiliser nos propre technologies pour tout ce qui est fondamental à nos produits". Si votre produit a pour grande valeur ajoutée de faire de la synchro d'informations rapide, fiables et cools, mieux vaut il pas la maitriser soi même plutôt que de se reposer sur le très gentil, ouvert et transparent Apple, l'ami des développeurs ?
avatar Disia | 
Purée, mais pourquoi ne pas tout simplement proposer une gestion locale des flux ? On reste ainsi maître de ses données, sans avoir de serveur ou un paiement mensuel supplémentaire. Cela semble pourtant si évident…
avatar oomu | 
iSync était bien plus robuste car tout se passait en local (un réseau qu'on peut presque espérer fiable) entre les machines de l'utilisateur, sans serveur central lourdingue. Pourtant, il suffisait d'une simple corruption de la base isync ou d'un conflit délirant provoqué par des circonstances spécifiques (plantage du client au mauvais moment, utilisateur forçant un truc farfelu prévu par personne, programme buggué, etc) pour que s'ouvre la Porte de l'Enfer. Malgré sa relative bonne qualité, peu de développeurs ont intégré isync à leurs logiciels, car le boulot restant aux développeurs était quand même conséquent, le risque d'appel à la hotline dissuasif. Icloud n'est pas isync++. - Voilà le genre de chantier qui appartient à ios7 et os x 10.9 (je dirais même ios8 et osx10.10)
avatar oomu | 
@Disia [28/03/2013 13:27] "Purée, mais pourquoi ne pas tout simplement proposer une gestion locale des flux ? On reste ainsi maître de ses données tout en se passant d'un abonnement mensuel ou de la nécessité d'un serveur. Cela semble pourtant si évident…" je suis bien d'accord. Mais la vrai fonctionnalité de Google Reader (et donc de Reeder et consorts) c'est la synchronisation de où vous en êtes dans vos lecture quelque soit votre ordinateur/appareils/mobile utilisé à l'instant. Pas simplement le stockage de fichier xml nommé avec une extension .rss :) Cette synchronisation des états (favoris, lu, non lus, etc) qui se doit d'être rapide, automatique, transparente, ha et sans me prendre la tête à configurer un "compte", est un problème difficile. Surtout si vous le voulez "distribué" (sans serveur central) quelque soit le réseau utilisé par vos appareils (donc potentiellement la complication du NAT, Proxy, des réseaux d'entreprises). Un serveur central comme celui de Google utilisé via HTTP a facilité la vie pour tout le monde.
avatar Disia | 
@ oomu La synchronisation est effectivement importante, mais j'imagine qu'elle serait envisageable entre les versions iOS et OS X de Reeder.
avatar tgjb | 
Le serveur a aussi l'avantage de collecter les données des flux en continue... => Vous pouvez partir en weekend/vacances sans manquer un article à votre retour. Un lecteur à gestion locale ne peut que récupèrer que les X (tres souvent =10) derniers articles au moment du lancement de l'application... @+
avatar Anonyme (non vérifié) | 
Je suis entrain de dev une application android pour Feedbin, et le dev m'a dit qu'il regardait pour proposer une offre gratuite, mais je sais pas si il va vraiment le faire, à suivre ...
avatar Rigat0n | 
Ok, alors je vais commencer par râler. Ça fait chier. Honnêtement, je vois pas quoi dire d'autre. Quand j'ai lu l'article je me suis dit que le gars de Reeder avait trouvé un moyen, soit avec iCloud, Dropbox, ou Feedly, de se relever de l'abandon de Google Reader. Au lieu de ça, deux solutions pas gratuites, dont une à installer sur son serveur. Super. Je me suis acheté les 3 versions de Reeder au prix fort, je trouve ça assez pénible de voir que pour le moment je vais être obligé de repayer OBLIGATOIREMENT pour ne serait-ce qu'utiliser l'application. La priorité pour moi aurait été la sauvegarde des fluxs en local, pas l'ajout de deux services payants peu utilisés... Bon maintenant, passons à la partie plus compréhensive. Ok, la vie de ce développeur a sans doute pas été rendue facile par l'abandon de Google Reader et les merdes répétées de Core Data dans iCloud, et il essaie probablement de faire ce qui est le mieux pour son logiciel. Espérons juste qu'il trouvera de meilleures solutions d'ici juillet. @ oomu : Tweetbot parvient à synchroniser parfaitement les tweets et mentions lues/non lues entre deux appareils via iCloud. Je vois pas trop pourquoi Reeder pourrait pas faire exactement la même chose. Je suis ouvert à une explication, si tu en as une.
avatar ferretphilippe | 
Hello ! Je déplore beaucoup de ne plus pouvoir IMPRIMER directement à partir de l'interface de Reeder. Avez-vous aussi ce problème chez-vous ou bien est-ce ma config qui cloche (imprimante Epson ?) Merci par avance de votre retour
avatar pat3 | 
J'ai jamais compris comment on pouvait mettre sept euros dans un client RSS, e je me félicite de ma réticence. J'avais découvert et commencé à utiliser Feedly quelques semaines avant l'annonce de Google, et leur gestion élégante du problème, en plus de l'élégance et de l'efficacité de l'appli ont fini de me convaincre de l'utiliser en exclusivité (je jonglais auparavant entre trois applis sur iPhone, trois ou quatre sur iPad et Netnewswire sur Mac. Là c'est Feedly partout (dans le navigateur pour Mac), l'essayer, c'est l'adopter!
avatar bikoz | 
"Reste un problème de taille pour les utilisateurs : ce service est payant, à hauteur de 2 $ par mois." C'est vrai, dans un monde où tout est gratuit [mais malgré tout « à but lucratif », ce qui ne semble poser problème à personne...] ça fait tâche. C'est même super choquant ! Rassurez-moi : c'était de l'humour ?
avatar AKZ | 
Reeder avec la fonction "readability" reste quand même mille fois mieux que Feedly, qui oblige comme la majorité des lecteurs RSS à "se cogner" au final le chargement complet de la page web pour pouvoir lire un article en entier.

CONNEXION UTILISATEUR