patrickjane
commented
3 years ago Hi, thanks for the feedback. The multi-provider approach was meant like "once API description is available, I can add more providers easily", and not like "I just added one provider, but if anyone wants to add others, go ahead". As a matter of fact I was unable to find complete API description for any other provider; Bird was the only provider where someone already found out how to unlock scooters. Other providers also do have (unofficially) documented APIs, however, they always lack the endpoint of unlocking/riding scooters.
I have contacted the following providers already: Lime, Bolt, Voi, Tier, Bolt, Bird, some of them up to three times, asking for support for implementing their services. I have not received any feedback yet. At least two providers (Voi, Tier) have APIs meant for third party usage, since they're part of e.g. the FreeNow app, however they most likely require some kind of official partnership. I have asked for this, but as mentioned before, I did not get any feedback. I have never heard of Jawls, and probably would not be able to implement this easily since this provider is not available in my city.
This means, the real challenge right now is to obtain a more or less complete description of the REST APIs used by the other providers. This can be done by reverse engineering, and while I failed with doing that with the Bird app, other people seem to be more talented in reverse engineering and in fact capable of finding out how the APIs work
Once there is a complete API description, I would be able to quickly add it to the app. The main points would be:
1) Subclass Provider and instanciate here: https://github.com/patrickjane/ut-scooter/blob/main/src/scooters.cpp#L74
2) Check where the QML part needs adjustment
3) profit
Since currently there is only one provider, I didn't put any special logic for the no parking areas, but probably at least this will be something which needs more work: It will probably be stupid to display all no-parking areas of all providers at once. Rather I thought about displaying the areas only for the provider of the currently active ride, and otherwise display no areas (or something similar).
What I want to say is, that even though the app code is pretty much ready for additional providers, there will be small adjustments necessary, depending on how the API of the newly added provider works. E.g. if it would pretty much work like the Bird API, then no big adjustments will be necessary. If, however, they follow a completely different pattern in terms of API endpoints, scooter logic and all that, maybe more adjustments will be necessary. This cannot be known beforehand, and must be taken care of when adding new providers.
In the meantime, if you happen to find up to date and complete API descriptions of other providers, let me know, and I will start the work on it.
xdub
darkdragon-001
S60W79
It would be nice to add support for additional providers. You are stating that the app is designed as multi-provider app. Could you please add a section to the README outlining the process of adding additional providers?
Tracking support for providers: