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

v1.5

• BungieUser Profiles
  Each BungieUser could correspond to multiple bungie profiles that are all equally valid. BungieUser should be reworked to include a List of valid DestinyUserProfiles.
• Return List of DestinyProfiles in user searching
  For the same reasons as above, when searching for a user it could come up with multiple valid profiles pointing to the same user. The search methods should return a List of valid profiles.
• Rework getMembers() system
  All of the getMembers() methods in the Clan class need to be combined down to one method. They should exclusively return a List of ClanMembers rather than BungieUser. Remove the entire async splitting architecture, as it isn't very beneficial anymore.
• Iteration options for searching
  Thanks to the suggestion in #16 the search methods should be at least partially reworked to include iteration options for the end-user. This could potentially improve search times in some cases.
• Add getOldestMembers() to Clan
  Use code from Benedict 99-40 to add a getOldestMembers() call, which returns a list of the oldest members in the clan.

v1.6

• Continue Work On Activities
  Pick up where we left off with the Activity and related scraping system.
• Continue work on Inventory and Collections Management
  Only partially complete, still missing some very important things.
• Implement system to use cached manifest file
  Instead of downloading the entire JSON Object or making individual calls, we can save the manifest file if the user wants and use SQL to get the manifest items.

Paginating through the API automatically to get all the data at once is an inefficient way handle search. This is slow when searching for common terms in a username, i.e. "guardian"

Ideally, you should simply expose the pagination and allow developers to customize this a bit so that it can be performant

This list is kept so I have tasks to work on when I feel like working on the API again.

• Guardian Ranks

• King's Fall Hashes & Lightfall Raid & Other Activities

• Loadouts

• Start setting up V2

So the code is pretty straight forward just wanted to see if it actually worked and
public static DestinyAPI api; public static void main(String[] args) throws LoginException { api = new DestinyAPI().setApiKey("api-key"); System.out.println(api.getUser("76561198334940394"));

Then i decided to just simply print out a BungieUser and was getting a NPE for getAccessToken.`

Caused by: java.lang.NullPointerException
at material.DestinyAPI.getAccessToken(DestinyAPI.java:136)
at utils.HttpUtils.(HttpUtils.java:31)

Add unit tests for all major functionality using JUnit

Improve documentation overall throughout the entire library.
Maybe also bundle javadocs?

I would like to use the API with your wrapper. However, I don't usually use maven for my projects and was wondering if you could publish a version of the wrapper as a jar file.

Have been working with the API for sometime now and requests work fine. The problem is that JSON parsing causes a few errors.
To combat this here is a JAR file build packaged with GSON. :)
JDestinyAPI_GSONPackaged.zip

Multiple issues keep arising from the user searching system.

1. getUserWithName() cannot handle a scenario with a discriminator with a leading zero. Such as 0946 for whatever reason.
2. Begin working on implementing some sort of test system like there is in Rust to squash these before we release a new update.