Newsfeed Reader Konzeptionsfrage

  • Newsfeed Reader Konzeptionsfrage

    Hi,
    ich möchte einen News Feed Reader bauen. Dieser soll am Anfang Feeds aus verschiedenen Themen vorschlagen. Also man soll die Auswahl haben von Nachrichten, Technik etc. Feeds zu abonnieren, die in einer Liste einen vorgeschlagen werden. Natürlich kann man auch manuell welche hinzufügen aber für viele ist es einfacher wenn sie Vorschläge bekommen. Jetzt stellt sich die Frage wie setze ich das um? Mir kam die Idee eine Datenbank zu erstellen darin dann manuell die Feeds zu den jeweiligen Themen einzutragen. Aber das hat zwei Nachteile: 1. sehr aufwändig 2. Sprachenabhängig. Die App soll zwar erst nur in Deutsch aber wenn mehr Fragen hinzukommen schon ungünstig. Wie könnte man das besser machen? Gibt es da noch andere bessere Varianten? Kann man das irgendwo abfragen?

    Viele Grüße
    Nils

  • Naja die Sprache musst du dann ebenfalls in der Datenbank für jeden Feed (einzeln) hinterlegen und für jede unterstützte Sprache entsprechend genug Feeds in die Datenbank einfügen. Die Datenbank kannst du direkt in die App integrieren oder per Webservice verfügbar machen.

    Möglicherweise gibt es alternative Quellen (also bereits existierende News Feed Datenbanken) aber ich vermute mal du wirst deine eigene Datenbank pflegen müssen.

  • Du bist wahrscheinlich nicht der Erste, der einen Newsfeed bauen will. ;) Zu dem Feed gehört ja nicht nur die Auslieferung sondern auch die Eingabemöglichkeit, mit der Du neue Beiträge erstellst oder importierst. Es gibt sicherlich sehr viele Open-Source-Projekte für Needsfeeds im Netz, die Deine und gewiss auch viele andere Features umsetzen. Ich würde mich da zunächst mal umschauen.
    „Meine Komplikation hatte eine Komplikation.“

  • Vielleicht wäre die Einarbeitung in CoreData gut investierte Zeit ... nein, es ist keine Datenbank :D

    Zum einen skaliert Deine Anwendung besser, wenn die Zahl der Feeds wächst und auch Punkten wie "gelesene Artikel", "neue Posts", "Likes" usw. adressiert werden sollen. Zum anderen könnte eine geräteübergreifende Synchronisierung leichter werden (funktioniert das eigentlich mittlerweile zuverlässig via iCloud?).

    Feed-Vorschläge würde ich dynamisch halten und von einem Server laden. Dann kannst Du anpassen / ergänzen, und sprachenspezifische Feeds wären auch kein Problem.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • macmoonshine schrieb:

    Du bist wahrscheinlich nicht der Erste, der einen Newsfeed bauen will. ;) Zu dem Feed gehört ja nicht nur die Auslieferung sondern auch die Eingabemöglichkeit, mit der Du neue Beiträge erstellst oder importierst. Es gibt sicherlich sehr viele Open-Source-Projekte für Needsfeeds im Netz, die Deine und gewiss auch viele andere Features umsetzen. Ich würde mich da zunächst mal umschauen.

    Danke ich schaue mal!

    MyMattes schrieb:

    Vielleicht wäre die Einarbeitung in CoreData gut investierte Zeit ... nein, es ist keine Datenbank :D

    Zum einen skaliert Deine Anwendung besser, wenn die Zahl der Feeds wächst und auch Punkten wie "gelesene Artikel", "neue Posts", "Likes" usw. adressiert werden sollen. Zum anderen könnte eine geräteübergreifende Synchronisierung leichter werden (funktioniert das eigentlich mittlerweile zuverlässig via iCloud?).

    Feed-Vorschläge würde ich dynamisch halten und von einem Server laden. Dann kannst Du anpassen / ergänzen, und sprachenspezifische Feeds wären auch kein Problem.

    Mattes

    Das hatte ich so und so vor mit CoreData zu machen. Für solche Sachen geht das echt besser. Und da ich schon öfters mit CoreData gearbeitet habe ist das auch nicht zu schwer. Der iCloud Sync geht mittlerweile relativ gut. Ich nutze den schon in anderen Apps und der läuft. Bei einigen treten aber ziemlich viele Probleme auf. Je nachdem. Ist manchmal sowas wie ein Glücksspiel. Das mit den Feed Vorschlägen finde ich eine sehr gute Idee! Das mache ich! Danke!

  • gandhi schrieb:

    Ich möchte in diesen Zusammenhang zum Thema "Persistenz" eine Lanze für Serialisierung mittels NSKeyedArchiver&Co brechen. Oftmals (nicht immer, nicht jedes Problem ist ein Nagel) ist das die einfachere, schnellere und leichtere Lösung im Vergleich mit CoreData

    Da gebe ich Dir vollkommen recht, nur leider skalieren die resultierenden PLISTs nicht sehr gut bei vielen und/oder großen Daten ... dann sitzt man in einer Sackgasse und muss migrieren (BTDT). Daher mein Hinweis auf CoreData.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Nix plist. NSKeyedArchiver kann auch Binär-Dateien erzeugen. Und das skaliert gut, Objektgraphen mit mehreren 10000ende Objekte in kurzer Zeit (1sec) sind kein Problem
    Bitte nicht plists mit NSKeyedArchiver verwechseln. Ersteres kann nur bestimmte Objekte (Array, Dictionaries, Strings, Numbers, bools &Co) aufnehmen, letzteres alles.

    ciao

    gandhi

    Nachtrag: Die alten NSArchiver/NSUnarchiver waren nochmal deutlich schneller wie NSKeyedArchiver/Unarchiver. Die sind aber deprecated und man muss etwas mehr Gehirnschmalz in die Auf- und Abwärtskompatibilität von erzeugten Archiven stecken.

  • Auch die Binärdaten des NS*Archiver sind plists. Binary Property Lists, um genau zu sein.
    NS*Archiver kann auch nicht einfach stumpf mit jedem Objekt zusammenarbeiten, sondern nur mit Objekten, die das NSCoding Protokoll implementieren.

    Ja, binary plists skalieren besser als der XML Kram.
    Ist für's iOS meiner Meinung nach aber keine Alternative.

    Schließlich wird jedes mal der gesamte Objektgraph in den Speicher geladen, und wenn der Feedreader ein paar Monate gelaufen ist und ein paar Seiten abgegriffen hat, wird das irgendwann ein ziemlich großer Objektgraph.

    Core Data lädt sich seinen Kram bei Bedarf aus dem SQLite Store und ist damit wesentlich performanter.

    Nachtrag:
    Ich persönlich finde die neuen NSKeyed*Archiver wesentlich robuster und simpler in der Bedienung als die alten NS*Archiver. Vor Allem in Hinblick auf die Auf-/Abwärtskompatibilität.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Auch die Binärdaten des NS*Archiver sind plists. Binary Property Lists, um genau zu sein.

    Na dann versuch' mal so eine Datei als Property-List zu öffnen. Viel Spaß! Du hast insofern recht, als das zugrundeliegende Dateiformat identisch ist. Wobei ich mir bei der Binärvariante gar nicht so sicher bin. Müsste man mal anschauen.

    sondern nur mit Objekten, die das NSCoding Protokoll implementieren.

    Richtig. Bei CoreData muss ich von NSManagedObject ableiten. Irgendwas muss man halt für seine Persistenz tun...

    Schließlich wird jedes mal der gesamte Objektgraph in den Speicher geladen, und wenn der Feedreader ein paar Monate gelaufen ist und ein paar Seiten abgegriffen hat, wird das irgendwann ein ziemlich großer Objektgraph.


    Schon mal in der Praxis versucht? Gemessen? Ich kann Dir sagen, es passen verdammt große Objektgraphen in den Speicher von so einem kleinen iOS-Gerätchen :) Das mag für bestimmte Anwendungsfälle sicher ein Problem sein, aber bestimmt nicht für geschätzte 90% der Anwendungen, die unter iOS CoreData einsetzen.

    Nochmal: Ich hab' nix gegen CoreData, aber NSKeyedArchiver wird oft unterschätzt, erschlägt aber sehr viel Anwendungsfälle und macht dort CoreData einfach überflüssig.

    schönen Gruß

    gandhi

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von gandhi ()

  • gandhi schrieb:

    Na dann versuch' mal so eine Datei als Property-List zu öffnen.

    Habe ich bereits getan. Unter Windows. Mit C# und .Net.
    Grauenhaft. Hab mich da von NSKeyedArchiver by Cocotron inspirieren lassen.

    Im Prinzip besteht das Ganze nur aus Objekten, die PropertyList fähig sind. Lediglich die Nutzung des Protokolls erlaubt es Dir, eigene Objekte hineinzuwerfen – welche im Grundsatz dann auch aus Objekten bestehen, die PropertyList fähig sind.

    Wie dem auch sei: NSKeyed*Archiver wird nur von wenigen verstanden und ich mag ihn auch sehr gern. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P