I'm using 'WCSession' for the connection between my app and apple watch. I preferred singleton approach. So, I made a shared session:
static Shared_WCSession *sharedInstance = nil;
+(Shared_WCSession*)getSharedInstance {
#synchronized(self) {
// If the class variable holding the reference to the single ContentManager object is empty create it.
if(sharedInstance == nil) {
sharedInstance = [[Shared_WCSession alloc] init];
}
}
return sharedInstance;
}
Then in start session I set up the delegate for the session:
-(void)startSession {
if ([WCSession isSupported]) {
self.session = [WCSession defaultSession];
self.session.delegate = self;
[self.session activateSession];
LOG(#"WCSession is supported");
}
}
What is the proper way to deallocate the delegate?
According to apple's docs I can do it in the following methods:
sessionDidBecomeInactive(_:)
sessionDidDeactivate(_:)
If I set the delegate to nil there will this interfere with the performance of my applications?
First I want to know that self.session is following arc, and as delegate always contains weak reference then no need to set it to nil.
Is it causing any issue? if you are not setting it nil manually ? If yes then you can set it to nil in sessionDidDeactivate as it says:Called after all data from the previous session has been delivered and communication with the Apple Watch has ended. and you can set new session like
func sessionDidDeactivate(session: WCSession) {
// Begin the activation process for the new Apple Watch.
WCSession.defaultSession().activateSession()
}
WCSession.delegate won't leak: it is a weak reference
NS_CLASS_AVAILABLE_IOS(9.0)
#interface WCSession : NSObject
// ...
/** A delegate must exist before the session will allow sends. */
#property (nonatomic, weak, nullable) id <WCSessionDelegate> delegate;
// ...
If you're using ARC and your delegate is still being held on memory, it is not because of WCSession.delegate
Related
I've extended AppDelegate with my category. The goal is initiate server request and show notification, when user entering some geofence with terminated app. This all done in class GeoNotificationManager. All I need to do - instantiate this class once app launched from location event.
Everything works, except the PROBLEM: - when #property (strong) GeoNotificationManager* geof; is inside category, code inside GeoNotificationManager doesn't work (no server requests, no notifications). And when it's inside AppDelegate itself, everything works as expected.
Also I tried without having property in catergory, it doesn`t work too.
GeoNotificationManager* manager = [GeoNotificationManager new];
[manager sendTestServerRequest:#"test"]; // REQUEST NOT SENDING, WHY???
//AppDelegate+Geofence.h
#import "AppDelegate.h"
#class GeoNotificationManager;
#interface AppDelegate (Geofence)
#property (strong) GeoNotificationManager* geof;
#end
NSString * const kNewPropertyKey = #"kNewPropertyKey";
#class GeoNotificationManager;
#implementation AppDelegate(Geofence)
-(BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:
(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
{
self.geof = [GeoNotificationManager new];
[self.geof sendTestServerRequest:#"test"];
}
return true;
}
// I don't understand what is that below, but seems it's required for having property in category
- (void)setGeof:(id)aObject
{
objc_setAssociatedObject(self, (__bridge const void * _Nonnull)(kNewPropertyKey),
aObject, OBJC_ASSOCIATION_ASSIGN);
}
- (id)geof
{
return objc_getAssociatedObject(self, (__bridge const void * _Nonnull)(kNewPropertyKey));
}
#objc class GeoNotificationManager : NSObject, CLLocationManagerDelegate {
let locationManager = CLLocationManager()
override init() {
super.init()
locationManager.delegate = self
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.allowsBackgroundLocationUpdates = true
locationManager.showsBackgroundLocationIndicator = true
}
// OTHER CODE, -didEnterRegion, server request etc
OBJC_ASSOCIATION_ASSIGN just should be replaced with OBJC_ASSOCIATION_RETAIN, and it works!
But if anyone knows how to do this with local variable, please share
I am having a hard time as a beginner to Objective-C with learning how and when a function is being called, as I am not seeing it explicitly stated. Below is some code for logging into, and playing a song from the Spotify SDK that I found online.
#import "AppDelegate.h"
#interface AppDelegate ()
#property (nonatomic, strong) SPTAuth *auth;
#property (nonatomic, strong) SPTAudioStreamingController *player;
#property (nonatomic, strong) UIViewController *authViewController;
#end
#implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
self.auth = [SPTAuth defaultInstance];
self.player = [SPTAudioStreamingController sharedInstance];
// The client ID you got from the developer site
self.auth.clientID = #"5bd669abf2a14fb59839c2c0570843fe";
// The redirect URL as you entered it at the developer site
self.auth.redirectURL = [NSURL URLWithString:#"spotlightmusic://returnafterlogin"];
// Setting the `sessionUserDefaultsKey` enables SPTAuth to automatically store the session object for future use.
self.auth.sessionUserDefaultsKey = #"current session";
// Set the scopes you need the user to authorize. `SPTAuthStreamingScope` is required for playing audio.
self.auth.requestedScopes = #[SPTAuthStreamingScope];
// Become the streaming controller delegate
self.player.delegate = self;
// Start up the streaming controller.
NSError *audioStreamingInitError;
NSAssert([self.player startWithClientId:self.auth.clientID error:&audioStreamingInitError],
#"There was a problem starting the Spotify SDK: %#", audioStreamingInitError.description);
// Start authenticating when the app is finished launching
dispatch_async(dispatch_get_main_queue(), ^{
[self startAuthenticationFlow];
});
return YES;
}
- (void)startAuthenticationFlow
{
// Check if we could use the access token we already have
if ([self.auth.session isValid]) {
// Use it to log in
[self.player loginWithAccessToken:self.auth.session.accessToken];
} else {
// Get the URL to the Spotify authorization portal
NSURL *authURL = [self.auth spotifyWebAuthenticationURL];
// Present in a SafariViewController
self.authViewController = [[SFSafariViewController alloc] initWithURL:authURL];
[self.window.rootViewController presentViewController:self.authViewController animated:YES completion:nil];
}
}
- (BOOL)application:(UIApplication *)app
openURL:(NSURL *)url
options:(NSDictionary *)options
{
// If the incoming url is what we expect we handle it
if ([self.auth canHandleURL:url]) {
// Close the authentication window
[self.authViewController.presentingViewController dismissViewControllerAnimated:YES completion:nil];
self.authViewController = nil;
// Parse the incoming url to a session object
[self.auth handleAuthCallbackWithTriggeredAuthURL:url callback:^(NSError *error, SPTSession *session) {
if (session) {
// login to the player
[self.player loginWithAccessToken:self.auth.session.accessToken];
}
}];
return YES;
}
return NO;
}
- (void)audioStreamingDidLogin:(SPTAudioStreamingController *)audioStreaming
{
[self.player playSpotifyURI:#"spotify:track:3DWOTqMQGp5q75fnVsWwaN" startingWithIndex:0 startingWithPosition:0 callback:^(NSError *error) {
if (error != nil) {
NSLog(#"*** failed to play: %#", error);
return;
}
}];
}
#end
I am wondering how exactly these functions are being called sequentially, and specifically how the audioStreamingDidLogin one is being run.
Additionally I was wondering how it would look to call that function from the view controller with some sort of input coming from the UI.
Any help with this logic would be greatly appreciated! Thanks.
Your question is closely tied to the Spotify framework being used. It is not a question of when Objective-C is executing something - the language has a standard sequential execution model - but how the framework is doing callbacks, e.g. audioStreamingDidLogin, to your code and utilising threads/GCD to do concurrent execution.
First you should read the Spotify framework documentation.
You can also place a breakpoint at the start of each method and then run under the debugger. When a breakpoint is hit check which thread has stopped and the stack trace. That should give you a good idea of execution flow and the concurrent threads being used.
HTH
UIApplicationDelegate method application:didFinishLaunchingWithOptions: is called first, followed by application:openURL:options:.
That first app delegate method sets self as the delegate for an AudioStreamingController. This is how audioStreamingDidLogin gets called. You're telling the streaming controller, "Tell me (self) when interesting things happen". (See the SPTAudioStreamingControllerDelegate docs for what else it might tell you about).
You probably wouldn't (shouldn't) call this function directly, especially if there's a chance that you might call it before auth is complete. Doing so would likely result in an error on the call to playSpotifyURI. If you're certain that the user is authenticated, then you don't need to call it. Just call what it calls: playSpotifyURI.
I have a NetworkManager class which does the task of connecting to a JSON based web service and returning the server response. I am using a completion handler block to return the success or error response from NetworkManager (Internally, NetworkManager uses delegate based NSURLConnection).
NetworkManager *objNetworkManager= [[NetworkManager alloc]init];
[objNetworkManager setCompletionHandler:^(NSDictionary *resp, BOOL isSuccess){
if (isSuccess) {
}else{
}
}];
[objNetworkManager initiateUrlRequestWithInput:jsonRequestInput];
Everything works fine now and my network requests work as expected using this NetworkManager class. My concern is that I am allocating an instance of NetworkManager each time I make an web service call. But, where should I set the objNetworkManager to nil? Because it uses a block callback, I'm not sure how to handle memory efficiently. Please advice!!
Here is my take on this:
ARC automatically takes care of it for you if you are not creating reference cycles or any leaks. For instance, if VC1 instantiates NetworkManager and post everything is done, you go out of VC1 and it gets deallocated then NetworkManager reference will also be deallocated.
If you really want to be proactive to release NetworkManager then you can do it in your both success and error completion blocks. This is how I do it :).
EDIT: Example:
__weak MyViewController *aBlockSelf = self;
// Save User Preferences (/ics/markavailable)
self.requestHandler = [[MyRequestHandler alloc] initWithEndPoint:#"/fetch/request" body:aBodyData container:self.navigationController.view loadingOverlayTitle:#"Loading..." successHandler:^(NSDictionary *iResponse) {
// Do success handling
aBlockSelf.requestHandler = nil;
} andErrorHandler:^(NSString *iMessage, NSString *iKey, NSInteger iErrorCode, BOOL iIsNetworkError) {
// Do success handling
aBlockSelf.requestHandler = nil;
}];
[self.requestHandler executeRequest];
To understand retain cycle, take a look at this thread.
If web service can be invoked at same time, you can use a NSMutableArray in a public data to save managers.
//Public data manager class add a NSMutableArray to save managers.
#property (nonatomic, strong) NSMutableArray *requestingManager;
NetworkManager *objNetworkManager= [[NetworkManager alloc]init];
[objNetworkManager setCompletionHandler:^(NSDictionary *resp, BOOL isSuccess){
//remove when finish
[[PublicData instance].requestingManager removeObject:objNetworkManager];
if (isSuccess) {
}else{
}
}];
[objNetworkManager initiateUrlRequestWithInput:jsonRequestInput];
//add manager when request
[[PublicData instance].requestingManager addObject:objNetworkManager];
After remove objNetworkManager, objNetworkManager will not be retained, and will release, the block in it will be set to nil automatically.
I'm trying to see if there are any ongoing calls, but I'm having trouble with keeping an instance of CTCallCenter as a property. Here's basically what I'm doing now that I'm debugging (everything is in MyClass):
-(void)checkForCurrentCalls
{
CTCallCenter *newCenter = [[CTCallCenter alloc] init];
if (newCenter.currentCalls != nil)
{
NSLog(#"completely new call center says calls in progress:");
for (CTCall* call in newCenter.currentCalls) {
NSLog(call.callState);
}
}
if (self.callCenter.currentCalls != nil) {
NSLog(#"property-call center says calls in progress:");
for (CTCall* call in self.callCenter.currentCalls) {
NSLog(call.callState);
}
}
}
My self.callCenter is a #property (nonatomic, strong) CTCallCenter *callCenter;. It has synthesized setter and getter. It's initialized in MyClass' init method:
- (id)init
{
self = [super init];
if (self) {
self.callCenter = [[CTCallCenter alloc] init];
}
return self;
}
If I call another of my methods before checkForCurrentCalls, then my self.callCenter.currentCalls stops updating the way it should. More precisely, the phonecalls I make (to myself) just keep piling on, so that if I've dialed and hung up three phonecalls I get printouts of three CTCalls being in the "dialing" state. The newCenter works as expected.
All I have to do to break it is call this:
- (void)trackCallStateChanges
{
self.callCenter.callEventHandler = ^(CTCall *call)
{
};
}
I have come across answers that say that CTCallCenter has to be alloc-init'd on the main queue. I have since then taken care to only call my own init on the main queue, using dispatch_async from my app delegate:
dispatch_async(dispatch_get_main_queue(), ^{
self.myClass = [[MyClass alloc] init];
[self.myClass trackCallStateChanges];
}
My checkForCurrentCalls are later called in applicationWillEnterForeground.
I don't understand why just setting the callEventHandler-block breaks it.
Everything is tested on iphone 5 ios 7.1.2.
This has been reproduced in a new project. Filed a bug report on it.
I have a method called in various places called "cancelAllPendingDownloads"
This is a general method that cancels various jobs and updates internal counters.
Problem happens when it is called within the dealloc method
-(void)dealloc
{
[self cancelAllPendingDownloads]; // want to cancel some jobs
}
-(void)cancelAllPendingDownloads // updates some internals
{
__weak __typeof__(self) weakSelf = self; // This line gets a EXC_BAD_INSTRUCTION error in runtime
for(Download *dl in self.downloads)
{
dl.completionHandler = ^{ // want to replace the previous block
weakSelf.dlcounter--;
}
[dl cancel];
}
}
Not sure why it fails in the dealloc method as "self" still exists
When I change the code to
__typeof__(self) strongSelf = self; //everything works fine
__weak __typeof__(self) weakSelf = strongSelf; (or "self") BAD_INSTRUCTION error
The error happens on the second line
Just to make the "you are not supposed" or "You can't" part of the other good answers
more precise:
The runtime function for storing a weak reference is objc_storeWeak(), and the
Clang/ARC documentation states:
id objc_storeWeak(id *object, id value);
...
If value is a null pointer or the object to which it points has begun
deallocation, object is assigned null and unregistered as a __weak
object. Otherwise, object is registered as a __weak object or has its
registration updated to point to value.
Since the self object has already begun deallocation, weakSelf should be set to NULL
(and therefore is not of any use).
However, there seems to be a bug (as discussed here http://www.cocoabuilder.com/archive/cocoa/312530-cannot-form-weak-reference-to.html)
that objc_storeWeak() crashes in this case, instead of returning NULL.
If an object is in dealloc state, you are not supposed to create any new references to it. Consider the object as already destroyed. Don't use it in a callback/delegate any more.
Note that dlcounter won't ever be read. Just cancel the connections without reading the results.
TL;DR
- How can I reference __weak self in dealloc method?
- Don't reference it.
You can't initialize a week (or a strong) reference to self in the dealloc method and use it elsewhere - it's too late, the object will be inevitably destroyed.
However, you might try this:
-(void)dealloc
{
NSArray* localDownloads = self.downloads;
for(Download* dl in localDownloads) {
[dl cancel];
}
}
It should be clear that there are better places to invoke cancellation, for example, in a view controller, you may override viewWillDisappear:.
I am assuming you are using ARC for your project.
Straight from Apple:
Apple Talked about Weak and Strong
__strong is the default. An object remains “alive” as long as
there is a strong pointer to it.
__weak specifies a reference that does not keep the referenced object alive.
A weak reference is set to nil when there are no strong references to the object.
This is an Article Explaining Dealloc:
Dealloc Method Explained and More
This method will be called after the final release of the object
but before it is deallocated or any of its instance variables are destroyed.
The superclass’s implementation of dealloc will be called automatically when
the method returns.
After this being pointed out... I highly recommend you revise your code design because there is no reason for you to call a weak typeof(self) to solve your problem of cancelling those downloads at dealloc or any type of deallocing that involves _weak_typeof__self for that matter.
What I can recommend though is that that class that you are trying to cancel those downloads frin, make it keep track of those downloads with a Download UniqueID and just stop them or delete them at dealloc. Its simpler and easier to manage rather than that wierd call to __weak self and all that code you are doing.
In short: you can use a __strong reference to self in dealloc instead of __weak for your purposes but if and only if that strong reference won't outlive the end of dealloc. Otherwise, I would advise using __unsafe_unretained, which is still unsafe if it outlives the dealloc but is clearer to read.
Longer: I had a similar situation where the object (view controller) during dealloc should unsubscribe from notifications. That's a custom notifications system and unsubscribing requires creating an object with a reference to the entity that's being unsubscribed.
I ended up with the same situation: in dealloc there's no way to create that object because it required a weak reference which caused a crash (here's some stupid demo code, not something you would have in production):
#interface Dummy : NSObject
#property(nonatomic, weak) id weakProperty;
#property(nonatomic, strong) id strongProperty;
#property(nonatomic, unsafe_unretained) id unsafeProperty;
- (instancetype)initWithWeakStuff:(id)stuff;
- (instancetype)initWithStrongStuff:(id)stuff;
- (instancetype)initWithUnsafeStuff:(id)stuff;
#end
#implementation Dummy
- (instancetype)initWithWeakStuff:(id)stuff {
self = [super init];
if (self) {
_weakProperty = stuff;
}
return self;
}
- (instancetype)initWithStrongStuff:(id)stuff {
self = [super init];
if (self) {
_strongProperty = stuff;
}
return self;
}
- (instancetype)initWithUnsafeStuff:(id)stuff {
self = [super init];
if (self) {
_unsafeProperty = stuff;
}
return self;
}
- (void)dealloc {
}
#end
#interface ViewController ()
#end
#implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
}
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
- (void)dealloc {
Dummy *dummy = [[Dummy alloc] initWithStrongStuff:self];
[[NSNotificationCenter defaultCenter]
postNotificationName:#"some notification"
object:dummy]; // do something with it
}
#end
If, on the other hand, the reference was strong, all seems to work well (during dealloc). The problem would arise if that newly created object would outlive self:
- (void)dealloc {
Dummy *dummy = [[Dummy alloc] initWithStrongStuff:self];
dispatch_async(dispatch_get_main_queue(), ^{
[[NSNotificationCenter defaultCenter]
postNotificationName:#"some notification"
object:dummy]; // do something with it
}); //Crash at the end of the block during dummy's dealloc
}
This would mean that whenever the dummy object would need to dealloc it would try to decrease the ref count of its strongProperty. And at that point the ViewController has been deallocated and released already.
However, IMHO the "safest" way to proceed is to use unsafe_unretained in this case. Technically it's the same as using assign: pointer will be assigned regardless of memory management and that reference will not need to be released when it goes out of scope. But using unsafe_unretained tells the readers of your code (or future you) that you were aware of the risk and there must have been a reason to do what you did.