I am using AVPlayer to playback a continuous internet radio stream. I set up an AVAudioSession and my Info.plist to continue playback while the app is in background, and handle the remote control events to play, pause and stop.
On iOS there are controls for next and previous track in the multitasking bar, in the lock screen, on connected Bluetooth devices and so on. With these controls available and not "grayed out" the user assumes he could skip to another "track". But this is not possible in my scenario. There are no single "tracks". The app can only consume what is played by the icecast server.
Question: Is it possible to hide or disable these controls, so the user understands that it is not possible to skip to another "track"? (And if yes, how?)
No. Just don't respond to those controls. Respond only to the controls you do respond to (e.g. playpause button).
In this example from one of my apps:
The "next" and "previous" buttons do nothing; they are meaningless. But I've never gotten a complaint from a user.
Related
I'm working on an application that is designed to speak some information about the data it captures from video as the video is being captured. Right now I'm using UIAccessibilityPostNotification to get VoiceOver to say what I want it to say with UIAccessibilityAnnouncementNotification. This typically works great until the user attempts to navigate between my UI controls. After swiping back and forth along the elements (a menu and an info button) a little bit, the application stops speaking the persistent notifications. I also find that posted notifications do not announce if I background the app and then return it to the foreground
I have a magic tap handler that pauses and resumes that persistent announcement and once it is triggered (which also triggers speech about the last rendered info), manually triggered speech works again and upon resume from a second magic tap the announcements continue as if nothing had stopped.
Is there a mechanism to get voiceover to reliably resume speaking without requiring some other kind of user-screen input in between?
Fortunately this was, following the rule of "it's probably your own code's fault first", my own fault. A timer was inadvertently changing the state of things and what I was using to track when to announce was being set to an invalid state which stopped the announcements.
I would like to execute some code when user presses one of home, power or volume buttons(it doesn't matter, which of these).
I would like to catch events even application is minimized to background and device is sleeping.
So primary task is processing events, when device is inside user's pocket and the user presses button, but not takes out the device.
Is that possible? If it isnt't possible for power button, may be it's possible for volume or home buttons? How can I do it?
Your application cannot interact with the hardware buttons on an iOS device. Your application can receive notification that it has entered the background (which may be a side-effect of the use pressing the home button, for example) but that is about all
There is idea about volume buttons, if you create player instance you can get notifications about volume change, not sure that is still work but you can try.
see answers here: program access to iPhone volume buttons
I came to know that iOS does't support widgets this is what i have read.But i am making application on Security in iOS, i want the user to perform some action when he is in need of help without opening the application.
I know iOS supports few background modes like play audio,receive location updates,voip etc.
Can anyone suggest me any alternative to fire some methods without opening the application like pressing some button when in dangerous situation to call those methods.
I don't know whether we can do it or not.
But have a look.
You said we can implement background modes like audio, location, voip updates etc.
Let take the example of Audio mode. It has previous, play/pause, and next button in the lockscreen.
What you can do is play an audio when the application is in background mode.
Check whether the any of the music buttons are pressed more than 3 times. If this is the case trigger alert messages for security and send them to appropriate persons or do your own action.
I don't know whether we can do this or not. Even if it is possible, I can't say Apple will allow such false actions for buttons which are meant for some purpose.
Also see whether we can get detect volume button presses when in background mode. If that is possible you can do that. Because even my LG mobile has an SOS mode which is enabled when I press volume buton in lockscreen 4 times. Apple may allow this action if it possible
I'm reading how to handle the events themselves, and I know I could intercept them and use them for my own design, but would Apple allow an app like that into the AppStore?
http://developer.apple.com/library/IOS/#documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/RemoteControl/RemoteControl.html
You could imagine playing a game and giving the option of physical back/forward buttons mapped to left/right in your game. I mean to use them when the app is active in the foreground, nothing outside the app or in the software control tray.
This article doesn't say specifically that it's not allowed, but it does imply that the events are to control music only.
Can anyone with more Apple/iOS background refer me to a document which specifies the rules about using the buttons?
I'm writing a streaming app that's using the remote control feature (remoteControlReceivedWithEvent:).
I can start and stop songs with the remote control as expected.
But I can't seem find out how to disable the next and previous song button on the home screen (double-tap home and swipe all the way to the left).
I'm using a MPMoviePlayerController internally.
Thanks :)
As far as I know the API doesn't allow you to show the buttons as disabled. I think the best you can do is just not take any action when one of those buttons are pressed.
I have not observed any other major app that shows the remote buttons as disabled.