Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an indirect path to the TrayIcon object #74

Merged
merged 8 commits into from
Feb 9, 2023
Merged

Provide an indirect path to the TrayIcon object #74

merged 8 commits into from
Feb 9, 2023

Conversation

EasyG0ing1
Copy link
Contributor

@EasyG0ing1 EasyG0ing1 commented Feb 9, 2023

Concerning Issue #72 - I spent some time working with the FXTrayIcon class in an extended subclass to see about using the protected method getTrayIcon() and though it can be relatively easy to do when using the base class constructors, it becomes more of a challenge when trying to also use the extended Builder class. Also, having to create a subclass just to gain access to that object seems to me to be a bit inconvenient, though I certainly can understand and appreciate the intent behind declaring that object as protected ... this is a JavaFX library and so all efforts should indeed be made to present it as a full JavaFX library.

So what I came up with will both maintain the existing protection of the object where its not possible to reference it via the protected method AND ALSO provide a relatively convenient way of getting to the object while it remains not exposed directly.

I created a class called Restricted that is only local to the package that it's in (so it cannot be accessed nor even seen while using the library), then I put the awt TrayIcon object in that class declaring it as final so that it is only created one time and that is when the final FXTrayIcon class constructor is called and it instantiates the Restricted class ... but there's a twist...

The variable named restricted is defined as being of type RestrictedInterface but when the Restricted class is instantiated in the final constructor, it is instantiated and assigned to that variable.

Because the Restricted class is only accessible to the package it exists in, the only way to make its getTrayIcon public method accessible outside of the package is by having that class implement the interface which has the declaration of that method declared as public - Restricted Overrides the interface method.

The result of this is that users of the library can use the getTrayIcon method that's inside the package-private Restricted class without being able to see or access Restricted directly, which preserves the goal of keeping that object protected.

Once FXTrayIcon is instantiated, a developer can gain access to TrayIcon like this:

fxtrayIcon.getRestricted().getTrayIcon();

It should be noted that the RestrictedInterface class is public and therefore it can be seen by users of the library, but there is no code in that class for anyone to use so its exposure poses no threat to any part of anything within the scope of the library.

Here is what this accomplishes:

  1. The TrayIcon object remains protected and not DIRECTLY accessible from the instantiated FXTrayIcon class as you originally intended.
  2. The class that holds the TrayIcon object cannot be seen by a developer.
  3. The TrayIcon object is guaranteed to only be created ONE TIME through the final class constructor of FXTrayIcon.

I believe this is a solution that meets both needs - protecting the object while making it accessible but never "accidentally" accessible ... the dev will have to want to get at it and also know how to do it.

The original behavior of FXTrayIcon has not changed at all so this PR will have no negative impact on existing users.

Java doc comments were added everywhere new code was added.

README was updated to explain the added functionality.

This has been tested and it works.

@EasyG0ing1
Copy link
Contributor Author

I also added one other method to the main class but that one just lets people add MenuItems withing needing to first create a menuItem object ... its similar to what the Builder class offers, only it offers it post instantiation.

@EasyG0ing1
Copy link
Contributor Author

EasyG0ing1 commented Feb 9, 2023

@dustinkredmond I also fixed a bug per issue #71 making sure that the insertion index will never go negative.

Actually, I decided to change that and not make sure that the index being pushed into the stack never goes negative ... the index being pushed into should always be whatever the current count is of the stack. So if there are no items in it, then the right index to insert into is 0. If there are 1 items in there, then that item will exist at index 0 so the correct index to push into would be index 1 etc.

@dustinkredmond dustinkredmond merged commit b0dfcc7 into dustinkredmond:main Feb 9, 2023
@EasyG0ing1 EasyG0ing1 deleted the EasyGoing1 branch February 9, 2023 23:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants