[Macworld]

Post your comments for iPhone SDK: One at a time? here

[cpoff]

Let this be a challenge for developers to come up with the ultimate One True App. ;)

One appllication to rule them all!

[MacTechAspen]

Macworld said:

Technically, you'll be logged off of AIM, and any messages sent your way won't arrive.

Not a great example, since when you are logged out of AIM messages can be sent to you via SMS. This is a setting in the desktop version of iChat now.

That said, you make very valid points. The iPhone remains a limited platform.

It certainly seems possible (I am only speculating) that there are only so many threads the iPhone can handle at a time. If this is the case then Apple may be trying to protect the integrity of the platform by ensuring that mail and SMS always have the resources they need, no matter what.

Much has been made about the fact that OS X is running on the iPhone. While this is a wonderful thing, it does not mean that the entire robust OS is on there. It is still just a phone.

5 years down the road the iPhone may well develop into the mobile computing platform we all hope for, but for now I am just happy that we are about to get to do even more with the phone than we can now.

[JoeC]

Why don't you wait for that clarification from Apple before you spread panic about it? I know Apple can be a pain in the butt about clarifying such things, but until we know for sure exactly how literally we're supposed to take the Interface Guidelines, it's a little premature to assume that apps won't BE ABLE to run in the background. Remember, these are guidelines, not hard rules. There's a big difference between Apple advising you not to run apps in the background, and Apple blocking that ability. It certainly doesn't impose that limitation on its own apps, or else SMS alerts, the phone app, etc. wouldn't be able to function properly.

[bslayerw]

According to the SDK documentation and the "Getting Started" videos "one at a time" means that the OS will quit your application when the user clicks the home button, a call comes in etc. Your application has 20 seconds to save it's state (optional) and shutdown. After 20 seconds your app will be "killed".
The more I go through the SDK documentation and videos the more useless the SDK becomes. For example, as it stands now any data you create using your app on the iPhone is sandboxed and cannot be placed anywhere else on the system. This wouldn't be so bad if you could at least synch your data but you cannot do that either. Someone please correct me if I am wrong... I reeally want to be wrong.

[bslayerw]

the clarification is in the SDK documentation and Getting Started Videos.

https://developer.ap...ne/index.action
Watch "Key Practices for iPhone Application Development" around 4:31 into the video.

[ahalvor]

....and please check your facts. Since 2004 (eons in internet age) you have had the option to not be logged of when closing an AIM client. Come on Rob....research!

[tazzben]

Hi Rob -

My company is making an iPhone native version of Heap CRM that syncs with the web version, so this SDK has taken most of my attention for the last few days. I have a few notes. First, there is an on exit condition that allows you save state allowing you to give the impression that the application continued exactly where it was left off.

Second, the iPhone has extremely limited ram in comparison to a desktop. Knowing that no other application is running does allow me to use ram for functions that I think are important while my app is running that I may not be able to do when other apps are consuming ram. That's not to say that you can exactly be sure how much ram is in use based on that, but there are things that I simply would not be able to do if ram was being consumed to a great degree by other apps (the sync process comes to mind).

Third, I also think there is principle at stake here. Constraints are good. It makes developers more creative in coming up with better solutions when the obvious solution is not allowed. I certainly wouldn't say all, but some applications on the desktop certainly could operate without always being on. But a look through most peoples login items will show a great number of apps that chose to operate (at least to some degree).

I think in the last few years SOME developers who write "desktop" (as in no server interaction where resources are limited) applications (both on mac and windows) have become a bit lazy. They have TONS of ram, TONS of cycles and gosh why not use them. For these people I think some good old constraints are a very good kick in the pants. (Yes, I'm one of those freaks that wrote software back in the 640K DOS days, so I don't have any sympathy)

