I am developing one sample application.
I want this application should not be garbage collected ever until i switch off the phone.
1. Is this is possible in android?
2. If it is possible. How can i do this?
No, it's not possible in Android. And there is a good reason for it : system manages memory as a limited resource and no application can remain active if not used to ensure memory is available to other apps.
Nevertheless, technically, you can use a foreground service to ask the system to keep your application running as long as possible, possibly longer than a "normal" app with no such a service.
But, all in all, what you want to achieve is not a good idea. The Android way is to create your app, persist its state and re-set new instances of your app in the same state. For persisting state there are multiple solutions like using SharedPreferences, files or a database.
Related
I'm only on search for the reason why Android does this and what can you do to "stop" it or handle it when coding any app. I haven't found any info about this except some yt videos that teach you how to stop it when using your Android smartphone. I'm looking for documentation or something like that to read and learn why does this happen and how to handle it.
Sorry for my bad english, not native. Thank you.
Why? Because a device is a computer and therefore the limited resources should be optimized. The optimizations favors the app with the user is interacting, making the user experience fluid.
How this happen and how to handle it is the life cycle
And how to make things even if the app is not open it is about the workmanager
From the official documentation
It is important that application developers understand how different application components (in particular Activity, Service, and BroadcastReceiver) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work.
and how it happens :
To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components
It seems to me that if you have some state or data in android that you want to access from different activities (but don't want to persist) you need a singleton. Is this correct or are there other ways to design an application?
It is not that I have a problem with singletons. I am just wondering because this is so radically different from normal desktop application development.
What you said is definitely not correct and there are other ways to design an Android app.
Actually, for Android development, Singletons should be avoided or used sparingly and should not be used as the first or only solution. It should especially not be used to carelessly share data or state across Activities.
If you find your app requiring the use of Singletons for everything, then chances are... you're in need of a redesign for your app.
When using Singletons, there are actually a few things to keep in mind:
They typically live throughout the entire lifecycle of the App until they're closed by the system closing your app
Improperly created Singletons can easily leak memory
Improperly designed Singletons and excessive use of Singletons can use up a lot of unneeded memory
They're hard to use for testing
Overall, when using Singletons, you really need to think about if there's a sufficient need for that part of your app to be a Singleton.
For most situations, the answer is no. In the cases you mentioned, such as accessing state or data between Activities, it's a yes and no.
It's a yes because the need to access data might warrant the use of a Singleton. It's a no because the need to access the state of the app shouldn't.
Your use of the word 'state' is a quite unclear, but Activities should really be self-managed, since the state of an Activity shouldn't interfere with the state of another Activity. If it does, there are better ways to send that information to the Activity (such as using Intent extras) rather than creating a Singleton that is accessible for everything and existing for longer than it should.
There really is very few reasons to warrant a need for a Singleton.
In my experience, there are only two reasons that might allow for the use of a Singleton:
The real need for a single instance to exist
The Singleton is used very often and it's expensive to constantly create it, but there won't be any major side effects to keep it in memory.
For example, an SQLite Database is commonly used as a Singleton because a single synchronized instance of the database can help prevent more than one Activity or Service from reading/writing to the database. This helps prevent situations such as one object writing new data, while another object reads old data before the new data is written. Or the simple situation of two objects writing different data to the same field at the same time.
Additionally, an SQLite Database is also accessed very often by apps, so it doesn't make much sense to constantly open a database, fetch some data, close the database, open a database, write some data, close the database, and repeat.
I've seen developers use Singletons for a lot of situations, and most of them for really bad reasons.
The Good:
Databases
SharedPreferences (the app needs to access preferences way more often than normal)
Logging system
The Bad:
I saw a developer load up a large amount of Drawables and stored it in a Singleton upon starting his app... just so he could quickly use those drawables everywhere.
I saw some developers using Singletons to hold a list of created Activities, so they could access those Activities methods and views... (dead)
I've seen more bad stories, but I can't recall them now.
Also, keep in mind that even though I said things like Databases are a good idea to be used as a Singleton, I only meant it has the needs to warrant the use of a Singleton. A database doesn't need to be a singleton and there are other solutions available that might fit your app better.
So always think about whether there's a need for you to use a Singleton.
In your case, does the state/data you need to access by other Activities really need to stay alive for the duration of the app and can it be solved through solutions like: SharedPreferences, Intent extras, Callback Interfaces, Databases, static classes/fields/methods, and etc.
If you've thought out your app well and really think a Singleton will benefit your app best, then use it. Don't forget to use an Application Context instead of the Activity's Context, because the Singleton will definitely outlive your Activity and you don't want memory leak issues.
I would like to know the correct way to monitor system events and operating system activity in Android. My research so far indicates there are various methods for running Activities, Services, BroadCastReceivers, etc. but I don't have an overall comprehensive answer for everything I want to accomplish yet. I did come across an app today called "Carrier IQ" and was wondering how they do it. I believe their app is built into the kernel or at least the phone's OS image, something I want to avoid doing if at all possible.
I know that the Android SDK offers various ways to obtain
Since my app cannot be allowed to be suspended, should it run as a foreground service? If I do this, will I consume too many resources if I need to poll for various activity? I ask this because I don't think I can get everything through receiving events (i.e., using a BroadCastReceiver). I think I need a combination of polling and events.
I want to log sensors, events, OS activity, etc. for a user study. This is NOT for hacking or phishing purposes!
These are the top three projects that I think may accomplish something similar to what I want to achieve, but I have not yet determined if they are viable solutions:
android-hci-extractor
cellbots data logger
android-os-monitor
Does the Android manifest permissions list contain all of the permissions your app will need?
http://developer.android.com/reference/android/Manifest.permission.html
Then you can just ask for permissions when the app is installed and you should be able to access them.
In my app, I use a static variable to hold the current user id. There is a bug that is very hard to reproduce of this user id simply disappearing. While it could be related to a bug in how this variable is set during application loading (I still wasn't able to reliably reproduce this situation in a controlled environment, so I'm not really sure exactly what happens), I'm starting to think this is related to how memory gets reclaimed from static variables (something I didn't consider before).
So, when can my static variable simply disappear?
As far as I understand, static memory can get reclaimed if the OS reports low memory - can it happen while the app is in the foreground? Or only background?
Are there any possible ways static memory is getting reclaimed without a low memory condition? I think sometimes the variable disappears without the app even going to the background and I'm not sure any low memory events occur (AFAIK low memory refers to the whole OS, not the app's memory)
What is a good way to simulate static variables getting reclaimed by the OS to see how the application behaves and subsequently fix the bugs?
Anything adding more clarity to my understanding will be appreciated.
Thank you.
This is question super, super old, but I was writing a blog post and mentioned seeing this. I have no idea if you're still working on this app (doubtful), or if you're still seeing this issue (also doubtful). My guess is you set these statics in the Activity that your app launches with. Of course, if your app gets shut down, then restarted, you won't go through that activity.
Lazy loading statics, or initializing them in a custom Application object generally takes care of this.
I've done a fair amount of research on the "statics removed in low memory" idea, and the basic answer is it doesn't happen. Ever.
I suggest you are not using static variable to hold the current user ID as the static variable is not one of the best way to store your data (I assume userID as a data which will remain on every session of your app, except when the user is logout).
The simplest way is to go with Shared Preferences. Look at the Android Data Storage to read the best (practice) way to store your data in Android.
From your need, I guest you should go on with SharedPreferences. No more problem and you don't even need to simulate any variables reclaimed by the OS.
I would like to know which applications the user has started within the last, say, 24hours. Is this possible?
No, not possible (at least not without significant low-level work). Android doesn't keep usage history for applications as-is.