iOS app version
nunogoncalves opened this issue · comments
Hi.
Do you have any plans for an iOS version of this? If not, I’m an iOS developer and might have some interest in helping out with that on my free time. What do you think?
There are plans for a iOS version, but it doesn't exist yet, for the reasons detailed in this forum post. Of course, any help in making a iOS version would be welcome, as I have zero experience with iOS development and I don't think this will change any time soon (the development of the server and of the Android version takes all of my free time).
To the best of our understanding, the iOS version would lack all the location features of the Android version. These features are essential for us to obtain real-time data on the status of the Metro network, and iOS users would never be able to contribute to that pool of data. At this point, getting more data is one of our priorities (so we can try and compute things like the times to the next train), and because of this iOS has been quite neglected.
Right now, the most-complete-possible iOS version would be quite "simple" in the sense that it would simply be a read-only viewer for the information returned by the API, not being able to contribute with any trip logs or real-time information.
There is also no API documentation yet, but it is a very simple REST API that can be understood just by exploring it with the browser.
Most discussion on the project happens on our Discord server. It would be easier for us if you could join us there, but if it's not convenient for you, we can coordinate through GitHub alone instead.
What do you mean with this?
the iOS version would lack all the location features of the Android version
About the docs, just a suggestion, do you know swagger? Maybe you can apply it to your and other people's convenience.
As far as I know, iOS apps cannot perform WiFi scans/access the results of the scans the OS does, especially in the background/with the phone in standby. This makes it impossible to implement the location technology that was developed for UnderLX. But I'd be very happy to know I'm wrong.
I never used swagger before, and it is going to take me some time to document the API properly under the OpenAPI specification. (The API has also been quite the moving target, but I take care to maintain compatibility with previous app versions; if a breaking change occurs I'll increment the version number. But because it has been changing so much, and because until now the Android app has been the only consumer, I never took the time to document it). In the meantime, if you wish to take a look, here are some example URLs:
https://api.perturbacoes.tny.im/v1/networks
https://api.perturbacoes.tny.im/v1/lines
https://api.perturbacoes.tny.im/v1/stations
https://api.perturbacoes.tny.im/v1/lobbies
https://api.perturbacoes.tny.im/v1/connections
https://api.perturbacoes.tny.im/v1/datasets (this is so the clients know when they have to update the network map based on the version string)
Most resources support specifying a specific ID to retrieve, for example:
https://api.perturbacoes.tny.im/v1/lines/pt-ml-vermelha
https://api.perturbacoes.tny.im/v1/stations/pt-ml-ro
https://api.perturbacoes.tny.im/v1/lobbies/pt-ml-am-norte
As project development slowed down and as the existing API proved to be suitable, it is no longer changing nearly as frequently.
More than a year and a half later, I'm happy to announce that the API is finally documented with OpenAPI 2.0 (this version was chosen instead of 3.0 because, for many languages, like Golang, 2.0 has better tooling support, and 2.0 is powerful enough to model the API anyway).
The API can be explored and the swagger file can be grabbed at https://developer.underlx.com/api/