Moin Zusammen,
Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu
programmieren und will das mit Qt machen.
Zunaechst mal, hier gibt es eine sehr empfehlenswerte Anleitung:
https://retifrav.github.io/blog/2017/12/28/qt-for-android/
Damit habe ich es letztlich hin bekommen. Aber die Installation war
einige Stunden Aufwand.
Mein System: Centos 7.4
Qt-Version: 5.12
Java: jdk1.8.0_181
ndk: android-ndk-r16b
sdk: android-studio-ide-182.5199772
Der Haken, man bekommt sehr schnell Probleme wenn die Kombination aus
Qt-Version, Java Version, ndk und sdk nicht genau passend ist. Man kann
auch unter der Haube schnell Probleme bekommen. (gcc oder clang) Es ist
auch keineswegs sichergestellt das man nicht noch irgendwo im System
eine zu alte Libary hat. Wenn man kein SuperGuru Wissen genau fuer diese
spezielle Software hat dann braucht man sehr schnell Anleitung und Hilfe
aus dem Internet. Die kann aber auch schnell total falsch sein wenn sie
auch nur eine Version zu alt oder neu ist.
Und das Problem hat man nicht nur hier. Es ist also jetzt kein Qt
Problem.
Praktisch jede moderne Entwicklungsumgebung ist derart extrem fett und
aufgeblaeht (Tausende von Libary im Untergrund) mit teilweise bizarren
Abhaengigkeiten. Um das Problem auch nur grob in den Griff zu bekommen
installieren sich da mittlerweile Gigabytes weil die Maintainer alles
reinpacken. Dabei kommt natuerlich sehr viel bei er Installation aus dem
Netz. Vermutlich ist es unmoeglich zwei Wochen spaeter nochmal dieselbe
Entwicklungsumgebung aufzusetzen und ein identisches Binaerfile zu
erzeugen.
Da frag ich mich langsam wie das weitergehen soll. Es ist doch nur noch
eine Frage der Zeit bis alles zusammenbricht weil es keiner mehr was
hinbekommt...
Jedenfalls wuenscht man sich das jede Software einen kleinen Knopf hat
mit dem man dem Entwickler einen elektrischen Schlag von 1Volt versetzen
kann und er mal die Summe des von ihm verursachten Unmutes alle User
verspuert. :-D
Olaf
Olaf schrieb:> Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu> programmieren und will das mit Qt machen.
Ungeeignetes Werkzeug. Kann man machen, gibt nur Schmerzen.
Olaf schrieb:> Praktisch jede moderne Entwicklungsumgebung ist derart extrem fett und> aufgeblaeht (Tausende von Libary im Untergrund) mit teilweise bizarren> Abhaengigkeiten.
Man kann Android-Programme auch mit vim schreiben und mit den Tools aus
dem Android-SDK zu Fuß per Makefile bauen. Aber ob man das will, ist
fraglich.
Sicher ist, dass die Mehrheit der Android-Developer soetwas nicht
nutzen. Dementsprechend ist das für Google keine Priorität - für andere
auch nicht.
Olaf schrieb:> Vermutlich ist es unmoeglich zwei Wochen spaeter nochmal dieselbe> Entwicklungsumgebung aufzusetzen und ein identisches Binaerfile zu> erzeugen.
Warum sollte man das tun?
Warum sollte man das wollen (für Android)?
Die moderne Lösung ist, eine VM (oder ganz modern: einen
Docker-Container) mit der gewünschten Version aufzusetzen und den zu
benutzen. Google spezifiziert für jede Android-Version eine spezifische
Ubuntu-Version und gut ist.
Olaf schrieb:> Da frag ich mich langsam wie das weitergehen soll. Es ist doch nur noch> eine Frage der Zeit bis alles zusammenbricht weil es keiner mehr was> hinbekommt...
Die Mobile Welt besteht aus Systemen, die für kontinuierliche Wartung
gebaut sind. Es kommen Updates, die Anwendungen gehen kaputt, die
Anwendungen werden aktualisiert, alles ist prima. Das Silicon Valley
lebt nicht in der Vergangenheit, sondern in der Zukunft.
Stabile Apps bringen nichts in einer Welt, die auf Services aufbaut. Da
sich mit Software allein schlicht kein Geld mehr zuverlässig verdienen
lässt und Cloud-Dienste zusätzliche Möglichkeiten bieten, geht die Welt
eben da hin.
Augenblick mal – die Cloud-Dienste wollen doch permanent neue,
zusätzliche Features verkaufen. Bugfixes für Probleme, die durch
unsinnig hohe interne Komplexität entstanden sind, bringen doch kein
Geld. Ganz im Gegenteil – die verzögern die Entwicklung neuer Features.
Das war nicht so geplant. Da sind sowohl die BWLer als auch die
Programmierer ganz gewaltig auf die Schnauze gefallen.
Während des Hypes musste ein Cloud-Dienst ein paar Tage früher auf dem
Markt sein, als die Konkurrenz. Damals hatte niemand Zeit für einen
sauberen, übersichtlichen Aufbau. Dadurch ist alles dermaßen unsinnig
Komplex geworden, dass wir es Heute nicht mehr aufräumen können.
Den riesigen unentwirrbaren Haufen in einen Container packen und auf
jede grundlegende Weiterentwicklung verzichten? Auf neue Werkzeuge
verzichten, weil jede Veränderung den Mikadohaufen zum Einsturz bringt?
Du widersprichst dir selbst. Dein Vorschlag beendet die
Weiterentwicklung der Cloud-Dienste.
Stabile Software interessiert heute in weiten Teilen keinen mehr,
Hauptsache, man kann möglichst schnell liefern. Dass dafür 100.000
Frameworks nötig sind, die Verantwortlichen interessiert das nicht.
Komplexität ist der Feind jeder Sicherheit, und trotzdem bügelt man halt
einfach noch schnell eine Schlangenöl-Pseudosecurity-Library drüber um
das ganze "sicherer" zu machen, weil man die Software so schon nicht im
Griff hat.
Allgemein bekanntes Problem, v.a. im Web- und Appbereich. Kein Wunder,
gerade dort müssen Programmierer in erster Linie billig sein.
Komplexität ist auch der Feind der Wirtschaftlichkeit. Billige Leute
irgendwelche Schnellschüsse übereinander stapeln lassen? Das ist nur ein
paar Jahre lang wirtschaftlich. Inzwischen wachsen uns die Kosten für
Workarounds, Bugfixes und Sackgassen über den Kopf.
Eigentlich haben wir immer wieder das selbe Problem.
In den 70ern wurden die Großrechner zu komplex. Jede popelige
Programmänderung dauerte Monate. Wir hatten mit PC-Netzen neu
angefangen.
In den 90ern wurden die PC-Netze zu komplex. In diesem Wildwuchs an
inkompatiblen, undokumentierten Protokollen ging nichts mehr voran. Die
Antwort waren dann die Web-Dienste.
HTML Dokumenten-Browser als Applikativen-Framework nutzen - da ist uns
die Komplexität ziemlich schnell über den Kopf gewachsen. Wir schreiben
Apps statt Weboberflächen.
Inzwischen ist in der App-Programmierung das Sammelsurium an Frameworks,
Containern und Deployment-Scripten zu komplex geworden. Mal schauen, was
als nächstes kommt.
Hinz und Kunz schrieb:> Billige Leute irgendwelche Schnellschüsse übereinander> stapeln lassen? Das ist nur ein paar Jahre lang wirtschaftlich.
Nur, wenn du langfristig denkst. Wenn deine Lösung nur 2 Jahre halten
muss, dann sind Schnellschüsse billiger als eine richtige Lösung.
Wenn du deinen Kunden alle 2 Jahre eine vollständige Neuentwicklung
verkaufen kannst, sind Schnellschüsse trotzdem sinnvoll. Vor allem, wenn
sich die Anforderungen und Wünsche ständig ändern.
Und zu guter Letzt bestehen die meisten Startups nur aus Kapital und
einer Idee. Entwickelt wird maximal ein proof-of-concept, der dann
produktiv eingesetzt wird und hoffentlich so lange hält, bis eine
richtige Lösung mit richtigen Entwicklern entwickelt werden kann.
Time-to-market ist wichtiger.
Nur mal so ein Gedanke….
Google will weg von Open Source, einen Android Nachfolger durchsetzen,
bei dem Google alles unter Kontrolle hat. Deren Strategie: Sie machen
die Entwicklungsumgebung so komplex, dass niemand mehr LineageOS weiter
entwickeln kann. Das niemand mehr Entwicklungsumgebungen für den Android
Nachfolger bauen kann. Und das niemand mehr fremde Libraries in die
Google Welt einhängen kann.
Traut ihr Google so eine Strategie zu? Oder entsteht die Komplexität
einfach nur aus der Kurzsichtigkeit der Manager?
Hinz und Kunz schrieb:> Traut ihr Google so eine Strategie zu?
Nein, das wäre Google-untypisch. Außerdem unterschätzt du die Entwickler
alternativer Distributionen und überschätzt die Entwickler von
Android-Hardware.
Der Tod von Android wird so aussehen, dass ein alternatives, aber
kompatibles Betriebssystem angekündigt wird (ChromeOS unterstützt
Android-Apps, ist also machbar). Dieses System wird im Gegensatz zu
Android weiterentwickelt, bis es für Entwickler zunehmend eklig wird,
beides bei voller Funktionalität zu unterstützen. Irgendwann wird die
Unterstützung der Google Services für Android aus technischen Gründen
eingestellt und die Plattform ist damit wirtschaftlich tot.
Das sehe ich auf absehbare Zeit nicht kommen. Smartphones sind schwierig
und Google scheint sich nicht mit den tausend Eigenheiten der
verschiedenen Märkte und Operators rumschlagen zu wollen. Das überlassen
sie den Smartphone-Herstellern.
Android Things ist da eine andere Hausnummer: Da gibt es zertifizierte
Module und gut ist. Eigene Hardware kann man mit Android Things nicht
nutzen und für das normale Android in solchen Szenarien gibt Google
keine Zertifizierung.
Hinz und Kunz schrieb:> Oder entsteht die Komplexität> einfach nur aus der Kurzsichtigkeit der Manager?
Google ist riesig. Die Entwickler sind fähig und haben die Freiheit, das
aus ihrer Sicht beste System zu bauen. Als Konsequenz hast du sehr viele
Systeme, die jeweils unterschiedliche Probleme lösen. Das Zusammenspiel
funktioniert "irgendwie", weil Google groß genug und fähig ist, um
regelmäßig ganze Subsysteme umzuschreiben.
Wenn man da von draußen draufguckt, ist das einfach nur pfui.
Aber es funktioniert. Nicht, weil es elegant ist, sondern weil man da
täglich tausend Commits reinstecken kann.
Hinz und Kunz schrieb:> Komplexität ist auch der Feind der Wirtschaftlichkeit. Billige Leute> irgendwelche Schnellschüsse übereinander stapeln lassen? Das ist nur ein> paar Jahre lang wirtschaftlich. Inzwischen wachsen uns die Kosten für> Workarounds, Bugfixes und Sackgassen über den Kopf.
Bin ich mir nicht sicher, irgendwie scheints zu funktionieren.
Aber ja, hoffentlich implodiert das ganze mal.
Anscheinend können wir uns nur zwischen 2 Extremen entscheiden, die
beide nur einige Jahre funktionieren.
Wenn wir die Entscheidungen den einzelnen Handwerkern überlassen, wird
das Zusammenspiel der Einzelteile zu komplex.
Wollen wir das Zusammenspiel planen, bekommen wir eine unfähige
Bürokratie, das alles lahmlegt.
Ich bin für den ersten Weg. Während uns die Komplexität Kopf wächst,
können wir einfach etwas neues aufbauen. Die Bürokraten dagegen
verhindern mit aller Macht die Suche nach Auswegen. Wenn ich mir die
Bürokratie in der DDR oder beim Berliner Flughafen so anschaue - da
wähle ich auf jeden Fall die implodierende Komplexität.
Benutzt doch einfach iOS-basierte Systeme. Da kommt vom Chipdesign bis
zu den Apps alles aus einer Hand und ist stimmig kombiniert.
Dieses System ist euch zu geschlossen? Um ein einheitliches Design
durchzusetzen braucht es nunmal Restriktionen.
Dr. Sommer schrieb:> Benutzt doch einfach iOS-basierte Systeme. Da kommt vom Chipdesign bis> zu den Apps alles aus einer Hand und ist stimmig kombiniert.
Ja ne, is klar. Apple ist ja das perfekte Beispiel für schlanke Software
ohne unnötige Komplexität.
Ach, doch nicht: https://blog.fefe.de/?ts=a2be40ecHinz und Kunz schrieb:> Ich bin für den ersten Weg. Während uns die Komplexität Kopf wächst,> können wir einfach etwas neues aufbauen.
Wunderbar. Und gleichzeitig wird Software immer unsicherher, weil sie
kaum noch wartbar ist, und 100000 Abhängigkeiten reingezogen werden.
Gipfel ist ja das Electron-Framework, wo simple Desktopanwendungen auf
einmal in Javascript geschrieben werden und eine komplette Brwoserengine
im Hintergrund brauchen. Electron ist eine massiv unsichere Technologie,
wie ein Webbrowser aus 2014 ohne Updates. Und der wie damals Firefox für
seine Extensions APIs exponiert. Führt halt dann zu sowas:
> The vulnerability allowed nodeIntegration to be re-enabled, leading to> the potential for remote code execution. [...]> Some popular applications such as Slack, Discord, Signal, Atom,> Visual Studio Code, and Github Desktop are all built using the> Electron framework.https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/cve-2018-1000136-electron-nodeintegration-bypass/
Oder sowas:
> out of 98 top Electron apps, they averaged 145 known Common> Vulnerabilities & Exploits each due to unpached versions of Chromiumhttps://twitter.com/jacobrossi/status/851992646151278592
Ich sehe in dem Zusammenhang noch eine weitere wichtige Fragestellung.
Wieso wird moderne Software eigentlich nie fertig? (das war mal besser!)
Schauen wir uns als Beispiel mal Internetbrowser an. Es ist klar das die
erste Version von Mosaic nicht perfekt war und es da am Anfang einen
gewissen Entwicklungsbedarf gab. Aber man sollte doch meinen das man da
mittlerweile ein ausgereiftes Konzept/Standards hat. Man niemals mehr
etwas verbessern muss, oder vielleicht alle 10Jahre mal den HTML
Sprachumfang leicht verbessert und ansonsten nur alle paar Monate,
später Jahre, mal ein Sicherheitsupdate raushauhen muss.
Die Realitaet sieht irgendwie anders aus.
Man koennte meinen Programmierer arbeiten bewusst darauf hin niemals
arbeitslos zu werden. :-)
Olaf
Olaf schrieb:> Man koennte meinen Programmierer arbeiten bewusst darauf hin niemals> arbeitslos zu werden. :-)
Genau so ist es. Mit neuen Funktionen kann man mehr Kunden gewinnen. Da
Software kein Verschleißteil ist muss man neue Versionen verkaufen
anstatt immer wieder die selbe Version - irgendwann hat die jeder. Wer
keine neuen Funktionen implementiert, wird von der Konkurrenz verdrängt.
Ein Nebeneffekt ist dass alte Versionen auch keine Sicherheitsupdates
mehr bekommen (viel zu aufwendig/teuer), sodass man auch niemandem, der
moralische Probleme mit aktueller Software hat, empfehlen kann 10 Jahre
alte Software (insb. Browser) zu verwenden.
Oder meinst du dass Microsoft morgen alle Programmierer entlassen würde
und einfach die nächsten 10 Jahre Lizenzen für die aktuellen
Programmversionen verkaufen könnte?
Vor ein paar Jahren wollte ich auch mit der Android-Pogrammierung
anfangen. Android-Studio runtergeladen und installiert. Waren etwa 4GB.
Es wurden diverse Frameworks installiert, Java u.a.. IDE gestartet,
Dateidialoge haben nicht funktioniert, "Datei nicht vorhanden" oder so
aehnlich. Nach einer Neuinstallation das gleiche nochmal. Ich hab dann
damit aufgegeben. Wenn so was Grundlegendes und eigentlich Einfaches
schon nicht funktioniert...
Aber irgendwie ist es auch sysrmtemimmanent. Nur mit komplexen
Werkzeugen lassen sich komplexe Systeme erstellen. Und wirtschaftlich
muss es auch noch sein. Der Kunde tut sein uebriges dazu. Er kauft den
Akkuschrauber zum gleichen Preis lieber mit Schnellstoppfunktion,
Selbstarretierung, Bohrfutterbeleuchtung, Display und Internetradio und
nimmt dafuer mangelnde Qualitaet in Kauf.
Ich bin momentan bei Processing "hängengeblieben", damit lassen sich
auch mit vorwiegend C-Kenntnissen recht einfach Apps erstellen. Dafür
jetzt noch Java und OOP zu lernen, würde ich mir nicht antun wollen.
> jetzt noch Java und OOP zu lernen, würde ich mir nicht antun wollen.
Qt ist schon nicht schlecht. Das was man an Zeit investieren muss um C++
zu lernen spart man locker durch die vom System mitgebrachten Funktionen
wieder ein. Bloss die Installation muss man einmal schaffen.
Und es ist natuerlich extrem praktisch das man fast dasselbe Programm
auf dem PC wie auf dem Handy laufen lassen kann.
Olaf
Es kommt halt auf die Anwendung an. Auf dem PC bin ich bis jetzt mit
GTK+ und SDL gut ausgekommen, da brauche ich nicht unbedingt C++.
Ich habe jetzt auch nicht vor, professionell Apps zu programmieren, mir
geht es momentan eher darum, alte Smartphones zu einer Art "zweitem
Leben" zu verhelfen, indem man sie als Robotersteuerung etc.
weiterverwendet.
Also: Kamera, Accelerometer und GUI, der Rest wird via Bluetooth
angebunden. Und selbst auf einem über 8 Jahre alten Samsung Wave,
welches ich von Bada auf Cyanogen umgeflasht habe, läuft das erstaunlich
flott.
Jörg
Olaf schrieb:> Und es ist natuerlich extrem praktisch das man fast dasselbe Programm> auf dem PC wie auf dem Handy laufen lassen kann.
Nachdem ich da auch schon durch bin (naja, noch nicht ganz): Prinzipiell
stimmt das schon, insb. was den Kram hinter der GUI betrifft. Wenn man
da konsequent mit den Qt-Funktionen für Netwerk, Files & Co gearbeitet
hat, ist das mit nur kleinem Aufwand angepasst.
Das Problem ist aber tatsächlich die GUI. Man kann den PC-Code zwar auch
fast 1:1 übernehmen, leider ist er dann auf Android nahezu unbedienbar.
Entweder schon rein geometrisch zu klein/unlesbar oder so an allen
Android-Konventionen vorbei, dass man auch nicht glücklich wird.
Also muss man mit QtQuick anfangen, wo es ja diverse Beispiele für
Flickable&Co gibt. Aber dann strickt man wieder in so einer komischen
Pseudosprache rum, die irgendwie vom Design her ein "moving target" ist.
Und dann ist das IMO auch noch alles ziemlich (schwach|un)dokumentiert
und tw. auch definitiv buggy. Auf jeden Fall ist eine mobil-taugliche
GUI (wenn sie etwas komplexer und hübsch sein soll) dann schon
aufwendig.
Und für die mobilen System-Eigenheiten (Background-Services,
Datenaustausch zwischen Apps, etc.) wirds dann richtig übel. Da brauchts
dann wieder natives Zeug oder Fremdlibs (zumindest bei 5.11, 5.12 muss
ich noch anschauen). Da muss man sich dann in die Niederungen begeben,
die man mit Qt eigentlich vermeiden wollte. Ich habs jedenfalls noch
nicht ganz verstanden.
> Also muss man mit QtQuick anfangen,
Bah!
> Das Problem ist aber tatsächlich die GUI. Man kann den PC-Code zwar auch> fast 1:1 übernehmen, leider ist er dann auf Android nahezu unbedienbar.> Entweder schon rein geometrisch zu klein/unlesbar oder so an allen> Android-Konventionen vorbei, dass man auch nicht glücklich wird.
Ich mach einfach mehrere mainwindow.ui.
Also z.B mainwindow_sonyZ.ui und mainwindow_ulefone.ui
Dann binde ich einfach ein eigenes Headerfile ein wo ich umschalte.
//#define SONY_Z
#define ULEFONE
#ifdef SONY_Z
#include "ui_mainwindow_sonyZ.h"
#endif
#ifdef ULEFONE
#include "ui_mainwindow_ulefone.h"
#endif
Der Nachteil ist natuerlich das man zwei ui pflegen muss. Aber soviel
Aufwand ist das auch nicht.
Die Ursache allen Uebels ist im uebrigen nicht so sehr die Geometrie
oder die Aufloesung sondern die stark unterschiedliche dpi. Ich hab hier
ein 10" Tablett und ein kleines Handy mit fast gleicher Aufloesung. Da
muss man schon andere Fonts und Buttongroessen verwenden. Ich denke
damit kann man auf dem PC auch viel Spass haben wenn man sich einen 4k
Monitor kauft.
Olaf
Olaf schrieb:> Wieso wird moderne Software eigentlich nie fertig? (das war mal besser!)
Weil sich die Anforderungen ändern und es im Gegensatz zu früher einfach
möglich ist, darauf einigermaßen schnell zu reagieren. Liegt die
Reaktionszeit unterhalb eines vollständigen Entwicklungszyklus, ist die
Software dauerhaft im Fluss.
Es gibt keine Zeit mehr, um einfach mal ein halbes Jahr "Stabilisierung
ohne Weiterentwicklung" zu spielen. In der Zeit würde das nämlich die
Konkurrenz machen.
Olaf schrieb:> Schauen wir uns als Beispiel mal Internetbrowser an.
Meinst du damit den Internet Explorer 6, der ja erstaunlich lange
"final" war und die Webentwickler in den Wahnsinn getrieben hat?
S. R. schrieb:> Olaf schrieb:>> Schauen wir uns als Beispiel mal Internetbrowser an.>> Meinst du damit den Internet Explorer 6, der ja erstaunlich lange> "final" war und die Webentwickler in den Wahnsinn getrieben hat?
Vermutlich eher den Firefox 64.0 - ach nee, der ist schon bei 65.0.
Gefühlt kommen zwei neue Major-Releases pro Woche raus.
Vieles an Ramsch auf dem Android-Markt bekommt nach spätestens 2 Jahren
keine Updates mehr womit das System dann höchstwahrscheinlich auf
irgendeiner kaputtgepatchten Version stehen bleibt. Der Androide ist
wohlgemerkt NICHT "frei" - Updates gegen den Willen des Herstellers sind
ausgeschlossen.
Ansonsten finde ich die Diskussion hier eher übertrieben. Es ist nicht
alles "iHandy Taschenlampe" mit einem Release-Cycle von 2 Wochen - so
2-3 Jahre muss man an unserer App z.B. schon gearbeitet haben, um
überall mal vorbei gekommen zu sein.
Gefühlt liefern wir mittlerweile das halbe Betriebssystem in Form von
selbstkompilierten Libraries mit aus, um über ein weiteres Spektrum von
Android-Versionen Support mal hier, mal dafür zu haben.
Mit einer Qt-LTS-Version hätte ich schon geliebäugelt - ist frei und all
inclusive, kommt für uns aber keinesfalls in Frage. Für ein paar
Systemfunktionen wäre eine Sprachbrücke imho noch gerade tragbar. Als
dauerhafter Zwischenzustand in Kernbereichen der App eher nicht. Schade:
QML scheint mir gegenüber den Android-Views um einiges leichtfüßiger
unterwegs zu sein. Die Sprache mischt sich erheblich besser mit den
typischen "onClick"-Zweizeilern als die Androiden XML-Layouts, wo man
kleine Codeblöcke nur in XML-Attributen(!) unter Stützung durch eine
Java-Klasse einbetten kann. Vom Serverseitigen JSON direkt in den View
injecten ginge nur mittels Maps als Datenstruktur und scheinbar kann man
so auch nicht alle Eigenschaften setzen. Was uns zuweilen ziemlich
zusetzt ist das undurchsichtige Speichermanagement. "vm_overcommit 1"
hat so seine Nachteile, wenn man beliebige Mengen an Speicher gut
gebrauchen könnte, sich dann aber auch mal das System verabschiedet. Das
macht eine Java-VM nicht unbedingt besser: Kommt schon mal vor, dass der
GC mit ein paar fetten Speicherbrocken in der Queue rumsitzt und meint
"Ich bin clever und lazy" während im Untergrund der Renderloop mit "Out
of Memory" aussteigt. Überhaupt bedarf das virtuelle Zeugs einiges an
designtechnisch ziemlich ungesunden Verrenkungen: Da werden regelmäßig
funktionslokale Variablen zu Klassenmembers, um zu verhindern, dass der
GC die Animation abwürgt und strukturierte Daten, da diese
Speicherallokationen benötigen, generell zugunsten von Spaghetticode
vermieden: Eine temporäre Matrix manuell als "float m0, m1, ...."
auszuschreiben und dann so damit zu rechnen ist in einer Androiden
onDraw()-Funktion einfach nur Gosu!
> einfach nur Gosu!
Kann es sein das du dein Leben ueberwiegend mit Selbstgespraechen
verbringst weil es kaum jemanden gibt der deine Worte versteht? .-)
Olaf
Olaf schrieb:> Kann es sein das du dein Leben ueberwiegend mit Selbstgespraechen> verbringst weil es kaum jemanden gibt der deine Worte versteht? .-)
Ich weiß das macht hier den Anschein ... - ist aber doch zu bezweifeln.
Was auch immer ein Gosu sein mag. Ich hab mal etwas gegoogelt und
wikipediert. Es gibt/gab eine Programmiersprache, die so heißt, und im
Gamer-Jargon bezeichnet man wohl jemanden mit überragend guten
Fähigkeiten so. Beides passt irgendwie nicht so zu der Aussage. Dann
gibt's noch eine Bibliothek für Spieleprogrammierung in Ruby mit dem
Namen.
Also keine Ahnung, was das sein könnte.
Vielleicht ganz interessant das die Erkenntnis das sich was bessern
sollte
schon ganz oben angekommen ist. (vgl mein Ausgangsposting)
https://www.youtube.com/watch?v=5PmHRSeA2c8 (6:50 bis 11:30) (31:00 bis
34)
Nur Schade das es weiter unten noch nicht jedem einleuchtet.
Olaf
Olaf schrieb:> Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu> programmieren und will das mit Qt machen.
Zu Zwecken der persönlichen Weiterbildung ok. Zum Beispiel um zu
erkennen wie sehr man sich dann verrenken muß um Dinge zu tun die in der
offiziellen Sprache, mit den offiziellen APIs ein Klacks wären.
Ich hatte auch mal so eine Phase. Android Apps programmieren mit allem
Möglichen, nur nicht mit den offiziellen Tools. Schmerzen, Verrenkungen,
noch mehr Schmerzen. Fazit: Es ist die Mühe nicht wert. Android Studio
installieren und ganz normal wie Millionen andere auch mit Java und dem
offiziellen API und den offiziellen Tools arbeiten, dann kann man bei
Problemen auch mal googeln und findet zutreffende Hilfestellung oder
Beispiele die man nicht immer erst wieder rückübertragen muß auf den
exotischen Ansatz den man selber fährt und sonst nur noch 3 andere auf
der Welt.
> noch mehr Schmerzen. Fazit: Es ist die Mühe nicht wert. Android Studio> installieren und ganz normal wie Millionen andere auch mit Java und dem
Mal abgesehen davon das ich mit so einem Mist nicht meine Lebenszeit
verschwende, ich geniesse es das ich meine Programme sowohl unter
Android wie auch Linux, ja gelegentlich sogar Windows nutzen kann.
Olaf
Olaf schrieb:> ich geniesse es das ich meine Programme sowohl unter Android wie auch> Linux, ja gelegentlich sogar Windows nutzen kann.
Wenigstens einer ;-) Ich kann den plattformunabhängigen Müll nicht
leiden. Riesengroß, läuft auf allen Plattformen aber auf keiner richtig.
Die unterschiedlichen Plattformen haben viel zu unterschiedliche
Bedienkonzepte.
Olaf schrieb:> Mal abgesehen davon das ich mit so einem Mist nicht meine Lebenszeit> verschwende, ich geniesse es das ich meine Programme sowohl unter> Android wie auch Linux, ja gelegentlich sogar Windows nutzen kann.
Vermutlich schreibst du halt auch Programme, die was leisten, und keine
Apps.
> Die unterschiedlichen Plattformen haben viel zu unterschiedliche> Bedienkonzepte.
Ich fuerchte da muss ich eine gegenteilige Position einnehmen. Die
unterschiedlichen Bedienkonzepte sind oftmals dem Nutzungsprofil
geschuldet. Bedien doch mal Windows (oder auch Linux) auf einem Tablett
oder Laptop das sich als Tablett nutzen laesst und du wirst sehen wie
bloed das ist.
Jetzt moechtest du aber vermutlich weder dein Handy mit der Maus
bedienen, noch zuhause am PC immer den Arm hochhalten um auf dem Monitor
rumzutatschen.
Was mich allerdings deutlich mehr nervt sind die grossen Unterschiede in
den dpi auch innerhalb einer Geraeteklasse. Allerdings ist das wohl
unvermeidlich wenn man mal ein gewisses Mass an Fortschritt erleben
moechte.
Olaf
