MapCompose

MapCompose copied to clipboard

Any plans on supporting multiplatform with jb compose for desktop app? 🥰

I will consider that once jb compose hits beta.

(According to the names of the of their releases they have hit beta and even RC :))

This will be my next priority after #19

Any news?)

I plan to start working on it in a few weeks.

I just found this project and it looks like exactly what I need. My app targets both desktop and android though. Is there any ETA for this? Seems like Jetbrains plans to make KMM stable by the end of the year

As I don't have much experience in KMM right now, my initial attempt to make this library a KMM project was a bit too much. It might be easier to just make it work for desktop, publish a new artifact like mapcompose-desktop, and then figure out a way to unify desktop and android code base under the same project. In any case, I would love to see this library work on desktop. It's just not my priority right now. Any contributions for the desktop evolution are welcome.

@wefhy Some time ago I was need multiplatform map. So I created one. https://github.com/Lewik/mapview It's a bit outdated, but demos (main.kt files) should work. If it interesting, I can update it. We used it in desktop and android. If you have any questions - feel free to text me, I'll help.

Thanks for the update!

I was able to port the project to desktop compose yesterday: https://github.com/krzysztofsroga/MapComposeDesktop It's not perfect, dp conversions are done with just an arbitrary number(so clusters and markers are not displayed properly) . But it required only a couple of changes to display the map correctly on desktop.

So to be honest we just need some gradle magician to merge these two projects together. In theory both Compose Desktop and Android Canvas use Skia under the hood so the changes are minimal and could probably be solved with expect/actual. But it might be better to wait a couple months until compose desktop is stable? Maybe then they'll have some proper android/desktop project support. PS if I messed something up with licensing, please let me know, I'm not an expert in this.

@krzysztofsroga That's amazing news! I'll have a look. You're right, ideally desktop and Android should be under the same project. However, having a working desktop version is a major step.

This commit contains all the changes that were required to make it compile for desktop (commits before were just copying the files and correcting package names) https://github.com/krzysztofsroga/MapComposeDesktop/commit/dcfbe77f839f7d36851dc7a19fbd18bde2b0a7ee

Honestly it's just a proof of concept, as much as I could do in a limited amount of time. I left like two TODO items (mainly dp conversion and something with drawing patches). I didn't check whether it all works good, just that it displays the map and lets me move it. But it generally wasn't much work.

I won't have much time for the next two-three weeks, but after that I can work on fixing any issues that might be there and maybe trying to merge these two into one project. I'd just need to learn a little about how gradle work and make sure both can use the same file structure.

Based on a coarse reading, I made a couple of comments. So that's really interesting. It shows the differences between the two platforms. So I guess the next step it to make it work properly on desktop, and then take a step back and see how the two projects can be merged. @krzysztofsroga No worries if you can continue in 2-3 weeks. Thanks!

I added some small changes. Looks like dpToPx needs to be initialized The way I added it might not be pretty, but it changes every time the window is moved between my screens (1f for big screen, 2f for small screen for me). And looks like it recomposes properly which is nice. On android dpi configuration changes are much less common. Clusters are still a little glitchy when zoomed in or when scrolled to right or bottom edge but now they seem to display equally decent on both screens.

One time after moving the window back and forth I got this though: So I guess dpi needs to be updated deeper in the code

Well, yeah, I'll look into this when I have free time. See you until then. For a proof of concept I'm satisfied for now 😅

Hmm.. tile size does not depend on dpi. If I had to guess, I would say the gap between tiles has something to do with the changes on tile positioning (the comment I made about the state). Anyway, we'll see. This is really nice for a proof of concept ;)

Hey guys, I hate to ask this question to open source devs... is this still somewhat of a priority? I am currently choosing my stack for compose multi-platform and I am desperately trying to avoid G&A-Maps. Thanks for your awesome work!

I made this library mostly because I'm using it on Android. Right now, I don't have time to make it multiplatform. That may change in the future. Meanwhile, I'm relying on open source contributors for this.

