I would like to know if its possible to save an object at the moment the user is installing the app on mobile.
Why I want this?
My app uses some default objects to his normal behaviour, whenever the user starts the App I want that the objests are there to be used. I could certainly just create them each time the user opens the app..
But that might consume a bit of unnecessary time and performance and battery.. If its default, I want to create only once, and then its always there.
I will also use Internal Storage to create new objects of this type, there will be the default ones, that I described above, and there will be also the option to create new ones and save them to use later, on another time that app is launched, but that its fine, I already read something about how to serialize the object and use internal storage to keep them :)
I am just here asking about the first question, create the item only once at the beginning, maybe on the install moment of the app? I was assuming.. but dont know if its possible.
It has been very helpful to have this space for over an year, I have already learned a lot here from you thank you ;)
Android provides following intent to detect app installation
<action android:name="android.intent.action.PACKAGE_ADDED"/>
<action android:name="android.intent.action.PACKAGE_REMOVED"/>
If you use these with conjunction with broadcast receiver you will be notified when user install a new app. Problem with this solution is, it will not help you as you are trying to detect your own app installation.
What you could do is every time user launch your app
check if object exist
if not create one and write it to internal storage.
in this way it will created once. Depend on type of object you are trying to save you might consider using SharedPreferences or SqlLite or simply a file IO. If you are writing Java Object yes serialization is the way to go.
Update
If you are planning to get data from network for the first time, depend on the size you can decide,
Small File: Put it inside Asset folder and ship it with apk.
large file: if the file size is huge you might consider to ship portion with apk and sync and update rest on a background process or download everything from network
I'm not sure what you mean. A Java object exists in memory, so "saving" it when the user installs the app makes little sense. It can't remain in memory unless some process is holding onto it.
If you mean something like a JPEG photo or other data, you can put the data in the directories of your project and then access it as a resource once your app is installed. See the
Providing Resources API guide.
Related
What is the best way to upload large files in the background of an Android/Glass application? I'm currently triggering an asynch task for each file (photos / videos) I want to upload, but if the asynch task crashes or the activity that launched it hits an exception the file upload fails.
Is there an android or Glass design pattern to store files in an application-specific directory and have a task that constantly works to make sure those files are uploaded then removed from that folder?
Depending on your requirements you should either use a background service (as #straya mentioned)
https://developer.android.com/training/run-background-service/create-service.html
Or you can use a SyncAdapter:
http://developer.android.com/training/sync-adapters/creating-sync-adapter.html
The first approach you would use if you need to upload those files as soon as possible, the second approach you would use if you want to bundle up several files together and let the operating system decide when to sync them with the server (you can specify how often you'd like your app to synchronize).
I don't know the requirements of you application but sounds like the second approach is what you need. That is what google is using for many applications like gmail, etc. It is way harder to implement then the background service, but it's worth it. Android is smart about the Sync Adapters, it bundles up several adapters together when possible to preserve the battery consumption.
use a background Service to manage long-running tasks that may occur whether an Activity is created or not.
As for crashes, avoid them by programming defensively and handling possible exceptions.
I'm using the Google Drive Android API (yes I know its still in developer preview), to create a file on Drive that can persist data across all of a user's devices.
https://developers.google.com/drive/android/create-file
So, use the app on your phone:
-Check that the file exists (filter by filename and not in trash)
--If exists then read and update local sqlite with data
--If not exists then create new file, and write data from sqlite. Then request sync.
-When user changes data, open file again, write contents and commit/sync.
I'm finding situations when testing where I run on my phone, and then on my tablet, and there happens to be multiple files created of the same name and my app gets confused when opening. I'm guessing there were duplicates because there was a delay in the sync and the 2nd device didn't find the existing file so created a new one.
So, now I'm thinking, I pull in all files with that name (not marked trash) and merge them, then mark trash on all but one of them and call that the current. This will leave many files in the trash as time passes.
Couple of questions:
Is there anyway to create a file with a unique name, or pull by some unique handle. The duplicates are making things a hassle to use this Drive product.
Is there anyway to delete a file, not mark for trash, but actually delete. After a merge, I don't want to leave hundreds of files marked for trash on someones drive after months of use.
Am I missing something obvious here? All I want to do is continually overwrite a file by the last device to save data and call that the master copy. Then let other devices know that they should refresh when they run. Right now, I have a network tool app, but I'm also creating a game and was hoping to leverage this same mechanism to save/persist game state across devices....at this point I'm not so confident that Drive is the proper means.
As you've discovered title's are not unique in Drive. However, each item in Drive does have a unique identifier. In the Android API, the DriveId is the representation of this. (In the web API its the resource id).
Once you create the file, you can save the DriveId in local preferences so that next time you can just look it up by the ID. This will guarantee that you will always have the same file on the same device.
On other devices, you can first do a query by title to determine if it exists already, and then save off the DriveId if it does.
Google Play Cloud Save is designed for lightweight persisting of save state across multiple devices including conflict resolution and was built originally for games (although any app can use it). This seems like a more likely fit for what you want to do than trying to work with the full file system approach that is Google Drive.
Im working on a self-test app.
And I wondering on how to store the data, I've got over 200 questions and more is on the way.
Was thinking of storing them as XML but didnt find a way to get a random question without reading the whole string-array to a variable, which is bad for the memory.
So the correct way to go is to use a SQL-database, right?
But how do I make such a database so that it exists at boot and dont need to be made during start up?
Can't seem to find any tutorial on this subject, on how to handle questionnaires.
Here's a good tutorial on SQLite and Content Provider. It'll introduce you to using SQL databases on Android, and wrapping them into a ContentProvider.
As for how to get the data to the device - you have two options:
You pack the SQLite .db file in the application assets folder. Pros: the database is ready for consumption on the first run of the app. Cons: your .apk is too big. Updating is hard.
You download the data on the first run. Pros: your .apk is slim. updating is easy Cons: there's a delay before the user can use the app.
You ship a small .db file with the first 10 questions. Pros: Your users can start using the app immediately, while you download the rest of the questions in the background. Cons: You have to pick 10 questions you're likely to never or rarely change, or you risk your app to start with outdated data.
Create the db offline and either put it in the apk or download it.
I want to maintain data on an android device even if my app is uninstalled.
I want to maintain the data (some key) in android device even when the app is uninstalled or removed i want to retain this data when my app is re-installed in the same device.
A similar question passed by on Google Groups quite a while ago and as far as I understood, there's not a single method that will fully prevent a user from deleting the data stored. If you think about it, it actually wouldn't make sense to provide a way to fill up a device's (internal) storage without the user being able to free up that space again.
That being said, your options for storing semi-persistant data that does not get wiped out when an app is being uninstalled seem to be limited to either the SD card, some web-based location or a seperate content provider - each with its own limitations.
You might also want to read through Google's documentation on this.
You can save it to a folder and if app is reinstalled, load it from there.
I need to block user access to my app's data stored in the SD card... like the images etc as they are crucial to my app's proper functioning and if deleted by mistake, will cause the application to function way different from what is expected of it. Is there any way to do so programmatically, like when I create this directory structure during my first run, lock the access to it to be only unlocked when the app runs?
Short answer... NO, it's not possible at all.
If it's that important, you could store all your data in a encrypted file. That way if it's deleted then you know it's all deleted and you have to start again. You also know that it's 'most likely' haven't been tampered with.
Most likely tho, the best solution is to handle errors better and become a more robust application.