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".
Related
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.
I have a program with about 8 Activity classes, and 1 Application class. I want my Application class to be able to communicate with every Activity, but on its own terms. I don't want the activity to ask the Application for data, I want the Application to send the Activity data. The problem with this, is that depending on the current state of the program I'm unsure what Activity will be open.
Is there a method of some sort which will send information from the Application to the CURRENT activity?
The Application class connects with an embedded Bluetooth Device and needs to receive different pieces of data depending on which Activity the user is currently in. I originally had it as a regular class, which was initialized in the MainMenu of my program and passed a Handler. However, it seemed like weak design to pass that Handler from Activity to Activity time and time again.
You could use a Callback Method
Every Activity has it's own callback method and registers that method onResume() in the Application Class. (it's like an onApplicationWantsToDoSomethingWithMeListener() ;)
or why not a Service in background? instead of the Application, since what you want sounds like a Service. More details?
EDIT:
I made a similar application with bluetooth, you should definetly use a Service for that, but you can communicate with your service per Application. Say the Service calls the callback in the Application look here for an implementation uf such a thing
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.....
I have a Objective-C class that makes an HTTP request and, after receiving a response, calls methods on its delegate. The class provides some convenience methods around the built-in NSURLRequest for my application.
My question is: how do I ensure that I release this object? Normally, an object's owner is responsible for ensuring that an object gets released. In this case, there's no obvious owner. I want to create an instance of this class, set its delegate, fire off the HTTP request, and then forget about it (I could be making several of these requests, so the only way to give it an owner would be to keep a list of the request objects in the calling object, which seems suboptimal).
One approach I've considered: when the HTTP response comes in, my object calls its delegate and then does [self autorelease]. The problem is that all clients have to remember not to release this instance (or else my object needs to call retain before it returns to the user).
Anyone have any good patterns for this?
Apple have already thought of this pattern. On the assumption that you are using NSURLConnection, check out the documentation for -initWithRequest:delegate: Here is what it says about the delegate parameter:
The connection retains delegate. It releases delegate when the connection finishes loading, fails, or is canceled.
[my emphasis]
So when you create the connection, set your object as the delegate. It won't go away until the connection is terminated for whatever reason, even if no other object of yours retains ownership.
By the way, the statement
there's no obvious owner
is false. You say your object has a delegate. The delegate is the obvious candidate to be an owner.
I would like to my object to receive notification with the DeviceToken becomes available. Is there a way to delegate only certain functions from the UIApplication to my class?
Update:
I'm not so much interested in accessing it from the application delegate, I already have an application delegate, but want to respond to the event via call back or some observer method if it's possible.
Despite not being marked as such in the documentation, all UIApplicationDelegate methods are optional, so you can simply implement the ones you require, and ignore the ones you don't.
However, you'll probably want to implement all three of the APS methods, rather than just the one indicating registration success!