macOS Background tasks with iPhone SDK?

[arn]

If anyone's had a chance to look through the iPhone SDK documentation yet... can someone comment on the possibility of a background task to alert you for new IM's, because based on this description, it appears the AIM client itself can't be running in the background

http://daringfireball.net/linked/2008/march#fri-07-iphone_hig

Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. It’s important to make sure that users do not experience any negative effects because of this reality. In other words, users should not feel that leaving your iPhone application and returning to it later is any more difficult than switching among applications on a computer.

 

[Voidness]

I also noticed that while reading the iPhone SDK documentation, but I still haven't read it in-depth. Apple's own applications seem to be able to run in the background (Safari loading pages, the iPod application playing music, etc).

It would be pointless if the AIM client can't run in the background. There must be some kind of solution.

 

[arn]

I also noticed that while reading the iPhone SDK documentation, but I still haven't read it in-depth. Apple's own applications seem to be able to run in the background (Safari loading pages, the iPod application playing music, etc).

It would be pointless if the AIM client can't run in the background. There must be some kind of solution.

yeah... that's what I'm thinking. I mean if there are hooks for small background tasks or some sort of alert system, then it seems like you could get around it reasonably... but wanted to get information on that, as some are jumping to conclusions already on this.

arn

 

[EnderTW]

I strongly believe that the apps demoed at the SDK event are considered by apple as "first party" applications.

Steve said that everything you saw today will be available to you.

It does suck that you can't switch between third party applications, a huge step backwards. But I don't think you can run a Instant Messaging program without being able to go back to the home screen. That's just retarded beyond belief.

I really hope Apple doesn't make a stupid decision like that.

 

[EnderTW]

Thinking about this though .. multi task could be done .. fakely.

For apps that do not require an active internet connection like an IM program, like we'll use that Photo Editor app that was demoed at the sdk event. The one with Photo Booth like effects.

What if .. you saved all the current data into a SQLite table, so user A has a photo open and pinched his nose to the right.. well when the user hits the home button, the program SAVES everything into a temporary table, all the variables for the methods are saved at the current state.

So user A opens his email.. decides oh ok, I am going to go back to the app, goes back to home screen and clicks his app. App opens, immediately accessing the previous saved state, so it looks as if you didn't close the program, and it was running in the background.

There are many hacks and tricks you could do as a programmer to get around the background task need.

I look forward though to see how Apple and AOL worked out their app. There must be some sort of daemon running in the background waiting messages.

 

[kainjow]

What if .. you saved all the current data into a SQLite table, so user A has a photo open and pinched his nose to the right.. well when the user hits the home button, the program SAVES everything into a temporary table, all the variables for the methods are saved at the current state.

So user A opens his email.. decides oh ok, I am going to go back to the app, goes back to home screen and clicks his app. App opens, immediately accessing the previous saved state, so it looks as if you didn't close the program, and it was running in the background.

Read the docs. In short, that's pretty much what you're supposed to do

 

[Voidness]

Read the docs. In short, that's pretty much what you're supposed to do

True, here's what the iPhone SDK documentation has to say:

In addition to saving out changes to user data, you should save out any application state information that is needed to return the user to the same place in your application when it is relaunched. Returning your application to the same state gives users the impression that your application never quit and makes it easier for them to pick up where they left off. Forcing users to navigate through the same set of screens each time your application launches is a frustrating experience.

I've been reading the SDK documentation further. I still haven't come across anything that would allow third-party applications to run in the background in some form. Everything I've read up to this point indicates that it's not possible.

 

[iSee]

I think that quote about only one app running at a time was directed at apps. I don't think it's relevant to background tasks (aka daemons).

I haven't found any documentation on daemons yet. It might be that they work pretty much the same way as they do under OS X--either as launchd daemons or forked from a startup script, etc.

I suppose Apple might prevent this in approved apps since any performance impact will affect the entire iPhone experience. Hopefully I'll have some time this weekend to try some of this out and read further into the docs...

 

[Voidness]

I think that quote about only one app running at a time was directed at apps. I don't think it's relevant to background tasks (aka daemons).

That thought occurred to me too. I also haven't found any documentation on daemons, yet.

Too bad I can't try out the SDK at the moment, as I don't have my MacBook Pro with me. I'm stuck with my iBook.

 

[Sean7512]

I have wrote an IM application before, and I immediately came up with a POSSIBLE solution, but I am unsure that it would work on the iPhone.

The AIM server will always know how to contact your iPhone once it is signed on. So if the AIM server sends out a presence packet, keep alive packet, or an IM packet to the iPhone, the OS should handle the receiving of data through the socket that was opened during logon. Ok, thats all good, but if the app can't run in the background, then that data would eventually be flushed out.

BUT...

I am unsure on how customizable Cocoa is (I've never used it). I'd imagine that there would be a way to write a custom event via a delegate, that should be able to alert the OS that it has received a packet pertaining to the AIM app. At this point, your delegate may prompt the iPhone to temporarily freeze, and display a MessageBox window saying something like, open AIM or close (just like the sms notification)...If the user ignores it, before focus is returned to the app which the user was using, the data packet received should be added to the appropriate data structures (for messages, etc). Then next time you open the AIM app, all of your information should be there.


Now, I do not know how customizable the Cocoa event system is, but this is the approach I used when programming a Jabber client via C#.

Hope this may help some!

Sean

 

[kmcrawford]

launch deamons to accomplish background tasks

I was attempting to launch a deamon to accomplish background tasks using popen on the emulator I kept getting (plist) "file could not be found". I later found that the popen commands executed on the emulator where being executed against my mac not the emulator. I confirmed this by doing a "ls ./Applications" and I was getting the results of all of my Applications I currently have installed....

 

[jakaj]

I don't doubt that it will be possible to do it on the iPhone, but if Apple says "no", then it's probably a bad idea to do it (since they will just revoke your cert or event disable your app immediately).