im not going to deny that the old nokia s60 devices (such as the n70) had serious memory issues. im not really sure which n95 you are talking about (because there are now 4 versions). the n95-1 is the original and has 64mb of ram. the new n95-3, n95-2 and n95-4 all have 128mb of ram (just like the iphone) and the n95-1,2,4 have demand paging which further improves memory management. it is very easy to have multiple applications open at once (such as web browsing and music) and i have never had my n95 crash.
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.
iPhone SDK Limitations: Multitasking, Java, Emulators
- Thread starter MacRumors
- Start date
- Sort by reaction score
im not going to deny that the old nokia s60 devices (such as the n70) had serious memory issues. im not really sure which n95 you are talking about (because there are now 4 versions). the n95-1 is the original and has 64mb of ram. the new n95-3, n95-2 and n95-4 all have 128mb of ram (just like the iphone) and the n95-1,2,4 have demand paging which further improves memory management. it is very easy to have multiple applications open at once (such as web browsing and music) and i have never had my n95 crash.
You just cant compare the mobile devices like iphone/touch to desktop systems. desktops have lots of memory, large screens to allow you to have a dock & overlapping windows so that you can work with multiple windows, larger power battery, more processing power, etc etc...
every device needs to work inside its limitations and intended purpose. On a desktop you can do a lot more than you can do conveniently on a phone, hence the limitations on the background processes makes sense to me.
Hmmmm, I wonder...
launchd anyone? That is specifically designed to listen for things on your behalf and launch processes as a result (amongst other things it's responsible for on OS X.)
So, if there ends up being a way to register interest in things, and launchd takes care of it, then we're good, right? OK, there's some details to figure out, like who "badges" the app icon with how many new messages you haven't read (in AIM for example.) but these things can be figured out.
As with all things, I expect the API and OS to evolve. You couldn't do a bunch of stuff with OS X 10.1 that we take for granted with 10.5. Over time I believe this will evolve.
Why people insist on things being perfect right off the bat I have no idea. Feedback is a wonderful thing and personally I'd rather they give us what they have given us now, and we provide feedback, rather than wait another 6 months and have them guess what we care about. Some of the feedback will be used, some will not, but that's up to Apple. It's their product. They don't add things to OS X just because someone asks either.
I believe market forces will be effective here, if not as instantaneous as some people would like.
be well
t
If there's an MSN Messenger app, I sure hope that would be allowed to run in the background, and a counter in the top bar (where the time is) to tell you if you have a new message.
Well, some apps do run in the background... I just bought an album from the iTunes store (thru WiFi) and began playing the first song & manipulating the playlist while the others were downloading in the background...
The whole process was a great experience... no fuss, no muss, no bother!
...Gee, just like a Real Computer!
Just to point out that these problems existed before the v20 firmware release for the N95-1 which fixed them by improving the memory management. I have one and it's much more responsive and hasn't crashed since the install a few months back.
You did read through the license agreement when you downloaded the SDK, didn't you?
Push email requires background task in device?
The iPhone is going to have push email, where email messages are sent from the server to the iPhone (presumably) whenever they are available to be sent (and, presumably, whenever the iPhone is within range of cell or WiFi signals).
Doesn't that mean, by definition, that the iPhone must have some background task always running to "listen" for the mail server?
Wouldn't that be a drain on the iPhone battery?
If less than that, say, the phone only listens when active, then what's the big deal... just run a background iMap email client on the iPhone, starting when you "slide to unlock".
Here's a, somewhat dated, explanation of how MS defines push email:
http://vowe.net/archives/006589.html
What am I missing, here?
The iPhone is going to have push email, where email messages are sent from the server to the iPhone (presumably) whenever they are available to be sent (and, presumably, whenever the iPhone is within range of cell or WiFi signals).
Doesn't that mean, by definition, that the iPhone must have some background task always running to "listen" for the mail server?
Wouldn't that be a drain on the iPhone battery?
If less than that, say, the phone only listens when active, then what's the big deal... just run a background iMap email client on the iPhone, starting when you "slide to unlock".
Here's a, somewhat dated, explanation of how MS defines push email:
http://vowe.net/archives/006589.html
What am I missing, here?
Sure i want to have as many apps "open" as possible so i can flick between them without noticing the transition.
What's more I want Apple (or any underlying Platform provider) to go "hard ass" on the Developers of these applications so they all play nice and not slow down my system.
It sounds like that is what they are doing.
Forcing Developers to think like it's a limited device and really thing about how they do things not just except that the way it was always done is the way it should be done now.
Apple approach encourages me that the device with apps will be good.
The reaction here on MR makes me think apps will need to be handpicked and treated as guilty until proven useful.
Edit: quick read says people are right Launchd is the way developer should be thinking about "background" tasks you can set it to watch a socket but also once you register your app to that socket a flag in your plist also registers you for Bonjour services.
You can set for watched paths if looking for file changes.
I see no reason to use the same system to pass messages between apps as well, so you can quit one app passing a message to start the next app if you created a suite of iPhone Apps
Yes and yes. By an amount measured and controlled by Apple; and possibly even tested by AT&T to make sure that they don't get in the way of incoming/outgoing emergency phone calls, thus creating a liability issue.
This nifty little device replaced my old cell phone and my aging iPod. Now I would like to see it replace all of my
remote controls sitting there on my coffee table. ... Maybe with a dongle attached to the iPhone or Touch that would emit an InfraRed signal, or just for the iPhone with a bluetooth accessory placed near the components that are to be controlled.
I really hope Apple opens up the dock connector to at least large license-paying third party companies for custom accessories. I have seen some 3rd party devices being demoed on hacked Iphones on Youtube (like the Belkin), but I'm unsure of and doubt that any company has been in offical contact with Apple on these yet. I would love to see a tiny GPS module that plugs into the dock connector. It's a shame Apple didn't put in a SiftStar III in the iPhone. That would make it just that much better.
Also, "cisco", That is definitely a great Idea. I recently bought a Logitech Harmony remote, which is great, but they start at $100 and the new generation one is $249. With an iPhone software application and a tiny IR insert, Logitech could use their existing web infrastructure that contains all the codes for every consumer device to put together a kickass system for an iPhone universal remote. Even better I guess would be your idea of a bluetooth connected IR module that could sit by your entertainment center rack/cabinet, allowing the dock connector on the iPhone to remain unused. I wouldn't doubt that they may be looking into something like this.
Even better, used in this way, the iPhone could also control a Playstation 3 or other device that only has bluetooth remote and no IR.
It doesn't take much though to come up with other great uses for the dock connector... cross your fingers
Yeah, smart-guy, the Air does use a FORM of flash in it's SSD. But all flash memory is NOT made equal; there are many different types of flash memory, different architectures, different controller types, different firmware, etc. The flash memory used in solid state disk drives (SSD) (such as in the MacBook Air) is high-quality, fast, and is specifically manufactured to withstand tens of thousands of read/write cycles.
Flash used in USB sticks and memory cards is much lower quality with respect to speed, resistance to wear, and manufacturing tolerances.
The flash used in iPhones and Ipod Touches is probably somewhere in the middle, but closer to a memory card than an SSD.
Just to be sure.. It's 128MB RAM and a 620Mhz ARM
It's mostly likely not about you at all, since you may not fit their target market demographics. It's about clueless users who may have no idea why their cell phone has slowed to a crawl when they need to make an emergency phone call, and blames this on Apple and/or the carrier.
You might also want to look at how much memory and swap space you have configured on your Mac, reconfiguring it way down to the same amount you get an iPhone, and see how you like saving yourself from the responsiveness of your thus configured system.
Notification Layer in the core OS
After thinking about this for awhile, It seems like the best idea to make this work is something similar to what "SuferFromUK" is saying above. Apple should have a "Notification layer/service" in their API that apps can register to for event handling, both for internal phone/OS events and for network events. These could then be handled by a small, very optimized, Apple written daemon running in the core of the OS.
For network events, I'm assuming in most cases like instant messenging, these apps currently work by having a background process listening on an open TCP or UDP port connected to the server, whether over WiFi or EDGE. So if you had multiple applications that needed this service, they would register with the Notification Service and the notification daemon would alert the apps whenever data came in on the TCP/UDP port they registered.
For phone/OS events, it would work the same way, but instead of apps registering for network data events, they would register for events such as "received call", "placed call", "txt message received/sent", "picture taken", etc and the notification daemon would alert them when these happened.
Can someone experienced with OSX programming / Phone app dev comment on this?
After thinking about this for awhile, It seems like the best idea to make this work is something similar to what "SuferFromUK" is saying above. Apple should have a "Notification layer/service" in their API that apps can register to for event handling, both for internal phone/OS events and for network events. These could then be handled by a small, very optimized, Apple written daemon running in the core of the OS.
For network events, I'm assuming in most cases like instant messenging, these apps currently work by having a background process listening on an open TCP or UDP port connected to the server, whether over WiFi or EDGE. So if you had multiple applications that needed this service, they would register with the Notification Service and the notification daemon would alert the apps whenever data came in on the TCP/UDP port they registered.
For phone/OS events, it would work the same way, but instead of apps registering for network data events, they would register for events such as "received call", "placed call", "txt message received/sent", "picture taken", etc and the notification daemon would alert them when these happened.
Can someone experienced with OSX programming / Phone app dev comment on this?
Synching is a huge issue for us, since we focus on mobile productivity apps that require synched data. We're looking at supporting OTA synching at first and then as the SDK evolves adding support for other approved synching methods (if they come out).
You want a Tasks app - look at http://www.pocketinformant.com/pocketinformant - its what we want to port to the iPhone. We have hit a few issues, not technically, but legal agreement-wise with the SDK to do this. But we're hopeful.
well let's hope in next generation iphone apple will use the same quality flash other smartphone manufacturers are using currently. after all apple is the only one having this silly restriction and if they can remove it by simply not cutting corners in flash quality they definitely should.
If the next version of the iphone has a faster processor and more ram will people write apps that will not work on the current generation iphone.
Well, that's simply not true. Manual memory management and "out of memory" problems are the flip side of the coin.
Nothing's stopping you. The iPhone does multitask, but requiring save state and exit promotes good programming habits. There's no difference to you, the user, whether it stays running in the background or not (except realtime data like file downloads and AIM), and in order to promote good automatic memory management, programs have to save and exit when instructed to do so by the OS. Allowing programmers to ignore that call to shut down would not be a better approach.
With the exception of dedicated applications not being available, you can do that now without a hitch. You seem like you don't have an iPhone and that you're somewhat confused about what this restriction means to you. You can still "multitask" by switching applications and having them remember their last active state. There's not really a downside for this, except for things like IM...and there's no technical roadblock to doing so, as the iPhone already does multitask with some of its Apple applications.
Yes. Mail already does this for interval-based email updates.
That the iPhone isn't allowing third-party applications to ignore memory management and OS calls to shut down. This doesn't mean that the iPhone doesn't multitask. It just means applications can't assume they can run for as long as they want in the background.
Well, it does, and there's a huge number of reasons not to let developers monopolize background resources. As a Windows Mobile user, it's not the path to stability.
This one's totally out of left field. The flash memory used is no lower in quality than any other smartphone. It is not an SSD, and no device has SSD-quality flash in it, except in, well, an SSD. More importantly, flash memory has exactly zero to do with multitasking in the OS.
I have an ipod touch, so same software. What worries me is how the software functions now under the jailbreak system. When most software save states, they seem to go back to a screen where you have to choose the data set you would like to work with or something like that. That can be taken care of with programming changes, but is still a concern. A native apps such as the addressbook (look at a contact's info, switch to a different app, come back, and you're at the selection screen) and calander (try to edit an entry, switch apps without saving, then try to come back.... poof....) behave in a manner which worries me. iDic is an AWESOME dictionary app, but if you're looking up a definition and go back to the home screen, come back and your search if gone....
Notes seems to do OK with saving state...
I remember people arguing their heads off against palm for not having true multi-tasking but saving to states, me being one of the people for multi-tasking.
Here's a little thing to take note of. windows mobile's X button minimizes by default. But I downloaded a program for my phone which closes progs by default when the X is pushed and only minimizes progs when the developer puts a flag for minimize in there. Surprising how much more stable WM is when you do that. Almost no resets (except for crappy progs that springs up on any platform, even Mac, that you just learn not to install by experience...)
What I want to know is when we are going to hear back on our developer program applications, I was able to submit mine and download the sdk fairly quickly after the announcement..
Haven't heard a word back, I don't know what the decision process is, I don't want to be stuck with just the emulator until June!
Haven't heard a word back, I don't know what the decision process is, I don't want to be stuck with just the emulator until June!
I'm not so sure that this hasn't been said already, but there has been mention of "well maybe for [insert example big company like AOL for AIM] that Apple could be petitioned to make an exception to the rules for."
It seems to me that this is a simple business proposition. Apple has presumably made this SDK as a delicate balance between openness/ability for the developers and security/need for review on apple's end (avoiding a bottleneck or huge delay between app submission and public release). It seems to me that apple should, and they would need to make it official to be fair to everyone, make a clause that says if you want to break the rules, apple would have to review your app more thoroughly. Apple would take a quick look and then bill the developer for the time needed to thoroughly review the app. There would need to be a steep starting price to scare away menial stuff, but it would make sense for Java and AIM.
It seems to me that this is a simple business proposition. Apple has presumably made this SDK as a delicate balance between openness/ability for the developers and security/need for review on apple's end (avoiding a bottleneck or huge delay between app submission and public release). It seems to me that apple should, and they would need to make it official to be fair to everyone, make a clause that says if you want to break the rules, apple would have to review your app more thoroughly. Apple would take a quick look and then bill the developer for the time needed to thoroughly review the app. There would need to be a steep starting price to scare away menial stuff, but it would make sense for Java and AIM.
I don't understand any of y'all who say there's no need to run stuff in the background. On my S60 I run stuff in the background constantly. Seemingly silly things like the stopwatch; why can't I time something while I go about my day, take calls, or browse the internet?
And multithreading works fine on the S60. I use an N75 (very little memory compared to an N95), still with the stupid AT&T package on it, and it routinely runs 5-6 apps. Many of which are actually running (i.e. not idling) at the same time.
These /are/ little computers, not just phones with fun extra features.
And multithreading works fine on the S60. I use an N75 (very little memory compared to an N95), still with the stupid AT&T package on it, and it routinely runs 5-6 apps. Many of which are actually running (i.e. not idling) at the same time.
These /are/ little computers, not just phones with fun extra features.
Well said and a VERY VERY important point which seems lost in the forums.
One of the best posts I have read in a long while.
Why do you all think that?
I have a G3 iMac with 300 MHz , 128 MB and a 10 GB HD. A modern iPhone will outperform this machine in many ways. Everyone is and was allowed to code for it and I did use a lot of third party software (including free). It never got screwed up anyway.
They should just include an emergency boot loader in a ROM that cannot be overwritten and that allows you to reinstall everything via USB easily if you really are in serious trouble. But I think this will rarely ever happen.
Christian
Because background apps on any other Mac cannot get your GPS location. They also can't steal any of your personal information such as SSN which is connected to your iPhone via AT&T account. iPhone are NOT computers as much as people try place them in that category. Therefor they should be treated as such. Development for Macs will and should be different than development for iPhone. And it WON'T EVER be open.