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.
Related
Im currently working on a project where I want to the user to be able to chose between two layouts (list and grid) at runtime. I was searching for examples in the UI5 documentation (Sample Apps) and on GitHub, I did not find examples for how to to this or best practice examples. So I thought about how I could achieve this behaviour and had multiple ideas, but somehow none of them feels like doing this would be best practice.
Idea 1 - Destroy the "old" controls and generate the new controls inside the Controller
My first idea was to destory the controls I do not longer need. For example if the user wants to switch to the grid layout, the list and every control related it to it gets destoyed. In the controller the needed controls for the grid are created and then rendered in the view. In my eyes this would mix up view and controller logic inside the controller and does not feel like best practice
Idea 2 - Create two views and switch between them
My second idea was to create two views, each for the layout I need and switch between them. This would mean a lot of code replication in both the controller and the view. Does not feel like this would be the right way.
So I would be glad if you have own experience on this or if there is really something like a best practice for such a behaviour.
Thank you and kind regards!
I would say, idea 2 because of the following reasons:
It is best practice to work according to the MVC methodology which means separating logic, view and data. Since the controls define your view it is best to instantiate your controls in the files that are meant for it (the XML Views).
Performance: Destroying all controls means that if the user decides to switch between views, the controls have to be re-instantiated by the controller every time. This is, even though you probably won't notice it, not performant.
You don't need code replication: The argument of code replication is not necessarily true. If you can execute the same actions in the list and grid-view, it should be enough to just link the controller to both views and in that case you'll hardly have to replicate any code. Just make sure that you split your logic in enough functions. That way you might need to write some extra public functions to handle events, but not much more.
https://github.com/brianchance/MvvmCross-UserInteraction is a very nice plugin for showing cross platform Alerts!
But for this question, can we assume it can not use a UIAlertView (or some other top level MessageBox type call on other platforms) but needs to show a Message within a given subsection of the screen (i.e. on IPhone you would need to supply a UIView to the plugin which it will use to show the message within).
So, how would you set this up so the ViewModel knows what View to use as its display container?
As a specific example, if I wanted an Error Service, as so -
public interface IErrorPFService
{
void Show();
void Hide();
void SetErrors(List<Error> errors);
}
and I create a platform specific implementation for it.
If I inject this into my ViewModel so it can control Error Show/Hide/Set how do I tell it the UIView (or equivalent) that I want my Errors to show within?
Can I just expose the IErrorPFService field as a public property and do -
MyViewModel.ErrorPFService = new ErrorPFService(View);
in my ViewDidLoad ...
Or is this coupled incorrectly vs Mvvm Practice?
I would expect the ViewModel to subscribe itself to the ErrorService.
When receiving a message it would expose it in a collection(?) and the View would bind to that collection.
This way the View is unknown to the service and the ViewModel has the chance to influence the View contrary to your solution.
It would help if you could give an example for the scenario you are describing.
Sometimes, the way you visually want to display something might not be the best way, so if it's possible for you, you might find a different and simpler way, which spares you from having to find a solution regarding what you are describing.
Generally, I always do the best I can to avoid the idea of having to actually pass a 'view' or an abstraction of it, from the view-model to view. Also, cross-platform wise, things can work very different in terms of UI interaction. You can find yourself in a situation when things are complicated just because UI works differently than what you expected.
But let's try find another perspective:
At any given point, the view knows what data \ feature it's displaying. So when you are calling from the view-model an user interaction action (by a service, property change, event, etc) the view should 'expect' it.
For example, the platform specific user interaction implementation is able to get the currently displayed top-view and interact it in a platform specific manner or based a relationship. In your example, the message-box can be displayed in a specific sub-view of the top level view.
In advanced scenarios, I guess you could try to create a cross-platform approach for this, but you should try to put in balance all the abstraction you want to create just for that. Think about doing this as a plan ... Z. If possible. Again, giving an example might help.
Lets say that on all my views, or generally at any time in my app, I want to be able to show an error message popup, and it always looks the same. How do I do that?
First thought is having all my view models extend a base view model which facilitates these things, but after that, do I have this base view model actually create the UI widgets and display them?
thanks,
Mark
If you've got some common functionality that you want to provide across a range of views, then you can implement a base class that inherits from the PhoneApplicationPage, and then derive all your classes from that class instead. The XAML for your pages then looks like this:
<local:BasePage xmlns ...
xmlns:local="clr-namespace:MyNamespace"
x:Class="MyNamespace.MyPage">
However, you will not be able to define common UI components in the XAML for your base page. If you wanted to have common UI components you would have create them manually in the code-behind for the base page, perhaps in a handler for the Loaded event, but I think a better solution would be to provide your common UI in a UserControl, which you then add to each of your pages.
If you want to show a Toast or Message Box, then I would recommend the ToastRequestTrigger and MessageBoxRequestTrigger from the Silverlight Toolkit as described in the patterns & practices WP7 Developer Guide.
you could probably define an event on base view model, which is fired inside view model whenever an error occurs, then in view, you can subscribe to this event and display the popup. You can carry error context in EventArgs of the fired event.
Additionally you could unify the logic for displaying the popup but that's probably another story :)
This is testable and nicely decoupled from the view.
Hope this helps,
Robert
Do you create a Viewcontroller per view screen? or should you share a viewcontrollers? (ie in the example below Should there be 3 controllers or just 1 controller?)
Example
Screens are related
Screen1 (input information),
Screen2 (Review and confirm Information),
Screen3 (thank you / status response).
You should code according to the MVC paradigm. Parcel out your code and separate it based on overrarching function. Here is a high level overview of MVC
(Data) Model: contains all of your app data, objects that are passed around and used to populate the views
View: everything that is some sort of visual output
Controller: Classes that make the models and views work together.
What this is saying, in iPhone development parlance, is don't just jam a bunch of code into your UIViewController subclass. If you want to change the way part of the system works, having one huge class with a ton of code in it is a lot harder to edit and fix, than several smaller classes with a specialized use.
To answer your question, you should most definitely use one controller for each view function, but going beyond that, you should create specialized classes that take the inputs and manipulate that data, create specialized classes that then use the data to send it back to the user in an output.
Don't put all of your code into one class. It might work, but if you ever need to tweak it, or, just like when the iPad came out, it has to be adapted to use on another platform, it will be easier to manage if you only have to change something small to make it work
In your case you definitely don't need separate controllers. In fact you don't even need separate views. You can create a single view to take information, process it in the same controller and show the result in a UIAlertView.
I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.
Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.
The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.
The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand!
The solution can be done by two (common) design-patterns:
Model-View-Controler (MVC)
Model-View-Presenter (MVP)
You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.
You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.
Next steps:
Add the rcp.presenter to the
dependencies of rcp.view (its
important that the presenter has no
reference to the view)
Export all packages that you are
going to create in the rcp.presenter
so they are visible
In rcp.presenter create an interface
IPerspective that has some methods
like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
call presenter.load() and implenent
this in the presenter maybe like this
code:
public void load()
{
User user = view.showLoginDialog(); // returns a user with the provided name/pw
user.login(); // login to system/database
if(user.isAdministrator())
view.showAdministratorViews(user);
else
view.showStandardViews(user);
}
As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.
For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view).
For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).
I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.
You might want to look at my second post at this question to get another idea on how you could structure your plugins.