feat(map): create the viewmodel for the list of hike routes

[rBergCode]

Implemented the ListOfHikeRoutesViewModel to later retrieve the hike routes from the repository.

Summary

The objective was to habe a basic view model with hardcoded values in order to create the map screen.
The following were done:

• Created a ListOfHikeRoutesViewModel with the said view model
• Created a ListOfHikeRoutesViewModelTest to test it (coverage achieved on the viewmodel: 100%)

For now, the view model will return hike routes as hardcoded Strings ("Route 1", "Route 2", "Route 3"). This will be changed when the HikeRoute model will be created.

[rBergCode]

The code coverage looks like is not correct. I'm trying to correct it on #14 .

[rBergCode]

I rebased the branch from main to get the fix from #14. I then force pushed it to re-run the tests.

[MaelImhof]

Nicely done, the 100% code coverage is very satisfying.

Two things that I think still need to be discussed :

1. It was my understanding that when the user zooms in or out on the map, the routes are filtered based on the areas displayed on the map (to avoid loading all of them at the same time, which is probably not viable). This will be implemented in the model, but the viewmodel should provide a method to set the current displayed area so that the model can know about it and update the list of routes consequently. A parameter type for this could be org.osmdroid.util.BoundingBox, which defines the minimum/maximum latitude/longitude displayed on the map view. For now, the function could not really be tested I guess, there are no assertions to be made without a repository.
2. We might want to use coroutines to make calls to the model, since it will be an API. Starting the coroutine in the view model instead of the model itself could have the significant advantage of being life-cycle aware, see official docs. You could keep your current methods as-is and make them call private suspend functions that will then call the repository on an IO dispatcher.

Let me know about your thoughts on those subjects or if you need any help !

[sonarqubecloud]

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[MaelImhof]

Good work, this looks good to me.

We might want to avoid hard-coded dispatchers later on but I'm not sure why this is necessary, hence I would postpone it to when we have to actually test coroutines, aka when the actual model gets implemented.

[MaelImhof]

I mentioned hard-coded dispatchers in the appropriate task so that the assigned person can have a look at it when the time comes.