Wrong Twitter result after unsuccessful send attempt - ios

When using TWTweetComposeViewController in IOS5 to compose and send a Tweet, if the Tweet is a duplicate, an error alert is shown saying that the Tweet is duplicate and cannot be sent, but the TWTweetComposeViewControllerCompletionHandler still gets a result value of TWTweetComposeViewControllerResultDone rather than TWTweetComposeViewControllerResultCancelled.
(This may happen in other cases as well, not just for duplicate tweets - I didn't check).
This makes it impossible to show a confirmation message to the user after a successful send, because the handler gets the same "Done" result whether the send was successful or not.
Is there another way to check whether the send was actually successful?

The documentation for TWTweetComposeViewController's completionHandler states the following:
The handler has a single parameter that indicates whether the user finished or cancelled composing the tweet.
The completionhandler tells you whether the user actually finished or cancelled composing the tweet herself, regardless of the result of actually posting the tweet.
Update
I've looked a bit further into this and it seems like the TWTweetComposeViewController is one of those convenience classes that take away most of the work for the developer in exchange for not letting the developer handle anything by himself. In this case, the developer has no way of handling the errors that occur when sending the tweet and has to rely on the iOS provided alert dialogs to inform the user instead.
You can hack around this by using Saleh's method, though I don't consider that safe enough to use in an actual app. See the comments in his answer.
Another method is by implementing your own view controller which handles tweet composition and sending. You can do this by following the procedure in the following stackoverflow answer.

Check for the alert message, if the alert message is shown you'll be able to know that the error occurred. I think that the alert message gets added in the window. You can check the count of window's subviews, if they get increased when delegate function is called, you'll know that the error occurred.

Isn't it only a view controller? The result of the view controller is fine as it states what happened with the view controller ( it is done running ).
With what are you sending your tweet? That library most likely has some stuff implemented you can use to determine whether your tweet was sent successfully or not.

[postRequest performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error)
{
if([urlResponse statusCode]==200)
{
//Tweet tweeted successfully....
}
}
this might help you .
In respponse if url response code is 200 you can say text is tweeted....

Related

Accessing previous MSMessages from MSConversation

If I have sent a few messages in my iMessage app and I want to access previous messages (obviously just my own app-created messages, not just any messages the users have sent in their conversation), is there a way I can do that?
I can access the most previous message with this:
[self activeConversation].selectedMessage;
Any way to loop through previous messages that might not have even ever been clicked by the user (so simply storing it in user defaults is not an option)
There is no way to do this. Apple considers this to be a security/privacy issue.

Watchkit : Handle multiple session sendMessageData requests

I have a WatchOS2 app which displays data on the watch after calling NSURLSession. Since response takes some time, if the user opens another interface controller another call goes to
- (void)session:(WCSession *)session didReceiveMessageData:(NSData *)messageData replyHandler:(void(^)(NSData *replyMessageData))replyHandler
But if previous api output comes then it returns data through reply. Again the second data output should also be send. So this is giving a crash and my app hangs.
Is there a way to stop the previous reply from being sent by closing the request?
No, there is no way to cancel the previous request. It sounds like you are making the "currently visible interface controller" be the delegate of the WCSession, which would be mixing a lot of responsibilities. Instead I'd suggest adding something like a singleton class that is the permanent delegate of WCSession; and it persists and notifies, or dispatches incoming data to the right place.

ios and evernote : How can i know which Createnote failed?

I'm using Evernote sdk on iOS and it works great.
But sometimes I'm sending several CreateNote methods in a row and, as Evernote sends them asynchronously, if one of them falls in error I can't say which one ...
The CreateNote method returns a Note object when success but a NSError when failure. And this one doesn't tell about which query it was.
How can I know which note creations failed ?
Thanks
The Evernote SDK does send the requests asynchronously, but its always one request at a time. So if a request fails, its always the last request that you made.

Facebook app invite delegation mixup

I'm sending a Facebook app-invite from my iOS app, and am trying to implement a success/fail flow using blocks.
I have created a class to wrap my communication with the Facebook SDK which exposes a send invite method.
In that method, I have the following code:
[self.facebook dialog:#"apprequests"
andParams:params
andDelegate:self];
as explained in the documentation.
My wrapper class conforms to the FBDialogDelegate protocol, and I have implemented 5 of the delegate methods:
dialog:(FBDialog *)dialog didFailWithError:(NSError *)error,
dialogCompleteWithUrl:(NSURL *)url,
dialogDidComplete:(FBDialog *)dialog,
dialogDidNotCompleteWithUrl:(NSURL *)url
dialogDidNotComplete:(FBDialog *)dialog
The problem is that wether the user cancels the dialog or sends the request, the only method that is being called is the dialogCompleteWithUrl:(NSURL *)url method.
Can anyone explain this?
This seems to be an outstanding issue that has been reported several times. The fact that didComplete is called when the user presses the cancel button is indeed a valid action so it is by design that didComplete gets called. The documentation might be outdated and we have a task to fix it, but reporting a doc bug on our developer site will allow you to track the progress.
So to answer your question, if the user presses the 'x' button it should call didNotComplete. User pressing send or cancel will call didComplete as it is designed that way.
However, this person came up with a good workaround for FBDialog where you can probably do something similar, such as checking the value of the URL when it succeeded vs when the user presses cancel and have an if check that checks for that case.
Hope this helps.

Cannot send facebook apprequest from iOS because FBSession.activeSession.isOpen gives false

my app can only send app request during the first run that the user logins into facebook. Once the app is restarted, the app request gets stopped because FBSession.activeSession.isOpen gives false.
Although, FBSession.activeSession.isOpen gives false still the app can perform other operations such as posting to the wall, getting friend list etc. Only it cannot send app requests. And still it has a valid access token too.
Any ideas?
You say "FBSession.activeSession.isOpen gives false", but, just to be sure : when do you run this test? When your call to the login request returns, or inside the asynchronous request's callback ?
If it's done outside the request's callback, it may say that the session is not opened yet. Then, the request returns properly, which means that any further call to another FB request succeeds.
Does that help?
If it does not, maybe an overview of your code could.
Ok, next to your comment from the previous answer :
yes, that's what you said already. but WHERE in your code do you check isOpen? To expect a proper value, it should be something like this :
FBSession openActiveSessionWithReadPermissions:_readPerms allowLoginUI:YES completionHandler:^(FBSession *session, FBSessionState status, NSError *error) {
// here is the proper place to check the isOpen boolean, and to go on with your program, including the app request
}];
// not the proper place to check isOpen.
Does that help?

Resources