iOS annoyance

[Daveoc64]

Ok, Daveoc64, since you are the expert and I am not.

Explain to me how the iphone is remembering what state the app was in (for the ones it just remembers the last state it was in before you switched to another app) if it is not using "memory" or CPU to do that? Far as I know it doesn't use your storage memory for anything but storing stuff so the only thing it could use is the RAM or CPU.

But maybe since I don't develop I am missing something or maybe you can correct me on my understanding of how it works?

Seems to me it's common sense for some one who uses a computer that if it is going to remember what state your app is in, it has to use something to do that. And for the ones not actually running in the background but support multi tasking, the whole idea was the phone would remember what state you left them in (but wouldn't run them to save on battery since you didn't need them run in the background). ANd that is the advantage of not closing them is that you can go right back to where you were.

Also, then explain to me why my phone runs better when I keep the amount of tasks on the background list down (by actively closing them) rather than never closing them and having a ton on the list. Sure, you could say maybe one of those apps is not working right but that goes right into the you are better off keeping most your apps closed that you don't need rather than letting the iphone do it cause one might not be as well coded as it should (and it's just simpler to keep only what you need backgrounded than figure out what. I do know Assassin's Creed sometimes eats battery if you don't close it manually. I think it's a bug of some sort but if I leave it running, eventually I'll come back to my phone sucked of battery when I hadn't used it the whole time. I don't seem to have that issue when I make sure to close it).

And according to this app I just downloaded that tells you what resources are being used, my apps in the background are using memory (perfect web browser - prolly cause i have a bunch of tabs open - and the app store seem to use the most of the ones that were backgrounded at the moment when I looked. I only had 4-6 apps backgrounded and most of my RAM actually was already taken up according to it).

Memory is being used, that has been established already. But using memory is not normally a bad thing.

All modern operating systems (Mac OS X, Windows, Linux, iOS, Android etc.) manage memory in the same way.

When you close an application, it is not totally purged from RAM. The OS "caches" it in memory so that if you open that application up again, it can be loaded from RAM which will be much quicker.

iOS works a little differently in that when you "close an application" (by moving to the home screen), the App isn't actually closed, it's suspended.

In the suspended state, the App is cached in memory, but it cannot run any code (i.e. use any of the CPU). iOS only allows apps out of the suspended state in the few scenarios I outlined in my earlier post.

With all of these OSes (iOS is no different), it'll remove things from the memory to clear space if it is needed.

 

[Daveoc64]

Per a developer he sent me this quick bit:

"when app is suspended, remain in RAM.....cpu usage is "near" to zero for them...

RAM will be released only when OS decide it...."

They still use a little cpu usage when suspended and they remain in RAM. Like I have been saying.

A developer just sent me this quick bit:

"CPU usage is zero in suspended mode".

I can make something up too.

 

[Daveoc64]

Rather than making something up, I'll stick with a quote from http://developer.apple.com:

Suspended - The application is in the background but is not executing code. The system moves an application to this state automatically and at appropriate times. While suspended, an application is essentially freeze-dried in its current state and does not execute any code. During low-memory conditions, the system may purge suspended applications without notice to make more space for the foreground application.

Link

 

[chrono1081]

WOW all this fighting!

Daveoc64 is actually the most correct. Its all in the Apple developer documentation. An app has different states that it can go into when moved to the background. These states determine how the app works while in the background. These states also determine who is correct.

I'm not going to go into a ton of detail here because I simply don't feel like typing it all, but depending on how the app is made, how much free ram the system has, whether the app has long running tasks in the background, and whether the app is in the suspended state or not.

In short, if your app is something like a music player, something that uses GPS, or voip, then yes, you will be using ram because those features need to be running.

If the app opts out of multitasking completely then no ram is being used, even if the app is in the multitasking bar. It is using absolutely no ram and is purged from the system memory.

Now here is where things get tricky. If your app supports multitasking but does not need to execute code then it goes into a suspended state where it could be stored in ram. If you have a foreground app or some extra background apps (background apps are different than suspended apps) then the suspended apps will be purged from memory.

Now, many people will say that apps in suspended state being stored in ram means Daveoc64 is wrong. Not true. In the developer documentation it tells you to ensure your program writes the state of the program to disk when entering the suspended state because it may be purged without warning from ram and needs to be able to be resumed if this occurs. This is exactly how multitasking works without using ram. This is actually the most common scenario and anyone who wants to try it can by writing a program that writes a log anytime the app is terminated by the OS. The state of the app gets written to disk and is resumed by the settings written to disk. The app was purged from ram, but iOS restores it by reading what was written to disk and the user is none the wiser.

I also just wasted 15 minutes digging through developer documentation but there it is. If anyone doesn't believe me then look up the iOS Application Programming Guide it will explain the different states and how to respond to them and how each behaves.

TLDR version: It depends on the app and how the OS wants to deal with it.

 

[nizmoz]

A developer just sent me this quick bit:

"CPU usage is zero in suspended mode".

I can make something up too.

Wasn't made up idiot.

http://www.iphonedevsdk.com/forum/i...stion-about-apps-memory-cpu-usage-iphone.html

 

[Daveoc64]

Wasn't made up idiot.

Might as well have been.

I love how you quoted the post where I quoted Apple and totally ignored that irrefutable evidence while throwing in an insult!

 

[nizmoz]

Might as well have been.

I love how you quoted the post where I quoted Apple and totally ignored that irrefutable evidence while throwing in an insult!

NEAR Zero. Not completely Zero.

 

[Daveoc64]

NEAR Zero. Not completely Zero.

So you're saying Apple's developer documentation, that companies like Facebook rely on is wrong, and a random person claiming to be a developer on a forum is right (posting without any proof)?

 

[nizmoz]

So you're saying Apple's developer documentation, that companies like Facebook rely on is wrong, and a random person claiming to be a developer on a forum is right (posting without any proof)?

Developers see what it uses in their apps that write them. They see the usage. Believe whatever you want from Apple but the developers WRITE THE APPS. Again now you are arguing with the facts. AGAIN. You are officially blocked.

 

[Daveoc64]

Developers see what it uses in their apps that write them. They see the usage. Believe whatever you want from Apple but the developers WRITE THE APPS. Again now you are arguing with the facts. AGAIN. You are officially blocked.

How incredibly mature, "I can't come up with a valid response so I'm sticking my fingers in my ears".

I suggest you look up the meaning of "fact".

 

[nizmoz]

How incredibly mature, "I can't come up with a valid response so I'm sticking my fingers in my ears".

I suggest you look up the meaning of "fact".

Why should I? You seem to know more than anyone here, the developers, Apple themselves, should I go on? Why even try to correct you when you just continue to argue and get the last word.

 

[chrono1081]

If you guys are talking about CPU usage for apps, then just like ram usage it depends on the app.

If an app is running in a background state, then yes, it uses CPU. That being said usually apps are only in their background state on their way to a suspended state where they do not use any CPU.

Background apps that would use CPU are things like voip, gps apps, internet radio, music players, things like that.

Many apps do not run in the background and therefore are only in the background long enough to save their states and be suspended.

When an app is suspended, it receives no events, and as stated above uses no CPU. The OS collects events for suspended apps so if they are reinstated the app receives the messages. This collection of messages is not the app using the CPU, it is the OS since its a built in feature for event handling in iOS.

 

[Daveoc64]

Why should I? You seem to know more than anyone here, the developers, Apple themselves, should I go on? Why even try to correct you when you just continue to argue and get the last word.

You never post facts to back up the things you post.

When I and others post facts you totally ignore them!

What part of that don't you understand?

If you are correct, it would be easy to prove. Your consistent failure to provide evidence from a reliable source strongly implies to everyone following this thread that you are wrong.

I on the other hand have posted many quotes and links to Apple's documentation, quotes from Steve Jobs and Scott Forstall (who is the Senior Vice President of iOS Software Development) and yet you claim all of these people are wrong.

You seem to think that one quote from someone on a forum is more valid than all of these first hand sources.

 

[taylortm]

He's Back!

Well, I'm SUPER glad that Dave is back. I was afraid we'd lost him.

Although Dave has cited copious amounts of credentials, I am still left wondering why he insists so much that he is correct when, in fact, he is not.

I'm sorry. I can resist the urge to flame no longer.

And, since Mr. Dave loves to "quote legitimate sources" so dearly, I'll take my shot here.

At this location, Apple's developer documentation (I think it's available to non-developers!) attempts to provide app developers some guidance as to what's acceptable and not acceptable for their apps to do while suspended. There are almost a dozen bullets. But there are two that stand out.

The first:

Avoid updating your windows and views. While in the background, your application’s windows and views are not visible, so you should not try to update them. Although creating and manipulating window and view objects in the background does not cause your application to be killed, this work should be postponed until your application moves to the foreground.

emphasis added by me

Clearly, iOS allows one to create, manipulate, and otherwise update views while in the background. We do it all the time. (We develop apps not intended for "general public" consumption. Rather some of our apps are intended more as "kiosk" apps where, if iOS would let us, they would be the only app running and we would disable the home button. They are typically deployed in physical environments where the users are not able to push the home button. But, if we take it out and pass it around for "show and tell," we require the views to remain fresh and up-to-date upon resuming the app.) We do this -- against Apple's general advice -- and it does everything you'd expect like slow down the foreground app and all that other lovely stuff. But we're not complaining about it. I'm just sayin'...


The second...

Do minimal work while running in the background. The execution time given to background applications is more constrained than the amount of time given to the foreground application. If your application plays background audio or monitors location changes, you should focus on that task only and defer any nonessential tasks until later. Applications that spend too much time executing in the background can be throttled back further by the system or killed.

again, emphasis added by me

Minimal work? How can that be? I thought that -- according to Mr. Dave -- NO work was serviced for backgrounded apps. Hmmmm... I hope I didn't just cause an aneurysm.


And, for fun, I'll throw in a third bullet:

Be prepared to handle connection failures in your network-based sockets. The system may tear down socket connections while your application is suspended for any number of reasons. As long as your socket-based code is prepared for other types of network failures, such as a lost signal or network transition, this should not lead to any unusual problems. When your application resumes, if it encounters a failure upon using a socket, simply reestablish the connection.

This one's going to be more fodder for Mr. Dave to interpret as he pleases. Admittedly, the prose is a bit loose here. However, I can attest (again, through direct personal/professional experience) that you can (and we DO) utilize network connectivity to send and receive messages while in the background. A more common example of this behavior is those apps that notify your friends of your real-time position. Even if your copy of the app is backgrounded, it (as Dave agrees) receives significant location changes. The kicker is that, once it receives it, it can "do other stuff." This other stuff includes forming and sending a network message to all your mates (as Dave might say) as to where you happen to be at the moment.


And, I'm sorry. I just can't stop here. I'm on a bit of a roll, I suppose. It seems Mr. Dave likes to freely interchange the terms "backgrounded" and "suspended." I'll admit my experience on this particular forum prohibits me from doing this super gracefully (as in, pretty), but here's a link that clearly distinguishes between the two states. (Look at Table 2-3... just below the anchor I've provided with this link.)

It's true, for SUSPENDED apps...

The application is in the background but is not executing code. The system moves an application to this state automatically and at appropriate times. While suspended, an application is essentially freeze-dried in its current state and does not execute any code. During low-memory conditions, the system may purge suspended applications without notice to make more space for the foreground application.

However, for BACKGROUNDED apps...

The application is in the background and executing code. Most applications enter this state briefly on their way to being suspended. However, an application that requests extra execution time may remain in this state for a period of time. In addition, an application being launched directly into the background enters this state instead of the inactive state. For information about how to execute code while in the background, see “Executing Code in the Background.”

once more, emphasis added

Seems our "mate" Mr. Dave should refer to that last section referenced by the above quote.

