PluginManager - wysohn/GeneralLib GitHub Wiki
This is an abstract class that is responsible for single functionality. Even though you can do whatever you want with this class, it has made to fulfill the SOLID principal's Single Responsibility Principal. To simply put, we create a class that is responsible for just one work. For example, you might can create a manager called UserManager that is responsible for only the operations related to Users. Maybe like saving player stats, loading them, etc.
You may find more information about SOLID principal by googling.
Lets look at the usage one by one.
public class MyPluginManager extends PluginManager<MyPlugin>{
public MyPluginManager(MyPlugin base, int priority){
super(base, priority);
}
@Override
protected void onEnable(){
}
@Override
protected void onReload(){
}
@Override
protected void onDisable(){
}
}
First of all, PluginManager accepts a generic type 'T extends PluginBase,' in the triangle bracket <>. This means that you can put any class type that extends PluginBase into this generic type. And if you remember how we made MyPlugin class in PluginBase section of the WIKI, we extends PluginBase for MyPlugin. For that reason, we can put MyPlugin in the generic type specifier like PluginManager.
Next, your class needs to invoke super constructor with two parameters: First parameter of T and second parameter of priority.
args0 -- The T part will be change into whatever you put in the bracket<>, and it's MyPlugin in our case. I suggest to leave it in the constructor just like the example above, so you can pass MyPlugin instance when you are registering the manager.
args1 -- And the priority is just integer, yet the range of number should be accurate. The range is 0 to 10 all inclusive, and smaller the number means earlier it will be initialized on plugin enables. Some of them are defined as constant in PluginManager class as static field, so you may use it too. However, just like the T parameter, I suggest you to leave it in the constructor so you can pass it when you are registering the class. This will give you more control in one place (I will tell you later in this section what it means)
-
onEnable() : just like the name itself suggest, this method will be invoked when plugin first enables. This will be called only once, so it's good place to initialize things you need to use like Database, FileConfiguration, etc.
-
onReload() : same story. It's invoked when / reload command is used.
-
onDisable() : same again. It will be invoked when plugin disables. Good place to do termination like closing database connection, saving data, etc.
It's good idea to implement Listener interface and receive events from it. To do so, simply implement Listener and use EventHandler annotation like you usually do with the plugin development. The events will be automatically registered to Bukkit's PluginManager, so you do not have to worry about that.
public class MyPluginManager extends PluginManager<MyPlugin> implements Listener{
public MyPluginManager(MyPlugin base, int priority){
super(base, priority);
}
@Override
protected void onEnable(){
}
@Override
protected void onReload(){
}
@Override
protected void onDisable(){
}
@EventHandler
public void onJoin(PlayerJoinEvent e){
e.getPlayer().sendMessage("Welcome "+e.getPlayer().getName());
}
}
Now you have your manager class ready, you need to register it to PluginBase in order to use it. Lets bring our previous example of PluginBase here.
public class MyPlugin extends PluginBase{
public MyPlugin(){
super(new MyPluginConfig(), "mymaincommand", "myadminpermission")
}
@Override
public void preEnable(){
//TODO initialize your commands, languages, managers, and APISupports
initManagers()
}
private void initManagers(){
this.registerManager(new MyPluginManager(this, PluginBase.NORM_PRIORITY));
//TODO and more managers as your need
}
}
Now lets look at what's going on.
The PluginBase class has a method called registerManager(), and it accepts any PluginManager objects. Because of that, we can create a new MyPluginManager object and register it right into the PluginBase. This is why I told you to leave those two T and priority arguments in the constructor; now you can change the load order freely depends on the context.
Some managers might need to be loaded prior to other managers. For example, you have a manager called UserManager that handles all the operations about the users, and a TeamManager that handles teaming between users. In this case, lets imagine TeamManager is going to validate the team status on enable by getting information from UserManager. UserManager, at this point, should be completely initialized and ready to be used. This is why priority can be useful.
To use the manager, simply use the getManager() method of the PluginBase. As you already know, most PluginBase related classes internally have a field called 'base,' and this is where the PluginBase(the MyPlugin) instance is saved. All you need to do is call that method from the 'base' field.
MyPluginManager mpmanager = base.getManager(MyPluginManager.class);
Notice that the method uses the input to determine what class to cast the saved instance. So keep your codes like that if you don't know what it means.
And of course, MyPluginManager is simply the PluginManager you just made, so now you have full access to it from almost everywhere in the plugin.