Krautkanal.com

Veröffentlicht am 2016-04-22 18:02:17 in /prog/

/prog/ 8698: Intel XDK

carlosgavina Avatar
carlosgavina:#8698

Arbeitet hier jemand mit Intel XDK? Wie sind die Erfahrungen damit so? Gibt's bessere Alternativen?

>Intel XDK is a development kit created by Intel to create native apps for mobile phones and tablets using web technologies like HTML5, CSS and JavaScript. Apps are compiled online via the Cordova platform for making cross-platform apps.

eloisem Avatar
eloisem:#8699

>>8698
>HTML5, CSS and JavaScript
Hört sich eher meh an.
Warum nicht einfach nativ entwickeln?

Oder meinst du ausdrücklich Cross-platform?
Habe gutes von Xamarin gehört, aber noch nie selber benutzt

Wenn ich eine Äpp schreiben müsste, würde ich einfach Java für Android nehmen, bzw. Objective-C (glaube das ist mittlerweile abgelöst worden? ka) für iOS.

zackeeler Avatar
zackeeler:#8700

>>8699
Wegen IDEs:
Xcode ist für Apple-Zeug ganz gut und quasi Apples VisualStudio für iOS/OSX (habe es allerdings das letzte mal vor 4 Jahren angefasst)
Bei Android weiß ich leider nicht was sich da so anbieten würde, da ich mich eigentlich nicht mit mobilen Plattformen beschäftige

splashing75 Avatar
splashing75:#8701

>>8699
>Warum nicht einfach nativ entwickeln?
Warum sollte jemand nativ entwickeln, wenn man es nicht zwangsläufig unbedingt muss?

>Wenn ich eine Äpp schreiben müsste, würde ich einfach Java für Android nehmen, bzw. Objective-C (glaube das ist mittlerweile abgelöst worden? ka) für iOS.
Du würdest also lieber dein Programm zweimal entwickeln müssen, wenn stattdessen z.B. auf HTML5/Javascript-Basis einmal reichen würde?

>Xamarin
Hm sieht ganz ok aus, aber scheint mit Kosten ab mindestens 25$/Monat verbunden zu sein.

andrewofficer Avatar
andrewofficer:#8702

>>8701
>Warum sollte jemand nativ entwickeln, wenn man es nicht zwangsläufig unbedingt muss?
Warum sollte jemand NICHT nativ entwickeln, wenn man es nicht zwangsläufig unbedingt muss?

>Du würdest also lieber dein Programm zweimal entwickeln müssen, wenn stattdessen z.B. auf HTML5/Javascript-Basis einmal reichen würde?
Wer spricht von müssen? Ich kehre nicht um Portierbarkeit habe eh nur Android zu Hause und habe auch keine Lust irgendwelche Apps zu verkaufen.

Mir wäre es lieber keinen Restriktionen zu unterliegen (bzw. auf gute libs zurückgreifen zu können, um sich das Leben einfacher zu machen), und ich denke mal, da wäre man bei einer nativen Lösung im Vorteil

emilioiantorno Avatar
emilioiantorno:#8704

>>8701
>Warum sollte jemand nativ entwickeln, wenn man es nicht zwangsläufig unbedingt muss?
Weil du sonst nur eine Webapp programmierst, die sich als App verkleidet. Und sie wird sich auch immer wie eine Webapp anfühlen. Dann entwickel halt gleich ne Webseite.

johnriordan Avatar
johnriordan:#8707

>>8704
>Und sie wird sich auch immer wie eine Webapp anfühlen.
Nein, du kannst einer App nicht ansehen, ob sie auf HTML5 basiert oder nativ gecodet wurde (es sei denn du öffnest die "App" über eine URL in deinem mobilen Browser, sowas nennt man aber eigentlich nicht App). Wir reden hier außerdem von einem Container, in dem das HTML5 kompiliert und ausgeführt wird. Um nochmal von meinem OP zu zitieren:
>Intel XDK is a development kit created by Intel to create native apps for mobile phones and tablets using web technologies like HTML5
Du kannst selbst komplexe grafische Spiele auf HTML5/Canvas/Javascript-Basis erstellen. Einmal gecodet, danach ohne Portierung für drei Appstores releasefähig (Android, iOS, Windows Phone). Eine native Entwicklung macht doch mittlerweile überhaupt nur Sinn, wenn man etwas speziell platformspezifisches braucht, dass über solche Container nicht oder nur mit schlechter Performance realisierbar ist.
Dein genanntes Xamarin ist ja vom Prinzip dasselbe, nur dass dort statt HTML5 C# verwendet wird.

lanceguyatt Avatar
lanceguyatt:#8708

>>8707
War nicht ich

PS:
>Dein genanntes Xamarin ist ja vom Prinzip dasselbe, nur dass dort statt HTML5 C# verwendet wird.
Es gibt wohl einen derben Unterschied zwischen HTML5 und C#... Merkste selber oder?

>Eine native Entwicklung macht doch mittlerweile überhaupt nur Sinn, wenn man etwas speziell platformspezifisches braucht, dass über solche Container nicht oder nur mit schlechter Performance realisierbar ist.
Nicht wirklich. Könnte genau so gut sagen diese Crossplatform-mems dienen nur dazu Shovelware auf den Markt zu kacken.

polarity Avatar
polarity:#8709

>>8708
>Es gibt wohl einen derben Unterschied zwischen HTML5 und C#... Merkste selber oder?
Es tut mir Leid, das so fragen zu müssen, aber kann es sein, dass du nicht viel von dem verstanden hast, was ich in >>8707 geschrieben habe? Sowohl die HTML5 App aus Intel XDK als auch die C# App aus Xamarin laufen beide nativ auf der jeweiligen Smartphone-Plattform. Natürlich gibt es Unterschiede zwischen Programmiersprachen und -umgebungen, was genau soll das jetzt mit der Fragestellung zu tun haben? Bitte verkneife dir doch einfach eine Antwort, wenn du inhaltlich nichts beizutragen hast und nur in einen trotzigen Ton verfällst, weil du dich aus unerfindlichen Gründen von irgendwas in diesem Faden angegriffen fühlst.

>Nicht wirklich. Könnte genau so gut sagen diese Crossplatform-mems dienen nur dazu Shovelware auf den Markt zu kacken.
Aussage = null

dpg Avatar
dpg:#8710

>>8702
>Warum sollte jemand NICHT nativ entwickeln, wenn man es nicht zwangsläufig unbedingt muss?
Ich denke wegen der geschenkten Portierbarkeit. Ich halte es schon für einen großen Vorteil, ohne Zusatzaufwand den gesamten Markt (und ggf. sogar neue zukünftige Märkte) bedienen zu können.
Wenn man aber 100%ig nur eine Plattform bedienen will und sich das auch nie ändern wird, ist es natürlich egal und man kann auch nativ entwickeln. Mir fällt allerdings selber kein guter Grund ein, warum man Nutzer anderen Betriebssysteme von seiner App unbedingt ausschließen wollen würde. Und vor allem wenn man sich erst in eine der nativen Sprachen einarbeiten müsste, sehe ich keinen Vorteil darin diese Zeit zu investieren, und würde stattdessen eine Crossplattformlösung lernen.

>Mir wäre es lieber keinen Restriktionen zu unterliegen (bzw. auf gute libs zurückgreifen zu können, um sich das Leben einfacher zu machen), und ich denke mal, da wäre man bei einer nativen Lösung im Vorteil
Ja, abhängig von der Aufgabenstellung einer App wird man sehr plattformnahe oder performancekritische Dinge ohne eine native Entwicklung nicht lösen können.

joshhemsley Avatar
joshhemsley:#8711

>>8707
>Nein, du kannst einer App nicht ansehen, ob sie auf HTML5 basiert oder nativ gecodet wurde (es sei denn du öffnest die "App" über eine URL in deinem mobilen Browser, sowas nennt man aber eigentlich nicht App). Wir reden hier außerdem von einem Container, in dem das HTML5 kompiliert und ausgeführt wird. Um nochmal von meinem OP zu zitieren:
Ich garantiere dir, das kann ich. Die App wird nicht so schnell auf Eingaben reagieren wie eine native App, die Eingabelemente werden nicht nativ aussehen, die Animationen werden nicht nativ aussehen (und nicht so performant sein), etc.

