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.
Related
I'm new to iOS and Swift and I have troubles figuring out how to navigate through views.
I'm trying to switch betweens views and being able to press back and next button as you wish without losing data (like textfields, spinner, etc.). I tried with "popToView" but as the name says, it will pop views which is not what I want.
What would be the best way to do such a thing?
The idea is being able to navigate through a form in multiple views. At the end, you have some kind of calculations with the values you filled. I want to be able to go back to previous views so I can change some fields. Once I did my modifications, I want to navigate to the final view again and see the new results.
This could be a design issue. You should normally have no data in the view themselves (e.g. content of text fields). The design pattern behind UIViewControllers assumes that you have a back end "model" with the data and that your views/view controllers are merely a means to convey that content to the user. So navigating between views should have no issues with content loss even if the views and controllers are released.
Besides, keeping a large number of views and controllers active in memory will eventually hit limits (iOS devices are not as memory rich as computers) and is generally not a good practice.
If you're supporting multiple devices, especially iPhone, popOvers and other presentation modes will automatically release views (as opposed to iPads that may keep them alive) so you need to be ready to handle both situations which means storing the data in your models, and not rely on views for that.
If you must keep them alive nonetheless, you simply have to retain a reference to the view controllers either in a global variable or array
This values get from web servies. Totally i want to show 4 layer to display[i show here only 2 layer]. some times in web servies values are come more means the layer become big and show the values.same and anther 3 layers are displayed. help me..!
Use UIScrollView or Freeform make it independent means don't use static value make it dynamic whatever number of layers you are getting from server and according to that adjust content size of UIScrollView.
First of all. This view (and design) doesn't really follow any iOS consistency. The Apple human interface guidelines are there to help you with finding the correct way to do something.
Right...
Do you need to show all the options at the same time? i.e. do you need all four "layers" on the screen at the same time? If so, why? What is the user supposed to do with this screen?
Is the user selecting one option from each layer? Multiple options from each layer? etc...
With either of these I would go down the route of using a navigation controller with a single UITableViewController to display each layer.
So, the user gets a nice list of options...
dumbell
E-Zbar
cable
barbel
...
And selects one (or many) of them.
Then the second "layer" is pushed onto the navigation stack and the user gets another nice list...
incline
decline
close-grip
rotating
...
This way the user has to only concentrate on one task and each list is deployed nicely and readably for them.
If I was a user and was presented with a big list of buttons like your design I wouldn't know what I was supposed to do.
I have a main Container View controller which has a table view controller and another view controller. In table view I am displaying certain items which can be selected and grouped. This group details are shown on the view controller(like a summary). once grouped these items will no longer be in table view. If needed I can even ungroup them and add it back to table view.
So these two view controllers need to have a communication channel between them. What would be the best approach here ? Protocols or blocks ? Notifications are a strict no.
The business logic of your application should be handled separately from the code that glues things into views — you're conflating model and controller.
So the items and the groupings would be maintained by a third class. Both view controllers would talk to it. They would nit talk to one another beyond transient UI information like, say, one saying "this was the specific item selected".
A good way to think about it is to start with the goal of no direct communication. Instead, both VCs have access to the application's model (usually a form of a singleton), and configure their state based on the state of the model. In other words, the view controllers are stateful with respect to the app's model, stateless with respect to each other.
But sometimes vcs in the same container must communicate, like in a navigation controller when a selection is made. That's typically done in prepare for segue. The selection is conveyed to the vc being pushed, and then it carries on. To the extent that vc needs to communicate back down the stack, I try to go by the first principal: can it just change the model state and get popped, counting on its parent to notice the changes in viewDidAppear?
If I need further communication still, I begin to worry about my design, but the next place I go is KVO. There again, view controllers are passive with respect to each other, watching the app's model for changes they care about. I classify NSNotification in this category. Even though it sounds like you want to rule it out, it's my third favorite idea after nothing.
While I'm editing here, I notice #Tommy has provided concise advice that I agree with (and consistent with my opinion here). I'll leave the answer since it adds a little nuance.
I am working on an app in which one View Controller has the responsobility of containing thre views.
Each and every one of this view has a datasource of somme measurements.
The views are in sync -> selectind one point in one view has a resemblence in other views.
User can select in various options to disply in each of the views (e.g. 3 views but 5 view options.
Here is my current aproach to take in this situation:
Create a component protocol -all views have to conform.
Component for example is a UICollecytionView with details for the selections (which is made in other components).
The component has a view property and is added dynamicaly to the container view of the view controller by the controller.
Visible view controllers are synced by a sync manager - to which the visible view is registered by the view controller.
Delegates are mostly implemented in the Component -> some events are exposed in a component delegate (user selected etc. so the sync manager can sync other views).
The view controller is responsible for capturing a delegate from user selection of measurement batches (e.g. batch from a given day in another view controller) and then loads needed data and triggers the sync manager to give the selected batch to each of the visible components.
The component is then responsible for presenting the batch (as well as loading/finding relevant points for the new batch if earlier batches had selected points)
Is this approach correct? Having the code of each component in the view controller would (and in the first approach did) clog the sense and clarity of it!
I also did read about View Controller Containment (so that if i understand correctly would mean crating a view controller for each option and handle that element inside the view controller and swap them for visible views on the screen). Then the user selection would trigger swapping a view controller responsible for a concrete selection of an option but then the sync would best be made by the parent view controller (am I correct).
Hope I am clear enough... although I am aware that the description is hazy but you should get the main idea.
Reasuming:
What approach is better? The component seem like a good reusable components that i can pretty dynamically add to other view controllers etc.
What are the possible pitfalls of each of these approaches if any?
I have a network client iOS app. There is a "controller" object that is responsible for receiving updates from the network. It should store / forward them to the various visible pages in the app. One page may need some of the data, one page may need some other part. There is overlap.
For example, a button needs to be highlighted or not based on the status of a device on the network. Buttons on different pages may need to reflect this status.
I need to determine if my various view controllers need to handle this or if the UI elements themselves can do it. In my example, I will need the UI button to react to events, probably based on it's "tag" field.
I've thought about implementing a category to "wrap" the various UI elements, but I'd like to use storyboard layout. This seems convoluted. Or, I can set tags on the UI elements and have the enclosing view controller gather all these up into a dictionary of UI elements and do the watching/updating using tags as keys. Or...?
I guess I'd like some pointers on what model may be best. I need this to be flexible and adaptable moving forward, so I'd can't have a bunch of code and IBOutlets for each UI item. I'm trying to keep everything as generic as possible so that when I need to make changes, I can add UI elements, set their tags, and let their enclosing view controllers take care of them.
Thanks
I think you should think about it this way:
Your app needs a model that represents the external state of the
world; in your case, devices on the network.
Another part of your app (probably a singleton with some
timers) is keeping track of the state of the world (probably doing
GETSs using NSURLConnection) and then updating your model.
Your ViewControllers present a view to the user, and observe the state
of your model, telling the views to change when the model does. (e.g. your viewcontroller would observe that a device in your model changed state to offline and then set a corresponding myButton.enabled=NO).
Take a look at iOS key-value observing docs to learn more about that. If you think you'll have many views observing the same aspects of the model, consider using the NSNotification center.