Konzeptfrage

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

  • Konzeptfrage

    Hallo,
    ich habe ein Uralt Projekt (iOS 5) rausgekramt, was ich komplett auf Swift neu schreiben will. Hierfür habe ich aber eine Konzeptfrage und finde keine Lösung: Mit der App soll man Elemente buchen können (egal welche). Diese Elemente sind auf einem Plan jeweils als View dargestellt. Nun kann ich auswählen "3 Stunden buchen" und es wird eingetragen. Wenn die Zeit aber abgelaufen ist soll sich der View rot färben. Wie macht man das am schönsten?

    Es sind so in etwa 200 Elemente welchen den ganzen Tag für verschiedene Zeiten gebucht werden. Derzeit mach ich das mit Notifications und verhindere das Anzeigen dieser. Dies ist aber nicht besonders elegant. Gibt es noch eine schönere Lösung?

    Viele Grüße und Danke
    Nils
  • Hallo Nils,

    Wenn Du nicht wirklich ein Ereignis triggern musst, würde ein Umfärben der Subviews doch auch bei Anzeige reichen ... selbst wenn die Zeit schon lange verstrichen ist.

    Ich würde einfach bei Anzeiger der View die Ablaufzeiten kontrollieren und ggfs. rot einfärben. Dann noch einen NSTimer, der die View (solange sie angezeigt wird) aktualisiert. Dieser wird bei Wechsel in den Hintergrund deaktiviert.

    Oder habe ich Dich missverstanden?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Hallo Mattes,

    danke für deine Antwort! Ich glaub ich muss ein wenig konkreter werden. Bei einem Timer hab ich bedenken, dass das zu viele werden. Also:
    Wir gehen jetzt mal davon aus ich habe 200 Sonnenliegen. Die vermiete ich angenommen 1h,3h und ganztägig. Die Vermietungen werden jetzt mittels eines iPads verwaltet. Für jede Liege existiert ein SubView. Jemand bucht die Liege angenommen für 3h. Wenn jetzt die 3h abgelaufen sind soll der View sofort rot werden und ein Timer sich starten, der anzeigt wie lange die Mietdauer bereits überschritten ist. Wenn die Liege vorher frei ist soll das ganze natürlich nicht geschehen. Zwischendurch kann es auch passieren, dass die App mal kurz in den Hintergrund geht.

    Wenn ich jetzt aber unter Umständen 200 Timer laufen lasse und dann jeweils danach eine Aktion ausführe, wird die App da nicht ein wenig langsam? Es können auch mal 500 Liegen sein. Davon sind dann vlt. 300 vermietet und mit 200 "arbeitet" man. Immer wenn ich Timer höre dann schwirrt in meinem Kopf so Thread Blocking und so.

    Viele Grüße
    Nils
  • Wiesoe nicht einfach ein Thread der einmal pro Sekunde gestartet wird und alle 500 Leigen checkt und entsprechend die Views einfärbt. Wenn 1s nicht performant genug ist (Kann man ja ausprobieren) kannst Du ja auch auf 10s gehen. Denke so genau muss er der Benutzer nun auch wieder nicht wissen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • was heißt wird mit einem ipad verwaltet?

    es gibt den Sonnenliegenverleiher der hat EIN ipad zu dem gehen die kunden und der trägt die Zeiten/buchungen ein
    oder hat jeder Kunde die App auf seinem iPhone/iPad und jeder kann sich selber ne Liege buchen?

    im ersten fall kannst du doch einfach ein Refresh button einfügen der das einmal alles aktualisiert
    jede Sekunde da Alarm zu machen empfinde ich zum einen etwas übertrieben weil wahrscheinlich zum Großteil keine Änderung passiert, (das vielleicht auch schön am Akku saugt?!?)
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • nussratte schrieb:


    jede Sekunde da Alarm zu machen empfinde ich zum einen etwas übertrieben weil wahrscheinlich zum Großteil keine Änderung passiert, (das vielleicht auch schön am Akku saugt?!?)
    Von einem Alarm war hier doch gar nicht die Rede, sondern von einem NSTimer (nicht NSNotification), der zyklisch eine Methode zum Refresh aufruft. Einmal z. B. ein Array durchlaufen, um Zeitüberschreitungen / Restzeiten zu berechnen, dürfte selbst im Sekundentakt piece of cake sein ... wobei ich - wie auch @Thallius - einen gröberen Takt für Sonnenstuhlabrechnungen für vollkommen ausreichend halte :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • nussratte schrieb:

    was heißt wird mit einem ipad verwaltet?

    es gibt den Sonnenliegenverleiher der hat EIN ipad zu dem gehen die kunden und der trägt die Zeiten/buchungen ein
    oder hat jeder Kunde die App auf seinem iPhone/iPad und jeder kann sich selber ne Liege buchen?

    im ersten fall kannst du doch einfach ein Refresh button einfügen der das einmal alles aktualisiert
    jede Sekunde da Alarm zu machen empfinde ich zum einen etwas übertrieben weil wahrscheinlich zum Großteil keine Änderung passiert, (das vielleicht auch schön am Akku saugt?!?)
    Also nur der Verleiher hat ein iPad. Das mit dem Refresh Button hab ich ihm vorgeschlagen. Kommt nicht in frage, da er jetzt schließlich eine App hat und die soll alles automatisch machen.

    Akku spielt für ihn keine Rolle. Seine iPads sind 24/7 am Strom.
  • Ich würde mir überlegen, ob ich zwei Timer nutze:

    Timer 1: Man weiß ja, wann die nächste Leihgabe abläuft. Auf diesen würde ich den ersten Timer stellen und danach auf den oder die nächsten, der abläuft. Usw.

    Timer 2: Für alle abgelaufenen Leihgaben: Timer 2 aktualisiert minütlich die Verspätung. Hier machen ja nur Stunden-/Minutenangaben sinn, darum minütlich.
  • manoh schrieb:

    Ich würde mir überlegen, ob ich zwei Timer nutze:

    Timer 1: Man weiß ja, wann die nächste Leihgabe abläuft. Auf diesen würde ich den ersten Timer stellen und danach auf den oder die nächsten, der abläuft. Usw.

    Timer 2: Für alle abgelaufenen Leihgaben: Timer 2 aktualisiert minütlich die Verspätung. Hier machen ja nur Stunden-/Minutenangaben sinn, darum minütlich.

    Resourcen technisch sicherlich ein schöner Weg aber ich finde ihn sehr fehleranfällig und kompliziert zu implementieren. Was ist wenn Kunde A um 15:00 eine Liege für 3h Bucht und Kunde B um 15.30 eine Liege für 1h? Dann ändert sich plötzlich der zuerst ablaufende Timer und du mußt den laufenden Timer umsetzen.... Viel Aufwand nur um das zyklische Abfragen der Stati zu verhindern. Würde ich nicht machen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    manoh schrieb:

    Ich würde mir überlegen, ob ich zwei Timer nutze:

    Timer 1: Man weiß ja, wann die nächste Leihgabe abläuft. Auf diesen würde ich den ersten Timer stellen und danach auf den oder die nächsten, der abläuft. Usw.

    Timer 2: Für alle abgelaufenen Leihgaben: Timer 2 aktualisiert minütlich die Verspätung. Hier machen ja nur Stunden-/Minutenangaben sinn, darum minütlich.
    Resourcen technisch sicherlich ein schöner Weg aber ich finde ihn sehr fehleranfällig und kompliziert zu implementieren. Was ist wenn Kunde A um 15:00 eine Liege für 3h Bucht und Kunde B um 15.30 eine Liege für 1h? Dann ändert sich plötzlich der zuerst ablaufende Timer und du mußt den laufenden Timer umsetzen.... Viel Aufwand nur um das zyklische Abfragen der Stati zu verhindern. Würde ich nicht machen.
    Die o.a. Lösung über einen Timer hört sich wirklich sehr kompliziert an. Daher würde ich für jede Liege bzw. jede Mietdauer einen Liege einen eigenen Timer starten. Den kann man ja löschen, wenn die Liege vorher zurückgegeben wird.

    Evtl. wäre ja auch eine User Notification sinnvoll. Dann weiß der Vermieter auch gleich, wenn die Mietdauer einer Liege überschritten wurde.
  • Naja, so kompliziert ist das wohl auch nicht. Vermutlich funktioniert GDC sowieso genau auf diese Art und Weise, dass es eine sortierte Liste mit Timers gibt... Somit muss das ohnehin nicht selber programmieren werden und man verwendet für jede Leihgabe einen Timer einfach.

    Für die Leihgaben, die die schon überschritten sind, verwendet man einen gemeinsamen Timer, der angemessen eingestellt ist.