How do people handle deep links in windows apps? I...

# compose-desktop

[S.]

How do people handle deep links in windows apps? It's technically working, but for each link windows creates a new process - starts a second instance of my app. I found a common way to solve this for jvm apps, is to check for already running instances and then communicating back to the original one.
in my case I'm simply trying to bind a socket to the same port, which fails for subsequent instances. This approach does work, but it's not ideal because it adds delay due to spinning up another instance while also showing the splash image again. Are there any other solutions?

[phteven]

I am also doing it with a socket instance because it could not find any other way.

To avoid any ui you can check if socket is running / handle deep link before doing any ui stuff.
(If you mean compose ui splash screen)

[S.]

yeah it doesn't show actual compose UI but I mean the jvm splash image added with jvmArgs += "-splash:${'$'}APPDIR/resources/splash.png"

[S.]

it also requires a permission popup for network access, which doesn't make sense for a local first app

[אליהו הדס]

@S. check this https://github.com/kdroidFilter/ComposeNativeTray?tab=readme-ov-file#-single-instance-management

[S.]

this locks and communicates via files but it still has the same delay + splash image, doesn't it?

[S.]

I guess the solution is to have native code manage the startup of the actual app to prevent that

[אליהו הדס]

yes you are right, you need a script that sends the onrequeststartup

[S.]

time for kotlin native (and hopefully not too much headache)

[אליהו הדס]

Kotlin native on desktop is not even in the roadmap

[אליהו הדס]

and personally I don't see myself depriving myself of the Java ecosystem

[phteven]

Creating a distribution will create native launcher. Would be cool if that could be extended to handle deep links.

Compose native on desktop will require some abstraction to handle user input and io. I guess it's a lot of work to get that done for each os.

[S.]

no I'm not talking about native for compose, just k/n for the launcher

[אליהו הדס]

ah ok

[אליהו הדס]

https://github.com/JetBrains/kotlin-desktop-toolkit

[אליהו הדס]

jetbrains is working on something, I don't know if it's for compose

[S.]

oh interesting. there's a lot to look into, I've never worked with kotlin native before

[S.]

for compose, maybe graalvm will be the answer but it also requires some work. better startup times are always welcome though

[אליהו הדס]

https://github.com/kdroidFilter/kotlin-libui maybe you can make your splashscreen with this

[אליהו הדס]

I was the one who resurrected the project

[אליהו הדס]

for compose, maybe graalvm will be the answer but it also requires some work. better startup times are always welcome though

You probably use a lot of libraries that use reflection, like jna, it won't work with graalvm

[S.]

local dbs probably do, yeah

[אליהו הדס]

I don't think graalvm is a solution, the solution is a new packaging system

[S.]

regarding splashcreen, do you mean during the native launcher? I hope it won't have to run for so long, and for the actual compose jvm app I might still be able to use the jvm splash image

[אליהו הדס]

We would need a packaging system that installs the JVM on the system and launches it when the machine starts. all composed apps would use it and they would start instantly

[אליהו הדס]

The installer checks if Java is installed and if not it should download it. This would also make the executable much lighter.

[אליהו הדס]

> regarding splashcreen, do you mean during the native launcher? I hope it won't have to run for so long, and for the actual compose jvm app I might still be able to use the jvm splash image
yes it's true, you don't need to do it natively, I was wrong

[S.]

tbh that's way out of my league. but since all store apps are sandboxed, idk if that will work

[אליהו הדס]

On Windows, I don't think it's a problem, on Linux either, on Mac certainly yes

[S.]

so if I run packageUberJarForCurrentOS I will get a jar with all dependencies, but I still need to provide a JRE in my package since I don't know if users have java installed?