Am 2. Oktober hat Microsoft sehr überraschend das Surface Phone vorgestellt. Offiziell heißt das Produkt Surface Duo. Hierbei handelt es sich um ein Foldable-Smartphone mit zwei 5,6-Zoll Displays, welche mit einem 360 Grad Scharnier verbunden sind.
Wie gestern bei der Anzeige des ersten Videos sehr schnell offensichtlich wurde, läuft das Surface Duo nicht mit Windows 10X. Stattdessen hat Microsoft das Smartphone mit einer Version von Android vorgestellt, sprich Googles Betriebssystem.
Warum Android?
In unserer Community wurde die Entscheidung des Konzerns für Android und gegen Windows 10 mit gemischten Gefühlen aufgenommen. Inbesondere die Inhaberschaft von Android durch Google sorgen für Bedenken beim Datenschutz. Der Suchmaschinengigant verkauft schließlich im Gegensatz zu Microsoft keine Dienste, sondern Nutzerdaten.
Microsoft hat sich aber mit Android abgefunden und unklug ist die Entscheidung nicht. Satya Nadella und Panos Panay haben die Entscheidung am Rande des Surface Events ebenfalls gut begründet. Für Microsoft ist das Betriebssystem heute nur noch ein Vehikel, um seine Dienste und Apps für Kunden bereitzustellen. Im Endeffekt geht es um das Benutzererlebnis, sagten beide Manager etwa einstimmig. Windows 10X wäre schlichtweg nicht in der Lage, dasselbe Benutzererlebnis zu bieten wie Android. Das Windows-Ökosystem ist nicht derart stark ausgebaut, man wir Entwickler kaum anlocken können und ohne Apps kommen auch die Nutzer nicht. Da können weder Preise, noch Innovationen wirklich etwas daran ändern. Versucht hatte man es schließlich.
Microsoft fährt beim neuen Edge-Browser auf Chromium-Basis außerordentlich gut mit Open Source-Software aus dem Hause Google. Chromium ist der etablierte Browser im Web, genauso ist Android das etablierte mobile Betriebssystem. Es wäre sehr kostenintensiv und wahrscheinlich kaum möglich, ein mobiles Windows-Ökosystem aufzubauen. Der Zug ist abgefahren.
Strategie: Microsoft hat eine
Microsoft spielt ein Spiel auf Zeit. Man hat vier Jahre gewartet, bis man wieder etwas präsentiert hat, das auch nur ansatzweise mit einem Smartphone verglichen werden kann. Der Konzern hat einen langen Atem und die Strategie, die sich mit Android, Surface Duo und UWP ankündigt, die könnte man glatt als interessant bezeichnen.
Ich bin mir dessen bewusst, dass Entwickler-Themen den Normalverbraucher nicht derart interessieren, aber Microsoft scheint eine wirklich konkrete Strategie zu haben. Diese beinhaltet Android, das Surface Duo und UWP gleichermaßen.
Microsoft bringt UWP auf Android
Ich habe den begründeten Verdacht, dass Microsoft seine UWP-Apps auf Android bringen wird. Verbinden wir doch nur folgende Punkte: UWP Apps sind ja jetzt schon mehr als nur Apps, sondern React Native ist mittlerweile eine wichtige Komponente der Plattform. Skype ist jetzt schon auf dieser Basis entwickelt worden und die Windows 10 Kalender-App wird folgen. Web-Technologien können also für die Entwicklung von nativen Windows Universal Apps genutzt werden und Entwickler werden auf diese Weise ihre Anwendungen für Surface Neo bereitstellen können. Es ist also deutlich leichter, eine UWP zu bauen. Das ist der Kern.
Ein Entwickler, der nun sowohl für Surface Neo, als auch für Surface Duo entwickeln möchte, wird so dennoch Android- und Windows-Programmierung beherrschen müssen. Unter Umständen nicht. Microsoft hat auf GitHub ein neues Open-Source-Projekt gestartet, welches man als „Java language projection for the Windows Runtime“ bezeichnet. Noch enthält die Repository keinerlei Inhalt bis auf eine generische Information. Der Name suggeriert aber, dass Microsoft ein Framework plant, womit Windows-Anwendungen in native Java-Android-Apps umgewandelt werden können.
Ziel: Entwickler programmieren Dual-Display Apps in UWP
Sofern meine Vermutung stimmt und sich diese Tools tatsächlich als brauchbar erweisen, hätte Microsoft ein mächtiges Werkzeug in der Hand. Wer nämlich sowohl für Android, als auch für Windows-Geräte mit Dual-Display entwickeln möchte, schreibt seine Apps defacto nur für UWP.
Langfristig könnte Microsoft mit dieser Strategie tatsächlich Erfolg haben. Dieser Erfolg wird allerdings nicht so sehr vom kleinen Surface Duo abhängen, sondern vom Surface Neo. Wenn sich dieser Foldable Windows-Formfaktor bei größeren Tablets tatsächlich etablieren kann und andere Hersteller mitspielen, könnte man glatt auch Entwickler auf die Plattform locken.
Microsoft hat tatsächlich eine Strategie. Ich bin ehrlich erstaunt, das zu sagen.
Traditionelle Desktop-Programme gehören mit zu den geschätzten Eigenschaften und Vorzügen von Windows, durch welche die Masse – und auf die kommt es im Wesentlichen an – auch noch weiter bei Windows gehalten werden kann.
Die „Umerziehung“ der Desktop-User zugunsten verstärkter Nutzung von „Apps“ könnte gefährlich werden und nach hinten losgehen! Der erste Schritt in Richtung App-Nutzung könnte da (einmal auf den Geschmack gekommen) auch sogleich für den Schwung zum nächsten sorgen, nämlich die „App-Nutzung“ auch gleich auf die Plattformen und Betriebssysteme jener zu verlegen, welche solche „Apps“ erfunden haben, also von wo die Apps eigentlich herkommen und wo sie in aller Köpfe noch immer „zuhause“ sind…
Ich hab die Hoffnung, dass Surface Neo endlich die User mehr dazu motivieren wird Apps statt Anwendungen zu verwenden. Nur dann geht die geschilderte Strategie auf. Denn neben dem Aufwand für mehrere Plattformen zu programmieren, den Microsoft ja erheblich erleichtert hatte, war das Hauptproblem, das Windows-Nutzer einfach kaum Apps nutzen wollten, wodurch sich selbst geringer Aufwand nicht gelohnt hat. Das haben mir mehrere Programmierer so gesagt… Okay es waren 2, aber mehr kenne ich halt nicht. ?
Ihr Journalisten von heute braucht immer einen Aufreißer, eine Story, die euch Klicks/Einnahmen garantiert. Und kommt dann immer erst nach einigen Sätzen zu der Einsicht, dass es aber eigentlich nicht so aufreißerisch, sondern richtig ist, was Nadella zum Thema Betriebssystem sagte. Hier bei dem Thema Windows ist das sicher nicht so dramatisch. In der Politik würde man dies in einigegn inzwischen weit verbreiteten Kreisen Lügenpresse schimpfen.
Würde nicht sagen, dass das jetzt hier die größte Reißer-Story ist zum Thema. Betrachte nur die Headline von mir und anderen Blogs. Vergleiche gerne auch die Berichterstattung und den Inhalt.
Woanders macht die Meldung über JavaWiNRT gerade die Runde. Guck mal auf die Headlines. „UWP Runtime für Android kommt“. Dabei geht’s nicht mal darum. Das ist völliger BS. Und das berichten auch Fachmagazine. ES GIBT KEINE UWP RUNTIME. wtf.
Andere Journalisten:
– reißerische Titel ✔
– technische Unwissenheit ✔
– falsche Infos ✔
WindowsArea:
– subtil fragender Titel, kein wirklicher Clickbait ✔
– technisches Wissen ✔
– objektive Berichterstattung und klare Kennzeichnung von Vermutungen ✔
– Qualitätsjournalismus ✔
Mit Android wird das auf jeden Fall scheitern. Sobald irgendwer , und wenn es die Chinesen sind, ein neues BS bieten werden die Leute vom Webterrorosten Google abspringen.
Aber auch so hat es keine Zukunft. Der Nutzer möchte ein gerät das er in einer Hand halten und bedienen kann. Wer heutzutage sein Smartphone mit 2 Händen benutzt, ist sofort als alter Sack und behindert gebrandmarkt.
Das letzte seh ich nicht so… Besonders nicht wenn der formfaktor das halt so nicht hergibt. Und bei immer größeren Smartphones ist das eben ein ziemliches problem. Ich kenn auch niemanden der halbwegs mit nem Smartphone umgehen kann, der zum schreiben nicht zwei hände bzw. Das zweidaumensystem einsetzt.
Ich find den formfaktor super, aber das hier verwendete OS darauf scheisse und superabschreckend und irgendwie auch ein tritt in die eier von MS gegenüber uns wp/w10m nutzern.
Du tust ja gerade so als würde das neue OS schon an der nächsten Ecke lauern. Vielleicht erinnerst du dich. Microsoft selbst war es, die den Versuch gestartet hatten ein neues OS für das Smartphone zu liefern. Warum sollte den Chinesen das heute, wo Android noch fester im Sattel sitzt, eher gelingen? In China vielleicht. Aber nicht außerhalb.
Und deine Abhängigkeit der Jugend gegenüber ist unsinnig. Du bist scheinbar ein alter Sack. Glaubst du, wenn du mit dem Foldable einhändig statt beidhändig arbeitest, macht dich das jünger? Das hat wohl eher etwas mit der Fertigkeit im Umgang mit dem Gerät zu tun. Erinner dich mal an die ersten Tage des Smartphones. Da war auch innerhalb der Jugend noch beidhändige Nutzung normal.
Hey, persönlich werden wir hier nicht ja? Geht echt gar nicht! So ne scheisse will ich hier keiner hören.
Ich würde es auch so verstehen, dass Microsoft bei Store Apps langfristig an Apps denkt die mit Web Techniken erstellt werden, und daher die Betriebssystem Plattform für den Anwender immer unwichtiger wird. Heute ist es beim Anwender akzeptiert bzw. sogar eher schon präferiert, daß Apps einheitliche UI Patterns über die Plattformen verwenden, und nicht die Gestaltungs-Eigenheiten einzelner Gerätehersteller. Das spielt alles in die Richtung, daß Mobile Apps auch unabhängig vom Play Store ihren Weg zum Anwender finden. Bis dahin arrangiert sich Microsoft eben im Smartphone Gerätesegment und nutzt sehr wahrscheinlich die Zeit, um Einfluss auf die Entwicklung von Android zu gewinnen. Ähnlich dazu, wie es bereits beim Chromium Projekt läuft. Für Smartphone Nutzer könnte dies immerhin irgendwann einen Weg zur Befreiung von den Google Diensten bringen, auch wenn man sich bis dahin erst noch eine Weile mit der Kontrolle durch Google abfinden muss.
Das wäre zwar wünschenswert ist aber Quatsch mit der einheitlichen UI über die Plattform grenzen hinweg. >95% der User werden genau ein Smartphone Benutzen wofür willst du dann eine Plattform übergreifendes UI wenn sich die APP dafür auf der Zielplattform wie ein Fremdkörper anfühlt?!
Wenn sich die Apps XY auf dem Smartphone, dem Tablet/Convertible Touchscreen, im Browser and auf dem Notebook Desktop immer wie die App XY präsentiert, ist das für die Mehrzahl der Anwender angenehmer, als wenn sie überall anders wäre. Wenn man auf dem Smartphone nur App A, B, C… XY, Z benutzt, und dazu zähle ich auch ersetzte Standardtools, wie Launcher, Keyboard, Cloud-/ Dateimanager, Browser, Email-Client, Kalender, Kontakte, Messenger, News, Wetter etc. dann werden die herstellerspezifischen Eigenheiten sowieso immer weniger von den Nutzern wahrgenommen. Echte Fans eines bestimmten Geräteherstellers, die unbedingt dessen gestalterische Eigenheiten wollen, sind bei Android Geräten jetzt eher nicht die Mehrheit der Kunden…
Ich bin schon vollkommen bei dir und war selbst ein großer Fan vom UWP Konzept allerdings sieht die Realität so aus das UWP Apps die klassischen Desktop Anwendungen nur ergänzen aber nicht ersetzen können. Das größte Problem von MS waren wieder mal ihre selbst gesetzten Limitierungen ähnlich Windows Phone.
Was du bei deinen Gedanken vergisst ist das erstens gar keine Apps auf Tablet / Convertible / Desktop bereitstehen und das ein Desktop User komplett andere Anforderungen stellt als ein Smartphone User.
Wo ich auf dem Desktop 100-200 Elemente auf dem UI platzieren kann sind es auf dem Smartphone gerade mal 25. D.h. du musst so oder so die UI komplett anders implementieren. Wer das selbst noch nicht machen musste versteht das einfach nicht.
Ist andererseits in Web gang und gebe… Responsive-/Adaptive-Websites machen es doch vor wie es geht.
Die Anzahl der gut umgesetzten Responsive Apps ist dermaßen gering das es keine Rolle spielt und beim Rest macht es einfach keinen großen Sinn. Selbst Google bekommt ihr Tabellen Zeug nicht im Web Responsive dargstellt oder versuchen es grad nicht.
Oh das wäre natürlich mal interessant: Was macht ihr denn bei Tabellen für Smartphone-Devices? Im Endeffekt ist das ziemlich sicher genauso umsetzbar für Web-Designs… sind dann halt Adaptive Steps und keine reine Responsive-Lösung (die reichen beinahe nie und machen meistens nur in Kombination mit Adaptive-Steps Sinn).
Flex oder Grid-Systeme oder einfach eine andere Darstellung indem man die Ansicht für große Darstellungen ausblendet eine für kleine Einblendet und gut ist. Alles geht, wenn man das will. Die Frage ist nur, wieviel man reinstecken möchte… aber weniger Aufwand als 3-4 unterschiedliche Programmcode-Basen in unterschiedlichen Programmiersprachen zu supporten ist das ganz sicher.
Ich „scheitere“ bei der Vereins Homepage schon dran die Google Tabellen auf dem Responsive Design zu integrieren….iframe lässt grüßen. Und selbst am Desktop ist das schon ein Beinbruch das Zeug halbwegs in ne Joomla Site zu integrieren. 🙁 Aber der Aufriss für ne eigene WebAPP auf nem extra Virtual Host und nen zusätzliches Modul für Joomla sind mir zu viel des guten. Und blanko Joomla macht keinen Sinn weil man dann nur dem Kern hinterher rennt.
Iframes eben… Versuchs mal mit einem Curl über php und les dann aus dem erhaltenen quellcode die daten aus. Dann kannst du sie umschreiben und auf deiner seite per php ausgeben wie du willst (in divs, oder was auch immer am besten funzt für diese daten. Oder ein ajax request (klappt vermutlich nicht wegen security richtlinien nicht, aber nen versuch ist es wert).
Danke für den Tip dafür müsste ich aber nen eigenes Joomla Plugin erstellen und dann kann ich gleich ne richtige App daraus machen :-/
WebApps sind aber in der absoluten Minderheit weil sehr stark eingeschränkt was die Funktionen betrifft und die UI nicht auf das Konzept vom Zieldevice passt. Letzteres ist auch einer der Gründe warum Firmen dann lieber zwei Apps entwickeln lassen die dann wenigstens ins Ökosystem integriert sind.
Mit dem Zugriff auf Gerätefunktionen, Offline und Hintergrund-Betrieb sowie Benachrichtigungen umfassen die JavaScript APIs bereits so viel Funktionalität, daß man wirklich nicht mehr von „sehr stark eingeschränkt“ sprechen kann. Allenfalls im Bereich grafikintensiver Spiele wird native Programmierung benötigt, dann wird aber eben C++ genutzt, also auch nicht die Managed Code App Programmierung der jeweiligen Plattform. Und C++ ist wiederum auch auf allen Plattformen nutzbar. Was durch Web Technik obsolet wird, sind die plattformspezifischen Managed Code Sprachen und Entwicklungs-Umgebungen.
Ich könnte mir vorstellen, daß Microsoft mit der Erfahrung aus dem Edge Projekt, die Chromium basierte HTML und JavaScript Engines mittelfristig in Android als Standard App Laufzeitumgebung einbaut, analog zur HTML/JavaScript Laufzeitumgebung bei UWP auf Windows. Dann können Web Apps ohne einen Java Stub direkt als apk installiert werden, analog zu JavaScript Store Apps auf Windows. Wenn Microsoft dann noch das Windows Store Paketformat mit dem Android Paketformat zusammenführt könnte man apk auf Abdroid Geräten anstatt vom Play Store auch aus dem Microsoft Store installieren und Microsoft könnte die App Entwickler sehr einfach dabei abholen, daß diese ihre Pakete auch bei Microsoft veröffentlichen, womit die dann auch auf Windows Geräten installierbar sind…
Soll das jetzt Wunschdenken sein oder weißt du mehr? Bisher sind alle solcher Ansätze irgendwann wieder verschwunden und ehrlich gesagt kenne ich keine einzige Plattform übergreifende APP Technologie die merkliche Verbreitung besitzt. Selbst mit Cordova ging damals schon viel aber selbst wir haben unsere Apps getrennt und bauen jeweils zwei native Varianten. Swift und Kotlin zeigen ja wohin die Reise geht und nach dem reine Tablets auch ziemlich vom Markt gefegt wurden schaut es nach zwei festen Instanzen aus iOS mit Swift und Kotlin für Android.
Die Frage ist: Warum? Meine Apps sind Cordova bzw. Phonegap-Apps und tun auch was sie sollen, erfordern aber für alle Betriebssysteme nur eine Code-Base. PWAs sind ähnlich, wenn nicht sogar noch interessanter.
Die Geschwindigkeit ist bei heutigen Systemen und der Leistung der Smartphones und Computer praktisch (das heisst so, dass der Nutzer kaum/keinen Unterschied bemerkt) gleichwertig zu Nativ-Systemen wenn gut umgesetzt. (schlechte Apps bleiben eben schlechte Apps, egal womit man sie schreibt…)
Es gibt natürlich Ausnahmen, aber bei normalen Informationsapps und vielen anderen Typen (da fallen mindestens 95% der Apps und auch einige Spiele rein) ist eine Hybrid- oder PWA-App meist absolut ausreichend und natürlich viel kostengünstiger besonders wenn man noch unterschiedliche Formfaktoren unterstützen will/muss. Besonders dafür sind WebGUI-Technologien einfach göttlich und sehr mächtig.
Und noch besser: Web-Entwickler findet man überall und die machen den größten Teil der Entwickler-Gemeinschaft aus. d.h. Fachkräfte sind da am einfachste zu finden, man kann sie auch für die Websites einsetzen und theoretisch kann man sogar die Websites/Mobile-Sites einfach mit der gleichen Codebase betreiben… das heisst ich kann damit Android, iOS, Windows, Linux, KaiOS und alles andere direkt und mit Feature-Gleichheit (solange die Browser gleichwertige Features haben, was aber bei modernen Systemen so gut wie immer der Fall ist, wenn man es nicht wie Google absichtlich torpediert und im Endeffekt auch nicht wirklich das Problem des Entwicklers sondern des jeweiligen Betriebssystems/Anbieters ist, solange ich mich an den W3C-Standard halte) befeuern.
Von was für Apps sprechen wir bei Euch denn, dass ihr da soviel Kohle, Zeit und Ressourcen reinsteckt, dass das notwendig wird?
Es gibt sinnvolle und weniger sinnvolle Einsatzszenarien. Was man aber festhalten muss bei deiner Euphorie für Hybrid Lösungen das sich diese bisher einfach nicht durchgesetzt haben. Wir bauen Business Apps (Industriezeugs) und ÖPNV Lösungen.
Industrieanlagen ist schwierig zu definieren worüber man da spricht (was genau?), aber Öpnv? Das ist eine der leichtesten Übungen überhaupt sowas damit zu bauen. Da geschieht doch eh alles über online-apis. Was hindert euch denn da genau auf Webtechnologien zu setzen?
Industriezeugs…siehe Beispiel in der anderen Antwort. Bezüglich ÖPNV hatten wir eben jenes aber für die Details müsste ich die Kollegen fragen was die genauen Gründe für den Rückbau waren. Wir sprechen hier aber nicht nur von der Anzeige sondern, Netze, Routing, Abfahrten, Tickets etc. ist wesentlich komplexer als es erstmal den Anschein hat.
PS: Warum machst du nicht auf Xamarin?
Hab mich nie tiefer damit beschäftigt, weil ich eben webdeveloper bin und mit meinen mitteln per cordova und co auch alles abdecken konnte (inkl. Multisystem-Kompatibilität). Steht aber auf meiner Liste da bei Gelegenheit mal tiefer reinzuschauen.
Hab mich nach deinem Feedback mal bissel in PWA .net core mit blazor und angular eingelesen aber die tutorials sind ja immer easy 😉 Parallel dazu noch nen Xamarin Vortrag da ginga auch immer um geht nicht auf x oder y ohne näher ins Details zu gehen.
Kann hier keinen Link einfügen guck mal bei YT nach Jennifer Deigendesch … Einführung plattformunabhängige
Was sind denn deine Apps?
Ne Filmdatenbank-App zum Verwalten von Filmen, zwei spiele (weltraumshooter und casual game), eine garagenkonfigurator-app, eine chatapp für das von uns entwickelte cms, eine subway-helfer app, ein soundboard für business Veranstaltungen, eine app für die Verwaltung von seminaren im Ophthalmogiebereich, eine app für medizinische studien. Nicht alles davon ist natürlich frei verfügbar und die 3d game apps mit unity hab ich natürlich mal rausgelassen, weil das prinzipiell natürlich keine webtechnologie ist, allerdings bietet unity ja intern kompilierung für unterschiedliche systeme mit einem click (einschliesslich web) an, so dass das da eben jemand anders übernimmt, die codebasis aber eben auch die gleiche ist.
PS: Ein ziemlich großer teil der apps in praktisch jedem webstore basiert intern natürlich auch auf webtechnologien. Schon allein weil wordpress und ähnliche systeme das einem ziemlich einfach machen. Warum sich webtechnologien noch nicht durchgesetzt haben? Da kann ich nur raten: Wenn die apps schon existieren wird natürlich deren code base weiterverwendet und die meisten kunden von denen, werden natürlich wieder zu Einzel-Apps beraten, einfach weil die entsprechenden Entwicklerstudies Programmierer haben, die eben swift, kotlin, c++, java und co beherrschen, die anderen Sprachen wie JS/Node.js, php und co sowie html, css und entsprechende webframeworks kaum bis nicht kennen.
Ich will auch nicht sagen, dass es nicht app typen gibt, bei denen es nicht so ohne weiteres ohne native programmierung geht (zB wenn die eigene infrastruktur eben schon auf der gleichen oder ähnlichen sprachen basiert) aber ein Großteil der Apps muss absolut nicht in nativer Programmierung gebaut werden und Webtechnologien bieten in vielen fällen GUI-technisch mindestens das gleiche bis sind den nativ-guis sogar teilweise überlegen, besonders in Richtung Unterstützung völlig unterschiedlicher Auflösungen und Formfaktoren. Das ist das, womit sich Websites schon immer herumschlagen mussten: Es war einfach nie definiert, mit welchen Geräten auf die Website zugegriffen wurde. Vom 8k-TV, über einen Desktop-PC mit 22:10-Bildschirm (oder noch krasseren Sachen), über ein Tablet, ein Smartphone bis zum Wearable kann da alles dabei sein und dafür wurden eine Menge gute Lösungen gefunden, um den daraus natürlich entstehenden Problemen Herr zu werden. Wenn ich nur für ein iPhone/iPad entwickle, sieht die Sache natürlich ganz anders aus… da ist ziemlich definiert was da auf mich zu kommt.
Hm wir haben ne eigne APP Entwickler Truppe die mit Phonegap angefangen hat mittlerweile ist es durchgemischt aber gefühlt ist der Trend Nativ!
Die Angular basierten Responsive Ansätze taugen in meistens nicht für den produktiven Business Einsatz…schaut zwar nett aus aber die Usability ist scheiße und umständlich. Kleines Beispiel du hast nen Ticket/Vorgangs System für Disposition, Dokumentation etc. mit viel Business Rules aber du setzt nur IOS ein für mobile Devices und willst Offline Funktionalität?
Ist da was mir lokaler Datenhaltung dabei oder only Cloud?
Da sind beide Arten dabei: Mehrere davon speichern natürlich für offline usage. Localstorage, FileAPI, IndexedDB und WebSQL oder cordova Plugins geben dir da alle nötigen Möglichkeiten. Die Garagenapp zB synchronisiert Bilderkataloge, pdfs und textdaten von einem online system mit moderierter Datenhaltung auf das Clientsystem und umgekehrt wenn eine Internetleitung besteht. Ohne nimmt sie den vorhandenen Katalog auf dem clientsystem.
Die Subway app speichert Daten der Subcard lokal ab, damit der nutzer seine subcard nich immer dabei haben muss, usw. Wir reden hier nicht über reine iFrame-Wrapper (iframe sind eh nicht gut… Man sollte die daten immer per ajaxrequest auslesen und einsetzen, weil iframes sonst ärger mit zugriffsrechten und responsive ergeben) oder sowas.
Die filmdb app ist u.a. dazu gedacht, filme nicht doppelt zu kaufen (zB wenn blurays oder so im laden gekauft werden kann man per qrscanner den barcode abscannen um zu schauen, ob der film schon in der heimischen bib steht bzw. vielleicht von einem anderen familienmitglied gekauft wurde (und beim eintragen der filme werden meta-daten von verschiedenen onlineplatfornen über den ean gezogen, damit man das nch alles händisch reinklopfen muss. Die funzt nur online, damit man da keiner lüge aufsitzt was den derzeitigen bestand angeht. (und weil bei den datenmengen nen online-db-server natürlich schneller und besser ist, als auf nem mobilen system die unmengen an daten zu durchforsten)
Es geht wie gesagt praktische jede Art wenn man nur will. Es gab mal vor einigen Jahren Größeneinschränkungen bei iphones/pads, die einem die suppe versalzen haben, aber die zeiten sind lange vorbei.
(ich könnte schwören ich hätte das hier schonmal geschrieben gestern, aber hab es nich mehr gefunden… Vielleicht wurde mein beitrag als spam klassifiziert?)
UWP ist tot Albert und ne WebApp hat nichts mit UWP zu tun. Es gibt aktuell noch viel weniger Gründe auf UWP zu setzen als jemals zuvor.
Es ist eine WebApp, aber Microsoft zählt sie als UWP, sie kann im Store erscheinen und läuft plattformübergreifend.