When i put a VerticalFieldManager to a Stack and delete all items in VerticalFieldManager, the VerticalFieldManager in Stack is also changing.
Does Stack keep reference of object? If so, how can I keep managers in a Stack?
Does Stack keep reference of object?
Yes, it works as any other Java container, such as a Vector for example.
If so, how can I keep managers in a Stack?
Not sure what are you talking about. Once you have put an Object into container the Object is already kept by the container.
Probably say what are you trying to achieve with putting managers in a Stack.
Related
When should I either of these?
Which of these is better suited, if I only need to group sub-views and hide/ show them based on a logic?
You should be more clear with your question. From my understanding ...
When people talk about container views, they usually mean just a plain old UIView that contains other views. Using a view in that way lets you move all the views it contains as a group, so that their positions relative to each other are maintained. It also makes it easy to hide all the contained views as a group.
Adding subviews for small applications, will not consume much memory. While if you are going for huge applications, you must maintain a state, so that which view will be added to container view as subview at each state of your application.
for example:
state 1 - login
state 2 - Dashboard
state 3 - People VC
Each state points to each viewController. So you have to maintain a state machine for states and viewController in your application.
Im trying to do app with a card based ui, kind of like Jelly. I was wondering the how this would be done. Im thinking by using a collection view but Im not sure. Are there any open source libraries that would make it easier to do this? Thanks.
You're probably not going to be able to accomplish this using out-of-the-box components. I don't think UICollectionView is going to get you very far. You will almost certainly need to roll your own.
I would start by creating a View Controller class for the "cards", instantiate a few of them, add the views as subviews to the main view, and get to the point where you can comfortably push these cards around with your fingers. You will want to read up on animating UIViews, and UIGestureRecognizers. Make sure the momentum is right. Apps like this really really demand highly-tuned physics, otherwise they'll feel awkward.
Once you get to the point where your cards are happily zipping around the screen, it's just a matter of getting them to "sink" into a couple pre-defined positions (focused front-and-center, and resting in a stack down below). You would probably also want to give your view controllers some sort of state that indicates whether they're "active", or not.
Easier said than done, obviously.
This question is a two-parter, I've looked about but have not been able to find a question like it, but perhaps I just didn't know specifically what to search for.
I have a container view which acts like a navigation for the user (with other options like saving) which sits at the top of most of my UIViewControllers. So each view is accessible from every other view. The problem I have is that this can create loops in the UINavigationController which is not advised. My attempt at the moment is to remove all but the root UIViewController and then load the new view controller. This is no good, while it loads alright, my assets are fairly memory intensive so loading them from scratch or having multiple instances loaded at one time takes a bit too much memory. I am going to reduce the asset size asap to reduce memory pressure but I still think the way I am doing it is pretty horrible and inefficient so I want to know a more efficient way of managing the UIViewControllers.
The other part of this question is about loading these UIViewControllers. I have multiple ways to enter certain UIViewControllers and they need slightly different configurations. I know I could load the UIViewController manually with a specific init method, or I could use an NSNotification to tell the class to do some extra initialisation stuff, but I was wondering if there is a better way to do this, and if there isn't which option would be better?
Sorry for the wall of text, any advice is appreciated.
For question one, it sounds like you should not be using a UINavigationController as the base for your container view controller. Instead you should be using your own custom container view controller.
If you want to check out an example of a custom container view controller, or to simply use a class that makes it a little easier to create one, you can check out my class CLFContainerViewController on GitHub: https://github.com/cflesner/CLFContainerViewController
It's not updated yet to use all of the new animation options that iOS 7 offers, so it's a little clunky to animate the transitions (although it gives you a lot of flexibility). It is fully compatible with iOS 7 though.
For question two, how you create them is entirely personal preference. You can create custom init methods, or you can just have properties that you set to configure the view controller. If you're using a custom container view controller, you will either need to initialize them with some flavor of init, or if you're using storyboards you can call instantiateViewControllerWithIdentifer: to get an instance of one.
This is a serious problem for me right now. Working on a code base with multi-layered children viewcontrollers about 4-5 layers deep - this is a tablet app with a very high degree of decoupling between viewcontrollers. The 5th layer child viewcontroller wants to send a message to the top level viewcontroller to show a modal. The 4th layer and 3rd layer have different messages as well so basically now I have like 4 protocols and its getting pretty complicated to send messages from such child viewcontrollers nested deep within to an ancestor viewcontroller. Is there an easier way to do this?
We thought about using NSNotification but not particularly fond of it because of its difficulty in debugging it and subscription not being a clear dependency within our control. We also thought about using a singleton but statics and singletons are evil (right?) and cause problems around state and concurrency.
Any help is appreciated. Also I realize I realize this is a slightly open ended design based question but it has a very specific use case (like the one described above).
Is an interesting question, but I guess we need few hints, such as a scheme. The first thought is why you need to add nested child? couldn't you manage using a simple stack and a single Container VC? It seems to be not correct how you manage your VCs. If they need to be notified about changes in the model, it should be only the visible to catch them, in the viewWill/Did/appear of the others you can ask fresh data again. If you need to inform each VC about their states, I think you should modify your hierarchy.
I imagine a Container VC with a stack or a set of VCs and visible VC propery. This Container will manage the exchange of info. As rdelmar said, it seems a really high degrees of coupling. You should rethink in way that sees communication only between container and visible VC, the others can refresh their data while they appear.
I am trying to create an array based implementation of Stacks. I am a bit confused with where should the Top Of Stack (a variable in my implementation) be when,
The list is empty
The list is full
The list is neither empty and not full
Please help me out.
Thanks.
That depends only how you define TopOfStack: is it the first unused slot? Or is it the last thing pushed onto the stack.
As soon as you choose one of those two options the rest can be deduced easily.