The bottom line (as I meant to conclude my previous post, Post #100) is this. Apple was initially (pre-iOS4) very reluctant to allow any backgrounding of any app (other than their own apps, like Phone, etc.) for the simple reason that it opens the door for bad user experience. However, with the advent of iOS4, the fine developers at Apple went to painstaking lengths to (a) somewhat limit what you can do in the background and (b) provide copious detail about "best practices" while developing apps that will "do things" in the background. So, they didn't provide us with "real multitasking" and all that. Rather, they did the Apple Thing and tried to give a large portion of the population the features they wanted (location awarenes, music players that run while you use other apps) while trying to achieve some balance and trying to maintain an overall good user experience.

In my opinion, they did a fantastic job. No single release of iOS is going to make 100% of users happy 100% of the time. When you consider that, I think most reasonable people would also tend to agree -- they did a pretty good job of striking that balance.

My crazy non-public apps are not the only ones that do resource-intensive things in the background. I also purchase a few from the App Store. And, while I'm not naming them here, the truth is I know that some apps are not good Resource Citizens. There are times when a background app is -- I don't know -- attempting to use the network and having trouble. Or is doing some other task in the background. During these times, my foreground app will sometimes lag or freeze for a second or so. (That's a long time, actually, to be sitting there wondering if your phone just crashed.) But it can and does happen.

Again, trying to get back to the spirit of the OP's question: the fact that iOS automatically sticks apps in the background is MOSTLY not a problem. But it can become a problem, depending on the particular apps you use. As suggested above, my "mates" and I have sort of a "known offendors" list. Sometimes, our phones bog down just a tiny (but noticeable) bit. When that happens, we purge the offender. And, while we're there, we just purge everything. (It's a cute habit of just tapping the screen where that right-most app in the tray always slides to. Takes about 5 seconds of tap-tap-tapping to clear everything out.)

This thread got jacked to a STUPID argument over the FACT that apps can (and do) run in the background... and use memory... and read/write to flash/disk... and make network connections... and... and... The bottom line is that this is not the issue. Apple did a FINE JOB striking a balance between "no backgrounding" and "controlled backgrounding." Apps still "do things" in the background. Memory is still traditionally managed in the background. Additionally, your app can be "jettisoned" whether you follow all of Apple's guidelines or not. There are a TON of things happening at the lower levels of iOS that affect the usability. Whether or not something is "running" is merely one small example of them.

With that, I'll borrow something from a previous poster:

/thread

(yeah... I'm kidding... because I saw how much love that last guy got with that. And, while I really do think we should be done here, I'm happy to give Mr. Dave the last word. And I'll also admit I'm ashamed I got (troll?)baited into wasting 20 minutes of my day on this. So, I promise. I'm out. Dave can say what he wants. But that, his CS degree, and whatever other tripe he uses as "evidence" won't change the facts. Nor will it change the OP's intent to determine whether iOS4's auto-backgrounding is a "bad thing."

 

[Daveoc64]

Well, I'm SUPER glad that Dave is back. I was afraid we'd lost him.

Although Dave has cited copious amounts of credentials, I am still left wondering why he insists so much that he is correct when, in fact, he is not.

I'm sorry. I can resist the urge to flame no longer.

This is easy for me to respond to, especially because of your last point.

emphasis added by me

Clearly, iOS allows one to create, manipulate, and otherwise update views while in the background. We do it all the time. (We develop apps not intended for "general public" consumption. Rather some of our apps are intended more as "kiosk" apps where, if iOS would let us, they would be the only app running and we would disable the home button. They are typically deployed in physical environments where the users are not able to push the home button. But, if we take it out and pass it around for "show and tell," we require the views to remain fresh and up-to-date upon resuming the app.) We do this -- against Apple's general advice -- and it does everything you'd expect like slow down the foreground app and all that other lovely stuff. But we're not complaining about it. I'm just sayin'...

If you listed the exact API you used to do this, I'd believe you. But as it stands, there isn't a documented API that does what you suggest.

Minimal work? How can that be? I thought that -- according to Mr. Dave -- NO work was serviced for backgrounded apps. Hmmmm... I hope I didn't just cause an aneurysm.

They are referring to the Task Completion API as mentioned by me many posts ago. Keep up. Task Completion should only be used for specific tasks that are urgent.

This one's going to be more fodder for Mr. Dave to interpret as he pleases. Admittedly, the prose is a bit loose here. However, I can attest (again, through direct personal/professional experience) that you can (and we DO) utilize network connectivity to send and receive messages while in the background. A more common example of this behavior is those apps that notify your friends of your real-time position. Even if your copy of the app is backgrounded, it (as Dave agrees) receives significant location changes. The kicker is that, once it receives it, it can "do other stuff." This other stuff includes forming and sending a network message to all your mates (as Dave might say) as to where you happen to be at the moment.

I've never doubted that Apps that use the 4 background APIs are running in the background (I mentioned the 4 APIs above and even described them) - that would be moronic to suggest otherwise. As I said above, these things don't use magic - they use 4 specific APIs. You have mentioned just one use of them. It's by no means a bullet. The location API is what you describe.

As for minimal work, they are merely referring to when the App returns from being suspended.

And, I'm sorry. I just can't stop here. I'm on a bit of a roll, I suppose. It seems Mr. Dave likes to freely interchange the terms "backgrounded" and "suspended." I'll admit my experience on this particular forum prohibits me from doing this super gracefully (as in, pretty), but here's a link that clearly distinguishes between the two states. (Look at Table 2-3... just below the anchor I've provided with this link.)

It's true, for SUSPENDED apps...



However, for BACKGROUNDED apps...

I've never disputed this. I've already said that an app doing something in the background will use CPU, but that isn't what the OP asked.

Other posters suggested that "suspended apps" use CPU.

You've just discredited your entire post in an effort to discredit mine!

You just confirmed what I've been saying all along - thank you.

As a sidenote, I don't use the term "backgrounded" myself. I always put it in quotes because it's a term people tended to use for iOS < 4 Jailbreak methods to do multitasking.

 

[chrono1081]

I think the problem here stems from the original post:

The one biggest annoyance I have with iOS 4 is the multiple app icons in the bar when double click on the home button, by the end of the day, I have something like over 30 icons of all apps I used in the day. My questions are, why can't the app just simply quit like it used to be? do they take up any memory or other resources while not in use, do they run any tasks in the background? Is there a way to get rid all of them with a simple tap instead of remove they one by one? Can this be prevented in the first place? This really annoys the crap of me!!

Most end users do not understand the difference between background and suspended (which may or may not be the case with the OP)

But, to answer the OP's question about resources, it depends on the app whether or not they use resources. If they run processes in the background such as a music player, the yes, the app uses resources. If the app doesn't do anything in the background and simply transitions to a suspended state then no, it does not use resources.

In any case though the OS will ensure it has enough ram and will kill any app it needs to in order to ensure the OS gets the amount of ram it needs.

 

[Daveoc64]

I think the problem here stems from the original post:



Most end users do not understand the difference between background and suspended (which may or may not be the case with the OP)

But, to answer the OP's question about resources, it depends on the app whether or not they use resources. If they run processes in the background such as a music player, the yes, the app uses resources. If the app doesn't do anything in the background and simply transitions to a suspended state then no, it does not use resources.

In any case though the OS will ensure it has enough ram and will kill any app it needs to in order to ensure the OS gets the amount of ram it needs.

All correct.

 

[nizmoz]

A man that has the time to present the facts. Great work Taylor. Like I have been saying but I refuse to make the time to sit down and research all this for him when I know I was right. When he started to argue that APPs didn't use memory, cpu, resources at all in task bar was just out of line and plain wrong. Glad you just showed him the facts and like some say, pwned him.

Well, I'm SUPER glad that Dave is back. I was afraid we'd lost him.

Although Dave has cited copious amounts of credentials, I am still left wondering why he insists so much that he is correct when, in fact, he is not.

I'm sorry. I can resist the urge to flame no longer.

And, since Mr. Dave loves to "quote legitimate sources" so dearly, I'll take my shot here.

At this location, Apple's developer documentation (I think it's available to non-developers!) attempts to provide app developers some guidance as to what's acceptable and not acceptable for their apps to do while suspended. There are almost a dozen bullets. But there are two that stand out.

The first:


emphasis added by me

Clearly, iOS allows one to create, manipulate, and otherwise update views while in the background. We do it all the time. (We develop apps not intended for "general public" consumption. Rather some of our apps are intended more as "kiosk" apps where, if iOS would let us, they would be the only app running and we would disable the home button. They are typically deployed in physical environments where the users are not able to push the home button. But, if we take it out and pass it around for "show and tell," we require the views to remain fresh and up-to-date upon resuming the app.) We do this -- against Apple's general advice -- and it does everything you'd expect like slow down the foreground app and all that other lovely stuff. But we're not complaining about it. I'm just sayin'...


The second...


again, emphasis added by me

Minimal work? How can that be? I thought that -- according to Mr. Dave -- NO work was serviced for backgrounded apps. Hmmmm... I hope I didn't just cause an aneurysm.


And, for fun, I'll throw in a third bullet:




This one's going to be more fodder for Mr. Dave to interpret as he pleases. Admittedly, the prose is a bit loose here. However, I can attest (again, through direct personal/professional experience) that you can (and we DO) utilize network connectivity to send and receive messages while in the background. A more common example of this behavior is those apps that notify your friends of your real-time position. Even if your copy of the app is backgrounded, it (as Dave agrees) receives significant location changes. The kicker is that, once it receives it, it can "do other stuff." This other stuff includes forming and sending a network message to all your mates (as Dave might say) as to where you happen to be at the moment.


And, I'm sorry. I just can't stop here. I'm on a bit of a roll, I suppose. It seems Mr. Dave likes to freely interchange the terms "backgrounded" and "suspended." I'll admit my experience on this particular forum prohibits me from doing this super gracefully (as in, pretty), but here's a link that clearly distinguishes between the two states. (Look at Table 2-3... just below the anchor I've provided with this link.)

It's true, for SUSPENDED apps...



However, for BACKGROUNDED apps...


once more, emphasis added

Seems our "mate" Mr. Dave should refer to that last section referenced by the above quote.

The bottom line (as I meant to conclude my previous post, Post #100) is this. Apple was initially (pre-iOS4) very reluctant to allow any backgrounding of any app (other than their own apps, like Phone, etc.) for the simple reason that it opens the door for bad user experience. However, with the advent of iOS4, the fine developers at Apple went to painstaking lengths to (a) somewhat limit what you can do in the background and (b) provide copious detail about "best practices" while developing apps that will "do things" in the background. So, they didn't provide us with "real multitasking" and all that. Rather, they did the Apple Thing and tried to give a large portion of the population the features they wanted (location awarenes, music players that run while you use other apps) while trying to achieve some balance and trying to maintain an overall good user experience.

In my opinion, they did a fantastic job. No single release of iOS is going to make 100% of users happy 100% of the time. When you consider that, I think most reasonable people would also tend to agree -- they did a pretty good job of striking that balance.

My crazy non-public apps are not the only ones that do resource-intensive things in the background. I also purchase a few from the App Store. And, while I'm not naming them here, the truth is I know that some apps are not good Resource Citizens. There are times when a background app is -- I don't know -- attempting to use the network and having trouble. Or is doing some other task in the background. During these times, my foreground app will sometimes lag or freeze for a second or so. (That's a long time, actually, to be sitting there wondering if your phone just crashed.) But it can and does happen.

Again, trying to get back to the spirit of the OP's question: the fact that iOS automatically sticks apps in the background is MOSTLY not a problem. But it can become a problem, depending on the particular apps you use. As suggested above, my "mates" and I have sort of a "known offendors" list. Sometimes, our phones bog down just a tiny (but noticeable) bit. When that happens, we purge the offender. And, while we're there, we just purge everything. (It's a cute habit of just tapping the screen where that right-most app in the tray always slides to. Takes about 5 seconds of tap-tap-tapping to clear everything out.)

This thread got jacked to a STUPID argument over the FACT that apps can (and do) run in the background... and use memory... and read/write to flash/disk... and make network connections... and... and... The bottom line is that this is not the issue. Apple did a FINE JOB striking a balance between "no backgrounding" and "controlled backgrounding." Apps still "do things" in the background. Memory is still traditionally managed in the background. Additionally, your app can be "jettisoned" whether you follow all of Apple's guidelines or not. There are a TON of things happening at the lower levels of iOS that affect the usability. Whether or not something is "running" is merely one small example of them.

With that, I'll borrow something from a previous poster:

/thread

(yeah... I'm kidding... because I saw how much love that last guy got with that. And, while I really do think we should be done here, I'm happy to give Mr. Dave the last word. And I'll also admit I'm ashamed I got (troll?)baited into wasting 20 minutes of my day on this. So, I promise. I'm out. Dave can say what he wants. But that, his CS degree, and whatever other tripe he uses as "evidence" won't change the facts. Nor will it change the OP's intent to determine whether iOS4's auto-backgrounding is a "bad thing."

 

[Daveoc64]

A man that has the time to present the facts. Great work Taylor. Like I have been saying but I refuse to make the time to sit down and research all this for him when I know I was right. When he started to argue that APPs didn't use memory, cpu, resources at all in task bar was just out of line and plain wrong. Glad you just showed him the facts and like some say, pwned him.

It's clear you don't understand what he's said if that's the conclusion you've drawn.

His post said the exact opposite of your argument!

 

[taylortm]

No. He got it right.

His post said the exact opposite of your argument!

Thanks for speaking for me Dave. But again -- *BUZZ* -- you're wrong. Nizmoz gets it. My colleagues get it. We're all sitting here laughing at the insanity of this thread.

Again, I'm ashamed I bit on the troll bait. But we all here just couldn't stand seeing your plain wrong "facts" go published uncontested. We also don't get why the popular vote took up against nizmoz and the other fellow around post #60.

But, at the end of the day, I think this thread doesn't belong here. It belongs at iphonedevsdk or stackoverflow or some place like that.

============

And, to be completely open and honest, I admit there is a slim chance that this is one of those cases where we both "know" the same thing and just think we're arguing opposite sides of the case. But... I really don't think that's it. I think you changed your tone somewhere around post #105 when chrono1081 joined. For the record, my hat's off to chrono. He gets it. It's about the OP's question: Does the END USER suffer from the backgrounding? The answer, as I said previously, is "usually not." But there can be some Bad Apples (no pun, I promise) that can make bad things happen in the background. And, there can be some Good Apples that still (call it bad luck) run into a "bad resources landscape" for one reason or another.

I'm really done debating. You're not going to admit defeat... and I really don't care if you do. I just wanted to make sure your incorrect tripe was countered with the facts. You can resort to twisting my (and other people's) words in a desperate attempt to appear "victorious." I'm after bigger things in life than winning a virtual argument on a forum like this.

If you're sincere (in that you really think I'm misinforming poor unfortunate souls with incorrect data), then my hat is off to you. I respect healthy debate. People (me too!) learn that way sometimes. But I don't think you are being sincere. I think it's an ego thing. It just feels too "hot" and personal when it's got your signature on it.

Best wishes. Good day.

 

[Daveoc64]

And, to be completely open and honest, I admit there is a slim chance that this is one of those cases where we both "know" the same thing and just think we're arguing opposite sides of the case. But... I really don't think that's it.

As far as I'm concerned, we're arguing the same point together - but that "nizmoz" is arguing a different point.

i.e. Suspended apps do not use CPU
Apps in the Background DO use CPU

I didn't feel earlier that you understood that (read post 101 as an example of where I say that background apps use CPU)

nizmoz disagrees with the above two line summary. He says that suspended apps do use CPU.

He can't possibly get it if you agree with me on that point. DO you agree with my two line summary?

 

[Daveoc64]

If you're sincere (in that you really think I'm misinforming poor unfortunate souls with incorrect data), then my hat is off to you. I respect healthy debate. People (me too!) learn that way sometimes. But I don't think you are being sincere. I think it's an ego thing. It just feels too "hot" and personal when it's got your signature on it.

I don't think that you are misinforming people, I think that nizmoz is.

Your post summarises EXACTLY how iOS works, including fringe cases where things go wrong.

I am most certainly being 100% sincere. The only reason I post on this site is to try and help people.

I genuinely think that telling people they need to remove ALL apps from the multitasking bar is misleading, a waste of time and will result in the future loading of those apps being much slower.

 

[johneaston]

You don't need to do anything with those apps,

If I don't need to do anything with them, then why are they more important than my Favourites list?

I miss double clicking the home button to bet my favourite contacts. Now, when I double click, I get a duplicate of the apps that are on my home screen.

Such a waste of a great shortcut.

 

[taylortm]

Happy Ending?

I genuinely think that telling people they need to remove ALL apps from the multitasking bar is misleading, a waste of time and will result in the future loading of those apps being much slower.

And I agree. I leave 'em all running until I hit a snag. Sometimes, I just kill the one or two that I suspect. But sometimes it just feels "good" to Kill 'Em All.

I am most certainly being 100% sincere. The only reason I post on this site is to try and help people.

Okay. Me too.

Let's just end it at that and be friends. <3

 

[Daveoc64]

Let's just end it at that and be friends. <3

Now that's something I can vote up!