Forwards Compatibility-Breaking Updates

[dec4234]

Forwards Compatibility Breaking Updates in v1.5

Soon I will release v1.4 of the API as the last packaged version of "Version 1.0" of the API. I will then begin work on v2 of the API which will start with the marker 1.5.

When I originally created the API, I failed to account for some things that would potentially impact its longevity and versatility. There are some things that need to be changed in order to make conventions and frameworks more consistent with existing rules. A lot of these changes will break lots of existing projects, which is why I am choosing to separate them into a new version specifically made for them.

The changes planned (in no particular order):

• Changing package names to directly package them together
  This is one of the most egregious examples of not planning for a well-made API. All of the packages just have their own name rather than being prefixed by "net.dec4234.javadestinyapi" This has made and will make it difficult to identify which packages specifically belong to JDA.
• Removing duplicate and often confusing methods and renaming many others
  As I have covered more and more of the API I have made many functions which often overlap with existing functions to an unnecessary degree. This has made it increasingly confusing to determine which are appropriate for each situation. On top of that, the names of many methods are unnecessarily long or cryptic, which may cause first-time users to miss a functionality that they could use. Appropriately naming functions based on their use and output will make the API more accessible.
• Renaming certain class names to be less cluttered and a little more relevant
  This is one that I am not as sure about. I think that some class names may benefit from being renamed, but I'll need to see how it pans out and how necessary it is.
• Standardizing id variable types
  This one is going to impact a lot of existing infrastructure.
  Just a couple days ago, I finally realized that all ids in the bungie api can fit under int64, which is a long in java. When I was originally building the API, I thought that ids could only fit under a String, because I only tested them being placed in ints. I think that it would be best if we switched all IDs referenced in the API from Strings to longs in order to make them a little more recognizable.

To Be Continued

[dec4234]

Update: v1.4 Packaged Jar Has Been Released

All classes have been repackaged under net.dec4234.javadestinyapi (More to come)

[dec4234]

A couple of weeks ago I completely revamped the username searching systems, narrowing it down to two methods.

getUserWithName() for names such as dec4234#9904
searchUsers() for names such as dec4234
searchGlobalDisplayName (Deprecated) - Same as first one but uses GET instead of POST

[dec4234]

A lot of simple things need more work, for example Clan Members.

I re-discovered only recently that there are 2 pieces of vital information in the Clan Members endpoint that allows us to bypass an extra request, potentially increasing efficiency. When completed, this will be most useful for those who wish to sort clan members by inactivity, narrowing the response time from about 165 seconds and 300+ requests to just 1 and less than two seconds.

They are: lastOnlineStatusChange (A.k.a last login/logout and join date). As well as isOnline() which will also be useful.