I am very new to iOS programming and iOS code design, and I am working on developing a simple iPhone application. The basic layout of my application is as follows:
In the first page, the user is presented with a list of categories. Upon clicking on a category, several options with drop down. Upon clicking on an option, the application will transition to a page where the user will input a number of values and be presented with an output. How many view controllers would I need for this application? Based on the little experience I have, I was thinking of using a view controller for the main page and then one for each option, but is this necessary? Is there a way I could use less view controllers?
Depending on how complicated and different each option is, you may be able to use one view controller for all options.
So..
Main view controller- Shows a list of categories, where options could show underneath when tapped
Option view controller- Shows input boxes with labels and an output box. You may show/hide different inputs based on how many you need and you can change the label text accordingly.
This would give your app the smallest UI with the most flexibility, in case you added more options.
Of course design is very subjective and depends on the deeper details of the project, but based on your description, I would implement it with 2 view controllers.
If the screen where you input the values can be generalised, then you will have only 2 view controllers.
But in the implementation of the first one, you will have to implement function:
func prepare(for: UIStoryboardSegue, sender: Any?)
to pass the data about the selected item. And the the second view controller should adjust its fields accordingly.
Related
I've create the following screen which takes 4 inputs when the user creates an account and 'Submits' for the first time.
After they submit once, the screen should go to "edit mode'. My question is, is it more effective to create two view controllers (one for initial input, and the other for edit mode), or just one view controller. If the latter, does anyone have any examples or tutorials? I'm positive that I'm not the first one to attempt this. Thanks!
All you want to do here is toggle the button's title and the editability of the text fields, so it is simplest (and best) to do that in place, in the same view and the same view controller. You are merely changing features of this view, not swapping out this view for another world of interface.
I am new to programming iOS and I am not sure on how to implement multiple/relational drop down pickers into my design.
I have a search form in my app that works like a panel-menu. If you click on the search icon then the panel slides in with the search form.
But what is the best way to implement multiple/relational drop down pickers for my search form?
The pickers are relational. First you select a state then you must select a city. Once you selected a state in dropdown1 then dropdown2 should get populated depending on what you selected in dropdown1.
So is there any good solution for this when it comes to design?
I would like to show both pickers at all time. Kinda like a datepicker when year / month / day always is shown.
But if anyone has a good resource example on relational pickers please share.
Thanks in advance,
You can set this up with nested UITableViewControllers.
These types of projects are generally called Master/Detail.
The Master tableView would display the list of categories.
Once the user has selected a category, the specific category is passed to the detail View controller. It queries all the subcategories for that category.
This can all by done in Storyboard, using Auto Layout, self-sizing cells, and a combination of show and unwind segues.
A show segue pushes a (table) view controller onto the navigation controller stack. In your case, the category controller would push a subcategory controller. prepareForSegue:sender: is where the category controller would provide the category to the subcategory controller.
An unwind segue returns from a view controller, popping it off the navigation stack. In your case, the subcategory controller would return (with the selected subcategory information) to the category controller, or a previous view controller.
It may sound like a lot to digest, but if you read up on recent (i.e. for iOS 8) walkthroughs which use these concepts, you'll have learned some acceptable practices for how information and control should flow within an app.
There's one more thing I didn't mention, called Core Data. Core Data, and NSFetchedResultsController would be a great tool to learn and use for the app. It's probably more complex than anything I previously mentioned, but once you get a handle on it, you will really appreciate it, and may end up using it in many apps!
Don't get too bogged down with how your app should look. Focus on how the model and view controllers are written, and get a good understanding of the underlying frameworks. That's more important right now, than any fancy transition/animation.
The design of any app will evolve as you use it. You'll discover what works well, and what doesn't, so don't get too attached to any one way of organizing the data!
Hope that helps! Enjoy programming for iOS, it's a great platform!
For years, I've hand-coded my view code for iPhone apps, but now I'm giving storyboards another look.
One common pattern in my code is to use the same view controller in two places, but with slight UI variations. For example, when browsing a list of brands (BrandListController), I'd like to show a table view of all brands in the system; tapping a brand shows you its products. But when filtering items by brand, I'd like to show a table view of brands (with the same content and same cell appearance), but I'd like tapping a row to take you back to the filter screen instead of showing you that brand's items. I'd also like a "Search" bar button item in the top right.
It's easy to make these things happen in code, by just adding a boolean member variable so the controller can be configured before it's presented.
But how would I do this with storyboards? I could have multiple controllers segue to the same instance of BrandListController, but again, I would want the controller to have different behavior and include/exclude UI elements based on how it's used. It seems like a bad idea to create two separate instances of BrandListController in the storyboard, because then I would have to duplicate all the outlet connections and I would have to keep changes in sync. But what are my other options?
The thing to realise with Storyboards is that you don't necessarily have to only use a single storyboard.
You can use multiple storyboards or use them in conjunction with nibs etc...
However, in this case what you could do is still use you boolean property on the controller.
Then in the prepareForSegue method of the other controllers you can set this boolean property to change the behaviour. You might even have a couple of nibs that defines a small section of UI to place into the view depending on the property.
I've done stuff like this to pass blocks into view controller too.
For example...
I had a "User Search" controller that had a default behaviour of if you tap a user it will push to that user's profile page.
But I could pass in a code block that would, for instance, dismiss the search controller and I use the selected user to create a new message to them (or whatever). Or something else entirely depending on the code block I passed in.
EDIT
LOL, just re-read your question. What I did with the blocks would work for you too. I created a block property called userTappedBlock or something. If that exists then I run it when the cell is tapped. If not I do the default behaviour.
I'm working on figuring out mvvmcross and if I can use it for an iPhone (and eventually iPad and Android) app I'm going to develop. The MVVM pattern is really powerful and works great for me, but I have several views where I need to add a navigation control that will allow the user to jump to several different other views and I'm wondering what's the best way to do it.
Right now, I've created a NavigationControlViewModel which exposes a collection of NavigationLinkViewModel which have a link text property and a command that will show the appropriate view. But to add this to a view for, say, MyViewModel is a little tricky. Right now what I've done is add the NavigationControlViewModel to MyViewModel so that I can bind it in MyView:
private NavigationControlViewModel _nav;
public NavigationControlViewModel Navigation {
get {
_nav = _nav ?? new NavigationControlViewModel (Mvx.Resolve<INavigationService> ());
return _nav;
}
}
This works, but doesn't seem as nicely contained as I'd like to be. I still need to add controls to MyView for the NavigationControlViewModel and then add it to every other view that needs it (as well as adding it to their view models).
What would be the best practice for handling this sort of thing in iOS and MVVM?
I've seen the video on using a split view, but I'm not sure if that's the best approach. I need a vertical split and I only need it on some views, not every view.
For sharing the navigation mechanism between view models, I guess you can use either aggregation as you have done NavigationControlViewModel or you can use inheritance with all the navigation items in a BaseViewModel class.
I personally would happily use either of those but would make sure to expose all my Navigation options as ICommands - simply because that's the way .Net-style data-binding generally expects 'action hooks' to be presented. Note that there is a reflection way of generating ICommand's - see http://slodge.blogspot.co.uk/2013/03/fixing-mvvm-commands-making-hot-tuna.html
For actually presenting the ViewModel via a View on the screen... I'd encourage you to believe that you can do whatever you and your UX/design team want to.
Some of the standard presentation approaches are available via: UINavgiationController, UISplitViewController, UITabBarViewController, UIPopupView and PresentModalViewController - and you are free to use these and to combine them together - e.g. you can have a navigation controller which two layers deep shows a modal view which contains a split view with two children...
Beyond the standard approaches, there are plenty of other UI design paradigms that people have selected:
flyout and flyunder views - like the hamburger menu
the Twitter iPad stacked view approach - like https://github.com/steipete/PSStackedView
heads up display views (dialogs)
continuous scrolled views
... plenty more - see http://pttrns.com/categories/13-navigations
By default, MvvmCross provides you with a 'whole page' presenter which presents every View-ViewModel pair the same way inside a UINavigationController. As you've seen in the N+1 video you mention, you can easily override that behaviour and you can then choose to present View-ViewModel pairs in any way you like - e.g. you can choose to present some whole page, some using a fly out, and then some using tabs.
Because an IMvxTouchView presenter is just C# code, and because we devs love writing C# code, we can implement whatever wonderful logic we want to within a presenter including code that tests what is currently being shown in order to determine where to show the next page.
I can't comment on what 'best practice' is for making a design look nice.
But I do believe that if you stick with showing your view models via ShowViewModel then that will allow you the most flexibility in what presentation strategy to use on each platform.
Some more on presenters is available via http://slodge.blogspot.co.uk/2013/06/presenter-roundup.html
I'm making a settings menu in my application, and so far I'm making separate view controller for every screen. Is this a correct way of doing that? It grows very fast, and I am not sure it is an optimal way. For example, I have:
UINavigationViewController that is main controller of settings tab.
Under it I have UITableViewController that shows main settings screen.
When I click any settings cell in the middle, it sends me to its own view controller.
And I need different models to keep every part of every view controller settings separate, or can I just fill them up into one file?
And as I have many customizable settings, do I really need separate view controller for every settings button? This looks overly complicated.
This will depend to some extent on the specific types of settings that you need. For simple on/off settings you can use a UISwitch control directly in your main TableView (see Airplane Mode in the main Settings app as an example).
For any other types of settings that are similar you can use a single generic view controller that is passed the necessary parameters for each setting. For example, maybe you have five different settings that all involve picking one item from a list. These could all call the same controller, passing an array of choices and a reference to the parameter rather than recreating essentially the same view five times.
By doing this and also grouping related settings into a single view (again, see the main Settings app for examples), you should be able to keep the number of necessary controllers to a minimum.
You have options, you can create multiple views and apply a navigation-like push animation varying the view. However, a better way, and where they finally come into use, is using a storyboard.
A storyboard is one file that can hold many view controllers and you can link interactions, it's really hard to use from my experience, but is exactly what you are looking for.