Und dein Marketingbullshit vom Hersteller kannst du dir sonst wo hin stecken. Eine HTML App ist nicht nativ, nur weil sie in einem Container-Browser läuft und ein eigenes Icon hat.

>Dein genanntes Xamarin
Das war nicht ich.

murrayswift Avatar
murrayswift:#8712

Eine cross-kompatible App zu entwickeln macht schon alleine deswegen keinen Sinn, weil die drei großen Mobil-Betriebssysteme alle andere Bedienkonzepte und eine andere Design-Philosophie haben.

Auf iOS gibt es zum Beispiel diese Button-Leiste am unteren Rand des Displays. Das ist kein Bedienelement aus der Android-Philosophie. Du kannst es natürlich emulieren, aber die App wird sich für den Android-Nutzer sofort "fremd" anfühlen.
Auch sowas einfaches wie Icons. Wenn du einheitliche Icons und nicht die jeweiligen Betriebssystem-Standards verwendest, sieht das immer sofort scheiße aus.

damenleeturks Avatar
damenleeturks:#8716

>>8711
>Die App wird nicht so schnell auf Eingaben reagieren wie eine native App, die Eingabelemente werden nicht nativ aussehen, die Animationen werden nicht nativ aussehen (und nicht so performant sein), etc.
Dazu kannst du bestimmt auch eine Quelle liefern, die ein derartiges Fazit zieht, ich habe nämlich eher den Eindruck, du ziehst dir diese Argumente aus dem Arsch und hast null Ahnung von HTML5, inbesondere im Zusammenspiel mit Intel XDK bzw. Cordova :3 Die einzigen Nachteile, die z.B. in Rezensionen wie auf heise.de genannt werden sind im Wesentlichen nur die bereits im Faden genannten Fälle für performancekritische oder hardwarenahe Funktionen. Inbesondere "wird nicht so schnell auf Eingaben reagieren" ist komplette Bullenscheisse, du hast wahrscheinlich noch nie eine HTML5 App gesehen (oder wahrscheinlicher, du hast möglicherweise sogar selber welche installiert, ohne zu wissen dass sie auf HTML5 basieren).

>Auf iOS gibt es zum Beispiel diese Button-Leiste am unteren Rand des Displays. Das ist kein Bedienelement aus der Android-Philosophie.
Dafür gibt es ja den Container, der die Bedien-, Eingabeelemente oder "Icons" nativ auf dem jeweiligen Betriebssystem darstellen kann.

terpimost Avatar
terpimost:#8717

>>8716
Die Quelle bin ich selbst. Ich hab nämlich im Gegensatz zu dir mehrere (native) Apps im Playstore, Webapps habe ich auch entwickelt, aber die vermarkte ich nicht als native Apps.

>in Rezensionen wie auf heise.de
>heise.de
Merkste selbst, ne?

>performancekritische oder hardwarenahe Funktionen
Du wirst selbst in total banalen Apps ständig Mikroruckler in den Animationen haben. Sobald du mal unter 60fps fällst, fühlt sich das sofort "laggy" an.

>Dafür gibt es ja den Container, der die Bedien-, Eingabeelemente oder "Icons" nativ auf dem jeweiligen Betriebssystem darstellen kann.
Es geht um mehr, als nur den Skin. Schau dir mal die Google Design Richtlinien an:
https://www.google.com/design/spec
Das kannste alles irgendwie mit HTML emulieren, zu 100% wirst du es aber eh nie treffen, und für iOS musst dus alles nochmal neu machen. Kannst also gleich ne native App schreiben.


Du kannst mir gerne ein paar Apps verlinken, ich werde dir zu 100% sagen, welche HTML und welche nativ sind.

herrhaase Avatar
herrhaase:#8719

>>8717
Sekundiere diesen Bernd

Mir fällt auch immer auf, dass diese "Webapps" die meisten Probleme verursachen was Ruckler u.ä. angeht.

Kenne auch mehrere Informatiker, die mit dem Dreck ihr Geld verdienen, und die sagen auch alle: Wenn du Qualität willst, programmiere nativ. Irgendwelche Crossplatform-dscheiße wird bei denen nur genutzt wenn der Kunde es ausdrücklich verlangt, um sich Geld zu sparen.

