Re: What is your experience with Samsung "RAM Plus" virtual memory expansion?

Andy Burns <usenet@andyburns.uk> wrote:

Frank Slootweg wrote:
 

   My/the point is that not all appscan be designed that way. It might
be that if they can be designed that way, they must be designed that
way. But an app developer can not be required to do the impossible.
 
   Note that I specifically mentioned external data or/and state. If an
app is killed, external data or/and state might/will be lost and the app
cannot recover when restarted. Examples of such apps are apps which
depend on data from (internal or external sensors or other data
sources).

 
They can save the most recent sensor values as part of their state, so
if they get killed, they can use the saved value rather than re-reading
the value from the sensor.

  Yes, but they will miss the sensor data that was generated between the
time the app was killed and when it was restarted. Think tracking/
tracing apps, activity trackers - including sleep tracking -, etc., etc..
For example the developer of Sleep as Android developed the
DontKillMyApp app [1]. Need I say more!?

  Like I said, if paging/swapping wasn't needed, computers wouldn't have
those functionalities, because one 'disk'-access (load-only) is faster
than two (page/swap out and back in).

  I'm sure there are many, many other applications where killing
processes just isn't an option. Actually the exact opposite, I think
there are few applications where killing the process(es) *is* acceptable
behaviour.

[1] 'DontKillMyApp: Make apps work'
<https://play.google.com/store/apps/details?id=com.urbandroid.dontkillmyapp>
Referenced from 'Tracking crashes, stops suddenly' on
<https://sleep.urbandroid.org/docs/sleep/automatic_sleep_tracking.html#after-fall-asleep>