[API] Network API.

My name's Nick. I'm a[n] experienced Java developer and have loved to explore my way through the several different server APIs for Minecraft, including but not limited to, BukkitAPI, BungeeAPI and Granite. I also have tons of experienced with program MySQL, and the SQL language.

I created this Network Lib a-couple days ago, I'd consider it very efficient if the desired user isn't using a Proxying Software for their server that has the ability to send network messages, e.g. BungeeCord.

Network Lib​

Firstly, grab the player like so..NPlayer data = NicksLib.getInstance().players.get(player);
Once you have your data variable, you're able todo quite a bit.

package com.nicksums.lib.listeners;
import com.nicksums.lib.NicksLib;
import com.nicksums.lib.api.API;
import com.nicksums.lib.mechanics.InvalidUniqueIdException;
import com.nicksums.lib.mechanics.NPlayer;
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.EventPriority;
import org.bukkit.event.Listener;
import org.bukkit.event.player.PlayerLoginEvent;
import org.bukkit.event.player.PlayerQuitEvent;
/**
* Created by Nick on 6/15/2015.
*/
public class LibListener implements Listener {
/*
Declare the method as an event to be watched with @EventHandler.
Declare the method as a higher level priority event. via EventPriority.
So that other plugins on the server can't take our priority of making sure
that the player is existing or not.
PlayerLoginEvent is executed before PlayerJoinEvent.
*/
@EventHandler(priority = EventPriority.HIGH)
public void onLogin(PlayerLoginEvent event) {
/*
Create the player variable, set instantiate.
*/
Player player = event.getPlayer();
/*
Declare a Object[]
Remember that our API.getPLayer() returns type of Object[]
*/
Object[] thePlayer = API.getPlayer(player);
/*
The player exist!
*/
if (thePlayer[0] == true) {
/*
So.. Since the player exist in the database, we'll just grab the Object[]'s contents and set it to the volatile storage of the HashMap<>.
*/
NicksLib.getInstance().players.put(player, new NPlayer(player, (int) thePlayer[1], (String)thePlayer[3], (int) thePlayer[4], (float) thePlayer[5], (int) thePlayer[6], (int) thePlayer[7]));
}
/*
The player doesn't exist!
*/
else if (thePlayer[0] == false) {
int uniqueId = API.addNewPlayer(player);
if (uniqueId != -1) {
/*
Perfect, the api was able to return is a valid number and wasn't -1.
Now, we have a fresh player and must set the players defaults.
Check constructor of (NPlayer) for more information regarding this.
Let's remember that NPlayer Constructor contains
Player, UniqueId, Level, Experience, Credits, Achievement Points.
*/
NicksLib.getInstance().players.put(player, new NPlayer(player, uniqueId, API.getLanguage(player), 0, 0f, 0, 0));
}else {
new InvalidUniqueIdException("Unable to handle PlayerJoinEvent() Event for Player: " + player.getName() + " with uniqueIdentifier " + uniqueId);
}
}
}
@EventHandler
public void onQuit(PlayerQuitEvent event) {
Player player = event.getPlayer();
/*
Now, since the player has left, let's remove the players storage.
Else, the server will hold this information in memory as volaitle
data until the memory is flushed. (Restarted)!
*/
if(NicksLib.getInstance().players.containsKey(player)) {
API.savePlayer(player);
NicksLib.getInstance().players.remove(player);
}
}
}

Explanation, this API is for testing purposes. If you're wanting to mess around with MySQL storing, and not want to convert your volatile data to Configuration (.yml) or otherwise Stream related files.

How it works: The code is very detailed, and shows for the most part everything that you need to know!

Few things you should either 1) take note of or 2) give a thought to switching to.

Greedy naming - while every developer loves their credit, greedy naming will turn away some people. (CheckSumLib being much less greedy that NicksLib)
Only reason I say this is that Nick not only is a first name, but a common one at that.

Git - pls learn to use it. If you plan on releasing anything publicly, utilize git and a git repository. Not only does it make it easier for people to suggest changes via pull requests, it'll also benefit you in the future when it comes job applications (if you're going into a CompSci field)

License - I cannot say this enough, even if you make the license as restrictive as possible via the whole "You're allowed to use it and that's it." statement.

Proper javadocs - if you're going to release something, please do not release it with notes saying SomeClass#someMethod - does this
That's the whole reason javadocs are used. And there's no need to explaining what a simple getter/setter does either (unless ofc, there's more happening under the hood that purely modifying a mutable field)

There's little actual usage information. You just dumped a few example classes, and expect people to find out if they could possibly use this by having to read through the examples. Instead of just saying it does X, Y, and Z, and then the potential user could easily find out whether they wish to use it or not.

Now, I don't say any of this in a condescending or degrading matter at all. I'm simply providing insight on what I feel you should do as the first statement says. All it will do is make you a better developer in the end.