Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Umm, that's the whole point, one is multiutasking and the other isn't you're closing one app to open another.
I don't think I am really stating what I am trying to state clearly.

Basically, there are three things being discussed at once and they all are a PART of multi-tasking.

Forget all the sex and computer comparisons. They are not good comparisons. Multi tasking on a computer is nothing like on a phone where your screen space is limited.

So, the three things being discussed when it comes to multi-tasking:

1) How you switch from app A to app B.

2) Apps saving their state.

3) Apps running in memory, thus, saving load time.

And MY point is, basically:

#1 is identical on the two phones. They may look different, but the amount of button pushes/swipes is identical. Cellocello posted the steps and is correct in what my point was with this one part.

#2 can be fixed by any application programmer if they wanted to. I realize that Apple could force their hand by allowing #3 and I agree, that it should happen if done right. But the bottom line is, I have apps that save their state, so it can be done. I tested Flight Control extensively and I have failed to get it to NOT remember where I was. Incoming calls, texts, just hitting the home button. Heck, last night, my battery completely drained to the point of the iPhone turning off, and it STILL picked up where I left off after I charged it.

#3 is the only real limitation on the iPhone, and I agree they should do something about it. But they should do it RIGHT.

Even so, the apps I have personally needed to run in the background can. (Stopwatch, Music on iPod)

And like I have said tons of times, and the Pre Pimpers have ignored every time, is if I am on speaker phone with my wife who is out in BFE lost, I can go to maps while she is on the phone and get some directions.

Pre can't do it.

That is one of the most useful forms of multi-tasking there is on a phone, and Pre can't do it.
 
As long as AIM can do instant push notifications, and Mail can be set up to have a pop up notification when new email comes in, I see no reason in trying to kill the battery wasting CPU cycles in the background to run multiple apps.

But that's YOU. Other people might have tasks that they want to run in the background, for whatever reason, and they might think it is worth sacrificing battery life to be able to do that. Ideally, this kind of choice should be user configurable. Maybe have an "optimum battery" mode where no task runs in the background, and a "power feature" mode where users are warned, when switching to that mode, that this might severely deplete their battery life. It's just a wee bit lazy on Apple's part to have decided to optimize battery life for ALL users, instead of giving users the choice to decide for themselves what trade-off they'd rather live with.
 
I don't think I am really stating what I am trying to state clearly.

Basically, there are three things being discussed at once and they all are a PART of multi-tasking.

Forget all the sex and computer comparisons. They are not good comparisons. Multi tasking on a computer is nothing like on a phone where your screen space is limited.

So, the three things being discussed when it comes to multi-tasking:

1) How you switch from app A to app B.

2) Apps saving their state.

3) Apps running in memory, thus, saving load time.

And MY point is, basically:

#1 is identical on the two phones. They may look different, but the amount of button pushes/swipes is identical. Cellocello posted the steps and is correct in what my point was with this one part.

#2 can be fixed by any application programmer if they wanted to. I realize that Apple could force their hand by allowing #3 and I agree, that it should happen if done right. But the bottom line is, I have apps that save their state, so it can be done. I tested Flight Control extensively and I have failed to get it to NOT remember where I was. Incoming calls, texts, just hitting the home button. Heck, last night, my battery completely drained to the point of the iPhone turning off, and it STILL picked up where I left off after I charged it.

#3 is the only real limitation on the iPhone, and I agree they should do something about it. But they should do it RIGHT.

Even so, the apps I have personally needed to run in the background can. (Stopwatch, Music on iPod)

And like I have said tons of times, and the Pre Pimpers have ignored every time, is if I am on speaker phone with my wife who is out in BFE lost, I can go to maps while she is on the phone and get some directions.

Pre can't do it.

That is one of the most useful forms of multi-tasking there is on a phone, and Pre can't do it.

Well said.
 
It's just a wee bit lazy on Apple's part to have decided to optimize battery life for ALL users, instead of giving users the choice to decide for themselves what trade-off they'd rather live with.

I don't think it's laziness. Apple's notorious for dictating their user experience to the dislike of many. By no stretch of the imagination are Apple's choices for everyone, but there are other phones with the options you want.

I can't count the number of products I don't buy because they don't allow me to do what I want, but I don't expect them to either.

