KMP version of MapCompose

[p-lr]

Plans for the future KMP port of MapCompose

[p-lr]

@rkreienbuehl We can continue here if you don't mind.
If I understand correctly, you started from Feb 8 commit, which is quite recent. You may have taken the pool from MapComposeDesktop because it wasn't using Java's specific ConcurrentHashMap.
I will think about a way to refactor this without using a JVM specific type. If I'm successful, I'll push on master.

[rkreienbuehl]

Thats right, I changed the pool to use the one from MapComposeDesktop. Maybe a solution is to use the Stately library from touchlab, but maybe theres also another solution. I take a look at this as soon as I am finished with porting the demo apps.

[p-lr]

I've done it on master branch.

[p-lr]

One important thing to note is that the pool on master requires we provide the bitmap size. The reason is the pool is actually a pool of pool. For example, if we want to get a Bitmap of size 1234, the returned Bitmap from the pool is taken from an internal "sub-pool" which stores Bitmaps of size 1234.
While on the other hand, the former pool used in MapComposeDesktop requires no argument.

[rkreienbuehl]

I will take a look at it and try to integrate it next week

[rkreienbuehl]

@p-lr I just pushed the port of the demo app on my repo. The app works for ios, desktop and android, but I had to change ui/widgets/Callout.kt a little bit and the design could be improved especially on desktop.

[p-lr]

Yes, desktop demo need a way to zoom. Performance wise, I also thought initially about missing optimizations.
I'll tell you when I'm done.

[p-lr]

I have created a new repo called MapComposeMP.
While was applying your changes, I also made some adjustments and fixes. For example, paths are now working. As you can see in git history, I regrouped most of your changes in two commits (for the core lib and demo app, respectively).
I haven't tested the ios demo app, because I don't have a mac, nor and apple device. However now, I will probably buy those^^

For the ios demo app, the Config.xconfig will have to be updated. As I haven't developed a ios app yet, I'm not sure what to do.

[rkreienbuehl]

Thats great, I will take a look this at it evening. I also started porting the BitmapPool and maybe found a way to use Bitmap instead of ByteArray, maybe this way the code could be more like in mapcompose without so much difference, but I am not finished yet, so I cannot tell for sure.

[p-lr]

I removed the BitmapPool, on purpose. It's useless because we can't reuse existing memory and every time we get a tile we allocate a whole ByteArray. So don't bother ;)

[rkreienbuehl]

I made a fork today and tested the demos. All of them worked really well. I also made some changes to the demos.
When I see it right, there are no ZoomIn/ZoomOut interactions by now in MapState?

For the ios demo app, the Config.xconfig will have to be updated. As I haven't developed a ios app yet, I'm not sure what to do.

In Config.xconfig one has to change theTEAM_ID, which is the ID of the developer-team when registring at apple for a developer account. I also changed the BUNDLE_ID and APP_NAME in my last commit on the fork.

[p-lr]

When I see it right, there are no ZoomIn/ZoomOut interactions by now in MapState?

I'm not sure I understand. What do you mean?

I made a fork today and tested the demos. All of them worked really well. I also made some changes to the demos.

Great! Don't hesitate to make a PR.

[rkreienbuehl]

I made a PR.
I thought about interaction like MapState.scrollTo() for zoomIn and zoomOut, but I realized that I can use scrollTo() for that.

[p-lr]

Yes indeed, when using scrollTo, we can specify a relative position and also a scale.