Re: Multitasking on Android
 

It might be both. The app gets an onStop() message saying it's being stopped. The app can then decide what it needs to do.

If it doesn't do anything, the OS will still save the state of text in edit fields (for example) in a bundle. When you navigate back to the same instance, those are restored to the view.

IME it's moot with 2GB mostly and I'm not sure of the utility of manually managing resources when the computer can do that for you better most of the time for most of the people.

I think this discussion is clouded by years of Nokia phones with not enough RAM in them be they Symbian, Maemo, Meego or following on, Jolla and Sailfish who seem to have inherited that daft notion that they can squeeze a quart out of a pint pot.

Re: Multitasking on Android
 

The point I was arguing was your claim that the Android method saves battery. I wasn't arguing on the usefulness of saving state.

The Android method has its advantages, I don't dispute that. Regardless of whether the OS is Maemo or Android, when the system runs low on memory, the OOM has to do something and that normally involves copy operations to non-volatile storage. On Maemo or any other regular Linux, there will not be continuous swapping if there is plenty of memory available so I don't really understand your subsequent argument either.

There's a lot of misconception here about Android multitasking. One problem people here have with Android multitasking is that the if an app is not active, it will be sent a SIGSTOP signal unless the app developer has explicitly told it not to. I think that is perfectly reasonable behaviour when you consider Android's target audience. You wouldn't want a misbehaving app to drain the battery.

I just want a device that behaves like a computer. I'm perfectly capable of identifying a misbehaving process and dealing with it.

When I see that modern Android devices have the "feature" displayed in the image below, it tells me that there is something very wrong with the design of the operating system. Then I look at the uptime on my 256MB N900 and I'm reminded that no Android device would ever replace it.

http://www.sammobile.com/wp-content/...rt-720x405.jpg

Re: Multitasking on Android
 

The point is, as long as there's no a single, accepted, definition of what multitasking means, we will be comparing apples to oranges.

Microsoft said Windows 3.1 did multitasling (cooperative). IBM said no, and argued OS/2 did multitasking (pre-emptive). Microsoft then said NT did real multitasking (independent input queues).

In my "book" multitasking also implies that tasks are not frozen randomly. They may be killed (OOM) but not just frozen around without me knowing or noticing it.

(EDIT)
Like wicket says above: "I just want a device that behaves like a computer."
(/EDIT)

In Android the only way to have a task continuously running is by having a persistent notification (AFAIK, maybe there are other ways). This is hacky, unreliable, and just plain wrong (again, in my book).

Re: Multitasking on Android
 

check this out
http://www.digitaltrends.com/mobile/...freeform-mode/

Re: Multitasking on Android
 

Long and short of it. If I start up an app, I want to be the one in charge of exiting it or keeping it in background. Not android.

Re: Multitasking on Android
 

Heh, "freedom mode", funny they named it that since Google is all the time locking down Android more and more... :D

Re: Multitasking on Android
 

Android - well i used android for downloads long time back (kitkat) and used apps
for Regular Download - Android Download Manager
for Jdownloader type Downloads - Share Downloader
for Torrents - A-torrent Pro

while Browsing and "None of them Ever Quit"
although i feel there are always some hidden apps that steal your internet-bandwidth(data) in Android.

For Navigation in Android(root) - you can always change the button(bottom three or any other) configration to whatever with Xposed tweak "Gravitybox"

__________________________________

iOs - Right Now i am Using iPhone which is Jailbroken , then applied a Cydia Tweak called Multiplexor>>Aura. Aura lets any app run in background for infinity. and there is no internet-bandwidth(data) theft in ios(mostly)
so ios+Aura=super strong multitasking


Why download from Mobile Device - well its Really Good to save your Electric Bills

P.s - do you know most of iOs jailbroken tweaks are .Deb files. so i feel its definitely possible for Debian Apps to get installed in iOs, just imagine Easy Debian Ported to ios.

Re: Multitasking on Android
 

Just wondering, what's even worse to you?

Power management sucks (but Jolla uses Android drivers, Ubuntu uses Android drivers, unavoidable)
Privacy - you could get Replicant.
Java - yep, that's some reason, but can survive with decent spec.
Lack of decent glibc - this is really irritating to a power user, but can chroot (read: workaround avaialable)

