Hello stackoverflow fellows!
Please consider an UI workflow in iOS:
One main viewcontroller and several other viewcontrollers branching out from there:
mainviewcontroller
+-viewcontroller 1
+-viewcontroller 2
+-viewcontroller 3
etc.
I would like to be able to switch and switch back from the main viewcontroller to one of the other viewcontrollers AND also switch BETWEEN the other viewcontrollers.
All iOS patterns I know of seem to be problematic for that usecase:
UITabbarController would be the right choice if I could make the
tabbar disappear - it doesn't fit to the design. I was able to hide
the bar, but the viewcontroller screens don't resize themselves and
the whole thing feels hackish.
UINavigationController is designed for a sequential order of
screens, also the slide-in animation doesn't fit to the design
Modal viewcontrollers are also meant for a sequential order, additionally I have to keep
track of how many viewcontrollers are on the stack. Also, there is a
timing problem with dismissing a view controller and immediately
presenting the next one.
I could just switching views within a viewcontroller I guess, but the
viewcontrollers have all kinds of subtasks to do. I would end up with
one huge viewcontroller and lots of methods embedded for the
different views.
My question:
What would be the best approach to manage a bunch of viewcontrollers in any order I would like to?
Thanks for any help!
I would have a main UIViewController. That one would have references to the other three UIViewControllers. You can then do something like this from inside your main UIViewController:
[self.view addSubview:view1.view];
This works, but I wouldn't advise you doing because it's not the natural way of doing it. As stated by apple:
You should not use view controllers to manage views that fill only a
part of their window—that is, only part of the area defined by the
application content rectangle. If you want to have an interface
composed of several smaller views, embed them all in a single root
view and manage that view with your view controller.
Ok, my solution is not perfect, but seems to work:
Create a UINavigationController.
Use the viewcontrollers: method to add a stack of viewcontrollers to your liking.
When switching between viewcontrollers, rebuild the stack and attach again.
Problem: You only have the navigation controllers animation (slide in/out) at your disposal.
But you can disable the navigationcontrollers animation, get the next viewcontrollers view, animate that in with a UIView animation, then switch to the view controller itself through stack building as explained above.
Really far from perfect, but works.
Related
I have a main menu screen, which has 4 options, New Game, Load Game, Options and Exit.
Then:
New Game has more options such as difficulty, # of players + Start button.
Load Game has multiple saves to choose from together with Load and Delete options.
Options has Graphics level and Volume radio/ slider + Apply, Discard buttons.
At last, the game screen would have a pannable game window, together with an overlaying UI on the side of the screen.
My problem is, I don't know what class to use for those UI parts.
From this answer I understand that Screen is a full UI page, but it seems that creating a new Screen and then a Stage for each of those main menu options seems like an overkill, but maybe that's the way to go. I don't know if I should use Group and show/hide those depending on what the user clicks. I was also told to use Table to lay out the game screen. I'm utterly confused by all the guides I've found online. Every one seems different than the other.
The documentation is really good, but it never states how the individual parts are meant to be integrating with each other.
Is there any consensus on how to use those classes in LibGDX? Or is it a personal preference?
Screen is core libGdx part that represents one of many application screens, such as a mainscreen, a settingsscreen, the gamescreen and so on.
mainscreen may contains buttons like settings, play, level that help you to redirect on other screen.
settingsscreen may contain back button that redirect to previous mainscreen and other ui element like sound button, music button, language selection button.
It is hard to maintain different UI Screen in one ApplicationListenercontext with different required lifecycle.
so there is a Game class and Screen interface that helps to display one active screen at a time on device screen.
I think you've clear now, why we need different screens.
Now how I design one Screen Like MenuSceen that contains menu buttons, game name and similar element that act as HomeScreen.
You can use scene2d, a 2D scene graph for building UIs using a hierarchy of actors. Stage and Group are core classes of scene2d.
Stage class has a camera, SpriteBatch, and a root group and handles drawing the actors and distributing input events.
Group class is an actor that may have child actors.
Does anyone have a simple C# Example showing how you could use Custom Container ViewControllers with Xamarin / Monotouch as per this Apple documentation -
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html
Instead of posting question, thought would be more helpful to go away and create an example.
https://github.com/wickedw/ViewControllerContainer/blob/master/README.md
Readme Excerpt
I got to a point within a project whereby I wanted to display 3 different "Screens" of information based on a user selection.
The TabBarController was not appropriate as the GUI sat within a UINavigationController hierarchy. Yet, the UISegmentedControl fitted the design well.
I already had my views fully coded as seperate ViewControllers (and not all using the same creation pattern, some used Monotouch Dialog, others Nib files, others Programmatic).
Therefore, I did not want to rewrite existing code to use a Single ViewController controlling multiple Views.
I also thought it was time I looked at "Custom ViewController Containers" as they seemed an ideal fit for this scenario.
Having read many tutorials, articles and questions, I am still have confusions about updating the GUI. Plus there are numerous related questions here on this website and still no luck - even though I think my problem is very simple.
Basically, I have a JFrame that has a JLayeredPane as its root container. And I have some layers of JPanels inside it.
The main issue is with updating a particular JPanel in this JLayeredPane. And for this particular Panel, I have implemented an update method that changes the contents inside it.
updatePanel(int para)
//doesn't remove this panel
//removes some existing labels and replaces it with new ones
Once I create the whole Frame, obviously just calling this method won't show any change displayed the frame.
private void static main (String[] args){
WindowFrame frame = new WindowFrame()//WindowFrame extends JFrame
frame.updatePanel(2);
.....
.....
}
And that's where I am stuck. I want to update the contents as the frame is displayed.
I saw these methods mentioned by people but due to nature of problems, I couldn't fully grasped the concepts. Plus the documentation on these methods isn't really helping - at least to me.
revalidate()
validate()
repaint()
How/when should these methods should be called? Or is this not the right way of what I should be doing, given these methods and the problem I am trying to solve?
Thank you for your time.
Basically you need two methods:
revalidate()
This method does the same as invalidate() but in AWT event dispatching thread (i will just call it Swing thread later on)). It updates container and all of its ancestors (parent containers in which this one is placed) layouting.
Basically if you either move something inside this container or place/remove components inside of it you should call this method (or invalidate in case you are performing it in Swing thread, for example inside any Mouse/Action listener body or just inside).
repaint()
This method forces component, all its sub-components (if it has them) and parent container (basically if this component is NOT opaque) to update what they are "painting".
Usually you don't need this method since all standard Swing components know when to repaint themselves and they do it on their own (that ofcourse depends on components UIs and some other things). This method might be useful in case you have your own specific components with some unique painting-way (for e.g. some custom selection over the components) and in some rare problematic cases with standard components.
Also the way this method acts depends on the components placement (due to some Swing painting optimizations) - if you have some massive repaints rolling you'd better optimize them to repaint only those parts (rects) that you actually need to repaint. For example if you change the component bounds inside any container the best choice is either to repaint its old bounds rect and new bounds rect OR repaint rect that contains both of those bounds, but not the whole container to avoid repainting uninvolved in the action components.
So, basically in your case after some changes with panels you should call revalidate on their container (or invalidate) followed by repaint (in case revalidate leaves some visual artefacts) again for the container.
Guess i didn't miss anything and i hope that now you know the basic meaning of those methods.
revalidate at the end of your update method like so .
updatePanel(int para){
.....
.....
this.revalidate(); //of course this refer to the panel
parent.revalidate(); // parent refer to the window
}
I have a uiNavigationController and two viewControllers. The problem I am having is the views are being generated in portrait size even though I want them in landscape!
Here is what I am doing:
1) Creating an instance of view1 and adding it to the uiNavigationControllers stack. This is performed inside the applications delegate didFinishLoadingWithOptions(...) method.
2) view1 has a button that when clicked creates an instance of view2 and pushes it onto the uiNavigationControllers stack.
This appears to work fine apart from the fact the views are being created in portrait format. I was going to manually force landscape by using transform methods once I create their instance but this feels really hacky.
I did speculate that this has something to do with the "shouldAutorotateToInterfaceOrientation" method, but this is set for landscape in all viewControllers.
I am royally confused.
Question 1) How on earth do I solve this, is the 'hacky transform' approach the only way?
Question 2) Is this the correct way to be using a navigationController - I am new to iPhone programming. All I want are two landscape views that I can click between and this seems to do this aside from the landscape bit ^^.
I found the answer for this problem.
The navigation controller DOES inherit the shouldAuthororateToInterfaceOrierntation method for each of the views inside its stack, I however made a mistake :)
After adding the navController to the main window I had not deleted the part where by default it adds the a rootController view to the main window. There was some kind of conflict which stopped my navigation controller working as expecting - removing that line fixed everything.
I just started to study the Model View Controller pattern. I now understand the basic usage of MVC, but when i tried to implement MVC in a simple test, i ran into a problem. Ofcoarse I could easily adjust the code so it works, but I wish to learn how to correctly implement the MVC pattern.
The test:
I used actionscript 3 to make a simple program. It consist of a turret, and a mouseclick. The turret is in the middle of the screen. When I click anywhere the turret rotates towards the point where I clicked. Both the mouse and the turret have their own model,view and controller. When I click, the MouseModel changes correctly. But for the actual TurretView to respond, the TurretModel must change its rotation variable and send out an event.
The question is who responds to the MouseModel event?
/------->MouseControl------\
/ \
MouseView ?<---MouseModel
TurretView <------------------TurretModel
TurretControl
I figured its best not to have MouseModel directly influence TurretModel or TurretControl, because this would require them to be an eventListener. Making TurretView listen to the MouseModel, and then tell TurretControl to adjust TurretModel, after wich TurretView can update trough a TurretModel event looks like a lot of extra code for a simple task. Also I'd rather not have MouseControl affect TurretModel, this would break the flexibility of the mouse as input for future classes.
Ow, also in which class do I put the code for the angle calculation?
Thanks in advance
Remember that the goal with MVC is primarily the separation of Model and View, and the Controller can serve as the communicator between the two.
Unless you are planning on storing each action that occurs (clicking, rotating, etc.), there is no real need for an action (in this situation) to send data to the Model. Everything you'd like to do should be easily handled with the Controller. So the flow would be:
Mouse click
Event is fired to trigger a command (in the Controller), passing along the mouse location
The command calculates the turret's rotation
The command tells the View to rotate the turret
This is, of course, my suggestion based off of your example. In truth, depending on the project, the above flow could easily change (for instance, in this situation it seems good to do rotation calculation in the command, but in other situations that may not make as much sense). Look at MVC as a goal - you're trying to separate these elements as much as possible, but there is no 100% "works-every-time" way to do it.
Robotlegs, a popular MVC framework, has a great diagram on their site showing how they tackled MVC:
http://www.robotlegs.org/diagram/
I'm not advertising that you NEED to use Robotlegs (it's good, but there's plenty of other alternatives), but they definitely made a pretty diagram :)
You should have one model, which then has pieces in it that you are currently calling MouseModel and TurretModel. You can either keep those names and breakdowns, or do something else once you have a better "handle" on what needs to be done.
The View that is tracking the mouse clicks should dispatch an event that your Controller component catches to update the TurretModel (at this point, there's probably no need for a MouseModel). Your TurretView can then update itself based on the TurretModel, or the Controller can update the TurretView based on the new value. This will depend on how you have it wired.
Usin a Framework such as Robotlegs can help you figure out all the ins and outs of this process, and I've heard that this book http://shop.oreilly.com/product/0636920021216.do provides a great explanation of MVC, even if you don't choose to use Robotlegs after you read it.