Swing Client Anwendung für MAC OS (Update Routine)

eskimo328

Aktives Mitglied
Hi,
wir möchten unsere Windows Anwendung zusätzlich für Macbooks (MacOS) freigeben. Dazu haben wir uns ein aktuelles Macbook (Air) angeschafft.
Ich persönlich betrete mit Mac Neuland, habe mich aber die letzten Tage schon etwas eingearbeitet.

Anscheinend werden Programme in der Regel als Application Bundles verpackt und als .DMG File verteilt.
Habe bereits den ANT-Build erweitert, sodass per JarBundler ein Application Bundle und daraus ein .DMG File erstellt wird.

Nun zum Problem:
Unsere Anwendung aktualisiert sich über eine selbstgeschriebene Update Routine. D.h. Die Anwedung ruft per http eine XML Datei auf dem Update Server auf, vergleicht die Versionsnummer und downloadet die Files, die in der XML Datei definiert sind. Die Dateien werden in das Home Verzeichnis der Anwendung installiert. Man kann aber auch Unterordner in der XML angeben, die auch berücksichtigt werden.

Für Mac würde das bedeuten, dass Die Anwendung die aktuellen .jar Dateien downloadet und im Application Bundle unter ANWENDUNG.app/Contents/Resources/Java/ speichert.

1. Frage: Ist das so OK bzw. üblich? Oder wie machen das andere Java Desktop Anwendungen?

2. Frage: Könnte das zu Rechte-Problemen führen? D.h. könnte der Fall auftreten das der User z.B. keine Schreibrechte auf das Application Bundle hat?
 
Das dürfte nur dann funktionieren, wenn der User das App-Bundle in seinem Home-Verzeichnis ablegt. Unter Programme sind vermutlich SuperUser-Rechte notwendig und dann wird es knifflig. Es gibt eine Bib dafür, aber muss dann natürlich unterschiedliche Fassungen für die verschiedenen Betriebsysteme entwickeln: osx - I need to give a java application super user access to view protected files on a mac - Stack Overflow
Es funktioniert auch dann nicht (und zwar gar nicht), wenn das APP-Bundle signiert ist. Das ist dann notwendig, wenn es per AppStore ausgeliefert wird oder neuerdings, wenn das AppBundle aus dem Netz geladen wurde (Stichwort GateKeeper). Wenn die Auslieferung über ein Read-Only-Medium stattfindet, dann muss es nicht signiert sein.

MacOS X ist für Entwickler eine echte Qual.
 
Probier's doch einfach aus. Ich überschreibe in meinem updater im Moment einfach das ganze app Bundle aus dem update dmg mit cp und das klappt problemlos ohne root rechte. Sollte also auch klappen wenn du nur eine jar im bundle aktualisierst.
 
Probier's doch einfach aus. Ich überschreibe in meinem updater im Moment einfach das ganze app Bundle aus dem update dmg mit cp und das klappt problemlos ohne root rechte. Sollte also auch klappen wenn du nur eine jar im bundle aktualisierst.

Das komplette Überschreiben des app bundles ist scheinbar auch die favorisierte Option von Apple. Das Dumme ist allerdings, dass auf diese Weise jemand bei einem Update an das komplette Programm herankommt, was bei kommerzieller Software weniger schön ist. Manchmal will man ja auch nur einzelne Jar-Dateien oder Ressourcen aktualisierten. Das Schreiben in ein App-Bundle geht prinzipiell (ist ja nur eine Ordnerstruktur), aber man kann nicht sicher sein, dass es auch tatsächlich funktioniert: osx - Writing inside Mac application package/folder with Java - Stack Overflow (Erste Antwort)

Ich stehe momentan selbst vor diesem Problem und bin etwas ratlos. Meine Versuche mit dem PackageMaker waren diesbezüglich auch nicht erfolgreich. Wenn jemand dafür einen passenden Vorschlag hat wäre ich ebenfalls sehr dankbar.
 
Probier's doch einfach aus. Ich überschreibe in meinem updater im Moment einfach das ganze app Bundle aus dem update dmg mit cp und das klappt problemlos ohne root rechte. Sollte also auch klappen wenn du nur eine jar im bundle aktualisierst.

Wie machst du das dann genau?

Bei uns funktioniert das so, dass alle Pfade vom Installationsverzeichnis ausgehen, z.B. "C:\Programme\ANWENDUNG\". Darin gibt es ein Unterordner "lib" indem alle .jar files und auch die .exe Datei liegen. Weiterhin gibt es z.B. ein "img" Verzeichnis für Logos etc.

In der Update XML ist die aktuelle Versionsnummer sowie die Dateien definiert, die aktualisiert werden sollen. Also da steht z.B. drin, dass die Datei "abc.jar" nach "lib\abc.jar" installiert werden soll. Oder "logo.jpg" nach "img\logo.jpg". Das herunterladen/aktualisieren der Datei übernimmt die eigentliche Anwendung und kein separater Updater.

Problem bei Mac: Die .jar Files liegen in ".../Contents/Resources/Java/". D.h. bei Mac wäre sozusagen ".../Contents/Resources/" das Installationsverzeichnis? Und Für Mac müsste ich "lib" durch "Java" ersetzen. Dann sollte das klappen?
Oder gibt es bessere Ideen?
 
Mach es dir doch ganz einfach:
1) verzichte auf dieses umständliche Rumgehampel mit Setup-Packages und baue dir das lieber selbst zusammen
2) lege ALLE Daten unterhalb von user.home ab, denn dort bestehen für den User immer volle Schreibrechte
3) verwende einen Launcher, also etwas was VOR dem eigentlichen Start deiner App geladen wird und dabei gleich auf Updates prüft, danach greift der Launcher dierekt auf die unter user.home/.deineapp/jar auf die entsprechenden JARs zu (wenn möglich mit URLClassLoader) und startet so die eigentliche "main-Klasse"
4) da Windows auch solche Einschränkungen hat versuche es doch einfach halbwegs genau so auf MAC umzusetzen, sich da extra in OS-spezifische App-Packages einarbeiten ist für den Anfang der MAC-Entwicklung ziemlich sinnfrei


Das wäre so meine Idee. Nehmen wir als Beispiel mal Minecraft: dort gibt es auch nur einen Launcher (unter Windows mit Launch4J in eine EXE gewrapped) und diese wird "ausgeführt". Beim Start zieht der Launcher alle daten und packt sie irgendwo unter user.home (unter Windows in %APPDATA%).
Da es außer der EXE für Windows nur eine JAR für Unix/Linux/Mac gibt sollte der Funktionsablauf dem der Windows-EXE ähnlich sein.
Versucht es doch so zu lösen. Dann hast du volle Kontrolle über deine Daten und musst dich nicht mit irgendwelchen DMG oder sonstwas rumschlagen. Das ist IMO halt deutlich einfacher. Und wo dann der User das Launcher-JAR ablegt sollte so ziemlich egal sein, dürfte aber zu 99% auch irgendwo unter user.home sein ala "Downloads" oder "Desktop" oder wo auch immer.
 
Die Idee mit dem Launcher finde ich gar nicht so schlecht.
D.h. für Mac würde ich eine kleine Launcher Anwendung basteln und als App-Bundle verpacken (und als DMG verteilen).
Dann könnte ich, glaube ich, sogar die Windows-Variante belassen wie sie ist. Also ohne Launcher. Denn ich kann nicht die Bestandskunden alle so einfach umstellen.

Müsste man mal genauer drüber nachdenken. Hört sich aber nicht so verkehrt an.
 

Zurück
Oben