jodytaggart Avatar
jodytaggart:#8721

>>8719
>>8717

Jenes, wobei Bernd jene Mikroruckler weniger als Problem empfindet, möglicherweise, weil er rechnertechnisch gut ausgestattet ist. Aber neue Software sollte ja nicht nur auf den krassesten Arbeitsstationen laufen.

Was Bernd hingegen als wirklich störend empfindet sind die großen Dateigrößen und (vermutlich auch damit verbundenen) langen Ladezeiten der Programme.

Für irgendwelche ERP-Systeme, die man zu Beginn seiner Arbeitszeit einmal startet mag das ja angehen. Aber für Software die sofort da sein muss - also Texteditoren, Chatclients und Musik/Videospieler - ist das nicht akzeptabel.

madebyvadim Avatar
madebyvadim:#8722

>>8721
>Für irgendwelche ERP-Systeme, die man zu Beginn seiner Arbeitszeit einmal startet mag das ja angehen
Für die wäre sowas allerdings tatsächlich geeignet, da viele ERP-Lösungen (Workforce z.B.) mittlerweile SaaS sind und daher nur ein einfaches Frontend brauchen.

n_tassone Avatar
n_tassone:#8724

>>8722
Dafür wäre es vermutlich sogar ziemlich gut geeignet, da manche ERP-Systeme stattdessen ihre eine GUI-Lösung mitbringen, die nicht nur wie ein Fremdkörper aussieht sondern auch scheise und vermutlich auch in Hinsicht von Barrierefreiheit und UI-Skalierung grottig sind.
In Electron und co. kann man zumindest die letzten drei Punkte gut ausbügeln.

olgary Avatar
olgary:#8726

>>8724
> die nicht nur wie ein Fremdkörper aussieht sondern auch scheise und vermutlich auch in Hinsicht von Barrierefreiheit und UI-Skalierung grottig sind.
Du hast keine Ahnung von SaaS

kosmar Avatar
kosmar:#8727

>>8726
Das ist nicht unbedingt die Generation ERP-Software, die ich meine.

Eher so was hier: http://elibrary.knoa.com/euidocs/7.1/product/images/sap-gui-screen.png

layerssss Avatar
layerssss:#8728

>>8727
....was mit SaaS überhaupt nichts am Hut hat....

Und ich habe auch keine Ahnung warum du auf einmal 10 Jahre alte Software ins Spiel bringst, du Troll. SAP ist übrigens mittlerweile auch schon auf den SaaS-Zug aufgesprungen, auch wenn Sie immer noch ihr altes Zeug verkaufen, auf Client/Server Basis.

jonkspr Avatar
jonkspr:#8729

>>8728
Ich rede auch nicht von SaaS-Systemen, keine Ahnung, warum du diese nun bei meiner Antwort die klar nicht auf SaaS bezogen war reinbringst.

smaczny Avatar
smaczny:#8730

>>8729
Weil es aus mehreren Gründen keinen Sinn macht, solche Client/Server-Anwendungen für mobile Plattformen zu entwickeln.

Für genau sowas ist SaaS gedacht.

Also macht es im Rahmen des Fadens nur Sinn, über ERP als SaaS zu reden.

abotap Avatar
abotap:#8731

>>8717
>Die Quelle bin ich selbst.
Also hast du keine Quelle.

>heise.de
>Merkste selbst, ne?
Ja verstehe schon, heise foll böse! Aber so ein Möchtegernexperte auf einem anonymen Bilderbrett weiss natürlich über alles Bescheid. Du machst dich echt lächerlich.

>Du wirst selbst in total banalen Apps ständig Mikroruckler in den Animationen haben. Sobald du mal unter 60fps fällst, fühlt sich das sofort "laggy" an.
Wie schon gesagt, du hast keine Ahnung, ich bezweifle auch, dass du überhaupt feststellen kannst, ob eine App auf HTML5 basiert oder nicht. Selbst wenn, kannst du von dem Vorhandensein von "Mikrorucklern" in irgendeiner App nicht sofort auf die verwendete Technologie als Ursache schließen.

