For some reason my compose desktop app crashes in macOS. The weird part is, it only crashes when I r...

# compose-desktop

[theapache64]

For some reason my compose desktop app crashes in macOS. The weird part is, it only crashes when I run the exported app/dmg. Not even in the runDistributable. How do I get the crashlog in this case?

[spierce7]

https://kotlinlang.slack.com/archives/C01D6HTPATV/p1630680806130800

[theapache64]

🤔 what’s app folder here?

[spierce7]

If you compile a DMG and then extract the DMG. The contents of the DMG look like an application, but it’s really just a folder that you can open by right clicking and clicking inspect contents

[spierce7]

If you go to your mac applications folder - all of those “applications” are just folders.

[theapache64]

Understood 👍

[spierce7]

instead of inspect contents it’s show package contents

[theapache64]

@spierce7 I can the access logs now, but it doesn’t crash when I run the app through this way 😞

[spierce7]

when you double click on the app folder to open the app it crashes?

[spierce7]

That sounds like it might be a relative pathing issue for accessing files. Are you accessing files via relative paths at all?

Install Bugsnag. You should get the cause of the crash there - https://docs.bugsnag.com/platforms/java/other/

[theapache64]

this is what happening…

Kapture 2021-09-07 at 01.09.03.mp4

[theapache64]

the first launch done via finder. then the second done via Contents/MacOS/<app name>

[spierce7]

your app looks nice 🙂 Give bugsnag a shot like I mentioned above.

[theapache64]

thanks 🙇 Hmmm.. let me try that one also

[spierce7]

After you initialize it - you can collect logs yourself, and then add them to the bug report via the following:

bugsnag.addCallback { report ->
    val logString = logHandler.logs.joinToString(separator = "\n")
    report.addToTab("logs", "log", logString)
}

[theapache64]

@spierce7 thanks. I got the culprit!

[spierce7]

I’ve dealt with file pathing issues a lot when moving between production and dev builds.

[theapache64]

I see. am a noob in desktop app development 😄

[spierce7]

We’re all noobs 🙂 Let me share with you what I’ve learned

[spierce7]

Inside your gradle script, you can set an appResourcesRootDir

[theapache64]

what does it do? 🤔

[spierce7]

compose.desktop {
    application {
        mainClass = "com.blahblah.MainKt"
        jvmArgs += listOf("-Xmx2G")

        nativeDistributions {
            includeAllModules = true
            targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
            packageVersion = versionString
            packageName = "Blah Blah"

            appResourcesRootDir.set(project.layout.projectDirectory.dir("resources"))

[spierce7]

They added this after I complained about this issue, but I haven’t seen documentation for it.

[spierce7]

I added the above script in the app gradle module’s build.gradle file.

That makes my root resources directory <project root>/app/resources

[spierce7]

the resources directory allows you to ship common resources for all platforms, but also allow you to ship platform specific resources.

If you add any files you want to ship with your application in the <resource root>/common/ folder, they will be shipped with all platforms.

[spierce7]

Then you can get that folder directory in production or development by calling:

val resourceRoot = File(System.getProperty("compose.application.resources.dir"))

[spierce7]

make sense?

[theapache64]

Understood 💡

[spierce7]

I don’t know where you keep the apk-tool.jar file, but that would be a way you could access it in a consistent way across app build types.

[spierce7]

@theapache64 Are you calling apk-tool.jar via the command line / ProcessBuilder?

[theapache64]

no.. the above exception is happening here . it happens when i create a copy of the jar file.

[spierce7]

I see - so you are including it in your java resources, which packages it in your application jar. Then you are trying to extract it so you can call it?

[theapache64]

Yes.

[spierce7]

The resources solution I gave you above removes the need to extract the file. It is shipped extracted.

[theapache64]

yeah, i think that should help here.

[spierce7]

👍 Poke me if that doesn’t solve it for you

[theapache64]

Sure. will try that maybe tmrw. and will update here 🙂 its sleep time here in India 😄

[theapache64]

thanks for the help 🙇

[spierce7]

np

[theapache64]

@spierce7 The root cause was, when i say Path("myDir") in non-dmg build, it was referring to execution-path/myDir but in dmg/app build, it was pointing to /myDir (root) 😕
since it was a read-only dir, i couldn’t create files in it. that’s why i was getting crash.

[spierce7]

Yeah

[spierce7]

There are a lot of factors

[spierce7]

Like where the app is opened from

[spierce7]

It's basically amounting to your working directory

[theapache64]

Understood. Anyway, bugsnag helped a lot in this. thanks 😄

[spierce7]

Glad you got it sorted out

[spierce7]

So did you end up using the compose resources directory?

[spierce7]

Or did you just adjust your path resolution accordingly

[theapache64]

as of now, fixed the path resolution. but i’ll be moving with appResourcesRootDir if it can help me avoid the

this::class.java.classLoader.getResourceAsStream

to copy the resources.

[theapache64]

but even without appResourcesRootDir.set(project.layout.projectDirectory.dir("resources")) ,

System.getProperty("compose.application.resources.dir") was returning a same path 🤔

[theapache64]

I am not sure how appResourcesRootDir would be helpful in my situation since its a desktop only app

[luen]

How create animated listlazy?

[theapache64]

@luen wrong thread I guess.