Grover-c13
[In progress]PokeGOAPI-Java version 2.0 Providers Framework rewrite
Description: This is a tracker of what needs to be done and what is done and what is being worked on in Pull Request #873. Also this can be used to suggest changes to the framework while it is being worked on.
Service Provider Interfaces This includes the delegate and the spi for the delegate along with any other interfaces/classes needed for the spi.
- [x] CredentialProvider
- [x] Gym
- [x] Pokestop
- [x] CatchablePokemon
- [ ] Map
- [ ] Inventory
- [ ] Settings
- [ ] PokemonGoClient
- [ ] Signature
- [ ] PlayerProfile
Implementation The implementation of the API and the SPIs
Couldn't you just create another branch than trying to mess up API v1? I guess your idea won't be finished in a day or two?
He didn't do anything but sending a PR so we will start working on a better API. and even after we will finish re-building the new API, the old API will still work (not supported probably) Don't complain, He is doing you a favor... so is Gegy
Well ok. Looks like there's a lot of business going on in the background. I did not know that there is something like a management behind this API. Just a bit concerned about this API v2 thing, because v1 is not that bad actually and currently running just fine. Hope that API v2 won't be too different and integration will get smoothly into running projects/bots using api v1.
Then, yes, there is kind of a management behind this API. grover was the one who started it (I think) and he left it for @gegy1000 to continue because he lost interest or something like that. you might not know that, but the current API has lots of problems and you need to write loads of code to implement things.
All we need to do now is to start working to built it by what he committed...
Looks almost like an invite to contribute. To be honest I am happy to be able to keep my pieces together. I have to check what I am able to do. Did not want to sound disrespectful. You all do great work and because of you I am able to train my skills with a bit of fun-coding.
@clangdev As @RebliNk17 said, there are a lot of issues with the API right now, specially when it comes to maintainability. And the fact that a lot of it is dependent on all the other parts of the code. So this means that say if you are only a scanner, you would have inventory for the account loaded up. That took memory.
So the goal of this is to increase maintainability by strictly saying this is how each part will be able to communicate, along with allowing quicker changes due to less dependencies all over the place. Also it gives more flexibility. For instance, it would be easier for a library user if they are using Android, to just implement their own PokemonGoClient so that it handles requests and responses the way they want it to instead of being forced to handle the requests and responses as defined by the API.
I know when I was creating my own scanner on Android, I had to fork the API and change quite a few things to get the API to behave the way I needed it to behave on Android without adding additional bloat that wasn't needed due to how the library was set up. Specially with the async requests (I just ended up removing them completely).
Overall, we shouldn't be changing how the underlying system works, but more how users would interact with the underlying system and how the underlying system interacts with other parts of the system. So we are kinda of changing the behavior of library, while not touching the function.
@s7092910 How did you end up getting it to work on Android? I have an error "Contents of buffer are null" which is probably because of the many requests
