Was benötige ich und wie am besten anfangen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Was benötige ich und wie am besten anfangen

    Hallo Liebe Community,

    folgendes Projekt würde ich gern in Angriff nehmen.

    ich beschreieb es mal an folgendem Beispiel.

    Ein Nutzer soll sich per Iphone mit einer Datenbank verbinden, die auf einem Server liegt.
    In der Datenbank sind, zb. Autos gespeichert (mit Bild, Name, PS, was weiß ich)
    Nun soll auf dem Iphone eine UITableview erscheinen, die mir pro zelle den namen des Autos und ein Bild ausgibt. (So wie bei zb der Autoscout24-App).
    Wenn ich dann auf Zelle tippe , soll ein DetailView erscheinen, welches mir weitere in der Datenbank gespeicherte Eigenschaften dieses Autos anzeigt.

    Muss ja jetzt kein Auto sein. Kann ja auch zb, Ware, Fußballspieler und und und sein.
    Was Benötige ich da auf meinem Server für Scripte bzw Datenbanken (Ich nehme mal an SQL)
    Und wie am besten Einbinden.

    Danke schon mal im vorraus,

    Gruß
    John

  • die bilder willst du wohl nicht in die DB speichern oder?

    es kommt auch drauf an ob du bestimmte suchanfragen an den server sendest und nur dafür die ergebnisse zurücklieferst oder zb die komplette db runterlädst (eben ohne bilder und sonstige resourcen).
    hängt ja auch davon ab ob sich die daten andauernd ändern etc...

  • Im Prinzip brauchst Du einen Webserver mit einem Datenbanksystem. Dafür wird gerne LAMP (bzw. MAMP oder WAMP) verwendet. Die Kommunikation mit den Clients erfolgt über HTTP(S)-Anfragen vom Client. Der server liefert Datei keine HTML-Seiten sondern XML- oder JSON-Seiten aus. Diese Kombination gibt's von vielen Providern schon als fertiges Paket auf einem (virtuellen) Server.

    Alternativ kannst Du auch Amins & Christians Objective-Cloud verwenden. Da brauchst Du Dich wahrscheinlich nicht um den Server-Betrieb zu kümmern.
    „Meine Komplikation hatte eine Komplikation.“

  • doch die Bilder sollen natürlich auch rein, entschuldigt.

    Da sich die Daten ändern und sehr groß sein können, wäre es wahrscheinlich günstiger sie auf dem Server zu lassen und nur anfrage zu schicken.

  • John1994 schrieb:

    doch die Bilder sollen natürlich auch rein, entschuldigt.

    Da sich die Daten ändern und sehr groß sein können, wäre es wahrscheinlich günstiger sie auf dem Server zu lassen und nur anfrage zu schicken.


    und warum sollen die auch in die DB?
    das ist auch nicht besonders effizient wenn diese in einem xml, json oder was auch immer mitgesendet werden weil die dann zb base64-encoded werden und dadurch größer werden als wenn du sie einfach vom server lädst (also in der antwort nur die bild-id drin steht und du diese dann direkt vom server lädst (anhand der bild-id). das hat auch den vorteil dass die suchanfrage viel schneller abläuft und du die textergebnisse schon darstellen kannst und die bilder erst nachgeladen werden (zb beim scrollen etc)

  • John1994 schrieb:

    doch die Bilder sollen natürlich auch rein

    Sowas kannst Du über Blobs oder in Postgres über den Datentyp bytea machen. Dazu musst Du Dir dann eine „Seite“ schreiben, die einen Eintrag für ein Bild ausliest und dessen Daten mit den passenden HTTP-Headern (Content-Type und Content-Length) zurück liefert.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    John1994 schrieb:

    doch die Bilder sollen natürlich auch rein

    Sowas kannst Du über Blobs oder in Postgres über den Datentyp bytea machen. Dazu musst Du Dir dann eine „Seite“ schreiben, die einen Eintrag für ein Bild ausliest und dessen Daten mit den passenden HTTP-Headern (Content-Type und Content-Length) zurück liefert.


    gibt das dann kein problem mit caches? also dass die bilder jhedesmal geladen werden anstatt aus dem cache vom gerät verwendet werden.

    dass das ganze auch performance braucht spielt in einem solchen fall wohl keine große rolle.

  • John1994 schrieb:

    ahh ok danke gut zu wissen :)

    Also geb ich dem JSON-Script die Bild-id mit, und anhand der Bild-id lade ich das jeweilige Bild. Ist das so richtig ?


    JSON ist kein script sondern das format in dem du die daten vom script (php, perl, python etc) ausgibst.

    und ja, dort gibst du einfach eine eindeutige id für die resource mit (anhand derer du dann eine url basteln kannst) oder aber die url selbst (kann von vorteil sein wenn man daten auch auf fremdservern liegen hat - erhöht aber auch die größe der JSON-data die übertragen werden muss (aber nur gering weil das JSON für die übertragung komprimiert werden sollte was wiederum recht gut funktioniert ;-))

  • gritsch schrieb:

    gibt das dann kein problem mit caches? also dass die bilder jhedesmal geladen werden anstatt aus dem cache vom gerät verwendet werden.

    Das Caching auf dem Gerät ist ja noch mal eine ganz eigene Geschichte. Natürlich kann man und sollte man auch die entsprechenden HTTP-Header dafür auch setzen. Wenn sich die Bilder nicht ändern, kann man auch eine einfache Caching-Lösung wie SDWebImage verwenden. Wenn Du die komplette Kontrolle über den Cache haben willst, kannst Du ihn Dir auch selber schreiben (beschreibe ich im neuen Buch im neuen Kapitel ;-).

    Serverseitig sollte das performance-technisch auch kein Problem sein. Aber auch da gibt es eine extrem einfache und dennoch sehr effektive Caching-Möglichkeit, für die man sich allerdings ein bisschen mit der Apache-Konfiguration auskennen muss.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    gibt das dann kein problem mit caches? also dass die bilder jhedesmal geladen werden anstatt aus dem cache vom gerät verwendet werden.

    Das Caching auf dem Gerät ist ja noch mal eine ganz eigene Geschichte. Natürlich kann man und sollte man auch die entsprechenden HTTP-Header dafür auch setzen. Wenn sich die Bilder nicht ändern, kann man auch eine einfache Caching-Lösung wie SDWebImage verwenden. Wenn Du die komplette Kontrolle über den Cache haben willst, kannst Du ihn Dir auch selber schreiben (beschreibe ich im neuen Buch im neuen Kapitel ;-).

    Serverseitig sollte das performance-technisch auch kein Problem sein. Aber auch da gibt es eine extrem einfache und dennoch sehr effektive Caching-Möglichkeit, für die man sich allerdings ein bisschen mit der Apache-Konfiguration auskennen muss.


    klar, wenn man es beachtet ist es kein problem, ich aber mal davon aus dass sehr viele das nicht beachten und somit ein mobilgerät (mit möglicherweiße schlechter verbindung) daten überflüssigerweiße immer wieder runterläd. aber dazu kenne ich mich mit den mobilgeräten auch zu wenig aus (also wieviel die daten im cache halten denn da fällts schon negativ auf wenn man plötzlich einen cache von mehreren GB hat - was mich aus dem desktop-rechner nicht stören würde ;)

  • Das werde ich nie verstehen ?(

    Nur weil ne Datenbank Blobs kann, werden die ganzen Binärdaten durch eine SQL Response gepumpt, von PHP komplett im Speicher gehandled und da dann rausgepumpt.

    Warum nicht einfach einen Link zum Bild das dann einfach als statisches File auf dem Server liegt. Warum soll man das nicht so machen wie Apple, Facebook, Instagram... Warum die Möglichkeit verbauen, die Ladelast für die Bilder einfach irgendwann mal auf x Server zu verteilen.

    Hier wurde ja aber auch immer vollmundig behauptet CoreData kann ja mit Blobs umgehen. Große Dateien sin da überhaupt kein Problem. War wohl so toll und Ressourcenschonend, das Apple sich aus Langeweile die external Storage ausgedacht hat.

    Aber gut, jeder wie er mag.

    Gruß
    Manfred
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Manfred Kreß schrieb:

    Nur weil ne Datenbank Blobs kann, werden die ganzen Binärdaten durch eine SQL Response gepumpt, von PHP komplett im Speicher gehandled und da dann rausgepumpt.

    1. Load balancing, sharding. replication
    2. Nur backup von der DB notwendig
    3. Atomar(er), insb. auch in Hinblick auf Backups/ Recovery
    4. Caching durch DB anstelle FS, dadurch u.U. kontrollierbarer

    (Aber wer PHP benutzt, für den sind diese Punkte sicher irrelevant)
    ♥C++

  • gritsch schrieb:

    macmoonshine schrieb:

    John1994 schrieb:

    doch die Bilder sollen natürlich auch rein

    Sowas kannst Du über Blobs oder in Postgres über den Datentyp bytea machen. Dazu musst Du Dir dann eine „Seite“ schreiben, die einen Eintrag für ein Bild ausliest und dessen Daten mit den passenden HTTP-Headern (Content-Type und Content-Length) zurück liefert.


    gibt das dann kein problem mit caches? also dass die bilder jhedesmal geladen werden anstatt aus dem cache vom gerät verwendet werden.

    dass das ganze auch performance braucht spielt in einem solchen fall wohl keine große rolle.


    Ich habe eine App für einen Kunden geschrieben, mit dem der Kunde seine Bestellungen in einem XT Modified Shop verwalten kann. Hier habe ich das Framework SDWebImages verwendet. Das flutscht wie sau.
    Ich bin gegen Signaturen!!!

  • Manfred Kreß schrieb:

    Das werde ich nie verstehen ?(

    Nur weil ne Datenbank Blobs kann, werden die ganzen Binärdaten durch eine SQL Response gepumpt, von PHP komplett im Speicher gehandled und da dann rausgepumpt.

    Warum nicht einfach einen Link zum Bild das dann einfach als statisches File auf dem Server liegt. Warum soll man das nicht so machen wie Apple, Facebook, Instagram... Warum die Möglichkeit verbauen, die Ladelast für die Bilder einfach irgendwann mal auf x Server zu verteilen.

    Hier wurde ja aber auch immer vollmundig behauptet CoreData kann ja mit Blobs umgehen. Große Dateien sin da überhaupt kein Problem. War wohl so toll und Ressourcenschonend, das Apple sich aus Langeweile die external Storage ausgedacht hat.

    Aber gut, jeder wie er mag.

    Gruß
    Manfred


    Genauso! :thumbsup:
    Ich bin gegen Signaturen!!!