Posts Tagged ‘iphone’

What webOS did better…

Having recently upgraded from a Palm Pixi to a iPhone 4S, leaving behind webOS for iOS, it’s easy to find many things that are vastly superior on iOS; not surprising, given the superior hardware on the iPhone and the relative maturity of iOS as a platform. However, I find myself missing a few things I’ve become accustomed to with webOS; things I think webOS simply did a better job at.

Notifications
While both platform alert you to events, webOS also kept notifications stacked on the bottom of the display until you chose to swipe them away.

notifications

Integrated Contacts
webOS automatically imported and linked contacts from multiple sources (Facebook, Gmail, etc.) making it fairly simple to manage (or more accurately, not have to manage) an address book.

integrated contacts

Multitasking
While iOS supports multitasking on a technical level, on a UI/UX level the focus is very much centered on one app at a time, as swapping between apps always requires a trip back to the home screen. The webOS process of sliding between cards was not only a slightly faster method to swap between apps but also fairly convenient when it came to glancing at something in another app and then getting back to what you were doing; the scenario that pops into my mind is texting something from a webpage but not remembering it exactly or entirely, and having to swap between the messaging app and the browser.

Also, swiping a card up and off the screen was a fairly elegant way to close it. Exiting apps is perhaps not a big of a deal on an iPhone due to the larger memory pool, but when you do near the memory limit, I’m not sure double tapping the home button, pressing and holding the app icon, and hitting the remove icon is the easiest nor most intuitive action.

multitasking

Leaky research

If your going to speculate (wildly) regarding technical details about the Apple tablet in relation to the iPhone, at least try to get the fundamental details in question correct. Case-in-point.

memory modules

For an Apple Tablet to be a hit, it will have to be more than a big-screen iPhone. And the difference between a lithe, touch-based Mac and a giant, lame iPhone comes down to one crucial nerd-factor: memory management.

When your program closes, your app is supposed to give back all that memory to the OS, so that it your computer can use it for other apps. If your program doesn’t give back memory to the system, it’s called a “leak.” Leaky programs are bad; they make things crash.

This sounded fishy, and it is – the iPhone OS, like most modern OSs, will reclaim memory when an program terminates. A program with a memory leak will not cause anything to crash, but running out of memory will force the OS to forcefully terminate apps (which is not the same as a crash).

It [Apple Newton] supported garbage collection, or automatic memory management, just like full-grown desktop Macs. What’s the difference to you? More powerful apps.

There is no correlation shown between garbage collection and more powerful applications. Many complex, powerful and high quality applications are written in languages that don’t support garbage collection; for example, Photoshop.

So iPhone apps tend to “leak memory,” or hang on to memory too long. Developers I’ve interviewed–even Apple Design Award winners–have mentioned to me that their iPhone apps are leaking memory almost constantly because they’re too lazy to be really anal about manual memory management.

Read: lazy developers designed apps with crappy architectures that couldn’t handle reliable deallocation of memory.

But this means iPhone apps can only get so complex before they require too much hand-tuning to be worth the time.

“worth the time” is entirely dependent on the developer and the purpose of the app. If a more powerful app is worth it to an individual or company, they’ll make the investment to build an app with a more robust architecture and better memory management.

Garbage collection is certainly a nice feature to have, but it’s not a silver bullet for developers.