I was searching for compose library to use for openstreet map tile and i stumbled onto your library which seems promising and nice.Please update it for kotlin multiplatform, compose multiplatform. The usecase might be huge for those who dont want to use google or apple map.Thank you for your contribution and really apreciate it.

@prabinshrestha Yes. Actually, I'd like to make an ios version. However, Compose for ios is still in alpha. Updating it for compose multiplatform might be a better start as it would require most necessary structural changes.

Would love to see this for compose multiplatform. I started a new repo and started to change the code from of @krzysztofsroga in the repo MapComposeDesktop to make it work for multiplatform, but am not finished yet and couldn't test the changes by now. For me it is more of a learning opportunity, because I am relatively new to kotlin, especially to coroutines. If it helps, I can share my repo with the changes by now.

I believe making it work for Compose desktop is the first step (and hard enough). Only then, desktop and Android platforms could be fused in one code base. If you manage to make it work consistently for desktop, that would be great. Good luck!

I added some small changes. Looks like dpToPx needs to be initialized The way I added it might not be pretty, but it changes every time the window is moved between my screens (1f for big screen, 2f for small screen for me). And looks like it recomposes properly which is nice. On android dpi configuration changes are much less common. Clusters are still a little glitchy when zoomed in or when scrolled to right or bottom edge but now they seem to display equally decent on both screens.

One time after moving the window back and forth I got this though: So I guess dpi needs to be updated deeper in the code

Well, yeah, I'll look into this when I have free time. See you until then. For a proof of concept I'm satisfied for now 😅

@krzysztofsroga I faced the same issue when porting mapcompose to multiplatform by using your code as starting point. by changing drawImage to drawImageRect inside TileCanvas, I could fix this issue.

I now have a working map for iOS, desktop and android. Next step for me is to port all the demos of mapcompose.

Excellent news ! Looking forward to see all the changes your made to make it work.

@rkreienbuehl Could you please share your fork of MapCompose? (even it's still in WIP) I'd like to start looking at the changes and think about what to do next.

@p-lr I copied the files and made a complete new Repo by using the https://kmp.jetbrains.com. The repo is available at https://github.com/rkreienbuehl/MapComposeKMP.

Biggest changes are:

• TileStreamProvider's getTileStream returns ByteArray? (InputStream is not possible in multiplatform and the new resources api can also return ByteArray for resource files, but maybe there is a better solution for this?)
• instead of Bitmap the BitmapForLayer stores ByteArray (skia Bitmap ans android Bitmap aren't compatible as types, maybe theres an other way to deal with this, seemed the easiest for me at the moment)
• UUID's are changed to be type String
• TileCanvas is implemented separately for each platform by using code from MapComposeDesktop and fixing the display error mentioned (maybe could be more unified in common code)

With these changes there is very little code that had to be written per platform. The iOS demo app works, but you have to change TEAM_ID inside demo/iosApp/Configuration/Config.xcconfig. the iOS and desktop apps only contain the OSM example by now.

I started porting the demo app, hope to finish this on saturday.

@rkreienbuehl This is huge! Honestly, I thought making the KMP version would require more structural changes. You should know, the library has changed since the fork MapComposeDesktop. Consequently, recent changes will have to be back-ported. For example, the file Pool.kt has been replaced by BitmapPool.kt. You probably shouldn't worry about that right now, and continue your work on the demo app. I will take care of that.

My plan is to make a kmp branch, and start from your work. Of course, it should be done fairly so that your contributions will be clearly visible in git history. We'll talk about those details later. I've created a separate discussion, it will be useful for the next steps.

Finally, thank you very much for what you're doing.

@p-lr I saw that the code of MapComposeDesktop was not updated for a year, so I started with your code from commit 4235d0c34752d2845e0da1644b9addbccd156be3 and took the changes from MapComposeDesktop as a little help, so there are only the changes of the last 5 commits missing. I don't know if I changed the code to not use BitmapPool.kt, but I can look at this when I finished porting the demo apps.

@rkreienbuehl Alright. I answered here.

Work is underway : https://github.com/p-lr/MapComposeMP This is promising! 🎉

MapCompose Multiplatform is officially released.

Great news, thanks for the work of the past days.