View Single Post
Capt'n Corrupt's Avatar
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#3709
Originally Posted by Slocan View Post
Most of the times, it's fine, but sometimes, I'd like to give priority to which app it closes. For example when playing a game, and then quickly going to check emails, or a website, I'd like to be sure that the game won't close up (haven't done too many experiments, but seems like sometimes it exits, sometimes it doesn't...). To really exit a program, you have to press the "back" button, so if you're 10 directories down in the file explorer, you have to press it 11 times. Not that big a deal, it's just a different way of doing things, but not sure it's in the right direction.
Very interesting...

The idea of persistence is something that the developer should bake into his/her app when focus is removed from the application via the Android activity event system. I believe the system automatically handles state saving if the OS needs the memory from the used App. I could be wrong about this.

It is possible to have the application reject these events and run wholly in the background as well, at the peril of being de-allocated should the system run out of memory. This is much more similar to a TL (Traditional Linux) implementation. Again, I could be wrong about this .

I suspect that these problems are more due to improper handling by the developer, than the actual system, though I could be wrong.

In your very well atriculated case, I agree that the VERY explicit TL method of task management eliminates this issue altogether.

EDIT: Here is an article on Android multitasking for those that are interested:
http://android-developers.blogspot.c...droid-way.html

From The Article:
If a user later returns to an application that's been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience. This is done by keeping track of the parts of the application the user is aware of (the Activities), and re-starting them with information about the last state they were seen in. This last state is generated each time the user leaves that part of the application, not when it is killed, so that the kernel can later freely kill it without depending on the application to respond correctly at that point.

In some ways, Android's process management can be seen as a form of swap space: application processes represent a certain amount of in-use memory; when memory is low, some processes can be killed (swapped out); when those processes are needed again, they can be re-started from their last saved state (swapped in)
It seems that with correct use of Activities, Android apps don't need to worry about de-allocation, as the system takes care of this automatically.

Since games are written using JNI (Java Native Interface), I have serious doubts that they are capable of taking advantage of this state saving, though I could be wrong about this as well!

Last edited by Capt'n Corrupt; 2011-06-15 at 17:19.
 

The Following 2 Users Say Thank You to Capt'n Corrupt For This Useful Post: