Gerade im Umfeld von IoT/Home-Automatisierung steigt das Interesse an der App-Entwicklung für Mobilgeräte. Heute beherrschen zwei Systeme 90% des Marktes: Android und iOS. Die native Entwicklung ist mit dem aufwändigen Einrichten einer jeden Entwicklungsumgebung, "fetter" SDKs und der Kenntnis ziemlich unterschiedlicher Programmiersprachen verbunden. Android ist im Wesentlichen Java, unter iOS schreibt man in Objective C oder Swift ... Reine Webanwendungen sind zwar im Prinzip plattformübergreifend, kranken aber daran, dass man sie jedesmal erst über den Browser aufrufen muss (was ist, wenn gerdae kein Internet vorhanden ist?) und dass sie aus dem Browser heraus nur eingeschränkten Zugriff auf die Resourcen des Mobilgerätes haben. Aber sie deuten dennoch den richtigen Weg an: Programmierung mit HTML5, CSS und Javascript, alles vollkommen plattform-neutral. Einen intelligenten Kompromiss bietet (angeblich, aber dazu später), das Konzept von Cordova: Es gibt eine native "Rahmen-App", die in einem Webviewer den in den Resourcen der App hinterlegten HTML/JS-Code "abspielt" (ist also nicht auf einen externen Webserver angewiesen). Diese Rahmen-App enthält zudem Schnittstelle für die lokalen Resourcen, wie Kamera, Mikrofon, Dateisystem, SQLite usw. Sie wird individualisiert (Name, Icon), mit dem HTML/JS "geimpft" und sieht dann nach Außen aus, wie 100% nativ. Von diesem Konzept ziemlich angetan, habe ich mich also intesiver zu Apache Cordova informiert und wäre bereit, reichelich Zeit und Energie zu investieren, Projekte dafür haben wir reichlich in der Pipeline. ABER: Voller Entsetzen musste ich lesen, dass man auch für die Nutzung der Cordova-Umgebung Android Studio und XCode nebst zahlreicher Plugins installieren und konfigurieren muss. Das war wie ein Eimer kaltes Wasser ... WARUM? Gibts Alternativen zu Cordova, die aber nach dem gleichen Grundprinzip arbeiten?
Frank E. schrieb: > Gibts Alternativen zu Cordova, die aber nach dem gleichen Grundprinzip > arbeiten? Webseiten. Als "PWA" sind die auch offline nutzbar, und lassen sich am Smartphone auch "installieren", damit man nicht immer den Browser aufrufen muss.
Εrnst B. schrieb: > Frank E. schrieb: >> Gibts Alternativen zu Cordova, die aber nach dem gleichen Grundprinzip >> arbeiten? > > Webseiten. > > Als "PWA" sind die auch offline nutzbar, und lassen sich am Smartphone > auch "installieren", damit man nicht immer den Browser aufrufen muss. Ja, das ist aber nur etwas für Technophile. Der "gewöhnliche" Smartphone-User kennen nur die Appstores. Deshalb ist das Konzept von Cordova ja eigentlich schon cool, quasi eine PWA in ihren eigenen Player als native App verpacken. Der schafft es dann vermutlich auch in die Appstores, oder?
Frank E. schrieb: >> Webseiten. >> >> Als "PWA" sind die auch offline nutzbar, und lassen sich am Smartphone >> auch "installieren", damit man nicht immer den Browser aufrufen muss. > > Ja, das ist aber nur etwas für Technophile. > Der "gewöhnliche" Smartphone-User kennen nur die Appstores. Wie man eine URL aufruft, weiss doch fast jeder. Bei meiner Ü80-Mutter wäre es sogar eher anders herum: Die würde es mit ziemlicher Sicherheit alleine nicht schaffen, über den App-Store eine App zu installieren. Eine URL zu öffnen, würde sie schon eher hinbekommen. > Gibts Alternativen zu Cordova, die aber nach dem gleichen Grundprinzip > arbeiten? Evtl. könnte React Native etwas für Dich sein. Allerdings habe ich das bislang nicht wirklich selbst genutzt, gut möglich dass ich da Unsinn erzähle und das doch in eine andere Richtung geht. Um damit eine iOS-App zu entwickeln, die Du tatsächlich in Apples App-Store veröffentlichen kannst, musst Du aber glaube ich auch da einen Mac besitzen.
Du kannst aber auch mal das SpiderBasic probieren. Das baut auch auf die Cordova - Plattform auf. Findest du bei https://www.spiderbasic.com/download.php Alternativ auch B4X.com. Das ist zwar free, außer IOS, aber man muß da eine gewisse Vorarbeit leisten : Java - SDK und ANDROID - SDK installieren. B4A ist mehr VB-like und man bekommt tonnenweise Java-Libs. Macht aber native Apps. Joachim S. schrieb: > Um damit eine iOS-App zu entwickeln, die Du tatsächlich in Apples > App-Store veröffentlichen kannst, musst Du aber glaube ich auch da einen > Mac besitzen. Bei Ios ist es so, daß man jährlich 99 Dollar als Entwickler abdrücken muß.
:
Bearbeitet durch User
Heinz B. schrieb: > Bei Ios ist es so, daß man jährlich 99 Dollar als Entwickler abdrücken > muß. Wenn man einen Mac hat (hab mehrere) und dort MacOS Server aufsetzt (ist ein Zusatzpaket zur normalen MacOS-Version), enthält dieser auch ein MDM. Damit kann man im "engeren Umfeld" (Firma, Verein, Familie) auch Apps ohne Appstore ausrollen ... war jedenfalls vor 3 Jahren noch so. Bei den Android-APKs reicht m.W. ein Download, oder eine Übertragung per USB im Debug-Mode, oder?
Frank E. schrieb: > Der "gewöhnliche" Smartphone-User kennen nur die Appstores. Zumindest im Google Play Store und im Microsoft-Store kannst du auch direkt die PWA publishen. Ist dann immer noch eine "Webseite", aber im Store auffindbar. (Der Microsoft-Store geht sogar noch einen Schritt weiter, wenn Bing deine PWA "zufällig" im Internet findet, kann es sein, dass die die direkt in den Store aufnehmen) Apple erlaubt generell keine PWAs in ihrem Appstore, da muss der User zumindest einmal deine Seite im Safari aufmachen und von dort aus installieren.
Frank E. schrieb: > Bei den Android-APKs reicht m.W. ein Download, oder eine Übertragung per > USB im Debug-Mode, oder? Bei Übertragung auf eigne Smartphone reicht da wirklich USB, BT usw. Ich mache das bei B4A mit der App B4A-Bridge. Was den Playstore betrifft, sind die jetzt auch restriktiver geworden und überprüfen deine App tagelang, bis sie dir die Freigabe erteilen. So hab ich es mal jedenfalls im B4A-Forum gelesen.
Die Frage, ob native APP oder nicht,stellt sich bei gegebenem Funktionsumfang eigentlich nicht. Ich behaupte, dass die meisten nativen APPs als PWA aka Webseite mit offline Funktion gensuso funktionieren würden und die EntwicklerInnen sich den Aufwand für zwei Systeme (Apple, Android) entwickeln zu müssen hatten schenken können. Ich höre aber immer wieder, dass Kunden ein APP im store haben möchten ungeachtet, ob das notwendig ist. PWAs muss ich im Browser aufrufen und auf installieren klicken, das ist aber nicht gewünscht, auch wenn ab dann die Nutzung identisch ist. Noch ein Vorteil von PWAs ist das updaten, das ja quasi zentral gemacht wird. Also ich würde mit den Stress mit der APP und dem store nicht antun, wenn nicht unbedingt notwendig. Lieber PWA mit Svelte: https://github.com/search?q=svelte+pwa Was soll den der Funktionsumfang eurer APPs sein?
Kolja L. schrieb: > Was soll den der Funktionsumfang eurer APPs sein? Die Kunden einer lokalen (Mini-) Kette von Autowaschanlagen sollen QR-Codes (Gutscheine für Wäschen) kaufen können. Mit verschiedenen Zahlungsmethoden, z.B. Paypal, Sumup Online u.a.
Frank E. schrieb: > Kolja L. schrieb: >> Was soll den der Funktionsumfang eurer APPs sein? > > Die Kunden einer lokalen (Mini-) Kette von Autowaschanlagen sollen > QR-Codes (Gutscheine für Wäschen) kaufen können. Mit verschiedenen > Zahlungsmethoden, z.B. Paypal, Sumup Online u.a. Wenn ich für diese vglw. banale Funktionalität extra irgendeine App aus dem App-Store installieren müsste, würde ich es ehrlich gesagt lassen. Denn ich installiere grundsätzlich nur ungern Apps auf meinem Smartphone, eigentlich nur wenn es unbedingt sein muss. Klar, viele sehen das anders, aber es gibt da draussen bestimmt noch mehr Leute, denen es zuwider ist, für jeden "Quatsch" eine eigene App installieren zu müssen. Sowas ist in meinen Augen ein gutes Beispiel für etwas, das als PWA bzw. WebApp eh besser ist.
Frank E. schrieb: > Die Kunden einer lokalen (Mini-) Kette von Autowaschanlagen sollen > QR-Codes (Gutscheine für Wäschen) kaufen können. Mit verschiedenen > Zahlungsmethoden, z.B. Paypal, Sumup Online u.a. Wäre das nicht viel einfacher mit einer responsiven WebApp gelöst? Ich meine, was ist der Vorteil der Waschanlage, dafür eigens eine App zu entwickeln? Eine native App muß ja schließlich deployt, gepflegt, und gewartet werden, und wenn einer die Aktualisierung verkackt... genau. Meine Empfehlung wäre, anstelle einer App nur einen Link zu einer WebApp auf dem Startbildschirm des Smartphone abzulegen. Hat denselben Effekt -- der Kunde wird von seinem Smartfön an die Waschanlage erinnert -- und die ganzen Aufwände für Deployment, Pflege und Wartung sind minimiert. Aber wenn es unbedingt eine App sein muß, würde ich vielleicht nicht gleich zur schweren Artillerie wir Cordova oder Electron greifen, sondern eher so eine moderne Progressive Web App (PWA) ins Auge fassen... nur so ne Idee.
MICH muss man von den Vorteilen einer PWA oder einfach nur einer Website nicht mühsam überzeugen. Das Problem: Wir bewegen uns hier in "technophilen" Kreisen, für die das kein Problem darstellt. Der gewöhnliche 0815-User jedoch kennt, bzw. traut nur "richtigen" Apps. Und der Auftraggeber sieht sich nicht in der Position, seine potenziellen Kunden zu belehren ... sieht aber den Aufwand und die Kosten einer echten nativen Entwicklung. Eigentlich sollte Cordova genau dieses Problem lösen.
Da würde ich bei der Auswahl des Entwicklungstools schon darauf achten, daß man Zahlungen mit Paypal oder Sumup Online leicht implementieren kann, sei es durch interne oder externe Bibliotheken. Auch die Möglichkeit zum Erstellen eines QR-Codes sollte vorhanden sein. Wenn man da das Rad neu erfinden müßte, wird das eine schwierige Sache. Deshalb mein Vorschlag : https://www.b4x.com/ Dort kann man solche Java Libraries zusätzlich einbinden. Dort gibt es auch für fast alle Zwecke entsprechende Libs. https://www.b4x.com/android/forum/threads/b4x-online-payment-with-paypal.111261/#content https://www.b4x.com/android/forum/threads/payment-online-sumup-source-for-sale.128480/#content https://www.b4x.com/android/forum/threads/sumup-mobile-payment.39394/ https://www.b4x.com/android/forum/threads/b4x-qrgenerator-cross-platform-qr-code-generator.93092/
:
Bearbeitet durch User
Was ich noch sagen wollte : Alleine schon die Entwicklung eines QR-Codes wird eine Herausforderung sein. Da gehört dann z.b. die Bestätigung der Zahlung und die Art des Waschprogrammes rein. Zusätzlich darf der Code nur einmal gültig und auch nicht leicht zu dekodieren sein. Szenarien des Mißbrauchs gibt es da ja einige : z.b. Ich bezahle so ein Waschgang, erhalte einen QR-Code. Wenn ich diesen nun dekodieren könnte und wieder zurück verwandeln kann, könnte ich mit einer einzigen Zahlung unzählige Waschvorgänge haben, was dann eure Pleite bedeutet. Also da muß so ein Qr-Code einige versteckte Merkmale aufweisen. Da könnte ich mir vorstellen, daß man auch eine DB braucht, die das verwaltet bzw. nachsieht, ob der Code schon mal eingelöst wurde. Da gibt es bestimmt noch mehr zu beachten. Dieser Aspekt alleine bedeutet schon relativ viel Arbeit.
Frank E. schrieb: > Das Problem: Wir bewegen uns hier in "technophilen" Kreisen, für die das > kein Problem darstellt. Der gewöhnliche 0815-User jedoch kennt, bzw. > traut nur "richtigen" Apps. Wie schon oben geschrieben: Im Google Play Store kannst du auch deine PWA veröffentlichen. Ist dann ein APK in dem nicht viel mehr als die Start-URL steckt. Bleibt die Sonderlösung für iPhone. Aber die ist sowieso nötig, weil dann 30% von jeder Autowäsche, die über die App gekauft wird, an Apple gehen. Oder hat der Appstore da Sonderregel-Ausnahmen für Dienstleistungs-Verkäufe? Evtl. ist das ein Argument für den Auftragsgeber: Er macht 30% mehr Gewinn, wenn er (nur bei iPhones) auf den Appstore verzichtet, und dann eben ein paar große Plakate mit QR-Code der PWA-Url aufhängt?
Ups! Dass auch In-App-Käufe mit 30% bei Apple bleiben, hatte ich so nicht auf dem Schirm, das geht garnicht. Ich dachte, das das nur beim Kauf der App als solches passiert, ok, das ist ein sehr schwer wiegendes Argument. Guter Tip! Danke. Im Laufe der Realisierung wäre ich zwangsläufig auch selber darauf gestoßen, aber den Weg kann ich mir nun definitiv sparen. Beim QR-Code ist eine einmalige Verwendbarkeit garantiert, parallel zum Verkauf und beim Einlesen wird das mit einer Datenbank abgeglichen.
Ich schließe mich dem an: Da die Aufgabe der App nicht über die Funktionen einer Webseite hinausgehen ist es keine technische Frage. Das iOS Prozente von InApp Käufen nimmt, (macht Google das nicht auch, ab einem bestimmten Umsatz?) ist vielleicht gar nicht das größte Problem, denn Apple soll sich vorbehalten, Apps abzulehnen, deren Funktionalität nicht über ein bestimmtes Maß hinaus geht. (Finds dazu leider auf Anhieb keinen link). Argumente für PWA: - eine Version für alle (auch Desktop) - Änderungen werden zentral gemacht, keine updates auf den Endgeräten notwendig - kein zwischen-Dienstleister der am Umsatz beteiligt werden will (ZahlungD ausgenommen) - daher deutlich günstiger zu entwickeln - keine "echten" Nachteile ggü nativer App
Ups! Dass auch In-App-Käufe mit 30% bei Apple bleiben, hatte ich so nicht auf dem Schirm, das geht garnicht. Ich dachte, das das nur beim Kauf der App als solches passiert, ok, das ist ein sehr schwer wiegendes Argument. Guter Tip! Danke. Im Laufe der Realisierung wäre ich zwangsläufig auch selber darauf gestoßen, aber den Weg kann ich mir nun definitiv sparen. Beim QR-Code ist eine einmalige Verwendbarkeit garantiert, parallel zum Verkauf im Automaten/App und beim Einlesen an der Anlage wird das mit einer Datenbank abgeglichen. Zusätzlich wird eine symmetrische Verschleierung angewendet, die ist sicher nicht Hacker-fest, aber 99% der Kunden dürften damit nix anzufangen wissen. Beispiel des Inhaltes des QR-Codes: XY5Z93A0TGP0AF000000000000Z1GOPL0G Enthalten sind: - Datum 05.03.2023 - Zeit 15:42:06 - enthalten 3 Artikel/Leistungen - 1 x Artikel 10 zu 19,50€ - 1 x Artikel 20 zu 5,00€ - 1 x Artikel 21 zu 7,50€ Hier nochmal das Gleiche, nur mit anderer Uhrzeit (14:42:40) B00000000Z1GOPLA5Z93A0TGP0AF00000G Ja, man sieht welche Stellen sich verändert haben, aber sonst?
Frank E. schrieb: > Das Problem: Wir bewegen uns hier in "technophilen" Kreisen, für die das > kein Problem darstellt. Der gewöhnliche 0815-User jedoch kennt, bzw. > traut nur "richtigen" Apps. Aber der gewöhnliche 0815-User kann doch gar nicht zwischen einer PWA und einer "richtigen" App unterscheiden?
Ein T. schrieb: > Aber der gewöhnliche 0815-User kann doch gar nicht zwischen einer PWA > und einer "richtigen" App unterscheiden? Technisch nicht. App: Appstore, suchen, installieren, kennt jeder Nutzer. PWA: Browser, URL eingeben, Menüs -> installieren, kennen (wahrscheinlich) die wenigsten. Bleibt die Frage, warum überhaupt installieren? Aus Sicht des Anbieters sinnvoll, weil Push Nachrichten verschickt werden können.
Kolja L. schrieb: > Ein T. schrieb: >> Aber der gewöhnliche 0815-User kann doch gar nicht zwischen einer PWA >> und einer "richtigen" App unterscheiden? > > Technisch nicht. > > App: > Appstore, suchen, installieren, kennt jeder Nutzer. > > PWA: > Browser, URL eingeben, Menüs -> installieren, kennen (wahrscheinlich) > die wenigsten. Soweit ich das lese, kann man PWAs auch über die handelsüblichen Appstores verteilen, ganz genau so wie native Apps auch. > Bleibt die Frage, warum überhaupt installieren? Das hatte der TO weiter oben ausgeführt, wenngleich mir seine Äußerungen nicht vollständig einleuchten wollen. > Aus Sicht des Anbieters sinnvoll, weil Push Nachrichten verschickt > werden können. Das ginge aber auch mit ganz normalen Webbrowsern und PWAs.
Frank E. schrieb: > Beim QR-Code ist eine einmalige Verwendbarkeit garantiert, parallel zum > Verkauf im Automaten/App und beim Einlesen an der Anlage wird das mit > einer Datenbank abgeglichen. Zusätzlich wird eine symmetrische > Verschleierung angewendet, die ist sicher nicht Hacker-fest, aber 99% > der Kunden dürften damit nix anzufangen wissen. > > Beispiel des Inhaltes des QR-Codes: XY5Z93A0TGP0AF000000000000Z1GOPL0G > > Enthalten sind: > - Datum 05.03.2023 > - Zeit 15:42:06 > - enthalten 3 Artikel/Leistungen > - 1 x Artikel 10 zu 19,50€ > - 1 x Artikel 20 zu 5,00€ > - 1 x Artikel 21 zu 7,50€ > > Hier nochmal das Gleiche, nur mit anderer Uhrzeit (14:42:40) > B00000000Z1GOPLA5Z93A0TGP0AF00000G > > Ja, man sieht welche Stellen sich verändert haben, aber sonst? Mal rein aus Interesse: Warum überhaupt irgendwelche Nutzdaten im QR-Code kodieren? Um sicherzustellen, dass sich jemand keine Gratis-Autowäschen erschleicht, indem er einen QR-Code mehrfach benutzt, muss es ja eh zwangsläufig Datenbank-Zugriffe geben, um festzustellen, ob der QR-Code bereits verwendet wurde. Wenn Datenbank-Zugriffe aber eh zwingend erforderlich sind, dann können die zu einem konkreten QR-Code zugehörigen Informationen wie Datum, Uhrzeit und gekaufte Leistungen doch ebenfalls direkt in der Datenbank stehen. Im QR-Code selbst müsste nur eine einmalige ID/Primärschlüssel kodiert sein, über die man dann die zugehörigen Daten in der Datenbank findet. z.B. in Form einer zufällig generierten 128-Bit-UUID, auf die man nicht durch Durchprobieren/Brute Force kommen kann. In meinen Augen hätte das eigentlich nur Vorteile.
:
Bearbeitet durch User
Ein T. schrieb: >> Aus Sicht des Anbieters sinnvoll, weil Push Nachrichten verschickt >> werden können. > > Das ginge aber auch mit ganz normalen Webbrowsern und PWAs. Ja, aber eine App muss installiert werden, eine PWA kann. Also ist der Weg für Push bei der Verwendung einer App immer gegeben.
Joachim S. schrieb: > > Mal rein aus Interesse: Warum überhaupt irgendwelche Nutzdaten im > QR-Code kodieren? Das hängt mit der Historie des Projektes zusammen. Ursprünglich war keine so intensive Datenbank-Anbindung vorgesehen, wie sie sich im Laufe der Entwicklung als notwendig herausgestellt hat. Aber du hast absolut recht, wahrscheinlich ändere ich das noch. Einfach ein langer Key zusammen mit Timestamp und den Produkten/Leistungen in der Datebank reichen eigentlich vollkommen aus.
Die ganzen Nutzdaten sind ja auch nicht relevant. Das einzige, das in den Key bzw. Qr-code rein muß, wenn die Zahlung erfolgt ist, ist die Art des Waschprogramms, da es ja mehrere gibt. Und dieser wird in der DB gespeichert, worauf auch die Waschstraße Zugriff hat. Damit weiß die Waschstraße, welches Waschprogramm sie abfahren muß. Wenn man will, kann man noch einen Zeit-Stamp rein machen, um später z.B. eine Statistik zu erstellen. Wer das bezahlt hat oder wann ist eigentlich egal. Bei einer normalen Waschstraße verlangt ja auch niemand die Adresse oder Autokennzeichen und die Uhrzeit/Datum wird auch nicht notiert. Auf ein Verfallsdatum würde ich da nicht pochen. Und übertragbar sollte der QR-Code auch sein, also so eine Art Gutschein. z.B. Vater kauft so ein Qr-code. Tochter/Sohn oder irgendwer Bekanntes kommt später mal vorbei. Tochter sagt : mein Auto müßte auch mal gewaschen werden. Vater sagt : Du hast mir letzte Woche mal geholfen, hier hast du einen QR-code für Waschstraße X. Sowas wird es wohl öfter geben, daß nicht der Zahler sondern jemand anderes den Nutzen zieht. Szenarien dafür gibt es ja, ähnlich wie oben, genug.
:
Bearbeitet durch User
Frank E. schrieb: > Der gewöhnliche 0815-User jedoch kennt, bzw. > traut nur "richtigen" Apps. Bullshit.
Joachim S. schrieb: > Mal rein aus Interesse: Warum überhaupt irgendwelche Nutzdaten im > QR-Code kodieren? Weil da wieder mal wer mit maximaler Planlosigkeit kaputte Systeme verkaufen will um Reibach zu machen. Frank E. schrieb: > Das hängt mit der Historie des Projektes zusammen. Ursprünglich war > keine so intensive Datenbank-Anbindung vorgesehen, wie sie sich im Laufe > der Entwicklung als notwendig herausgestellt hat. Mitten im Projekt draufkommen dass die Ursprungslösung kacke ist und dann irgendwas rundherum basteln ist immer eine gute Idee.
:
Bearbeitet durch User
Frank E. schrieb: > langer Key Der braucht nicht lang sein, herkömmliche Waschanlagen mit Barcode und Zettel haben auch nicht mehr als 10 Dezimalstellen. Hat den Vorteil dass man die Nummer im Zweifelsfall auch händisch eintippen kann. Vielleicht solltest du einfach eine fertige Lösung nehmen...
:
Bearbeitet durch User
Heinz B. schrieb: > Auf ein Verfallsdatum würde ich da nicht pochen. Und übertragbar > sollte der QR-Code auch sein, also so eine Art Gutschein. > z.B. Vater kauft so ein Qr-code. Tochter/Sohn oder irgendwer > Bekanntes kommt später mal vorbei. Tochter sagt : mein Auto müßte > auch mal gewaschen werden. Vater sagt : Du hast mir letzte Woche > mal geholfen, hier hast du einen QR-code für Waschstraße X. > > Sowas wird es wohl öfter geben, daß nicht der Zahler sondern > jemand anderes den Nutzen zieht. Szenarien dafür gibt es ja, > ähnlich wie oben, genug. Ich glaube, Du hast da was falsch interpretiert, von einem Verfallsdatum war nie die Rede. Und von irgendwelchen Massnahmen, die eine Übertragbarkeit verhindern würden, ebenfalls nicht - das wäre hier wohl eh schwierig bis unmöglich.
Joachim S. schrieb: > Heinz B. schrieb: >> Auf ein Verfallsdatum würde ich da nicht pochen. Und übertragbar >> sollte der QR-Code auch sein, also so eine Art Gutschein. >> z.B. Vater kauft so ein Qr-code. Tochter/Sohn oder irgendwer >> Bekanntes kommt später mal vorbei. Tochter sagt : mein Auto müßte >> auch mal gewaschen werden. Vater sagt : Du hast mir letzte Woche >> mal geholfen, hier hast du einen QR-code für Waschstraße X. >> >> Sowas wird es wohl öfter geben, daß nicht der Zahler sondern >> jemand anderes den Nutzen zieht. Szenarien dafür gibt es ja, >> ähnlich wie oben, genug. > > Ich glaube, Du hast da was falsch interpretiert, von einem Verfallsdatum > war nie die Rede. > Und von irgendwelchen Massnahmen, die eine Übertragbarkeit verhindern > würden, ebenfalls nicht - das wäre hier wohl eh schwierig bis unmöglich. Ein Verfallsdatum gibt es tatsächlich auch. Hin und wieder sind besonders umfangreiche Wäschen (mit zus. Pflegen usw.) im Angebot, so 3...5€ billiger als regulär. Der Betreiber möchte jedoch nicht, dass diese dann auf Vorrat gekauft werden, der Code soll nur für den/die Angebots-Tag(e) gelten. Wie ich das finde ist irrelevant, des Kunden Wille zählt da. Für Gutscheine gibts Prepaid-Karten auf RFID-Basis.
:
Bearbeitet durch User
Frank E. schrieb: > Es gibt eine native "Rahmen-App", die in einem > Webviewer den in den Resourcen der App hinterlegten HTML/JS-Code > "abspielt" (ist also nicht auf einen externen Webserver angewiesen). > Diese Rahmen-App enthält zudem Schnittstelle für die lokalen Resourcen, > wie Kamera, Mikrofon, Dateisystem, SQLite usw. Erinnert mich etwas an Macromedia(Adobe) Flash / Flashplayer.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.