I didn't think this was the case based on the documentation, but now that I actually try it, it looks like you're right.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apples plays True or Faux multitasking
- Thread starter samcraig
- Start date
- Sort by reaction score
I didn't think this was the case based on the documentation, but now that I actually try it, it looks like you're right.
So a remote desktop app could potentially ask for 5 minutes after you switch away to keep the connection alive. If you switch back within that time it's still going, if not it has to reconnect.
Not the greatest solution, but this isn't something that the vast majority of users will ever wish to do.
Not the greatest solution, but this isn't something that the vast majority of users will ever wish to do.
Possibly. It could also claim to be a VoIP client, I think, in which case the OS would keep its connection open for it. Of course it might get rejected from the app store for not actually, you know, being a VoIP client.
Then again... no reason a remote desktop client shouldn't play remote audio, right? RDP, the Windows remote desktop protocol, supports this at least. And conceivably one might want to have one's remote desktop audio still playing in the background, to, say, listen for a sound indicating a task on the remote system has completed, right?
I think we've just found a way a remote desktop client could plausibly claim it needs to run in the background as a background audio application....
Air sharing works by mounting the iPhone as a WebDAV server to which your desktop can connect to and add/modify/remove files. If you switch to another app, does it also kill the connection?
We can at least take comfort in the fact that Apple can modify and add multi-tasking API's as the need arises.
I don't think there will be a legitimate way to "fool" the system. In your audio example, your app is not remaining in the background pretending to look for an audio stream. It is telling Apple's audio process how to obtain the music stream. When the app is not in the foreground, it goes away completely. It is Apple's audio process that continues to stream the music.
The task completion suggestion is the only real possibility of maintaining a temporary connection for a limited amount of time after quitting the app.
This is completely wrong. Like, 180 degrees wrong.
ScaryRobot has posted what I believe is an accurate description of how background processing works a few posts up. I think there are few misstatements in my previous posts, which are, after all, just speculation based on the public presentation. If anything, my comments - although describing more flexibility than that of the naysayers here - in fact, portray a more restricted environment than actually exists.
I'm saying that I was probably wrong on some minor points, but I erred on the side of the nay-sayers. The reality seems to be even more liberal than I had thought.
It seems I was wrong about Local Notifications being a way to schedule call-backs to the app. Frankly, I've never used the current Notifications system and so was unfamiliar with it. Local Notifications appears to be simply a way to schedule a future notification to the user, who can then choose to switch-back to the app. Mea culpa. But it looks like if you have an audio, GPS, or VOIP app, you really do get true background processing. As ScaryRobot has pointed-out, these categories are arbitrary and artificial. If your app does these things, and does background processing, it will be approved for the App Store. If it doesn't, it won't.
Fortunately, my interest is in GPS apps. Specifically, GPS apps that would only be practical if running constantly as you move around, while allowing the user to work with other apps. Check.
Those who are interested in understanding background processing should read and re-read his post. Non-developers are reading between the lines in the presentation and seeing restrictions that aren't there. Developers (at least, experienced developers who have written code for background processing) no doubt have already read the documentation and are shaking their heads all in the same direction.
If your information is just based on speculation, then what makes you think that my information is completely wrong?
Do some Google searches with relevant keywords. You might find some stuff has leaked onto some blogs. (Like an overview document on background processing.) This supports (most of) my speculation.
It does appear that an app will have to be GPS, audio-playing, or VOIP focused to be approved for backgrounding right now. But there is nothing faux about it. There are going to be some fine-line judgements made in the App Store approval process. For example, is this app really a GPS or audio app, or is it gratuitously including GPS or audio functionality in order to slip-in some other background processing?
ScaryRobot's information appears to be based on the same source as mine.
Wrong.
Until it hits a "low water" mark and needs more filled audio buffers. At which point it wakes up the app to supply the buffers from "wherever". The OS can't guess what comes next. The app has to provide it.
BTW, this is just how the audio system works - in any version of iPhone OS. The only difference is that now you can have this process continue while the app is in background.
Anyway, I think this discussion has gone as far as it can without straying into discussing NDA material. Ya'll will have to wait. Looks to me that the ball really is in Apple's court and restrictions are policy-related rather than technical. That's my take, anyway, and time will tell. I haven't seen anything non-policy related that makes me unhappy.
Are your sources secret? Link?
Wait, how is that 180 degrees different than what I said? It's the same, except I only considered streaming music (where the server would decide "what comes next") and not local audio.
What part of "leak" did you not understand?
Leaks, alas, come and go.
All things come to he who waits.
you have to remember that iphone os 4 only exists as a developer beta.
and the iphone os 4 event was geared towards developers and techies.
there is a difference between a task and an app and the people the iphone os 4 preview was intended for should know the difference.
if you claim the dock is a task manager then where is the icon that represents the bluetooth radio? or the gsm module?
someone mentioned the activity monitor. that would be the task manager steve was referring to.
The process itself is never asleep, though, as far as the OS is concerned. It can continue to do whatever it wants while the audio is playing.
Because it can't really work the way you're describing. With, say, VoIP... iPhone OS doesn't have native support for the Skype protocol (and every other VoIP protocol anyone ever might want to create an app for). Code from the app has to be executed on a nearly continuous basis; things can't just be handed off to some generic OS process.
We weren't talking about VOIP, we were talking about audio. Apple definitely knows how to stream audio.
But they don't know how to guess what audio you are going to send it next. The OS doesn't understand "play the Star Spangled Banner"...
While I haven't done audio programming on iPhone OS, I have on Windows (device drivers) and Linux (speech-to-text and text-to-speech). What you are describing is impossible, or at least impractical.
Under the scenario you've described, an app that plays a stream from a server would have to first download - not just the ENTIRE song you want to play, but the next one after that, and.... (at least everything that is to be played until the user decides to put the app back in foreground - which is when?) and send that in one big-ass buffer to the OS. (Or a bunch of little ones, if you like).
All modern audio systems work by having a ring buffer in the OS that is constantly added-to by the app that supplies the audio. In some APIs, you have to maintain a process or thread that goes to sleep when the ring buffer is full, and wakes back up and provides more audio when the buffer gets to a low-water mark. Alternately, the OS can make a call-back into the application when it gets to low-water.
Your solution simply can't work, and Apple isn't that stupid.
This gets REALLY interesting when you want to stream a real-time news show. Especially breaking news. Figure that one out, and we will award you a special Genius Award. All I want in exchange for the Award is to know who will win the World Series in 2016. I want to get my bets in early.
I may be wrong about whether the audio process belongs to Apple or the app, but the situation you described is not the only way to get audio from a server. The local app does not need to request each song individually. It could simply point to the location of an audio stream on the internet. Safari can do it already.
Something like Pandora could login to an account to create a personalized stream. The next song is determined by the server, not the local app.
1. Stream live audio from cnn.com/liveaudiostream.m3u (or whatever)
2. News breaks
3. You here it.
Not really genius-worthy.
This probably would not work. When OS maintains VOIP connection for your application it probably maintain specific type of connections. Remote desktop will use totally different protocol and when OS will try to maintain a VOIP connection to a remote server/computer this server will not like your VOIP
Will 4.0 truly multitask? Yes, but only some apps. Pause state and resume is not true multitasking. However, something like Pandora running in the background is. Its not the same kind of multitasking you can do with an Android device where I can have things downloading from the market, streaming music, IMs and web browsing all at the same time. We will see soon what 4.0 can do though.
You are.
For specific, supported protocols/audio formats. But there's no such restriction.
See above.
What about a text-to-speech app? The TTS engine is built-in to the app. How does the OS guess what is supposed to be spoken next? And turn the guess into audio?
What about an app that alters your voice or music in some way - applies a filter?
That's genius-worthy.
I may be wrong, but you actually agreed with that claim.
https://forums.macrumors.com/posts/9640497/
Fantastic, but I was only pointing out how music could be streamed from a server with intervention of the third-party app, which you claimed is "impossible, or at least impractical." But it's actually easy.
I made no claims about that. As I admitted, I shortsightedly only considered streaming music.
Ditto.
Your the one that claimed genius-worthiness, not me.
Sometimes I look up songs I want to hear in YouTube. Will I be able to run YouTube and listen to the song while using other applications on the phone?