Re: Multitasking on Android
 

You know, everything Google. Even though you can block some of Google's peering eyes and wandering fingers, they still sink their teeth into just about everything you do.


Sent from my XT1095 using Tapatalk

Re: Multitasking on Android
 

Neither do I like the way Android is one big Google-playground.

But you can after all use Replicant. I know it's not so fully up-to-date. Or use some Android without Google services.

This is something that could be possibly alleviated by the community (but, let's be frank, won't)
The multitasking is a (bad) design decision

Re: Multitasking on Android
 

The worst thing about android is the UI. It's got better over the last few years but it reminds me of Symbian too much rather than what for me was the UI high point of the N9.

The multitasking model just isn't the problem people make it out to be.

Re: Multitasking on Android
 

The last one is what ails me most. I just cannot live with a system that hasn't got glibc, and all the goodies that come with it.
Real unix userland is mandatory or else it's just a bloated featurephone IMHO. :eek:

• I don't care for UI that much, doesn't really touch me. UI is just what is used to launch applications.
• As said, privacy issues can be solved, so no problem
• Using java is silly really, it is a bit irritating
• Multitasking, well any platform can multitask but why make it so painful?

Re: Multitasking on Android
 

Finally a voice of reason!

Re: Multitasking on Android
 

Really not bothered. It just needs ssh to get to a server and I'm good. Why run commandline software on a phone when you've got multiple 12-16 core servers with 64GB RAM and an SSD RAID array to hand? :D

No, that's a launcher.

Unless the apps have their own custom UIs then they too are using the UI framework that the OS provides and it's this that IMHO looks and feels a bit dated on Android and iOS. That's the problem with being spoilt by the N9's lovely UI. :(

