I have two view controllers which should work like described below:
First view controller displays a view which has a table in it. The table contains data which is constantly changing. I have a delegate method for reloading the data when a change occurs. So that is taken care of. When the user selects a row in the table I would like to display a second view which would also contain live data in text format (one UITextView which would constantly change).
I would like to allow the user to access view 1 while view 2 would still be monitoring and displaying live data and vice versa. While user is on view 2, view 1 should still be monitoring and displaying any changes in the table content.
I guess its like having two view controllers present at the same time and switching between them.
What is the easiest or the most standard way to accomplish this? I dont mind if its all done programatically.
It's a little hard to tell what you're asking here. First, views shouldn't be processing data at all -- they should only be displaying it. It sounds like what you're describing is having a background process that updates to your second view. That process could certainly be running while your table is on screen, and when you switch to the second view, you can update it using this running process. Exactly how you would do this depends on the details of what you're trying to do. So, I think we could help you better if you provide more context on what kind of process you want going on that updates your second view, and how choosing a row in your table affects that process.
After Edit:
You can certainly do what you want to do. I think the main thing is that you need to have a property (typed strong) in your first view controller that points to your second view controller, so that when you go back to the second controller a second time, it goes back to the same instance. Based on the selection from the table, you can start whatever process you need to populate your text view, and that process can keep running even after you go back to the table view, since that controller won't get deallocated when it's view goes off screen (due to the strong reference you have). You would just have to have some sort of if clause in your second view controller to know whether the user has selected the same row again, and if so, just show the updated text view, rather than starting a new process.
That's about as specific as I can be without more detail from you.
what you have is a problem where you need a custom parentviewcontroller
look into splitviews as one example :: SplitView like Facebook app on iPhone
cool intros of how to do custom container view controllers :: Container View Controller Examples
Related
I have a simple project that was started from a Master/Detail template for iOS7.
I'd like to layout the detail view controller just like iOS settings. Do folks recommend using a table for that or just laying out the controls one by one?
Here is a screenshot of the effect I am looking for:
This is probably a matter of taste/opinion but I prefer tables for this kind of thing for these reasons:
You get all the nice features of tables right out of the box (efficient scrolling, cell reuse and delegate methods to handle where to push new view controllers on to the stack, etc...).
Flexible data model backed cell data. Your table view needs to be backed by some "settings" model object collection, obviously. That collection can be modified to include or exclude settings programmatically. Combine this with custom cells and you're off and rolling. This is really nice if your UI needs to change on the fly.
Code Reuse. If you have another set of "settings" you can use this data-backed table view approach and change only your data model. Doing this manually means you have a new view controller for every settings view. In your example picture, I'd bet my lunch that the 3 view controllers you see in that image are the same type of object.
The table's delegate methods are really helpful when segueing or pushing to new view controllers. Imagine having 10 settings that all took you to separate view controllers. You'd have to manually hook those transitions one by one, yuck.
Of course if you only have 1-2 settings that will never change, perhaps manual is the way to go. For my money, though, tables make sense because things like this always seem to change.
For a simple note application, there is a table view controller with a fetchedResultsController that has a list of saved notes in core data. The user can either click the + button to add a new note or click on one of the records in the table view to edit an existing note. In either case, a modal view controller with a text view shows up.
I want to save as the user types each letter, so in textViewDidChange I am updating Core Data. If the user types too fast, the core data saves hang. I recently added code to add the updates to NSOperationQueue which was an idea taken from here:
How to implement work queue in iOS where only newest request is handled? and that has helped somewhat.
Here's the problem I need help with. Let's say the user types an update in the textView, then pushed Done to return to the table view controller, and then clicks on the same note to edit the note again before the original update was refreshed in the table view. The user is presented with a textView that has the old data. The update is not there. If the user goes back to the table view and edits the note again, the latest updates show.
What are some approaches to consider, or how could I attempt to fix this issue? I want the textView to always show the latest updates even if user is switching back and forth from the textView and tableViewController faster than a user should ;)
You don't need to save the context everytime the user adds a character, do it only when he finishes adding the note, or at least when the textfield loses its focus (first responder resigns). There's really no point in doing it everytime he taps. Saving the context is a pretty expensive operation.
Maybe try saving all of the changes at once in:
- (void)viewWillDisappear:(BOOL)animated
Instead of constantly saving as the user types, which is a bit redundant.
If the user goes to their home screen, then save the changes in
- (void)applicationDidEnterBackground
I have created a custom camera overlay to capture an item, but my app requires that I go through the capturing process twice, so basically, once the user has taken the picture of the front of an item, they need to take the picture of the back of that same item, back to back. At the moment I am re-initializing the same view controller after the first picture has been taken, but I have read that it would be better practice to create a separate view controllers for each "step".
Which would be the better option, separate view controllers, or one view controller that gets re-used, as and when is needed?
I am quite new to Objective-C, so I am not sure if I have phrased everything correctly, I hope that I was able to adequately convey my problem.
I have a simple iPad application with 5 views. On the first view, the user is asked to make some selections and set some options. From this information, the other 4 views are programatically changed after an NSNotification message is sent to them. (i.e controls are added, updated).
My problem is that when the application is first loaded, the user sees View1, but View2, View3, View4 and View5 have never been opened yet, so any changes I make programatically to those views are not done and when the user navigates to them (via the tab bar) for the first time, no changes are shown.
[EDIT: I should point out that the code for making the changes to each view is contained within the ViewController itself, and is executed when the view observes the incoming NSNotification. When the view is not loaded, it understandably never received the incoming NSNotification.]
Only after the user looks at any of those screens at least once and then goes back to View1 and makes changes, are the other Views updated properly.
I thought I could get around this issue by actively loading Views 2,3,4 and 5 into memory on application start, so that they are ready to begin receiving notifications right away.
Is there an easy way to do this in iOS 5?
Why do the view changes straight away?
I would store an indicator of the changes needed when the users answers the questions on the first view and then apply the changes on -viewDidLoad of each view that needs to be changed.
Instead of trying to load the views into memory, I'd suggest you initialize these views with the options that the user set on the first view. What I usually do in such situations, when I have a global parameters that are used in many places, I create a utility class to keep the data, make it a singleton, then access the shared instance in the viewDidLoad in the views that use the data during initialization.
In a table-view that contains say 10 cells, is it the case that we need to create 10 separate UITableViewControllers to handle the different views loaded by clicking on each of those 10 cells?
That doesn't seem very efficient - especially in situations where large amounts of data (and thus tables/menu) need to be displayed.
How can you write a dynamic UITableViewController, that can accept any data-set (like an Array) on the fly and display its contents - and do it in a recyclable manner, so that it can be recreated again and again for each cell that is clicked?
I have it mostly working in an app I'm building - the only thing I don't fully understand about the method is how the incrementing of the "CurrentLevel" works since it seems like the variable would just keep getting reset since the controller calls itself.
Anyhow, the concept is that every time someone clicks a cell, a new instance of the UITableView controller is called and a new level is generated and added to "the stack", and a navigation controller is able to track what is in the stack and allow you to browse back to the previously loaded views.