Move to use futures

[HarelM]

This will require minsdk to be 24 in order to support Future, but I find this code a lot more readable.
Let me know what you think.
Keeping in mind that I want to add the post notification permission check, this opens the way for it to be added more easily.
I've changed the code so that notification is never null...
The service is started when adding the first watcher and stoped when removing the last watcher.

[HarelM]

Smaller diff can be seen with "hide whitespace" diff mode.
Let me know what you think.

[diachedelic]

I appreciate the work that went into this, but I have two problems with merging it. One is that it drops support for a version of Android without providing benefits to the user. The other is that I don't understand the code anymore, and I don't have the time to learn how Futures work enough to satisfy myself that your changes are correct.

[HarelM]

The benefit is that the service will have higher priority and last longer.

Regarding futures, I can try and rewrite without them, it just make the code harder to read.

Generally speaking, the idea is as follows:
When the plugin starts, don't do anything special (don't start the service like now).

When adding a watcher do the following:

1. Request location permission
2. When granted start the service
3. When the service starts call add watcher on the service

When removing the last watcher, stop the service.

Since the service has high priority it needs a notification icon, so it is always created with the service.

The idea behind futures is that they allow to easily wait for stuff to complete instead of dealing with all the callback hell.

I tried to keep the changes minimal, I might be able to split them to smaller PR so that it will be easier to read.
Most of the changes are basically moving some code into methods to be able to easily reuse it.

[HarelM]

Please let me know how you would like to proceed, I'm good with what feels right for you.

[diachedelic]

Can you link me to anything explaining why the lazy service initialisation improves reliability?

If you think you can rewrite it without futures, that might be best. I am reluctant to drop support for SDK 23, because that will affect many apps using this plugin.

[HarelM]

I couldn't find an article about why futures improves readability, I'm just used to the concept because this is how promises work in javascript and it's easier to recon with.
It's also nice that if you use a future that was already fulfilled you don't need to keep the state of the future as it is handled out of the box - meaning, for example in this case, when I want to get the service instance I don't keep it as a local variable and if it's null I try to connect and then I need to make sure I don't call this twice at the same time etc, I simply connect a callback to the future success and then execute the code that needs to happen when I have a service instance. It's very convenient...
I understand your concern about SDK 23, although this is a 10 years old version of android, I believe it will be hard to find devices that are still running it and probably will be removed soon from the google play store. Having said that, it is still supported by google play so my arguments are weak...

[Dwimcore]

Hello, just passing by while doing my round of capacitor plugin updates.

If that can be of any help, Android SDK 23 support has been dropped in Capacitor 8.

[HarelM]

I've moved to maintain capgo's geolocation plugin if that's interesting to anyone. Feel free to close this PR or merge it, I'm good either way. Good luck!