iOS App in Planung?

    • in Arbeit

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

    • RE: iOS App in Planung?

      Klar, das wurde auch schon mehrfach gefragt. Allerdings ist die Programmierung für Mobile Systeme sehr viel aufwendiger als für Desktop Anwendungen. Dazu kommt noch das Android mit Java Programmiert wird und ich in Java schon relativ fit bin. Aber iPhone Apps werden in C# oder neuerding SWIFT Programmiert wo ich komplett bei null anfangen müsste.
      Als letzter aber nicht unwichtigster Punkt kommt noch dazu dass ich bei iOS auch nicht auf echter Hardware testen kann, was ich bei Android auch erst lernen musste das diese Tests unerlässlich sind.

      Sollte sich jemand finden derdas übernimmt kann ich das gern unterstützen, aber von mir ist da aktuell keine Chance auf eine iOS App.

      Nur noch kurz zum Versdändnis, die Android App war/ist meine erste ernsthafte Android App. Mal abgesehen von dem Buch "Android 5" vom Rheinwerk Verlag für 40€ habe ich in dieApp noch etwa 100h Zeit investiert (Entwicklung, testen, Fehler beheben ....)

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

    • Hallo,

      nach langer (beruflich und privat bedingter) Abwesenheit melde ich mich mal wieder ;)
      Zum Thema IOS App könnte ich ggf. das passende beisteuern und eine entsprechende App für die Community entwickeln. Ich würde die tatsächlich unter Swift schreiben, wenn Interesse besteht.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Nein, niemals. Aber wie gesagt, aus privaten und beruflichen Gründen konnte ich mich lange nicht mehr mit dem Thema beschäftigen. Da ich vor einiger Zeit in die Entwicklung von IOS-Apps musste/wollte würde sich das ggf. anbieten.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Das glaub ich gerne.
      Die mobile WEB-Oberfläche vom SHC ist schon ganz nett. Aber eine native App, das ist schon ein ganz anderes Look-and-Feel. Das ist auch der Grund, warum ich seinerzeit überhaupt mit der App-Entwicklung angefangen habe. Man kann zwar schon einiges mit Web-Apps machen, aber 1. war mir der Aufwand zu groß, 2. hat man grafisch doch ganz andere Möglichkeiten und 3. kann man technisch mehr realisieren (z.B. Push-Mitteilungen).
      Wenn es also eine gute Schnittstelle gibt (ich habe mir den aktuellen Stand noch nicht angeschaut) sollte eine IOS-App nicht das Problem sein.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • agent47 schrieb:

      DieterWo schrieb:

      Wenn es also eine gute Schnittstelle gibt (ich habe mir den aktuellen Stand noch nicht angeschaut) sollte eine IOS-App nicht das Problem sein.
      Welcome Back.

      Natürlich gibt es eine gute Schnittstelle. Für die Android App ist die ja auch nötig.
      Ist oder wirst du die Veröffentlichen? Wenn ja, wo und wann?

      JamesTM schrieb:

      Wenn das ähnlich läuft wie bei Embarcadero's Firemonkey, womit man auch mit Windows Delphi über den Umweg XCode IOS-App's erzeugen kann, dann würde ich darauf verzichten.
      Zumindest haben die sich wenigstens dazu entschieden, nur die Businesslogic und Model zu übernehmen. Die View muss man dann wohl unter XCode selbst erzeugen (das haben die wohl aus den gleichen Gründen weggelassen, aus denen es auch bei Embarcadero nicht so optimal läuft). Allerdings setzt der Compiler von Google auf Objective-C. Und das wo sich unter XCode gerade alle eher in Richtung Swift orientieren.
      Und wenn man die View's eh selber machen muss, dann kann ich auch gleich komplett unter XCode coden.
      Noch dazu nehme ich an (kenne allerdings das ganze Java-geraffel nicht), dass es doch einige Unterschiede bezüglich der Code-Optimierung geben wird, so dass der übersetzte Code nicht allzu optimal sein wird. Aber das ist eher eine Vermutung. Das müssen Tests zeigen, die sicherlich nicht lange auf sich warten lassen.
      Grundsätzlich wäre es schon gut, unter einer gemeinsamen Codebase compilate für die verschiedensten Plattformen zu erstellen. Dann aber sollte sich das auf die komplette Anwendung beziehen und nicht auf Logic und Model. Embarcadero hat das wenigsten gleich so gamacht, dass man mit einer Codebase Win32, Win64, OSX, IOS, Adroid und WindowsMobile Apps/Anwendungen erstellen kann. Nur Linux habe sie aus bekannten Gründen noch weggelassen. Aber vielleicht folgt das auch noch.
      Aber trotz diesen Möglichkeiten würde ich z.Zt. die Entwicklung auf den empfohlenen Plattformen einfach vorziehen, weil die Ergebnisse einfach besser sind hinsichtlich Look-and-Feel, Geschwindigkeit, Hardwarenutzung, Speicherplatzersparnis und Akkuschonung.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • agent47 schrieb:

      @DieterWo
      Die Schnittstellenbeschreibung findest zu -> hier
      Die Schnittstelle wird sich aber mit Version 3.x noch einmal ändern.
      Das ist schon ganz nett. JSON ist auf jeden Fall schon mal super. Der Zugriff sollte aber auf jeden Fall über HTTPS erfolgen, da der Zugriff auf ungesicherte Verbindungen aus einer IOS-App nur zugelassen wird, wenn man das Ziel explizit in der APP als Ausnahme für HTTP-Zugriff definiert. Und da jeder eine andere URL haben wird, wäre HTTP-Zugriff nicht zweckmäßig. (Ich hab jetzt nicht das ganze Forum durchgelesen, ob es für HTTPS-Zugriff schon entsprechende Einrichtungsanleitungen gibt).

      Ist denn das, was du in dem o.g. Post an Beispielen gepostet hast, schon die ganze Schnittstelle?
      Bzw. man müsste für die Schnittstelle eine Versionierung einführen, damit sie abwärtskompatibel bleibt, und sich die App mit einer beliebigen Schnittstellen-Version am SHC anmelden kann. Und ggf. wäre es auch sinnvoll mit Sessions zu Arbeiten. Bin jetzt zwar bei der Web-Entwicklung nicht so super aktuell, und weiß auch im Moment gar nicht, ob das noch den aktuellen Sicherheitsstandards entspricht, aber in jeder HTTPS-Abfrage User und Kennwort in der Abfrage mitzuführen würde ich jetzt auch nicht unbedingt als "sicher" empfinden. Und auch Apple lässt nicht alles in den Appstore, wenn man gegen deren Auffassung verstößt, was solche Sachen angeht. Dann könnte die App vielleicht nach der Anmeldung als Return eine Versionsnummer des SHC bekommen um sich auf die Version einzustellen (Und umgekehrt vielleicht auch). Nicht jeder hält sein SHC oder die APP immer auf dem aktuellen Stand. Und so könnte man auch Erweiterungen in der Testing leichter umsetzen, ohne von einander abhängig zu sein.

      Und, wenn ich das richtig gelesen habe ist schon jemand an der Entwicklung für Windows Mobile?
      Jetzt wären natürlich auch mal Screenshots vom aktuellen Android und WindowsMobile interessant. Dann könnte ich mich in der IOS-Entwicklung im Groben daran orientieren. Denn es wäre ja nicht schlecht, wenn alle APP's zumindest mal so ungefähr in der Bedienung ähneln (bis auf die Hersteller-Guidelines natürlich).
      Und ich habe leider nur IPhones und IPads. (evtl besorge ich mir mal ein billiges Android, aber da muss man schon wieder aufpassen, dass die aktuelle Android-Version darauf läuft).
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Die aktuelle Schnittstelle ist nur in die Anwendung herein gebastelt. Daher auch die Schwächen vor allem im Bezug auf Sicherheit. Mit Version 3 wird es unter anderem auch der neuen besseren Architektur geschuldet eine wesentlich umfangreichere und bessere Schnittstelle geben.
      Unter anderem auch die von dir angesprochene Anmeldung und Sessions. Eine Versionierung der Schnittstelle gibt es aktuell nicht, wäre aber für Version 3 zu überlegen.
    • Das hab ich mir schon fast gedacht.
      Aber ich würde die Schnittstellenversion von der SHC-Version entkoppeln. Ich weiß nicht, wie du das innerhalb des SHC implementiert hast, aber du könntest die Schnittstelle auch parallel von SHC implementieren, und somit auch einzeln updatebar machen. So dass deren Weiterentwicklung nicht zwingend an die von SHC gebunden wäre. Hätte meiner Meinung nach einige Vorteile.
      Das ganze ohne die oben aufgeführten Sicherheitsstandard zu publizieren und auch öffentlich zugänglich zu machen sollte nur mit dem ausdrücklichen Hinweis geschehen, dass ein Zugriff von Fremden nicht ausgeschlossen werden kann. Wenn ich lese, dass einzelne hier ihren Graragentorantrieb darüber steuern....
      Wie gesagt ohne HTTPS unter IOS...schwierig und bald unmöglich.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Das SHC auf HTTPs dürfte eigentlich relativ einfach Möglich sein.

      Die Version 3 wid bis auf die Sensorschnittstelle ausschlieslich auf HTTPs setzen, ich muss nur mal noch schauen wie die Umsetzungn mit dem eingebeddeten Webserver ausschaut (der ist nicht so umwerfend Dokumentiert).
      Die neuen Version wird auch generell per JSON angesprochen, auch die Clients laufen selbst über JSON zum Server.