I want to determine whether my application being run for the first time, and so it will be hard to pass around it.
The preferences or empty file approaches are not going to work because you can simply clear the application data or delete the empty file.
Also I want to do it offline so no server checking is going to work either.
Maybe it's possible to add some code to the installation of the apk so it will only run once.
So my best bet is spawning a lot of empty files all around and hope the user won't find them, but this is pretty messy.
Has anyone ever done this somehow before? Any suggestions?
The preferences or empty file approaches are not going to work because you can simply clear the application data or delete the empty file.
One possibility is to have a BroadcastReceiver, registered in your manifest, that you do not actually use for anything. On first run of your app, disable that receiver via PackageManager and setComponentEnabledSetting(). On future runs, you can determine if that BroadcastReceiver is already disabled via PackageManager and getReceiverInfo().
If the user uninstalls and reinstalls the app, the app will return to its original state. Rooted device users can also get past this. Otherwise, this should be reasonably solid.
I know you said you dont want files, but if you create them as local internal storage then the user can not delete them as they wont have access unless it is rooted phone. Clearing data "may" delete them.
There is another solution but it is lengthy one. Use SQLite database.IT is local and I dont think it can be deleted otherwise the whole application will crash
Related
I would like to know if there is any way to force Android to update its media table before querying MediaStore.Audio.Media.EXTERNAL_CONTENT_URI.
There is a flow where the user can insert or delete songs media from his device through USB, and after that the media table doesn't update by itself.
Maybe this is not the answer you are looking for, but it is easier to monitor those changes instead of somehow forcing the update of the MediaStore, you can even apply this approach for when it detects changes to make your query again.
You need FileObserver to monitoring file changes, but first your need setup it, let me explain.
You need to create a BroadcastReceiver, which tells you when the device starts. Why? Because you need to know when the device starts to start monitoring changes to your files.
Then you need create one service that observe changes, the class that can help you are FileObserver, SingleFileObserver.
But that is general, you can see the solution in this answer in similar question.
How to monitor folder for file changes in background?
in my app I am using push notifications to notify the user about something.Based on different app state I have to assign different activities to click event of notification. If the user press home button and app is in background i have to handle that scenario as well. But here the issue come when user clear the app instance from memory. If user do that I have to consider it as app closed. But i dont know how to get that app instance clear event. Please help me.
The task you are willing to solve is equivalent to protection against the task manager. I am not sure that your app knows better than the user whether or not to show the ads. Please do not create malware.
Try the UncaughtExceptionHandler stuff like setUncaughtExceptionHandler(). I am not sure it will be necessarily called, and it may depend on the Android version, but it is something to start with.
Another possibility is to use one or more remote service(s). The processes will not die all at once, there's a good chance that one process may notice the death of another process. There should be some kind of wait-for-process-to-complete at least on the JNI level.
One more possibility is to use two applications, one monitoring the other...
After you solve this problem, please post your own answer telling the world what you did.
I have couple of applications that implements some login logic. If lets say one application is logged to some_account#gmail.com I want that all of these applications be logged to some_account#gmail.com. If I logout I want to all application do the same. But I don't want to immediately do the same. Application itself can handle it, but it need to know if some other application is already logged in and if yes just log in for the same email address as this app. So I need to know what is the email address for which other app is logged. I need to store one string.
First I was thinking about SharedPreferences, but this is rather bad idea because there are other options (and stackoverflow is full of bad example of SharedPreferences usage between processes). Despite it I tried this. Set up sharedUserId on all apps, called createPackageContext and eventually try to get preferences. But I cannot read from it. Always I got null, even if I used Context.Mode_WORLD_READABLE - which is deprecated by the way.
Ok, lesson learned do not use SharedPreferences for that (I suppose). But everything what I need now is to store single string somewhere where it could be read by other my apps.
Maybe I should use ContentProvider? But seriously... for one string?
What is the other option? I am sure that for so simple operation I really don't need Service or ContentProvider, but I actually haven't got idea how to do that.
You could use a broadcast receiver. All you would have to do is send a broadcast to application B when the data changes in application A. Then application B can handle the data in the background, and store it however you need to. It might be a bit of over kill, and there could be a better way to do it, but it would work.
Okay, so this is my problem:
I am making an app that recieves sms messages, and can sort through them and such. it all works fine, but i am at the point where i have to make the class that will cause the phone to vibrate, play a sound and light the screen when the sms is recieved. you log into the system, and therefore different users will have different ways they want the app to notify when an sms is received.
i am making a class that, when constructed, reads the users settings for the 3 notification methods as ints from a file, can save new values for these ints, and can then do the actual notifying. ive made it so that when the object is constructed it takes the username as a parameter, and then reads and writes the settings from a file specific to him.
My question is this: what is the best way of saving and retrieving these ints from a file?
I know about SharedPreferences, and it is very easy to use, but how much can i trust this? if i close the app, turn off the phone, and start everything back up again, is the information still there?
I am currently thinking of making a small class with 3 public int fields, that implements java.io.Serializable, and then saves the whole object to a file, as then its easy to get the specific ints when i need them (keys/values, like SharedPreferences), but ive read that this is a quite slow process, and since the app is gonna recieve ALOT of messages(could be more than once a minute), having to read from a file at every recieve might make the app kinda heavy, since battery life is also important.
So thats my question, should i make my own reading/writing file system, or can i trust SharedPreferences to never lose any data?
i went with sharedpreferences, and it works beautifully, thanks! =)
To elaborate on the whole performance thing of storing, how much data would need to be stored in order for an sqlite database to be worth it? because all these sms' have to be stored in a certain way, and since it will probably be hundreds at a time, is that enough for using an sqlite database? because i read somewhere that using a database is a bit slower than the io way, until you reach a certain amount of data? i am hoping the database is worth it, as its probably gonna make things alot easier down the road.
SharedPreferences is safe for your saving the data. It's one of the recommended methods for storing data, see http://developer.android.com/guide/topics/data/data-storage.html
Another way, and also very safe, is to use a Sql table where you have the user name and those ints. Being just a few values this should be simple to implement. More information about this in the same link.
I do not see any reason to avoid using any of these 2 methods and go for the file system. They have been used many times before and they just work.
SharedPreferences should work perfectly for what you are doing. I implemented mine storing everything I need in the preference except password. Never once it's gone missing.
Also, SharedPreferences writes to a file as well SharedPreferences file
Unless you want these setting preserved even after the user delete the app, it suit your purpose.
If you insists to write a file, best way will probably be write it as xml or json. The latter would probably be faster by a fraction. Then load this file when appropriate.
Still, you should really consider hard to choose writing to a file over SharedPreferences. It's trust worthy! If you don't trust it, trust me and probably other people who writes Android and its applications.
I have a task which I need to run in the background in my Android app. It reads data over the network and populates a database. It can take several minutes to run.
Once it's started, it needs to complete successfully without interruption. (Otherwise I'll end up with a broken half-populated database.) I realise I can never guarantee it will always complete, but I want to make it as hard as possible for the system to kill off this task. For safety I guess I will have it populate a temporary database, and then only swap out the old database for the new one on successful completion of the import.
It's a modal operation; it does not make sense for the user to be interacting with the app while the import is in progress.
My first attempt is using an ASyncTask with a Progress dialog to achieve the modality, but this obviously breaks the "don't interrupt" requirement. I could work around the screen-rotation issue with ASyncTasks, but I don't think that goes far enough.
At the moment I'm not sure if this should be an ASyncTask, a Service, an IntentService, some combination of these, or something else entirely. Can you help me decide?
I'd run it as a service and additionally I'd also have a clean SQLite DB on my server populated with the data the clients are going to retrieve so I can generate a kind of signature. Have the clients check for the correct signature of the DB. If the signature is not matching the servers signature then reinitialize the database filling process.
This is just an idea tho. I have no idea whether it'd be possible with what you are trying to do or not.
You are better off with services in that case. The Android runtime will leave it alone working as long as enough memory is available. In the case it kills the service, you can save the state in a bundle, and the system will restart the process as soon as possible, so you can resume the process, if possible for your solution:
Android Fundamentals, Service Section
Then it is easy to communicate with the service, like showing the progress/ notifications etc, using a handle registry like proposes by Mark Bredy in his Android Service Prototype