und die hat man ganz schnell zusammen, wenn man international auch
unterschiedliche carrier-revisionen, 3hrd party android
installationen, DAUs wie paranoiker die ihre OTA-Updates nicht
einspielen etc mitzählt (was man tunlich sollte ;) und unterstützt.
Aber: Das ist schlußendlich dann doch trivial.
So einige der Endkunden-apps sind funktionell nicht grade klein,
viele streaming video clients mit buffering und 3g/wlan/ip on the fly
wechsel, anspruchsvolles DRM & region control,
stream/buffer/download, remote datenbankzugriff auf die archive
uvm... also nicht ein schlichter taschenrechner oder eine uhr.
Was der Kollege falsch gemacht hat:
- Man darf NICHT von einem Zielgerät ausgehen, das beginnt 320*240
pixel müssen genauso funktionieren wie 2560*1600, man darf NICHT
vorraussetzen das funktionsbereiche wie bspw. 3G überhaupt vorhanden
& ansprechbar sind und man darf beim init NICHT irgendwelche frei
verfügbaren "gerät x hat folgende auflösung etc" librarys nutzen -
sondern explizit abfragen und auslesen - schlicht weil viele User das
auf ihren Geräten frei parametrisieren können, ein beispiel von
vielen: sony bspw. hat eine ganze subfunktionseinheit die 960*480,
1024*480, 1024*960 schaltbar (und das on the fly) als displayfläche
alloziert - wer das nicht abfragt sondern auf tabellen zugreift wird
zumindest UI bereiche abschneiden - oder gar crashen.
- Man braucht WIRKLICHE qualitätssicherung in-house, sprich mind.
einen vollprofessionellen teilzeit-Sadisten der gandenlos ALLE
schrauben verkehrt eindreht, und zwar nicht nur auf einem
referenzgerät, sondern auch gnadenlos in veralteten emulatoren mit
schrägsten resourcen und exotischen anno-domini endgeräten. War bei
unseren Apps sogar öfters outgesourced, denn wenn einer/die devs das
selber machen müssen, gibts ganz schnell kameradenschweinprobleme
wenn ein böser bug in den grundlagen sitzt, bzw betriebsblindheit -
und keinen Fokus auf den Code. Zudem sollte man Beziehungen zu den
top 15 Hersteller unterhalten - nach Events wie MWC kommen die
Leihgeräte kartonweise und da kriegt man dann schnell mit, wenn ein
Hersteller was besonderes in der Suppe hat. Besonders die Exoten wie
bspw. dual/multiscreen, hardwarecontroller & keyboards sind da gute
Laborratten, weil dis durch den Hersteller von schnell über schräg
bis schlampig programmierte Funktionen anflaschen oder unterbinden -
und wer bspw "moderneres" wie TYPE_ROTATION_VECTOR nutzt knallt bei
Android API level 8 eben gegen die Wand. Auch gern gesehen sind
"unerwartete" konstellationen, bspw geblockte telefonieapps trotz
gegebenen 3g, grade bei tablets immer wieder gern gesehen etc.
Sprich: Qualitätssicherung VORM publish, NICHT nach release beim
Kunden. Nicht auf Referenz, sondern auf worst case auslegen. NICHT
vertrauen, sondern testen. Nicht vom Heimatmarkt ausgehen, sondern
schön auch mit chinesichem 3/4g und japanischem Input bzw indischen
Frameworks foltern. Und da reicht ein, vielleicht zwei Routiniers -
so man das von Anfang an berücksichtigt und die nicht als Störer,
sondern als Testpiloten begreift.
Und hey, offen gesagt - das ist an für sich alles selbstverständlich.
Linux (mit zig distributionen und subvarianten & desktops) & windows
(und das mit zig versionen von xp mit ohne patch bis brandaktuelles
8er mit allem) sind ungleich komplexer, grade wenn man bspw.
hardwarenahe "altlasten" wie directx aus dem letzem jahrzehnt
braucht/mitführt, oder man denke nur an moto68/system-> macos/ppc->
osxppc-> osxx86; wenn man da hardwarenah oder gar auf treiberniveau
herstellte... dagegen sind die heutigen telefonOS ala
android/ios/windowsP dann doch recht einfach & bequem ;)
Und im Vergleich zur fantastilliarde an hardwarekombos der ibm pc
clones sieht dann der android-gerätezoo doch extrem übersichtlich
aus. Ausserdem führt so oder so kein Weg mehr dran vorbei, wer
android nicht supported verliert eben dann bald 90% der user der
telefonOS.
unterschiedliche carrier-revisionen, 3hrd party android
installationen, DAUs wie paranoiker die ihre OTA-Updates nicht
einspielen etc mitzählt (was man tunlich sollte ;) und unterstützt.
Aber: Das ist schlußendlich dann doch trivial.
So einige der Endkunden-apps sind funktionell nicht grade klein,
viele streaming video clients mit buffering und 3g/wlan/ip on the fly
wechsel, anspruchsvolles DRM & region control,
stream/buffer/download, remote datenbankzugriff auf die archive
uvm... also nicht ein schlichter taschenrechner oder eine uhr.
Was der Kollege falsch gemacht hat:
- Man darf NICHT von einem Zielgerät ausgehen, das beginnt 320*240
pixel müssen genauso funktionieren wie 2560*1600, man darf NICHT
vorraussetzen das funktionsbereiche wie bspw. 3G überhaupt vorhanden
& ansprechbar sind und man darf beim init NICHT irgendwelche frei
verfügbaren "gerät x hat folgende auflösung etc" librarys nutzen -
sondern explizit abfragen und auslesen - schlicht weil viele User das
auf ihren Geräten frei parametrisieren können, ein beispiel von
vielen: sony bspw. hat eine ganze subfunktionseinheit die 960*480,
1024*480, 1024*960 schaltbar (und das on the fly) als displayfläche
alloziert - wer das nicht abfragt sondern auf tabellen zugreift wird
zumindest UI bereiche abschneiden - oder gar crashen.
- Man braucht WIRKLICHE qualitätssicherung in-house, sprich mind.
einen vollprofessionellen teilzeit-Sadisten der gandenlos ALLE
schrauben verkehrt eindreht, und zwar nicht nur auf einem
referenzgerät, sondern auch gnadenlos in veralteten emulatoren mit
schrägsten resourcen und exotischen anno-domini endgeräten. War bei
unseren Apps sogar öfters outgesourced, denn wenn einer/die devs das
selber machen müssen, gibts ganz schnell kameradenschweinprobleme
wenn ein böser bug in den grundlagen sitzt, bzw betriebsblindheit -
und keinen Fokus auf den Code. Zudem sollte man Beziehungen zu den
top 15 Hersteller unterhalten - nach Events wie MWC kommen die
Leihgeräte kartonweise und da kriegt man dann schnell mit, wenn ein
Hersteller was besonderes in der Suppe hat. Besonders die Exoten wie
bspw. dual/multiscreen, hardwarecontroller & keyboards sind da gute
Laborratten, weil dis durch den Hersteller von schnell über schräg
bis schlampig programmierte Funktionen anflaschen oder unterbinden -
und wer bspw "moderneres" wie TYPE_ROTATION_VECTOR nutzt knallt bei
Android API level 8 eben gegen die Wand. Auch gern gesehen sind
"unerwartete" konstellationen, bspw geblockte telefonieapps trotz
gegebenen 3g, grade bei tablets immer wieder gern gesehen etc.
Sprich: Qualitätssicherung VORM publish, NICHT nach release beim
Kunden. Nicht auf Referenz, sondern auf worst case auslegen. NICHT
vertrauen, sondern testen. Nicht vom Heimatmarkt ausgehen, sondern
schön auch mit chinesichem 3/4g und japanischem Input bzw indischen
Frameworks foltern. Und da reicht ein, vielleicht zwei Routiniers -
so man das von Anfang an berücksichtigt und die nicht als Störer,
sondern als Testpiloten begreift.
Und hey, offen gesagt - das ist an für sich alles selbstverständlich.
Linux (mit zig distributionen und subvarianten & desktops) & windows
(und das mit zig versionen von xp mit ohne patch bis brandaktuelles
8er mit allem) sind ungleich komplexer, grade wenn man bspw.
hardwarenahe "altlasten" wie directx aus dem letzem jahrzehnt
braucht/mitführt, oder man denke nur an moto68/system-> macos/ppc->
osxppc-> osxx86; wenn man da hardwarenah oder gar auf treiberniveau
herstellte... dagegen sind die heutigen telefonOS ala
android/ios/windowsP dann doch recht einfach & bequem ;)
Und im Vergleich zur fantastilliarde an hardwarekombos der ibm pc
clones sieht dann der android-gerätezoo doch extrem übersichtlich
aus. Ausserdem führt so oder so kein Weg mehr dran vorbei, wer
android nicht supported verliert eben dann bald 90% der user der
telefonOS.