tais993 / java-osuapiv1 Goto Github PK

Introduce a couple of methods:

• filter
• stream
• parallelStream
• asList
• asSet
• toArray
• getItemsById
• getItemsByName
• collect
• size
• isEmpty
• contains
• containsAll

• Every class has an logger
• Debug logs on retrieval

Certain methods, are to fix issues with generics.
While instead I can just use .<User>map instead of .map

Not sure how the operator is called ^^

• update Gradle to 7.3

The user might wants to cache certain entities to lower the amount of repeating calls.
Our wrapper takes care of that and caches for them.

This makes caching a lot easier for our users.

Add LocalDateTime getter for the JoinTime

Implement getters for the user's Profile picture, see osu-api-wiki

The basic of the project.
Implement settings, and such, so the user can customize things.

It's inconsistent, the rest doesn't return optionals.
And I personally don't really like optionals

It's just a simpler name, and I'd personally argue better (not so complex)

See the documentation

Blocked by #3

• Add more @see
• Add dots at the end of sentences
• Add missing line breaks
• Fix broken {@link } uses

Making usage of modules would result in only the API having javadoc, instead of both.
The internal module will just not generate javadoc, and it's also good practice.

Add

• NotNull if possible
• Nullable if possible
• Contract

To make it clear for the user whenever the method is nullable, not null etc

This results in all method arguments not randomly changing resulting in unexpected behavior.

After some thinking, in most cases it doesn't make sense to just grab the first item.
Instead, I should make sure only 1 items exists, and if only 1 item exists return.

Most of the times, the API returns an array. So just throwing away all the existing items doesn't make sense IMHO.

And such behavior might result in things the user didn't expect

Create separate object for storing difficulty information

Implement unit testing

See osu's api wiki for more info on how to get a cover image and thumbnail

None of the code currently has documentation.

Add documentation before proceeding on any other issues.

There's multiple kinds of scores, and they all have mutual values.

The different scores:
Scores <- BeatmapScore in code
Best Performance <- BestPerformance in code
Recently Played <- Recently Played in code

List of all mutual fields:

• score
• maxcombo
• count50
• count100
• count300
• countmiss
• countkatu
• countgeki
• perfect
• date
• rank
• enabled_mods

If we create a BaseScore which contains all these fields, we won't have to duplicate a lot of code 3x, which also makes using the scores easier for users.

• Create an interface hierarchy
• Create BaseScore implementation
• Create other implementations
• Add to cache
• Add requesters
• Add retrievers on OAWv1
• Add docs

Make sure all methods marked with @NotNull validate the argument given, same applies for Range

• Range
• NotNull
• Every method has a nullability annotation

The user object as it stands right now