I am using TWTweetComposeViewController, when available, to send tweets from inside my iOS app. I pre-populate the view controller with boilerplate text, then let the user modify and send at their discretion. It works great for the most part. Distilled down, it looks like this (with body
pointing at a valid NSString
):
if (NSClassFromString(@"TWTweetComposeViewController")) {
TWTweetComposeViewController *iOS5twitter = [[TWTweetComposeViewController alloc] init];
[iOS5twitter setInitialText:body];
iOS5twitter.completionHandler = ^(TWTweetComposeViewControllerResult result)
{
[self.viewController dismissViewControllerAnimated:YES completion:nil];
};
[self.viewController presentViewController:iOS5twitter animated:YES completion:nil];
[iOS5twitter release];
}
else {
/* Do something else when the framework is missing */
}
Now if body
is too long, i.e., more than 140 characters, the resulting tweet view is empty of any text at all, character countdown set to 140. I might have expected truncation in this case, although it does not appear to be documented in the Class Reference one way or the other what happens when the initial text is too long, but I can accept that I have to do the truncation to maximum tweet length before passing to setInitialText
.
What I don't understand is that certain messages which are shorter than 140 characters also produce the empty tweet view.
Initially I saw what seemed to be a perfectly valid string with 139 characters failing. I noticed that shortening the string made it work. But after a great deal of experimenting, I also noticed that replacing a URL which happened to appear inside the text with random text of the same length made it work. In other words, the URL itself is causing a problem.
So I thought maybe there was something weird about the URL I was using, but I distilled it down to this. This one works:
NSString *body = @"............................................................................................................................................";
while this does not
NSString *body = @"............http://a........................................................................................................................";
Observations:
[body length]
). The only difference is the presence of something vaguely URL-like embedded in the middle of the second one.Anybody ever seen something like this? Any idea what is going on? Am I doing something wrong, or is the iOS Twitter Framework just broken?
I have run into the exact same problem. It is a known bug in the Twitter framework and is being tracked.
Please see this discussion on dev.twitter.com https://dev.twitter.com/discussions/5024
(I would have posted that as a comment rather than an answer if I could, but I don't have sufficient SO credibility so thought I'd add the below observations as well in case they are of interest).
When just adding text without URLs, the character count works as expected. Adding a URL with the addURL: method causes 21 characters of the tweet to be used (20 for URL plus a space). Adding the URL in the initial text causes 20 chars to be used for the URL. When including a single URL (using either method) the framework fails when the total character count exceeds 138 (e.g. 20 for URL + space + 117 chars of initial text) thus losing 2 characters. With just one URL the order of setting the initial text and then adding the URL with addURL: does not make a difference.
When adding 2 URls, it fails when the total character count exceeds 113 this losing 27 characters! However, with 2 or more, if you add the URLs BEFORE setting the initial text, it fails with a total count of 136. So 2 chars are lost per URL again.
Summary/Workaround - if just including 1 URL then adding it in the initial text will give you one extra character than using the addURL: method, but you will still be short 2 characters overall. If adding 2 or more URLs using addURL: then add them before the initial text, but until the bug is fixed, you will still lose 2 chars per URL.
I have filed a radar, but according to this Can I browse other people's (Apple) bug reports?, the more times a bug is reported the higher priority it is given, so it is worth others filing it as well to increase it's priority.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With