简体   繁体   中英

Deleting Twitter Account from settings crashes the application using iOS5 twitter framework

I a using iOS 5 Twitter framework and I save the ACAccount object. If user goes and deletes the specific account from settings, the application (obviously) crashes. My current workaround only save the username and re-fetches the array of twitter accounts and matches the usernames to get the correct account. Is there any better work around. I know there is a notification from ACAccountStore

ACAccountStoreDidChangeNotification

but I am not receiving it.

The code below is the fixed version. Here I am comparing the previousAccount username. If I remove that and use the AccountObject picked by user earlier, and if the user has changed that account, application will crash.

if([TWTweetComposeViewController canSendTweet]) {

        ACAccountStore *store = [[ACAccountStore alloc] init];
        ACAccountType *twitterType = [store accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierTwitter];
        [store requestAccessToAccountsWithType:twitterType withCompletionHandler:^(BOOL granted, NSError *error) 
         {

             if(granted)
             {
                NSArray *arrayOfAccounts =  [store accountsWithAccountType:twitterType];
                 if (arrayOfAccounts != nil && [arrayOfAccounts count]>0) {
                     for(ACAccount *anAccount in arrayOfAccounts)
                     {
                         if ([anAccount.username isEqualToString:previousAccount.username] ) {
                             [self setPhoneTwitterAccount:anAccount]; //alwAYS SET the new Account.
                             break;
                         }
                     }
                     //previous account was deleted if a userName match was not found
                     //show the picker or just pick the first account.
                     //TODO: provide a picker from here as well.
                     if (self.phoneTwitterAccount == nil) {
                         self.phoneTwitterAccount = [arrayOfAccounts objectAtIndex:0];
                     }

                 }
             }
         }];
    }

Crash happens on using the older account:

 TWRequest* twitterRequest_5 = [[[TWRequest alloc] initWithURL:profileURL 
                                                          parameters:parameters
                                                       requestMethod:TWRequestMethodGET]autorelease];

        [twitterRequest_5 setAccount:phoneTwitterAccount];    

        [twitterRequest_5 performRequestWithHandler:^(NSData *responseData,NSHTTPURLResponse *urlResponse, NSError *error);

I had a similar problem with ACAccounts, my app would crash and the debugger would give me an EXC_BAD_ACCESS every time the following block was executed:

performRequestWithHandler:^(NSData *responseData,NSHTTPURLResponse *urlResponse, NSError *error) 

The problem was solved when I retained the ACAccountStore as an instance variable in my application delegate. Maybe you could try allocating and initializing the ACAccountStore once in your app delegate, then referencing that instance each time you need to get account data from it rather than allocating and initializing new instances whenever you need to get Twitter account data.

AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
ACAccountStore *store = appDelegate._accountStore;

It's not very clear what the relationship between the ACAccountStore and the ACAccount is but the documentation says "Each ACAccount object belongs to a single ACAccountStore object.". I take this to mean that if I don't retain the ACAccountStore instance that my ACAccount instance is derived from there could be problems at some point.

Let me know if this helps, is completely wrong, or maybe someone can explain what's really going on here.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM