Getting a boolean from another class

Discussion in 'Plugin Development' started by nuno1212sss, Jan 11, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    nuno1212sss

    Hi i'm creating a plugin that has gave me a few problems and the newest one is a java null pointer exception when i get the boolean from a diferent class my code :
    Code:java
    1. public class Teleport implements Listener {
    2.  
    3. private Arena a;
    4. private Main plugin;
    5.  
    6. public Teleport(Main plugin) {
    7. this.plugin = plugin;
    8. }
    9.  
    10. @EventHandler
    11. public void playertp(PlayerTeleportEvent e) {
    12. World w = e.getTo().getWorld();
    13. if (!w.equals(Bukkit.getWorld("Arenas"))) {
    14. return;
    15. } else {
    16. if (a.on = false) {
    17. Arena task1 = new Arena();
    18. task1.setId(Bukkit.getServer().getScheduler()
    19. .scheduleSyncRepeatingTask(plugin, task1, 0, 10));
    20. } else {
    21. Bukkit.broadcastMessage("COISO");
    22. return;
    23. }
    24. }
    25. if (!w.equals(Bukkit.getWorld("ArenasItem"))) {
    26. return;
    27. } else {
    28. if (a.on = false) {
    29. Arena task1 = new Arena();
    30. task1.setId(Bukkit.getServer().getScheduler()
    31. .scheduleSyncRepeatingTask(plugin, task1, 0, 10));
    32. } else {
    33. Bukkit.broadcastMessage("COISO");
    34. return;
    35. }
    36. }
    37. }
    38. }

    Code:java
    1. public class Arena extends BukkitRunnable {
    2.  
    3. private int id;
    4.  
    5. public void setId(int id) {
    6. this.id = id;
    7. }
    8.  
    9. public boolean on = false;
    10. World w = Bukkit.getWorld("Arenas");
    11. World w2 = Bukkit.getWorld("ArenasItem");
    12.  
    13. @Override
    14. public void run() {
    15. for (Player p : w.getPlayers()) {
    16. for (Player p2 : w2.getPlayers()) {
    17. List<Player> pw = w.getPlayers();
    18. pw.add(p2);
    19. for (Player pp : pw) {
    20. if(pp == null){
    21. on = false;
    22. Bukkit.getServer().getScheduler().cancelTask(id);
    23. return;
    24. }
    25. double vida2 = pp.getHealth();
    26. float vidap = (float) vida2 * 5;
    27. String vida = ChatColor.RED.toString() + ChatColor.BOLD
    28. + "HP: " + ChatColor.YELLOW.toString()
    29. + ChatColor.BOLD + String.valueOf(vida2)
    30. + ChatColor.RED.toString() + ChatColor.BOLD
    31. + " Corações(20 = 10)";
    32. BarAPI.setMessage(pp, vida);
    33. BarAPI.setHealth(pp, vidap);
    34. on = true;
    35. }
    36. }
    37. }
    38. }
    39. }
     
  2. Offline

    MrAwellstein

  3. Offline

    DevRosemberg

    nuno1212sss
    Code:java
    1. private static boolean on = false;
    2.  
    3. public static boolean getOn() {
    4. return on;
    5. }
     
  4. Offline

    1Rogue


    No no no NO.

    Do not use static to substitute for lazy coding practices. You should be passing a reference of an object/primitive, not using static to access a member.

    Some class:
    Code:java
    1. private boolean somefield = false;
    2. private OtherClass clazz = new OtherClass();
    3.  
    4. void someMethod() {
    5. clazz.anotherMethod(somefield);
    6. }


    OtherClass:
    Code:java
    1. //...
    2. public void anotherMethod(boolean value) {
    3. //work with value
    4. }


    In general, primitives are pass-by-value, and Objects are pass-by-reference.

    More about passing instances: http://forums.bukkit.org/threads/using-a-string-in-different-classes.184140/#post-1916182
    Why static is bad: http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil
     
    Henzz likes this.
  5. Offline

    MrAwellstein

    There is absolutely nothing wrong with using static variables, unless you use them wrong.
     
  6. Offline

    1Rogue


    There is everything wrong with them. If you read the SO page I linked you would see why.


     
    Stealth2800 likes this.
  7. Offline

    nuno1212sss

    1Rogue I could use like constructors, but for what I want i'm not very clear on how to do because i want to check if the boolean is true or false, so do i like create a constructor and then return it true? Or can you explain a little better
     
  8. Offline

    1Rogue


    Is your boolean a field? A common method is setting an accessor method:

    Code:java
    1. public class SomeClass {
    2.  
    3. private boolean someValue = true;
    4.  
    5. //...
    6.  
    7. public boolean getSomeValue() {
    8. return this.someValue;
    9. }
    10.  
    11. }


    As far as design patterns go, I usually structure mine in a way where you pass the main instance of your plugin to lower classes, and then you can always reference up. For example:

    Main class:
    Code:java
    1. public class YourMain extends JavaPlugin {
    2.  
    3. private SomeManager some;
    4. private AnotherClass another;
    5.  
    6. public void onEnable() {
    7. this.some = new SomeManager(this);
    8.  
    9. this.another = new AnotherClass(this);
    10. }
    11.  
    12. public SomeManager getSomeManager() {
    13. return this.some;
    14. }
    15.  
    16. public AnotherClass getAnotherClass() {
    17. return this.another;
    18. }
    19.  
    20. }


    AnotherClass:
    Code:java
    1. public class AnotherClass {
    2.  
    3. private final YourMain plugin;
    4. private boolean someValue = true;
    5.  
    6. public AnotherClass(YourMain plugin) {
    7. this.plugin = plugin;
    8. }
    9.  
    10. public boolean getSomeValue() {
    11. return this.someValue;
    12. }
    13.  
    14. }


    This means that in our "SomeManager" class, we can then call the appropriate values:

    SomeManager:
    Code:java
    1. public class SomeManager {
    2.  
    3. private final YourMain plugin;
    4.  
    5. public SomeManager(YourMain plugin) {
    6. this.plugin = plugin;
    7. if (this.plugin.getAnotherClass().getSomeValue()) {
    8. // value of "someValue" in "AnotherClass" instance is "true"
    9. } else {
    10. // the value is false
    11. }
    12. }
    13.  
    14. }


    That's the gist of it, really.
     
Thread Status:
Not open for further replies.

Share This Page