If they want to remove the "one at a time constraint", I would ask apple to not even consider it for 6 months, give the developers time to try to come up with more creative solution (this goes for me too, it would have been really simple to just have Heap sync on a schedule). Second, they would have to prove to apple that there is no other way. And third, that when the app is in background mode, it is using an incredibly low amount of ram.

[tazzben]

bslayerw said:

According to the SDK documentation and the "Getting Started" videos "one at a time" means that the OS will quit your application when the user clicks the home button, a call comes in etc. Your application has 20 seconds to save it's state (optional) and shutdown. After 20 seconds your app will be "killed".

The more I go through the SDK documentation and videos the more useless the SDK becomes. For example, as it stands now any data you create using your app on the iPhone is sandboxed and cannot be placed anywhere else on the system. This wouldn't be so bad if you could at least synch your data but you cannot do that either. Someone please correct me if I am wrong... I reeally want to be wrong.

Your wrong. 1) you have access to a SQLite database on the device. 2) We've already go our app to sync with Heap CRM Sync Service

[bslayerw]

[quote name='tazzben']
>

bslayerw said:

> According to the SDK documentation and the "Getting Started" videos "one at a time" means that the OS will quit your application when the user clicks the home button, a call comes in etc. Your application has 20 seconds to save it's state (optional) and shutdown. After 20 seconds your app will be "killed".
>
> The more I go through the SDK documentation and videos the more useless the SDK becomes. For example, as it stands now any data you create using your app on the iPhone is sandboxed and cannot be placed anywhere else on the system. This wouldn't be so bad if you could at least synch your data but you cannot do that either. Someone please correct me if I am wrong... I reeally want to be wrong.

Your wrong. 1) you have access to a SQLite database on the device. 2) We've already go our app to sync with Heap CRM Sync Service

Could you please point me to the documentation for that? I cannot find it anyway. The docs say you can use sqllite in your application but nowhere can I find how to access some sort of global database. Here's a use case that might explain the pain. Say you've recorded some audio from the mic how do you get it into iTunes? How do you synch it with your desktop? WIFI? Bluetooth? Does it automatically synch with iTunes when you synch your phone?

[cweber]

We have to remember that this is a beta program. I am sure part of the beta process is tracking what is happening out there, how people are responding to the SDK, and working on features developers request most often or most fervently. Which isn't to day Apple will do everything we ask for, but they are certainly not dumb and completely unresponsive.
I do think, however, that handheld devices as envisaged by Apple will require significant recalibration of developer's mindsets. Database storage instead of files, for instance. Stateful apps which can stop and start instantly, for another.
We don't know whether SQLite makes access to data private to each application, or whether that would be one (safe?) avenue for interprocess communication. Likewise, data syncing can be accomplished via storage in the cloud, and on the iPhone apps can pass URLs to each other.
In the end, developers with new, unconventional ideas will win, and those who are wedded to "desktop think" will stay behind. That's probably a good thing.

[tazzben]

I don't know exactly what you want me to point you to, the documentation points a number of ways to do network conversations (almost exactly as you do on the desktop). It also has some great services to deal with XML. I guess if you are asking if apple wrote a sync system for you no they didn't you have to write it your self. But that's probably a good thing.

[tazzben]

SQLite databases are private. However you can register protocols and send data that way. So just like "mailto" opens e-mail you can register "myapp:" and send data between apps.

[bslayerw]

tazzben said:

I don't know exactly what you want me to point you to, the documentation points a number of ways to do network conversations (almost exactly as you do on the desktop). It also has some great services to deal with XML. I guess if you are asking if apple wrote a sync system for you no they didn't you have to write it your self. But that's probably a good thing.

Yes I know I can open TCP/UDP ports, connect to other systems using Bonjour etc etc. I know I can parse/create XML/XSL. So what you're saying is that it's a good thing if everyone wanting to synch/backup data with their iPhone apps and their desktop needs to write their own synch services (and we can't use usb)? Maybe for the application you're creating writing your own synch services to somewhere in the cloud is fun, exciting and relevant.