Mal ein paar Beispiele für "super laggy" und "ach so schlechte" Apps, die auf HTML5 basieren:
>Twitter App
>Uber App
>Instagram App
>Gmail App
>Der App Store von Apple (!)
usw....
(siehe auch z.B. http://blog.venturepact.com/8-high-performance-apps-you-never-knew-were-hybrid)

PS da ich dich für meine Meinungsbildung eh exkludieren muss, kannst du dir eine Antwort gerne sparen. Wenn ich wissen will, was ein 08/15-Dummtroll von Technologie XY hält, kann ich auch gleich /b/ fragen.

oskamaya Avatar
oskamaya:#8732

>>8731
Wenn du dich für so überlegen hältst, warum dann der Faden? 3 oder 4 Leute haben dir gesagt, dass es keine so großartige Sache ist, und du greifst immer noch nach irgendwelchen Strohhalmen.

Was willst du denn jetzt mit diesem Blog der nur "Apps" vorstellt, die als glorifizierte Frontends bzw Browserersatz dienen, bei denen clientseitig aber nichts abläuft? Das beweist gar nichts. Wurde hier im Faden auch schon erwähnt. Ist näher an WebDev als an allem anderen. Und WebDev mag halt hier keiner. Nicht unser Problem, vor allem wenn du dich absolut querstellst und anfängst Leute zu beleidigen.

Und jetzt geh Addition zweier Zahlen mit JQuery implementieren oder so

sokaniwaal Avatar
sokaniwaal:#8734

>>8732
>3 oder 4 Leute
Das Problem bist nur du

>dich für so überlegen hältst
So wie jemand, der alles besser weiss als z.B. Heise oder Technologie-Blogs, dabei aber null Fakten referenzieren kann

>greifst immer noch nach irgendwelchen Strohhalmen
So wie jemand, der dauernd nur neue Behauptungen nachliefert, und seine vorherigen nicht weiter stützen kann

>Leute zu beleidigen
"Merkste selber oder?"
"kannst du dir sonst wo hin stecken"
"Ich hab nämlich im Gegensatz zu dir"

>Was willst du denn jetzt mit diesem Blog
Ist normalerweise so üblich in einer Diskussion, seinen Punkt mit ein paar Fakten und Querverweisen zu stützen. Du hast sowas aber natürlich nicht nötig :^)

>Nicht unser Problem
>unser
Oh ok, dein Ego ist also schon soweit, dass du nun zum Sprecher und Monarch aller /prog/-Bernds geworden bist

>warum dann der Faden?
Um Meinungen zu hören. Kann ja nicht ahnen, dass ein rangierender Möngi sich gleich angepisst fühlt, wenn er damit seine heilige native Kuh infragestellt sieht.

hammedk Avatar
hammedk:#8737

>>8734
>Ist normalerweise so üblich in einer Diskussion, seinen Punkt mit ein paar Fakten und Querverweisen zu stützen. Du hast sowas aber natürlich nicht nötig :^)
Wie die Russen auf /int/ ...
Ich hab halt diese Erfahrungen beim Programmieren gemacht, sie froh, dass ich sie mit dir teile. Ich hab keine Lust, da jetzt auch noch Internetrecherche zu betreiben.

Die Apps, die du genannt hast, sind zwar große Namen aber keine Beispiele für gute Android Apps. Und dieser Screenshot mit dem uralten GMail disqualifiziert die ganze Quelle eigentlich eh.

Ich war übrigens Teil der Diskussion, aber nicht alle Pfosten stammen von mir (zb >>8732). Minimum zwei, eher mehr Bernds sind hier einer Meinung.

bassamology Avatar
bassamology:#8738

>>8737
>Wie die Russen auf /int/
Ganz und gar nicht, der Witz bei den Russen war ja gerade, dass sie mit einer Vielzahl an Quellen, Rechercheergebnissen, Aufnahmen konfrontiert wurden und trotzdem noch das letzte Stückchen Beweis eingefordert haben.

>keine Beispiele für gute Android Apps
Deine Aussage zu jeder HTML5 App, die man dir nennen würde. Und natürlich hast du jede App vorher gewissenhaft in Augenschein genommen ;^)