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.
Related
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.
I use the MVP pattern in my project. According to it Place define view after a new Activity starts. In some cases when I have to save the content of some Text areas after change of Place. I think that it is not a good idea to put these text areas in Place, because they don't define business logic. To save them in View elements is not good either. How do I resolve this situation?
GUI elements (GWT widgets) belong in Views. Why do you think otherwise?
Then your View interface (or is it Display?) can have getTextData()/setTextData() methods to retrieve data in your TextBox.
I have a ViewController whose view results from data from a fetch request with Predicate 1. I'd like to repeat the fetch request with a more restrictive Predicate 2 that will give a SUBSET of the data using Predicate 1.
Then I'd like to update (and possibly animate) that view on the iPhone screen by pressing a toggle button, so that the old and new views expand and collapse the rows. (I don't want to do this modally, as I'd like the user to see which rows came from the old rows.)
I'm thinking of something like the Phone application on the iPhone. Under the "Recents" tab, you'll see "All" and "Missed" buttons. When you press these buttons, it switches between showing all calls and just the missed ones by expanding/collapsing the rows. As far as I can tell, this is not a modal transition.
Can someone give me pointers as to how to do this?
If your view is a UITableView, you can use a combination of
-deleteRowsAtIndexPaths:withRowAnimation:
and
-deleteSections:withRowAnimation:
as well as the corresponding -insert methods, if applicable. You can batch multiple changes (so they animate at the same time) with -beginUpdates and -endUpdates.
I'm not aware of any way you'll be able to do this that doesn't involve iterating over one of the two sets and repeatedly calling -indexForObject on the other, though.
I found a way to expand/collapse rows by changing the heights of each cell, using tableView:heightForRowsAtIndexPath:indexPath:, as in:
http://www.alexandre-gomes.com/?p=482
Hope that's helpful to someone!
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.
From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.