so I'm having a lot of classes that use the UIBinder to make the layout. Each one of those classes has a lot of added features in it though, so it's starting to get a little bit cluttered. My idea was to make a GUI class, where I will initialize the UiFields, and to make a class extend that one, and handle all the events in the subclass.
My problem is, the ClickHandlers are not working anymore. Anyone knows why?
Also is it bad practice to do it this way?
You probably have to implement HasHandlers interface and make sure you GUI extends composite
Related
I'm working on a game (in Unity3D) which consists of a dozen menus and no real 2d/3d game world. From a programmer's perspective it is just a bunch of buttons, labels and images.
To not have everything inside of one big menu class, I decided to split the code in parts for every menu. The result is that I've got a dozen classes which themselves have all the references to their gameobjects and e.g. the button methods.
My problem is that almost everything in my project is static by now, because these menus do not get instantiated multiple times and I have to access variables and methods from one menu with the script of another menu.
Thus my question is what the best practice would be for this situation. I've got a couple of ideas, how I could do it, but unfortunately I didn't get to learn what to do in such a situation.
So if you straight up want to suggest something, feel free to do so. :)
My ideas:
1) Make a controller which has static instances of all menus. A button-method in class 'A' could then call Controller.B.x. This does work, but I dislike putting "Controller" everywhere so often, because most classes access methods and variables from other classes so often, that it's just ugly.
2) Make these menus all be singletons. Afaik are singletons "ok" for something like this, but aren't they just shifting the static instance to their own class instead of one controller? When I switched from option 1) to this with one class, basically Controller.A.x became A.instance.x, where "instance" is the static instance of the class inside the class.
3) Keeping everything the way it is, having variables and method being static whenever I need to access them statically from another class, otherwise make them private.
The game is probably not a "bunch of buttons, labels and images".
I suggest to forget about the menus for a second, focus on the model of your game, create classes strictly for that. You don't put things like "how much of a currency does the player have" in any menu, it should exist in a Player class or similar (the model).
Once you can manipulate your model from a single test controller class, and simply log the results in debug console, you're ready to do the same with menus.
After that, you can much easily create user interfaces to read /display (creating labels and images on the fly) and write (hook button events into) the model beneath. These UI classes will probably have so much in common after that.
You can use UnityEvent class for communication between UI and model, they are nicely shown in the Inspector (the same events used in UI Events and Event Triggers).
Fore more general info, Google on some design patterns like MVC, MVP, MVVM, or VIPER.
My recommendation is to strongly consider why you have statics. I understand your reasoning that they are singletons but I don't think that is a good enough reason.
I hope you are using the Unity GUI features properly.
I would just write a base "Menu" component. Then you can add references into the sub classes. For example.
You have a "StartMenu" class derived from "Menu" which is derived from "MonoBehavior". In "StartMenu" you write a method "ShowCharacterCreationMenu()". Then add a button component and hook the method up to that button press. StartMenu will have to have a reference to Character menu. This is the classical OOP approach.
I would do this a little differently though. Unity's strength lies in component based design so I would lean towards that. I would probably create a "Transition" component class that listens for a button press. When that button is pressed it goes to the next menu.
Hope that makes some sense.
Hi I have a JFrame class that I update based on information I recieve from another class. I have created an update method within the JFrame which I use to update the different objects on the page. But my Question is is that the correct thing to do?
You can make it however you want, there is no "right" way. It's all a matter of preference. Personally, I like that way of doing it. In almost all of my GUI's I have a method called "update()" or something similar.
its depends on how updates are being triggered, but using event-listeners and actionCommands might be helpful. I don't necessarily like this methods but it is convenient.
I did something a little bit nasty today.
All of our view controllers inherit from two different parent view controllers, let's say XXXViewController and YYYViewController. XXXViewController in turn inherits from TrackedUIViewController, which is a class provided in the Google Analytics SDK so all your view controllers can inherit from it and easily track them.
YYYViewController however, inherits from a different type of view controller. Ah, and it's an open sourced piece of code that I really don't want to change.
What's the problem here? We cannot track any of the YYYViewController children because we can't access the methods provided in TrackedViewController, since they are private.
I don't want to modify the source provided in the Google Analytics SDK. So what did I do? Create a category that exposes those methods, just to avoid the compilation error.
The obvious downside to this is that the GA source code changes it may break, but it will be fairly easy to detect.
I was wondering what other problems I could be facing by doing this, and if you guys can think of a better approach.
Thank you
You can go up in the inheritance chain of YYYViewController, see in turn what class it inherits from. If it's UIViewController, simply change that particular superclass to TrackedUIViewController in the source and you're fine to go.
Example for better understanding: suppose YYYViewController inherits from ZZZViewController, which in turn inherits from UIViewController. Now you can change the superclass of ZZZViewController from UIViewController to TrackedUIViewController - since TrackedUIViewController inherits from UIViewController, no functionality will be lost, but magically your whole YYYViewController class will become trackable.
Hope this helps :-)
You already mentioned the biggest risk of using undocumented APIs: Changes to the API are beyond your control and may break your logic, for example if methods are removed/renamed, or their behavior stops matching your expectations.
From the purely technical point of view, I can see no further problems, since in Objective-C all methods are public. As long as they continue to exist, you may continue to call them.
I would say the root problem is excessive subclassing. Keep view controller hierarchies shallow. Use composition instead of subclassing. If you must subclass ensure that functionality that a class provides can be turned on & off by it's subclasses.
I tried to create a properties view for a graph model in an Eclipse RCP Application. The graph elements are from a non-eclipse library and so don't implement IAdaptable or even IPropertySource.
The Tabbed Properties View, explained here:
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
seems to be a simple possibility - but only for inputs that implement IAdaptable.
I've thought about implementing my own IPropertySheetPage but the only implementations I found are the built-in PropertySheetPage and TabbedPropertySheetPage which are very complex.
Is there another way to create a properties view for input elements that don't implement IAdaptable? Can I use Tabbed Properties View in a way I don't see yet? Are there any other less complex implementations of IPropertySheetPage, I can look at?
Thank you!
Kristina
Actually, you can write an IAdapterFactory for objects which don't implement IAdaptable and register it in plugin.xml or in your plugin activator. See http://www.eclipsezone.com/eclipse/forums/t61666.html.
Are there any other less complex implementations of IPropertySheetPage, I can look at?
Short answer: No.
But why don't you wrap the non-adaptable object into your own object that implements IAdaptable or IPropertySource or whatever, so that the property-page can work with your wrapper which holds the object you want to make editable through the property-page. And instead of providing this "library" object to global adapter-mechanism, create the wrapper, set the object and provide it to your global selection-service or whatever.
in a définition of a widget, what is a better practice, and why, use the widget himself or the type "higher", example, it's a better practice to do
1) Button myButton;
or
2) Hastext myButton; (and set a button later)
thanks for your answer.
It is usually a good idea to use "higher" types or interfaces. By doing this properly you can hide implementation details. The code that uses an object looks at it as the one of a higher type and it is not important what is actually hiding behind it. This is good because you can easily change an implementation of the object without breaking anything.
For example when defining a panel in an application you should use Panel class instead of its implementation e.g. HorizontalPanel or VerticalPanel.:
Panel myPanel;
Then you can create a proper implementation of it, e.g HorizontalPanel:
myPanel = new HorizontalPanel();
If you then later decide to change myPanel to be VerticalPanel you will not have to change anything in the code that uses myPanel. Everything will work just fine.
However you must remember that you will be only able to use methods available in Panel class. Additional methods defined in e.g. HorizontalPanel will not be accessible. And this is actually what you should remember when choosing the type of your widgets. Your widgets should be of types which provide methods which you want to use.
In your example using HasText instead of Button isn't probably a good idea because HasText has only methods for setting and getting a text and you probably also want to have access to addClickHandler method available in Button and a few more.
So to summarize it is good to use "higher types" but they should not be "too high" to be useful.
The answer to that lies in the Model-View-Presenter pattern, that was introduced in last years Google IO presentation by Ray Ryan. There's also an official tutorial/docs - part 1 and part 2. There are also a number of questions here on SO that cover that topic :)
And a quick answer to your question (that will make more sense once you get familiar with MVP): use interfaces in the Presenter and their implementations in the View :) That way your Presenter stays oblivious to the underlying implementation/Widget you actually used (was it a Button? Or a Label? It doesn't matter, they both implement HasText).