I am building an app that presents UITableView to the user, from which the user needs to make a selection. Once the selects a row, they are presented another ViewController which displays details of the selection they made on the previous ViewController.
Here's the catch: After the user makes the selection, the app needs to make a call to the network to retrieve some data to be displayed on the next ViewController. I was planning on calling a method from the prepareForSegue method which would return the results from the network call, and then call the appropriate ViewController, but I'm wondering if this is something that should be called from the "didSelectRowAtIndexPath" method (which I have not implemented).
My fear is that the second ViewController will be called BEFORE the call to the network returns with the data that I need to display. Is this even the place to put such a network call, or should I make this call from the "viewDidLoad" method of the destination ViewController instead? What is the best architecture and why?
Call prepareForSegue method inside didSelectRowAtIndexPath method to navigate to secondViewController then to display details, make network call inside viewDidLoad method of secondViewController and show activityIndicatorView until the data is fetched.
I would use some asynchronous loading starting in prepareForSegue and managed in the details view. Once the details view appears, you have to inform user that something is loading (an appropriate turning wheel exists for it), and then populate the interface after the loading has been done (or manage loading error).
But using viewDidLoad of the details view would be ok too, provided you always inform user of the current loading...
Don't use didSelectRow because it is just intended for selection... There can be no navigation on a tableview cell!
Asynchronous is preferred because it does not block user in some weird state waiting something he does really know.
Related
I am making an IOS app where i am calling an API in viewDidLoad method of view controller. Now i want to reload the same view controller with the data that comes from server. How many ways are there to do this task and what would be the best way?? Please help me.
Thanks!!
viewDidLoad method is called first time when UIViewController is first loaded and when it pop and then you reenter in it at that time viewDidLoad is called. So if you want to load the API only once then viewDidLoad is the best place to call an API.
viewWillAppear called every time when you enter in that UIViewController and it is the place load the API when you want to get refreshed data (updated data).
viewDidAppear also called like viewWillAppear but bit late called than viewWillAppear so if you want to call the API every time than the best place is viewWillAppear method.
Because viewDidAppear method called late from viewWillAppear method and you are just requesting the API so the response of API may be late and If your UI change based on API response then it will stuck the application UI so there is a best place to call API either viewDidLoad & viewWillAppear methods.
viewDidLoad is called once. If you use navigation controller and do back and forth ou view controller this viewDidLoad method will never be called. Until you create this ViewController again (i.e [navContoller pushViewController]). If your api data will never changed the life cycle of this View Controller the this is the better place to call your API. But if your api data need to call frequently [i.e. back and push.forth this view controller] then you should not call api here.
viewWillAppear: before a view controller shows.If you call you api
inside this method you UI will stack until the data loading finish. which looks odd.before load the view of viewController this "viewWillAppear" method is called. This is the reason, it's name is "viewWillAppear". That means this view will load some time later (i.e some micro second later). If you call your api here after what will happen lets analyze. Say, your api return response after 10 sec. Then UI will freeze/stuck for 10 sec and you will see after this 10 sec later your view will called.
viewDidAppear: after finished a view controller showing.So, you need to called your loading API inside this method.
viewDidAppear is definitely not the one you want to use, it will 'pause' the view from responding while you're loading the data.
Normally viewDidLoad is the one you want to place it.
If we stay in the same ViewController,the three method viewdidload,viewwillappear,viewdidappear will not called again.So we stay in the same view controller, we get the data from the server,we should call the reload method after get the data.
Hope this answer can help you.
I think viewWillAppear is best place for loading data from API. Because viewDidLoad called once when the view is being loaded, but viewWillAppear will called when it loaded from its parent view or child view.
You don't need to call API every time you navigate to view controller, you need to call it one time.
If you have a TableView with Cell and this cell get from API and will open new ViewController when you press on it.
So here you will not add your API in :
viewWillAppear()
viewDidAppear()
You will add it one time in viewDidLoad() while we need to minimize num of requests as many as we can.
Example like this: navigation controller:
suppose Fruits and Cars will present from API.
when you click on the fruits cell you will navigate to below viewController:
So when you want to go back to the first view controller, clearly you dont need to reload api while it is already exist.
In this case we use viewDidLoad() to handle API request
My title probably makes no sense, but I'll do my absolute best to explain it. So, basically, I have a UITableView that's getting data from Firebase. It has a listener, and any time values are changed on that tree, it updates the tableview. The thing is, I put this in viewDidLoad. (which seemed to make the most sense). Say, if the user goes over to the settings screen (a separate VC), and goes back, it reloads the tableview all over again. A couple users are complaining that it takes long to load the tableview when they come back to the main VC, and I was curious if I could keep the data there on THAT vc, so it's permanent until my listener detects a change in the database. Not sure if that makes any sense - but basically the only time I want the tableview to load data is the initial load, AND when data is changed on my backend. Not every time viewDidLoad gets called.
TL;DR:
How do I make it so tableview loads data once, and the data stays even when switching view controllers
viewDidLoad is only called once during the lifecycle of a viewController. You are using a segue to return to your tableViewController from your settings viewController. A segue always instantiates a new destinationViewController. The only exception is the special unwind segue which returns to a previously instantiated viewController.
So, use an unwind segue to return to your tableViewController and your data will still be there and viewDidLoad will not be called.
I am making an IOS app where i am calling an API in viewDidLoad method of view controller. Now i want to reload the same view controller with the data that comes from server. How many ways are there to do this task and what would be the best way?? Please help me.
Thanks!!
viewDidLoad method is called first time when UIViewController is first loaded and when it pop and then you reenter in it at that time viewDidLoad is called. So if you want to load the API only once then viewDidLoad is the best place to call an API.
viewWillAppear called every time when you enter in that UIViewController and it is the place load the API when you want to get refreshed data (updated data).
viewDidAppear also called like viewWillAppear but bit late called than viewWillAppear so if you want to call the API every time than the best place is viewWillAppear method.
Because viewDidAppear method called late from viewWillAppear method and you are just requesting the API so the response of API may be late and If your UI change based on API response then it will stuck the application UI so there is a best place to call API either viewDidLoad & viewWillAppear methods.
viewDidLoad is called once. If you use navigation controller and do back and forth ou view controller this viewDidLoad method will never be called. Until you create this ViewController again (i.e [navContoller pushViewController]). If your api data will never changed the life cycle of this View Controller the this is the better place to call your API. But if your api data need to call frequently [i.e. back and push.forth this view controller] then you should not call api here.
viewWillAppear: before a view controller shows.If you call you api
inside this method you UI will stack until the data loading finish. which looks odd.before load the view of viewController this "viewWillAppear" method is called. This is the reason, it's name is "viewWillAppear". That means this view will load some time later (i.e some micro second later). If you call your api here after what will happen lets analyze. Say, your api return response after 10 sec. Then UI will freeze/stuck for 10 sec and you will see after this 10 sec later your view will called.
viewDidAppear: after finished a view controller showing.So, you need to called your loading API inside this method.
viewDidAppear is definitely not the one you want to use, it will 'pause' the view from responding while you're loading the data.
Normally viewDidLoad is the one you want to place it.
If we stay in the same ViewController,the three method viewdidload,viewwillappear,viewdidappear will not called again.So we stay in the same view controller, we get the data from the server,we should call the reload method after get the data.
Hope this answer can help you.
I think viewWillAppear is best place for loading data from API. Because viewDidLoad called once when the view is being loaded, but viewWillAppear will called when it loaded from its parent view or child view.
You don't need to call API every time you navigate to view controller, you need to call it one time.
If you have a TableView with Cell and this cell get from API and will open new ViewController when you press on it.
So here you will not add your API in :
viewWillAppear()
viewDidAppear()
You will add it one time in viewDidLoad() while we need to minimize num of requests as many as we can.
Example like this: navigation controller:
suppose Fruits and Cars will present from API.
when you click on the fruits cell you will navigate to below viewController:
So when you want to go back to the first view controller, clearly you dont need to reload api while it is already exist.
In this case we use viewDidLoad() to handle API request
In my app, there are tabs. I have one tableviewcontroller that contains messages and I have implemented pull to refresh so that works fine. However, if the user goes from the message tab to another tab and then back to the message tab, the uitableview doesn't reload and the user has to pull to refresh. I have thought of putting [self.tableview reloadData] or [self loadObjects] (i am using Parse) in viewDidLoad/viewWilAppear, but that doesn't seem to work...it's because they are only called when the view controller is initially visited right? So I'm wondering as to where I should put that code so that the table view can be reloaded every time the view controller is revisited?
viewWillAppear and viewDidAppear are both called every time the view controller appears. If you call reloadData in one of those methods then it will refresh the table view.
I think your problem is you aren't updating your data source. You will need to make another call to Parse otherwise your table view will just reload with the same data.
I don't think that this behavior is desirable. I suggest you tu wait for a reasonable timeout before updating data, or your user will experience lags and high network usage.
However to do that, you should set a delegate that fires when the corresponding view is loaded (take a look here how to get the event that switch tab menu on iphone ) and then call
[yourTableView reloadData]
inside didSelectViewController
Can someone more knowledgeable than I explain performSegueWithIdentifier:sender: for me? I need to switch views (and classes) and also carry a few NSStrings and IDs over to that view's class. I was wondering if this is possible with performSegueWithIdentifier:sender:
Thanks!
First, you have to have set up the segue in your storyboard and give it the appropriate identifier. (Click on the segue (left panel) and then click on Attributes (right panel).
You can then link this to buttons or selection of table rows from your storyboard, or you can call it in code using performSegueWithIdentifier:sender:.
After this, your view controller will be sent the prepareForSegue:sender: message. You override this method in your view controller subclass, and can configure the target view controller as follows:
TargetViewController *targetVC = (TargetViewController*)segue.destinationViewController;
targetVC.string1 = string1;
And so forth. The sender in this method will be the object that you use as the sender in the original method call.
Most segues are initiated automatically as the result of some user interaction. For instance, if you have a segue that is wired up from a button to a scene in a storyboard, when the button is tapped the segue will automatically initiate.
Occasionally, it makes sense to trigger a segue programmatically - e.g. you have a High Scores scene that is displayed when the user wins a round of a game. There's no way to express the concept of winning in the storyboard itself, so you can instead create a segue, assign an identifier to it, and invoke -performSegueWithIdentifier:sender: at runtime.
The other segue related method on UIViewController, -prepareForSegue:sender:, is the method you should override to perform any customization on the destination view controller.
In prepareForSegue:sender: you get a chance to configure the destinationViewController: that's where you'd pass it the data it needs. It's discussed in Cocoa Application Competencies for iOS.
Today I ran into the issue of performSegueWithIdentifier: not executing due to the fact of not having set a delegate queue on my URL session.
So by any chance, check if you are actually setting a delegate queue when creating your URLSession, else URLSession will create it's own.
urlSession = [NSURLSession sessionWithConfiguration:sessionConfigObject
delegate:self
delegateQueue:[NSOperationQueue mainQueue]];
I mention this here because I quite often see URLSession handling ending up calling some sort of UI related activity. And performSegue needs to be executed on main, or else it will do just nothing.