I'm curious, how do most of you folks handle errors such as HTTP Forbidden or 5xx type requests from a server? Or say an exception is thrown in one of your UIViewControllers? Do you typically bubble up the error to the App Delegate and handle generic "window" level errors at that point? Do you couple errors directly into the UIViewController? What if you have several UIViewController's which all speak to a common NSURLConnection wrapper, and a connection fails for some HTTP 4xx or HTTP 5xx similar error. Will you typically bubble up the error to App Delegate so it can present a UIAlertView from that portion of the application?
Just wondering what solution you're using for your Mac OSX/iPhone error handling techniques.
Thanks a bunch.
Your current view controller should be responsible for dispatching any error message and dealing with the result.
The last part is the key here. If you encounter an HTTP error and pass the message up to your app delegate with a "retry" option the response then needs to go all the way back down to the controller. This all gets a bit yucky.
Now you may want to create a common class/view in your app that can deal with all the errors you're likely to encounter, but this should still be presented (in a modal fashion) by the controller that encounters the error and it's this controller that should receive delegated responses.
The controllers may or may not need to know there has been an error in order to properly recover from a network error, but for iPhone development I have found it useful to have a core communications class that understands all the communication going into and out of the system, and when it detects failures issues an alert directly. That way you can prevent an overload of failure notices if a user switches tabs or otherwise moves about the application, and just generate one message so that the user can understand why screens are not updating.
Related
I'm working in an application that loads a few remote jsons at startup. The application has been programmed to do certain tests on the incoming data to prevent invalid states and to detect possible human errors. However, I am not sure of how we should treat such situation at the GUI level - our initial idea was to display a "Oops there was an unexpected server error. We are working to solve this issue. Please, try again later." popup to quit the application when the user hits an "Ok" or "Exit" button.
Apple apparently discourages exiting the application from within your code: https://developer.apple.com/library/ios/#qa/qa2008/qa1561.html
What good alternatives are there to handle this situation?
Update: I updated the error message above, since it was misleading.
I encountered a similar issue. My app was useless unless it could establish a connection to a server.
There are two ways around this:
place holder text, this can hold the position until you can get your json arrays, or at least allow a back drop for popping an alert.
Load a view with all interaction disabled, with a small message box saying "connecting..."
Basically I have taken the first responding storyboard frame and disabled everything that the user could touch. I just allowed static interaction like pressing a button to get to the about screen.
Don't beat yourself up too much about it though. If you don't have any connectivity at all then none of the user's apps are going to be functioning properly. I think in this state, from a GUI perspective it is mostly about damage control and protecting the user experience.
It's tough to be graceful at startup. I suggest presenting UI modally while your app gets ready to run. I asked and answered this SO question which shows a clean way to do the UI, including nice transition effects.
As for exiting: Your app should never self-terminate (copyright Arnold Schwartzenegger circa 2003). The correct app behavior when it can't get something done that has to be done modally is to alert the user and give the option to retry. If the user wants to not retry, there's a hardware home button on the phone.
Sorry if this is a dumb question, but I'm debugging a dangling pointer issue in my App and I need to know - Is it possible for the app to resignActive without first enterBackground?
To becomeActive without first enterForeground?
My situation - I have class (called 'Connection') that manages all of the application's requests/connections. It needs to be available for as long as the app is alive, really.
In my -didFinishLaunchingWithOptions I init an instance of Connection and set some params. In my -applicationWillEnterBackground I suspend Connection's actions.
And, in my -applicationWillEnterForeground I check to see if the Connection instance still exists. If it does, simply resume actions, else a new one is created.
When I leave the app running for a while (an hour or so, with or without going back to the home screen), the app crashes with this error.
"2012-08-19 13:08:42.708 Picsilk[11108:707] *** -[Connection respondsToSelector:]: message sent to deallocated instance 0x24e120"
The class, 'Connection', is just a simple NSObject subclass, which manages an ASINetworkQueue instance and handles some specific needs I have for storing a user's tokens and authenticating requests to my api.
An instance of this class is created and managed by app delegate. My various view controllers use the app delegate to access the Connection, which automatically handles the queue (and non-queued requests as well)
Surely I'm missing something very simple and fundamental to my understanding of this SDK, please help. :]
The app can receive a UIApplicationWillResignActiveNotification when a call comes in or other notifications are presented. So, yes, it's possible "for the app to resignActive without first enterBackground".
In my app requirement is, when the app is launch for the first time it will send request to server to get data, parse it and save it in document folder which will be used across entire project.Again after particular time interval the app will send request to server to get updated data(if any) and update that data in document folder, which again will be updated across entire project.All this process is happening in background thread.This process will repeat until the app is running in foreground once the user close the app, the app will get terminate, it will not go in background.
This repeated request I am creating in app delegate as well as doing xml parsing once the data is received and saving after parsing. Now my question is, Is this proper means doing too much stuff in app delegate is safe or there is some limitation or is this bad programming?
What is the correct way of doing this?
I disagree with torrey.lyons to an extent. I think creating singletons is bad practice generally speaking and should be avoided where possible. One thing you should never do is code a class so that it has to be a singleton. Purpose built singletons tend to increase coupling and can be really problematic when it comes to unit testing where you might want to replace your singleton with a stub class or you might need it to be reinitialised for each unit test.
If this task of getting data is an application level task, there is absolutely no reason why it can't logically be located in the application delegate. I would however create a "connection manager" as torrey.lyons suggests and have one as a property of the app delegate.
I would also not use an explicit background thread to do the data update but I would use a subclass of NSOperation. This is a whole lot easier than managing your own thread.
It is bad practice. Your app delegate should ideally be concerned purely with its own responsibilities, i.e.. responding to the messages the application sends its delegate. It is much better to split off other discrete responsibilities into other objects. For example, you could have a "connection manager" object that is responsible for periodically communicating with the server. If you are sure the app will only connect to one server at a time you probably want to use the singleton pattern so that there only one instance of the object in your application and it can be easily reached by any other class. A good discussion of the proper role of the app delegate and singletons can be found on at Singletons, AppDelegates and top-level data. A good general overview on writing singletons can be found under the Care and Feeding of Singletons.
So, I have 2 types of data, some needs to be persisted and some doesn't.
I'm thinking about where to put all my network related code, inside my UIViewControllers, where all the network request start from, or in a another layer.
What I had in mind is this:
Have a layer called NetworkManager.
NetworkManager is singerlton to all my web service calls.
For data that needs to be persistent and can be presented in a list, I would have network manager issues the request, save the response in my local core data DB, and have my UIViewController listen to that data using FetchResultsController.
But, there's many other types of requests. For example : login request, user info request, friendsNearBy, and so on… some don't have to be persistent in my db, and some don't fit the FRC architecture.
For these type of request, as far as I see, there are 2 ways of handling it:
1. Have another layer that separates between the ViewControllers and the NetworkManager.
Let's call it Mediator. The Mediator gets the dictionary(JSON) request from the networkManager, decides according to the app logic if there's anything else needs to be done with it, and then post a notification with appropriate name and data. If the mediator saves the UIViewController who issued the request, it can delegate the response directly to him instead of posting a notification.
The Flow would be like this:
MyUiViewController - > Mediator -> NetworkManger->Mediator-> PostNotification (or directly back to MyUiViewController)
Pros:
Decoupling
Nice structure and separation of concerns
Cons:
Harder to code
Sometimes harder to understand and debug.
2. Not having this 3 layered architecture, but instead having MyUiViewControllers, issue a network request with blocks. Meaning instead of the Mediator intercepting the response before MyUiViewController, just let MyUiViewController handle the response using blocks as he is the one that issues it.
Pros:
Simple and quick to code
Easy to understand
Cons:
Coupling of network code inside your controllers
I was hoping to get suggestions and comments about what's best from people's experience, or other/better way of doing this.
Have you got whats the best method already?
Here's what i do generally,
Have a NetworkManager which is not Singleton. Define a protocol with method OnSuccess,OnError. Implement this in your ViewController which initiates the network connection. Set the delegate on NetworkManager and let delegate be called when Asynchronous request is executed.
Use delegates instead of blocks as its easy to maintain.
This may not be best solution, but hopefully it gives you some pointers.
I recommend option 2 with a little bit of what you listed for option 1. In my apps I tend to have two distinct modes of operation that operate concurrently.
Automatic downloads:
App essential data is downloaded and saved directly to the database. It's initiated each time the app becomes active. As each request completes an NSNotification is sent out for any visible view controllers that may need to know about the new data.
For example, if I save player data I'll send a notification like "PlayerDataUpdated". When a view controller is visible it listens for notifications. When it's not visible it doesn't listen for notifications since any changes in to the database will be discovered during viewWillAppear.
User Initiated downloads:
For user-initiated network requests, such as pull to refresh, you should call the appropriate method on NetworkManager from the view controller that needs the updated data.
hi i am developing a sms App for my client. so far i have put down this plan in place.
1)The app keeps polling the server with an asynchronous request so that it does not interfere with the user interface.
2) for sending sms i am currently using synchronous request , depending on the reply from server i have do various things. i am showing the spinning circle and make the user wait until i get the response from server.
my client has problem with point 2.
The client says as soon as the send sms button is clicked it has to go back to the homescreen and should be able to navigate to any screen and do all other things that the app offers. i could have used async request , but i am not sure how to handle the responses from the server when i am on different view controller other than the one request is called from.
Can somebody help me on this.
Thank You.
The classic way of handling the response of an asynchronous action is either using delegation or notifications. Do not use a singleton. This breaks modularity and decoupling of different view controllers.
Roadmap of how to handle asynchronous actions
Register for the response of the asynchronous actions. This can be setting the delegate of the requesting object e.g. NSURLConnection to the view controller, which is typically self in this context. The othe possibility is that you register for the notification which is fired by the requesting object if things have happend e.g. when a download is finished or an error occurred.
Implement the delegate methods or the notifications to update your model and/or your user interface. Be aware that updating the UI has to happen on your main thread.
Start the asynchronous action. What happens in the background is that a separate thread is spawned or an operation is dispatched using GCD. These are implementation details and do not bother you.
Wait for the answer, which will result in one of your implemented methods to be executed which you then use to update what has changed.
Difference between notifications and delegates
The two differences between delegates and notifications is that delegate is a one-to-one connection between the delegate and the delegating object. Notifications are posted application wide and can be observed by as many objects as needed creating a one-to-many connection. Think about this as a broadcast. The second main difference is that delegation can be used to transfer information back from the delegate to the delegating object. Meaning that the delegating object asks the delegate for certain information. Typical example would be the data source of an UITableView. Notifications however are a one way street. The information flows from the posting object to the observing objects. This makes sense because think about the situation where you would have more than one observer and each would give feedback to the posting objects. Which one would be the right one?
In your case you would have to look up the delegate methods of the asynchronous HTTP request object and implement them accordingly.
Maybe you can try ASIHTTpRequest , It has Sync an Async request
If you using Async request , you can do anything after you press a button to do a request .
Check this
The solution depends on the response processing.... if you are just showing user that the sms sending is failed/successful than you can do it in any general utility class that shows alert.. but for this you have to create the singletone instance of your connection class so delegate(class itself) don't die when the response comes back.......
For this we need to keep track of currentViewController ....... we can do this by creating a reference ........ id currentViewController in appDelegate(with setter/getters).......... so it could be accessible in everywhere application........
its referred object should be changed each time when user changes the viewController.... that will help us to know on which viewController user is currently working.
than when the singeltone class of connection finished its response loading we can use this currentViewController with your desired viewController.
I am not sure how you are using different view controller....... pushing it/ presenting it or adding its view.....