I wrote a post before listing all the features various iPhone owners want. If everyone got their "user choice" the iPhone would be horrible. The list is huge and the iPhone would be clunky and gaudy as hell.
 
I don't think it's laziness. Apple's notorious for dictating their user experience to the dislike of many. By no stretch of the imagination are Apple's choices for everyone, but there are other phones with the options you want.

Really? And I thought that the Pre was getting so much attention because it is the only phone other than the iPhone that supposedly offers a feature set and user experience comparable to that of the iPhone. ;)

I wrote a post before listing all the features various iPhone owners want. If everyone got their "user choice" the iPhone would be horrible. The list is huge and the iPhone would be clunky and gaudy as hell.

Must be why Mac people decry Windows systems, because they *are* clunky and gaudy, but personally, I'll put up with the clunkiness and gaudiness in order to have more control over my computers, which is why I haven't yet switched to a Mac, and maybe never will. I do wish Apple would realx a bit on their need to control user experience, though. Surely they don't have to go all the way and give all users everything they want (which is impossible to do, anyway), but just a tiny bit more options would be nice.
 
Basically, there are three things being discussed at once and they all are a PART of multi-tasking.

So, the three things being discussed when it comes to multi-tasking:

1) How you switch from app A to app B.

2) Apps saving their state.

3) Apps running in memory, thus, saving load time.

I wholly agree with your post as far as it goes, but I think there's one more aspect to multitasking - apps running at the same time. This is obviously a big thing with apps like IM programs or Pandora. This is something that the iphone can do with some apps (ipod, phone, mail) and will address using push notifications with other apps (IM). However, to give the devil his due, the Pre will be able to do this with all apps.
 
I wholly agree with your post as far as it goes, but I think there's one more aspect to multitasking - apps running at the same time. This is obviously a big thing with apps like IM programs or Pandora. This is something that the iphone can do with some apps (ipod, phone, mail) and will address using push notifications with other apps (IM). However, to give the devil his due, the Pre will be able to do this with all apps.

That is actually what I meant by #3. :D
 
However, to give the devil his due, the Pre will be able to do this with all apps.

That's true, but not entirely true.
The Pre cannot run *all* apps. Only web applications.

There's a big class of applications that won't run at all on the Pre, because the Pre does not support native code, pedal to the metal applications.

Of course Palm may introduce native apps with an update.

And if native apps do come along, and want to use all the resources, and all the memory - we will see then how well unconditional multi-tasking works.

C.
 
As I've said before, Apple and Palm need to do one thing:

Have native apps for games and things that aren't possible to write in native code, these apps will only be able to run one at a time; and have apps written using AJAX and web languages, these apps will be able to run in the background.

That way the heavy lifting apps will still run at full speed and the lighter web apps will be able to run simultaneously.
 
As I've said before, Apple and Palm need to do one thing:

Have native apps for games and things that aren't possible to write in native code, these apps will only be able to run one at a time; and have apps written using AJAX and web languages, these apps will be able to run in the background.

That way the heavy lifting apps will still run at full speed and the lighter web apps will be able to run simultaneously.

Great idea, but it means 2x sets of APIs to support.

As Apple have shown with cocoa and carbon, this can only carry on for so long before it gets old and you really have to start making decisions about where to focus your energies.
 
As I've said before, Apple and Palm need to do one thing:

Have native apps for games and things that aren't possible to write in native code, these apps will only be able to run one at a time; and have apps written using AJAX and web languages, these apps will be able to run in the background.

That way the heavy lifting apps will still run at full speed and the lighter web apps will be able to run simultaneously.

This gives an impression that native apps are heavy and AJAX apps are light. In resource terms the opposite is true. Action for action, native apps make the least demand on the processor and the memory.

C.
 
Great idea, but it means 2x sets of APIs to support.

As Apple have shown with cocoa and carbon, this can only carry on for so long before it gets old and you really have to start making decisions about where to focus your energies.
Yes, but for the most part Apple has a good set of web app APIs that they could adapt to a more native settings, but I agree with you. In the long run it would be a little pointless as one day battery life probably won't be a big issue, but for now it'd be a good solution.
 
Palm's stock has gone up 23% this week alone. There's a lot of investors who believe this device is going to make money.
 
This gives an impression that native apps are heavy and AJAX apps are light. In resource terms the opposite is true. Action for action, native apps make the least demand on the processor and the memory.

C.
You're right, but (and I'm not sure if this is true) since web browsers are so developed (and I figure a web based app would live in a browser like environment) that multitasking would be easier.
 
Multi tasking on a computer is nothing like on a phone where your screen space is limited.

I thought we have gone over this...

1) How you switch from app A to app B.

2) Apps saving their state.

3) Apps running in memory, thus, saving load time.

4) Apps running in the background (selectively by the user, of course).

5) Previous apps automatically return to attention when secondary, multitasked apps are closed or minimized. This is a large part of what keeps thoughts and workflow organized. Instead of writing an email, replying to a text, and being booted back to the home screen, it's: writing an email, replying to a text, and back to writing your email. It may seem like a subtle difference, but in practice it is just much more intuitive with respect to how our brains work. I think you are underestimating just how much it improves user experience.

I just don't understand the debate. The entire point is thus:

1) True multitasking accomplishes all of the above with the only requirement being there is enough memory to accommodate all the tasks.

2) Instead, the iPhone mimics multitasking behavior, but falls short is various ways.

3) The arguments apologizing for iPhone's system are, in effect, that the iPhone is close enough to multitasking so it doesn't really need full multitasking. It's just ludicrous. If it could multitask, the iPhone would do everything it does now, plus some. There would be no downside.

You may argue about battery life, the speed of the device (equates to not enough memory for multiple apps), etc. That would reflect on the hardware of the phone - not good enough battery or too bloated of an OS/lack of memory to support multitasking. Anyway you look at it, however, the Pre has the advantage. It either A) has a better support for multitasking on the software end, or B) has better hardware that is capable of supporting multitasking.

I've done some memory studies on the iPhone. The iPhone OS uses at least 50 MB of memory - native programs use an average of 30 MB each. The next generation will have 256 MB of memory, meaning it would be capable of running 6 average-sized apps simultaneously. Honestly, that is more than I could see myself having open. Will it support multitasking? No. Is there any UI solution in place to support application switching? No. But why?

Even so, the apps I have personally needed to run in the background can. (Stopwatch, Music on iPod)

Because of background processes. Those apps, while closed, run as a process in the background - which you can see is limited to native apps. Now the problem is when apps must be closed there is no UI element indicating which programs are actually running in the background. Users can forget exactly what is running and what is not. That is why 3rd party apps aren't enabled to run in the background. It's a non-issue with multitasking, however, since the user can easily track all open apps.

Finally, there is a different between multitasking and background processing. You say the stopwatch running in the background is multitasking. Wrong. I don't care how many dictionaries you quote. Let me illustrate:

tasks.jpg

process.jpg

All tasks have an associated process. When you close the stopwatch, it ceases to be a task and continues to run as a process in the background. It's not multitasking just because it happens to be processing still. Indeed, the iPhone runs dozens of processes from the moment you boot it up before you launch a single task.
 
That's true, but not entirely true.
The Pre cannot run *all* apps. Only web applications.

There's a big class of applications that won't run at all on the Pre, because the Pre does not support native code, pedal to the metal applications.

Of course Palm may introduce native apps with an update.

And if native apps do come along, and want to use all the resources, and all the memory - we will see then how well unconditional multi-tasking works.

C.

Ugh... what the hell are you talking about? WebOS apps are native apps. Javascript is it's native code. They do have access to all the device's memory. They may not have access to all the device's resources, but neither do iPhone applications.
 
When you close the stopwatch, it ceases to be a task and continues to run as a process in the background.

I don't believe the stopwatch even runs its own process - based on the processes listed in MemoryInfo.

When you tap Start, stopwatch probably logs the exact system time and starts ticking away. When you close and reload, a brief pause can be observed while the state reloads and stopwatch calculates the system time elapsed and then starts ticking again. For example, you can't hit Stop immediately upon opening a running stopwatch.


I think much of this multitasking debate should be held until after Apple announces a new iPhone. To compare how a year old device operates compares to a not-yet-released device is somewhat silly. But, I will not disagree that much could improved in the iPhone's workflow paradigm. Responding to SMS has to be my biggest pet peeve with the iPhone, though I have a long list.
 