All OSs provide UI frameworks (eg Sailfish's Silica) and design guides and generally developers follow them so the apps look and feel like the OS dictates.

You do realise that people on the other platforms will think Sailfish and Maemo's multitasking where you have to manage tasks yourself and they don't close when you leave the app and don't save state is even more painful to them. As a Mac user it's a running battle with Windows users in the office explaining why if you close the last window in a Mac app so there's no visible windows open, it might still be running in the dock.

IMHO there's a middle ground. N9's UI with Android style state saves and Sailfish 1.0's covers and pulley menus. Plus keep full old-style persistent apps running if the user allows them.

Re: Multitasking on Android
 

This "applications never quit" paradigm was used on Palm OS and, so I've heard but never used, Symbian. It annoyed me to no end. Closed should mean closed.

Re: Multitasking on Android
 

And I beleive the middle grouhd is the user's choice. Configurability.

Re: Multitasking on Android
 

Freedom to choose for yourself is my choice.

Re: Multitasking on Android
 

PalmOS was pretty much single tasking. Even having a music player which could run in the background was rather special.

Symbian had proper multitasking. Closing apps meant the process was ended and gone. I had a Nokia N95. Its bigest draw back was the severe lack of RAM, but it was astonishingly feature rich and supported many open standards. Neither the N9 nor SailfishOS supports the things the N95 did.

It was way beyond anything Android or iPhone, feature-wise and multitasking. From what I've read, Symbian was a real-time-OS, and thus the main CPU could be used for strict real time tasks such as modem and camera, for which other devices required extra or more complex software. But, also from what I've read, creating apps for it was hard, with too many device-specific quirks.

Re: Multitasking on Android
 

At least, Symbian featured preemptive Multitasking as it originats from PSION's EPOC32 that was a pre-emptive multitasking, single user operating system with memory protection, see wikipedia

Re: Multitasking on Android
 

Nope. On traditional PalmOS it saved state but was essentially single tasking. Because the apps were so small and data minimal you didn't really need multitasking, just the impression of multitasking was enough to be productive. Later on they merged BeOS into PalmOS but IIRC Palm never shipped a product with that version.

Symbian was proper multitasking with no state saves. What it did do differently was ask you to close apps if it ran out of ram or didn't have enough to start an app which it did frequently on Nokia phones. That's why you had to pick carefully with Nokia so you got 'Hero' devices like the e71 or n95-2 which had more ram than crap like the 5230. Every now and again Nokia would let one slip out.

Re: Multitasking on Android
 

There is no need to dig into details. I know Palm OS was single tasking, but save state or suspend, the effect was the same: you never closed an application, you just started a new one. When you then went back to the previous one, it resumed from the same state, i.e. it never started from zero.

With a handful of very rare exceptions, applications on neither OS even had the "Exit" option. On Symbian, it was even actively discouraged (by programming guidelines) for applications to have that option.

I have (thank Zarquon!) never owned a Symbian phone and have no extensive user experience with it, but I have a lot of programming experience and that alone made me never want to touch Symbian with a barge pole if I could avoid it. We had to go through hoops to follow the guidelines, such as #if-#endif to make "Exit" available for debugging but taken out from the release build. Yuck!

This is what now annoys me about Android. There is the "Back" button that, if you press it enough times, eventually closes the application. But does it really? The fact that you can never be sure is what I find rather irritating.

Re: Multitasking on Android
 

You are right, not many Symbian applications have an "Exit" option. However, that is because the right hardware button always closes the current application. No need to be redundant.



Sent from my XT1095 using Tapatalk

Re: Multitasking on Android
 

I beg to differ. Most do have an Exit option. Especially the older ones. Even on my 808 many of built-in applications have Exit - Mail, Store, Music Player, etc.

Some apps have 3 ways to close

1. back arrow
2. Menu option
3. Hangup button

Some have only 1 or 2, and 3. And some like Camera can only be closed using 3.

Coming from some other company I would say it gives you choice, but coming from Nokia it's more of them being inconsistent and incompetent. One of the changes they made in the Belle upgrade was supposed to be an improved keyboard. The English input keyboard was a marginal improvement, but the Chinese input keyboard was a step back from the Anna version. And to make things worse some remnant of the Anna keyboards are still present after the upgrade and some applications would use those instead of the new ones.

Re: Multitasking on Android
 

I use the "hangup button" to close every application except Gravity (you have to use the "Exit" option in the menu to exit that).

I was merely adding to pichlo's personal experience with the "Exit" option in the development guidelines for Symbian. If I minimized the existence of the "Exit" option, I apologize.

I would like to add that I have never had an application be removed from the "open apps" by pressing a back button. The "hangup button" and "Exit" are the only ways I know of that happening.

Sent from my XT1095 using Tapatalk

Re: Multitasking on Android
 

This seems relevant.

The comments range from people bad talking the N900, to people praising it. Everyone picking it apart to show why it is/isn't an amazing feat.

Re: Multitasking on Android
 

Calendar on the 808 has a back button that removes it from the open apps list. Music Player's back button does not remove it from the open apps list (which is probably the expected behaviour since you would want it to go into the background and continue playing). Like I said before, inconsistent and incompetent :)

Re: Multitasking on Android
 

Hmm... I could see a way to achieve real multitasking on Android.

1. Memory Locker to prevent apps from being killed
2. Binding one middle key to kill and app and launch the recent apps.

I assume that recent apps is cleaned of dead apps, otherwise we'd need a daemon for it.

Re: Multitasking on Android
 

If the calendar is your only example, it make sense that I am unfamiliar. Not being able to link it with my other calendars, I have never used the it.



Sent from my XT1095 using Tapatalk

Re: Multitasking on Android
 

Technically, programs are always 'running' in PalmOS. This is because there's no distinction at all between storage and memory, and thus there's little difference between an "unloaded" and a "loaded" program in PalmOS (the difference is, basically, whether globals have been allocated or not).

In fact, e.g. if you created a socket and used the asynchronous IO equivalent to listen() or read() from it (more or less equivalent to Linux AIO's raise a signal when IO finishes), you would quickly realize that your signal callback would be called _even after going back to the launcher and switching programs_. That is how my 'background' FTP server for PalmOS worked.

Similarly, it was easy to malloc() something that would leak even if you 'switched' programs.
However, this was not the default. In practice, PalmOS worked like Android. When you get the notification that the user is going to the launcher, you just free() everything (or as much as possible). When you get launched, you load stuff back.

Unlike Android, no one would kill or "SIGSTOP" you if you decided to not free() everything.