The documentation for MFMessageComposeViewController says you should check [MFMessageComposeViewController canSendText] before trying to create a MFMessageComposeViewController.
It also says:
in iOS 5.0 or later, you should register as an observer of the MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification notification to be notified of changes in the availability of sending text messages.
What possible reasons could there be for the availability of text messaging changing?
Is it just to make Linus Torvalds cry?
Background: I’m creating an iOS app that requires the ability to send SMS messages. I’ve added sms to UIRequiredDeviceCapabilities in Info.plist. It should only run on iPhones (according to Apple docs, I read somewhere this does not include iPod touches or iPads solely with iMessage)
If text messaging is not available, the app is useless, and should present some useful error message.
Update: I’ve tested with my iPhone 4S that simply having a locked SIM still returns YES from canSendText – still not a reason for message sending ability to change.
Update #2: I have created a simple test app to see what might cause it. I have not received the notification at all.
Things that don’t cause MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification
Turning iMessage on & off
Losing WiFi connectivity
Turning on airplane mode
Locking iPhone SIM card
Things that can cause canSendText to change between YES/NO (but not send a notification)
Turning iMessage on & off on an iPad (I assume iPod touch too)
I’m guessing the correct case is for iPads and iPod touches when iMessage is turned on or off, however, there must be a bug (either in my test code or Apple’s) that’s preventing this from working.
If you need this notification, I tried just checking [MFMessageComposeViewController canSendText] again on UIApplicationDidBecomeActiveNotification. This sometimes works, but if you switch quickly between Settings.app and your app, it may not have changed yet by the time you switch to your app, causing canSendText to still reflect the old value.
My solution for now is just going to be simply checking canSendText just before relevant decisions are made, and handle the (rare?) case where it may have changed without me knowing in some appropriate way.
Since MFMessageComposeViewController can use iMessage in iOS5, I'm guessing it's probably to handle the case where iPod Touches and Wi-fi iPads lose internet connectivity while a message is being typed.
I managed to rule out another scenario where it does not trigger MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification.
Sender iPad with a working wifi connection
Reciepient Android phone
Result: MessageComposeResult == MessageComposeResultSent, MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification was not triggered
Next I tried the same scenario with iMessage in order to duplicate the final results. (== not being able to send an iMessage).
Then I realized that iMessage was able to tell me in advance this would never work by putting a red exclamation next to the recipients name with the message this person is not registered with iMessage. The MFMessageComposeViewController does not do this!!!
My current conclusion is: canSendText should be named canComposeText.
MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification does nothing.
Currently, there is no case where MFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification is sent.
The only time when the value of canSendText changes is when iMessage is turned on/off on an iPad or iPod Touch (not an iPhone, which has SMS messaging).
Even when canSendText changes, no notification is sent.
(Unless it’s just a bug in my test code?) This appears to be a bug or missing feature in Apple’s code.
Related
I'm using both NSWorkspaceDidActivateApplicationNotification and NSWorkspaceDidLaunchApplicationNotification notifications to know which app the user is interacting with.
The problem is that, if an application is just opened and still launching, I first receive a activate notification, and soon afterwards a launch notification.
Is there any way to know within the activate method that the app is still launching and not yet ready for use? (Still bouncing in the dock)
I see that the ichat sample project by apple does not use the above approach and instead only listens to launch notifications. It then uses kAXApplicationActivatedNotification to add an AXObserver to the app. Is this the preferred way? (And also NSRunningApplications to add an observer to all already loaded apps).
I wanted to keep using just plain simple NSNotifications because I think it may be less memory intensive. (No need to keep an observer around for each and every app loaded).
check the NSRunningApplication object passed in the userinfo of the NSWorkspaceDidActivateApplicationNotification
NSRunningApplication *app = [note.userInfo objectForKey:NSWorkspaceApplicationKey];
if(app.isFinishedLaunching)
NSLog(#"up");
What's the best way to resume playback of the ipod or other audio sessions after your app has completed using its session?
NOTE I've already tried calling...
[_session setActive:NO
withFlags:AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation
error:outError];
I'm building an iOS VoIP app which uses AVAudioSessionCategoryPlayAndRecord as its category and kAudioSessionMode_VoiceChat as its mode. To simplify handling of audio session management, I've got a singleton which listens for notifications on application state and other important events. However, the above code does not seem to cause the music to resume on the iPod app.
Finally, we've also noticed that the music controls that are shown on the bottom of the screen when the home button is double tapped act as if our application is the one playing audio. Yet we've already set it to be inactive.
Would love to understand more about what's going on here if anyone has any clue.
I seems to me that you are unable to notify the iOS that you no longer require an audio session. Are you sure that the call to "setActive" doesn't fail? Or maybe somewhere else in the code you reactivate your session.
Other than that, the Music application should be able to re-gain it's audio as soon as the system realizes you are not using it. This can be accomplished by third-party applications using the AVAudioSessionInterruptionNotification notification. For debugging you might try adding yourself as observer and see if your callback gets called. So, if you successfully deactivate your session, other applications should be able to do the rest.
I'm using Apple's view controllers quite alot in my app (like MFMessageComposeViewController and ABPeoplePickerNavigationController). So when I receive a notification (Local or Remote notification) how would I deal with it the most elegant way since I can not interact (send messages) to Apple's view controllers.
My assumption is that if the user is actively using the app and in i.e MFMessageComposeViewController he does not want to get disturbed/interrupted with what he is doing. But if it was me I would get a bit confused if I was doing something and I would hear boing sound (from the notification) and then nothing more happened.
So would a reasonable way to handle this do let the user finish doing his task in whatever Apple view controller he is inside and then display the notification for the user?
Or dismiss the Apple view controller and handle the notifaction and then put the user back in the Apple view controller?
I'm not quite sure I understood you exactly correct, but to me it sound like you want to do something like this:
If the user is composing a message in your app and there is an incoming notification, lets say a push notification from the facebook app, you want to handle this event somehow in your app by letting your MFMessageComposerViewController do something.
As answer to this request I would like to state the following:
You should be able to send messages to your MFMessageComposerViewController if you extend this class (i.e. create a class called MyMessageComposerController and let it extend the standard controller, and do whatever you need there)
However, you can't really do anything about the push notification, it comes from another app and this functionality is built into iOS, you can not make the push arrive later when the user is finished typing, it will always arrive and the user will always be the one to decide if he/she should keep typing or look at the notification. The only thing you can do is to make sure that your app saves everything that the user has typed so that he/she can continue typing when returning to your app.
Assuming you don't just want to display an AlertView or something similarly modal over the message composer, I would do something like the following:
assign a MFMessageComposeViewControllerDelegate to the composer.
show the composer as usual.
queue/remember the notifications received while the composer is in play (through the normal application:didReceive{Local|Remote}Notification: messages)
when the composer is closed, the delegate receives its messageComposeViewController:didFinishWithResult: message.
Do... whatever... with the stored/queued notifications.
Whether you delay responding to the notification until the user is finished with the composition or interrupt them is a trickier situation. If it's a relatively unimportant notification or notifications that are frequent, I'd tend towards the queue/delay approach. But for "important" notifications, I'd have no problems in interrupting the user. Of course, that just moves the question to what determines importance. And that is very much dependent on the app.
Here is some background information, otherwise skip ahead to the question in bold. I am building an app and I would like it to have access to the remote control/lock screen events. The tricky part is that this app does not play audio itself, it controls the audio of another device nearby. The communication between devices is not a problem when the app is in the foreground. As I just found out, an app does not assume control of the remote controls until it has played audio with a playback audio session, and was the last do so. This presents a problem because like I said, the app controls ANOTHER device's audio and has no need to play its own.
My first inclination is to have the app play a silent clip every time it is opened in order to assume control of the remote controls. The fact that I have to do this makes me wonder if I am even going to be allowed to do it by Apple or if there is another way to achieve this without fooling the system with fake audio clips.
QUESTION(S): Will Apple approve an app that plays a silent audio clip in order to assume control of the remote/lock screen controls for the purpose of controlling another device's audio? Is there any way of assuming control of the remote controls without an audio session?
P.S. I would prefer to have this functionality on iOS 4.0 and up.
P.P.S I have seen this similar question and it has gotten me brainstorming but the answer provided is not specific to what I need to know.
NOTE: As of iOS 7.1, you should be using MPRemoteCommandCenter instead of the answer below.
You create various system-provided subclasses of MPRemoteCommand and assign them to properties of the [MPRemoteCommandCenter sharedCommandCenter].
I'm keeping the rest of this around for historical reference, but the following is not guaranteed to work on recent iOS versions. In fact, it just might not.
You definitely do need an audio player but not necessarily an explicit session to take control of the remote control events. (AVAudioSession is implicit to any app that plays audio.) I spent a decent amount of time playing with this to confirm this.
I've seen a lot of confusion on the internet about where to set up the removeControlEventRecievedWithEvent: method and various approaches to the responder chain. I know this method works on iOS 6 and iOS 7. Other methods have not. Don't waste your time handling remote control events in the app delegate (where they used to work) or in a view controller which may go away during the lifecycle of your app.
I made a demo project to show how to do this.
Here's a quick rundown of what has to happen:
You need to create a subclass of UIApplication. When the documentation says UIResponder, it means UIApplication, since your application class is a subclass of UIResponder. In this subclass, you're going to implement the remoteControlReceivedWithEvent: and canBecomeFirstResponder methods. You want to return YES from canBecomeFirstResponder. In the remote control method, you'll probably want to notify your audio player that something's changed.
You need to tell iOS to use your custom class to run the app, instead of the default UIApplication. To do so, open main.m and change this:
return UIApplicationMain(argc, argv, nil, NSStringFromClass([RCAppDel`egate class]));
to look like this:
return UIApplicationMain(argc, argv, NSStringFromClass([RCApplication class]), NSStringFromClass([RCAppDelegate class]));
In my case RCApplication is the name of my custom class. Use the name of your subclass instead. Don't forget to #import the appropriate header.
OPTIONAL: You should configure an audio session. It's not required, but if you don't, audio won't play if the phone is muted. I do this in the demo app's delegate, but do so where appropriate.
Play something. Until you do, the remote controls will ignore your app. I just took an AVPlayer and gave it the URL of a streaming site that I expect to be up. If you find that it fails, put your own URL in there and play with it to your heart's content.
This example has a little bit more code in there to log out remote events, but it's not all that complicated. I just define and pass around some string constants.
I bet that a silent looping MP3 file would help work towards your goal.
Moshe's solution worked great for me! However one issue I noticed is when you paused the audio, the media controls would go away and you won't be able to play it again without going back into the app. If you set the Media Info on the lock screen when you play the audio then this won't happen:
NSDictionary *mediaInfo = #{MPMediaItemPropertyTitle: #"My Title",
MPMediaItemPropertyAlbumTitle: #"My Album Name",
MPMediaItemPropertyPlaybackDuration: [NSNumber numberWithFloat:0.30f]};
[[MPNowPlayingInfoCenter defaultCenter] setNowPlayingInfo:mediaInfo];
I want to track four finger touches in my application, but they are cancelled as the iPad uses the four finger swipe to switch applications.
Is there a way to cancel / override this gesture?
I looked into this for a game I worked on and I could not find a way to override it. Even if you found a way, it would probably get you rejected from the app store, since there doesn't seem to be any public API for it.
This be my answer. I'm not sure how you'd go about to actually execute the below as I guess implementions do things differently, but generally it sounds as there is a possibility, because after all these are the words of Apple regarding the multitasking gestures:
"Developers are encouraged to evaluate any existing interactions in
their applications for potential sources of interference. In order to
properly interoperate with multitasking gestures, applications must
properly handle the following methods and notifications:
touchesCancelled:withEvent: (UIResponder) cancelTrackingWithEvent:
(UIControl) applicationDidBecomeActive: and
applicationWillResignActive: (application delegate)
UIApplicationDidBecomeActiveNotification and
UIApplicationWillResignActiveNotification notifications These can be
enabled for development via Xcode so you can update your apps to
interoperate with these new gestures. Test them and give us your
feedback in the Apple Developer Forums."
I really don't think you can because I have watched countless videos on how to override on iPhone/iPod but there are no ones for iPad must be so you can't cheat on games!