I have a table that contains 4 varying types of data and depending on the type of data that is selected by the user, a specific edit view is shown. One of these views has one edit field, a second one has 2 edit fields, a third one uses a picker, and so on. What's the best way to handle these varying views without an explosion of classes and without too 'switch'ing to figure out which data I'm working with?
One way I can think of is to have 4 different view controllers with respective views and then launch each one when the specific item is selected in the table but is there another elegant way to do this?
You can either go with the four different view controllers, or have one view controller that accepts an argument in the initialization for which content to create. The second approach seems to work better when the views are very similar (different numbers of the same controls, etc.)
For your case, some views have pickers, some have text fields... It seems that it might be best just to create a different view controller for each. With this you get added flexibility down the road, even though there is slightly more code to maintain.
Related
I'm creating a calendar app and i want to lay it out in a UIPageViewController kind of style. So where each page displays a day. Each page will be exactly the same (as in UI components) but just contains different data. I would like to use the same ViewController to do this as it would obviously be a lot neater. But i'm just wondering if this would possible? And if so how would i go about doing it? Thanks guys.
When you say "same ViewController", do you mean same class or same instance of that class? The former is trivial. The latter is problematic because as you swipe from one page to another, you're seeing the multiple instances at the same time, so you would have to keep track of a series of instances, knowing when one was no longer needed, etc. That would probably introduce a complexity that is likely not warranted. I'd suggest you just instantiate a new instance of your view controller for each page, and only resort to further optimization if there are performance issues.
The other pattern would be to not use page view controller, but rather use a collection view (where each entry is a different full page cell). Then you enjoy cell reuse patterns. It might also open up other options (where you have different collection view layouts for daily, weekly, and monthly views, for example).
But you might want to go ahead and start with a nice and simple UIPageViewController and simply don't worry about separate instances of your single class of "day" view controller, because the overhead is negligible.
I am showing a form the user fills in my iPhone app. One of the fields is a set of 2 or 3 dates from which the user has to pick one. Putting a picker, or bringing up a table view just for this takes up too much space, leaving no room for the other fields. Is there any simpler way to do this?
To do this you can put two or three arrowed label with text like "Select Date" upon click of it you can show one view that allow user to select the date; once selected you can back to the original view. You can do this for all three (or two) dates and get those date on form view.
I am giving you idea of how you can design apps; if you want code i can assist that too but from your question it seems you want design ideas.
You can go for your custom drop down/combo box, but their is no inbuilt functionality present for this.
Also following is mentioned in apple HIG guideline, you need to consider those as well-
(http://developer.apple.com/library/IOs/#documentation/UserExperience/Conceptual/MobileHIG/UIElementGuidelines/UIElementGuidelines.html)
Guidelines
Use a picker to make it easy for people to choose from a set of values. It’s often best to use a picker when people are familiar with the entire set of values. This is because many, if not most, of the values are hidden when the wheel is stationary. If you need to provide a large set of choices that aren’t well known to your users, a picker might not be the appropriate control.
Consider using a table view, instead of a picker, if you need to display a very large number of values. This is because the greater height of a table view makes scrolling faster.
Use the translucent selection bar to display contextual information, such as a unit of measurement. Do not display such labels above the picker or on the wheel itself.
On iPad, present a picker only within a popover. A picker is not suitable for the main screen.
So I need to create a filter that is presented from a UIPopoverController. The different lists to filter on go to the data manager (model) class and query the sqlite database. The problem I am having conceptualizing is how to do this for multiple UIPopoverControllers with the most reusability. What I mean by that is, if I have two filters, one for say fruits, and another for say vegetables. Each one needs to be presented in a popover.
What I have done is, I have a UITableView that has a generic array. In the class that presents the popover, depending on what filter was pressed, I present the popover with the UITableView and the corresponding fruit and vegetable list.
The tricky part for me is, the problems with the checkmarks. Since my list consists of "All", plus each entry like "Apple" or "Orange", when the user selects All, no other checkmarks are visible. If the user selects apple, then all is deselected, and apple is selected with a checkmark. If apple is selected again, then apple is deselcted, and All is reselected. The way I handle this is, in didSelectrowForIndexPath, I query the model class, get my NSDictionary of YES/NO values for each key, and set it. This also takes care of when the popover is closed, and then presented again, then the checkmarks are all there in the last state they were in since the model was already updated.
So my two questions are
(1) if this implementation is 'ok,' then how would I have a separate list for each UITableView? It seems like since the UITableView manages one list, I would need to create multiple UITableViews, one for each filter, so those specific calls to the data manager, like "All", don't mess up the other filters
(2) is there a better way to do this? I'm open to suggestions! Thanks!
You may want to reconsider the user interface. It may not be necessary to have "All" as an option, and it may even be preferable to leave it out.
I've checked out how such filters work in other apps, and I've found that "All" is often not an option. When the table first appears, all fruits, say, are shown by default. When one entry, say "Apple", is selected, only apples are shown. When "Apple" is deselected, all results are shown once again.
This, of course, is the inverse of what is logical. Logically, if nothing is selected, nothing should be shown. However, I've found that when you're using such a filter without the "All" option, you don't realize the logical inconsistency and it somehow works very smoothly, as you would expect it to. On the other hand, it may appear more cumbersome for the user experience to have "All" being checked and unchecked automatically when the user is selecting an entirely different entry.
I've implemented a filter in just this way. In my opinion, it's more user friendly even if it's less logical.
As to the implementation, I just subclassed UITableViewController and set an array property for the filter entries. Then I re-use my subclass for different filters.
For my application I have multiple customers. For each customer there is a different set of images and server URLs. To address this issue I have created customer-specific files. So according to the target selected, the specific file is used for getting the images and dynamically loading them in the UI. But this method works only in case of similar layout for each customer. So precisely saying, the method I am using currently is not scaleable.
Following are the issues which I am facing right now:
The real problem comes when I need to change the layout according to the customer. In case of few screens I can dynamically set the position of elements in UI but its not a feasible solution in case of several XIB files. What is the best industry standard to achieve this?
Addition/deletion/modification of a feature is an issue. Suppose I have a Tab bar in my application. To provide 6 features to a customer, I have 6 different TabBar items in the app. Suppose if one the customer doesn't want any one of the feature from those. Is using a simple if-else to suppress any specific tab a right way to achieve this?
My approach is to not use XIB files and create all objects programmatically.
I have plist configuration files which define the objects in the app going so far as to define:
1) if the app starts with a tabbar or not, (if so how many items, their names and what viewcontrollers they refer to),
2) the viewcontrollers and tableviewcontrollers,
3) any buttons or images or text fields within the view of each viewcontroller etc.
then each version of the app can have different plist files and associated resources.
I am maintaining some code, part of it is a very cluttered xib file with two table views on top of each other (only 1 visible at any time when running) - I need to connect data sources and delegates from each of the tables, but because they're on top of each other, when I drag across, it always picks up the top one. Moving stuff around is not really an option, because it's very cluttered and cramped.
Any ideas on working efficiently with cluttered and complicated xib layouts?
If you're working with Xcode 3, look to the small window that shows the main objects, usually File's Owner, First Responder and View. There's a button on the top left of the window that lets you choose viewing by icons, list, or hierarchical. If you choose either list or hierarchical view, you can clearly see all your views and subviews in their hierarchical structure. You can right-click on any of them to make connections. When you have many views, one on top of another, it's usually much easier to work with them here.
I haven't moved to Xcode 4 yet, but there must be a similar option to view the hierarchical structure of views and subviews. I hope this helps some.