Ugh... what the hell are you talking about? WebOS apps are native apps. Javascript is it's native code. They do have access to all the device's memory. They may not have access to all the device's resources, but neither do iPhone applications.

The difference is in the compiling for use with actual system components. Using javascript can reduce what a developer is able to take advantage of are are therefore less capable applications.
 
Ugh... what the hell are you talking about? WebOS apps are native apps. Javascript is it's native code. They do have access to all the device's memory. They may not have access to all the device's resources, but neither do iPhone applications.

Java is not native code. It runs on a virtual machine. Each instruction has to be interpreted. It is intrinsically inefficient.
Put another way. On the same hardware, an application compiled down to machine code will run significantly faster than a Java app.

There are only two native apps on the Pre. The browser and the Palm emulator.

C.
 
New Yorker Cover

This is the New Yorker Cover:
jorge_colombo_newyorker_cover.jpg

It might not be the most awesome painting in the world, but it was painted on an iPhone. The artist used an application which costs $5.99

I might be wrong, but I think this class of application would be impossible to write on the Pre.

C.
 
Java is not native code. It runs on a virtual machine. Each instruction has to be interpreted. It is intrinsically inefficient.
Put another way. On the same hardware, an application compiled down to machine code will run significantly faster than a Java app.

There are only two native apps on the Pre. The browser and the Palm emulator.

C.
/facepalm

javascript does not run in a virtual environment, however it does make calls to one thing that makes calls to another, instead of making direct calls. Java and javascript have absolutely nothing to do with each other despite the names.

This is the New Yorker Cover:

It might not be the most awesome painting in the world, but it was painted on an iPhone. The artist used an application which costs $5.99

I might be wrong, but I think this class of application would be impossible to write on the Pre.

C.

and you'd be entirely wrong. It's not hard to make a drawing application using web technologies.
 
I might be wrong, but I think this class of application would be impossible to write on the Pre.

C.

Why? The only real limitation I'm aware of for the webOS is 3D gaming (if you consider that a limitation :p). Theres nothing super complicated about painting apps until you get into heavy effects, which that picture contains very little of.
 
The Boy Genius Report has conducted a hands-on review of Palm's Pre:

"The screen is where the Palm Pre shines. Selections take little to no effort and there’s that oh-so-magical water ripple effect when actually touching the display. It’s vibrant, rich and all around really clear. Like we said in our Pre-view (har, har), we’d rate it just behind the iPhone’s glass capacitive touch screen — it’s that close to being perfection," The Boy Genius reports.

"Keyboard: It’s really not good. My hands aren’t that big (I can type faster than you could ever dream on a BlackBerry, iPhone or E71) and my thumb literally takes up 3 or 4 keys on the keyboard," The Boy Genius reports. "It’s really such an important area that couldn’t afford to be messed with and we’ll admit it… we’re a little let down... this is kind of disappointing... You can’t compete with RIM in the keyboard area and you can’t compete with Apple in the soft-keyboard area, so how are people going to enjoy using your product when the data entry isn’t perfection? It’s like buying a brand new Ferrari, but getting an Accord steering wheel."

"Feel: This is an important area when designing a phone," The Boy Genius reports. "To be honest, the device feels a little cheap. The edges of the bottom piece are sharp on the back of the screen and even worse, when sliding it up and down, the top part that houses the screen will sometimes catch on itself. It feels good in your hand, but the actual build quality really leaves a lot to be desired. One of our friends that checked it out over here said it felt like a Fisher Price toy."

"WebOS itself is off to a great start we think," The Boy Genius reports. "It will be interesting to see how developers try to take advantage of the operating system, yet we can’t help but feel it’s going to be iPhone web apps all over again until Palm releases an SDK that lets everyone (not just special partners) access areas of the OS that are needed to create applications that aren’t just 'fluff.'"

"Battery life: We haven’t been able to really put this thing through the ringer in regards to battery life... The browser for the most part renders pages properly and pretty quickly. It took around 15-20 seconds to pull up BGR over Sprint’s EV-DO connection but navigating is a little bit of a problem. We found that zooming in and out didn’t produce a smooth effect, rather it simply increased the size of the page sort of how Internet Explorer zooms in," TBG reports. "Applications: To be honest, there weren’t too many applications to explore here. The App Catalog was empty so we were left scrounging around anything that’s preloaded."
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.