DLL für Android oder iOS?

[himitsu]

Zitat von mjustin:

Update: ab iOS 8 werden dynamische Bibliotheken untersützt:

Wobei das Dynamisch nicht wirklich geklärt ist.
Sowas wie DLLs lassen sich doch in iOS schon immer laden. Es war nur das dynamische Laden (LoadLibrary) verboten, aber das statische Einbinden (via External-Aufruf) ging dennoch.

[arnof]

Zitat von himitsu:

Zitat von mjustin:

Update: ab iOS 8 werden dynamische Bibliotheken untersützt:

Wobei das Dynamisch nicht wirklich geklärt ist.
Sowas wie DLLs lassen sich doch in iOS schon immer laden. Es war nur das dynamische Laden (LoadLibrary) verboten, aber das statische Einbinden (via External-Aufruf) ging dennoch.

iOS ist sowas verboten no way! Kann man nur statisch via .a dazulinken lassen, hier gibt es ein Beispiel für den Barcodescanner (XE4)

Bei MacOSX gibt es, wenn das din in den Appstore soll so gut wie keinen weg, ich versuche hier nur seit Monaten ein Miniprg in den Store zu bekommen, gestern bekam ich wieder eine Ablehnung (echt zum )

[Sherlock]

Ich finds eigentlich gar nicht schlecht, daß die Abhängigkeit von DLLs unterbunden wird. Monolithische Applikationen haben den entscheidenden Vorteil, daß sie nunmal einfach laufen, weil es keine Abhängigkeiten von Drittinstallationen gibt. Klar kann die DB kaputt sein oder sowas, aber das lässt sich fixen. Wenn man erstmal in der DLL-Hölle ist, lässt sich da auf potentiell tausenden Endgeräten wirklich nur noch schwer etwas machen. Das ist dann eine negative "User-Experience" und fällt am Ende immer auch auf den Gerätehersteller zurück.

Wenn man also unter Windows auf eine DLL angewisen ist, muss man sich eben bei anderen Systemen umsehen, ob man nicht ein Äquivalent fest einbinden kann.

Sherlock

[mjustin]

Zitat von Sherlock:

Ich finds eigentlich gar nicht schlecht, daß die Abhängigkeit von DLLs unterbunden wird.

Dass jede Anwendung ihre eigene OpenSSL Bibliothek einkompiliert haben muss, hat auch Nachteile. Nicht wegen der Speichernutzung, sondern weil jedes OpenSSL Update erst einmal vom App-Hersteller in die App integriert werden muss, Anwender eine Sicherheitslücke daher nicht selber schliessen können, sondern warten müssen bis das Update eintrifft.

[Sherlock]

Und SSL Routinen des OS zu nutzen geht nicht weil? Ernste Frage, denn ich brauch das für gewöhnlich nicht.

O'Neill

[himitsu]

Bei den mobilen "Apps" ist das doch Anders.
Die laufen quasi alle unabhängig und nutzen keine gemeinsamen Fremdkomponenten.
Jede App bringt ihre eigenen Fremdkomponenten mit und somit gibt es diese DLL-Hölle aus Windows nicht, welche dort auch nur auftritt, wenn die DLLs in irgendwelchen globalen Verzeichnissen rumliegen.

[Sherlock]

Meine Rede. Ich wollte nur noch erläutern, warum das mMn so ist.

Sherlock

[mjustin]

Zitat von himitsu:

Bei den mobilen "Apps" ist das doch Anders.
Die laufen quasi alle unabhängig und nutzen keine gemeinsamen Fremdkomponenten.
Jede App bringt ihre eigenen Fremdkomponenten mit und somit gibt es diese DLL-Hölle aus Windows nicht, welche dort auch nur auftritt, wenn die DLLs in irgendwelchen globalen Verzeichnissen rumliegen.

Unter Android werden SSL Funktionen von der Android Umgebung direkt bereitgestellt (z.B. HttpsUrlConnection), sie müssen nicht mit der eigenen App mitgeliefert werden. Das bedeutet natürlich, dass man auf die Sicherheitsfixes angewiesen ist, die je nach Hersteller schnell, langsam, oder überhaupt nicht eintreffen.