Do you know any way for safe copy cut operation in Android?
I want to make a file manager. I can do them with FileReader/Writer, but as is not safe (if app crashes), I want another safe way to do this.
You should probably design a fail-safe order of operations. For example (just making this up, haven't validated it thoroughly):
Record in a persistent worklist file (/shared preference, etc) what you intend to do
Copy the file
Verify the copy is complete
Only then remove the original
Cleanup the record in the worklist
You should not do the work on the UI thread. You may want to consider doing it in a service to handle the case of huge files (or large numbers of files) which may take a while.
You may also want to consider if you can in some cases use the File.renameTo() method - this would require that the source and destination be on the same partition (ie, both on external storage). Also you would have to make sure that the destination directory exists.
Also put some thought into what you are going to do if the selected object is a directory rather than a file...
Related
I have an app with data stored (by previous developer) in user-based directories: context.getDir(userLoginHash, Context.MODE_PRIVATE). And there is no users list - when user logs in app tries to load contents of his directory (or creates new one), when user logs out directory remains on the device.
And now I wan't to clean the data. So I need to get list of such folders, but didn't find method for that. It confused me a lot because task looks too obvious. Do I miss something? How can I do this?
So I need to get list of such folders, but didn't find method for that
There is nothing really built-in for that.
How can I do this?
Start with:
File motherOfAllUserDirectoriesAndOtherStuff = getDir("whatever", Context.MODE_PRIVATE).getParentFile();
You can iterate over all of the contents of motherOfAllUserDirectoriesAndOtherStuff using standard Java I/O (e.g., listFiles()). However, bear in mind that not everything in motherOfAllUserDirectoriesAndOtherStuff will be your user directories. SharedPreferences, databases, other files, etc. will also be in there. You will need to devise an algorithm that can determine whether a subdirectory of motherOfAllUserDirectoriesAndOtherStuff is one of your user directories or not, perhaps based on what a hash looks like.
If you can someday rewrite this, create your own root and put the user directories in there. IOW:
File userDir = new File(getDir("myAppRoot", Context.MODE_PRIVATE), userLoginHash);
I want to know if there is a way to include your Android bootanimation.zip inside frameworks.apk(or another place not easily accessible) when building from source so that it gets loaded instead of the one in /system/media/bootanimation.zip
So when a user replaces the bootanimation in /system/media it still loads the default one built into frameworks.apk or some other place that Android can access to stop a user from modifying the bootanimation easily.
Or another scenario, a user replaces the bootanimation but then on the next boot Android checks if there is a size, file difference on the bootanimation.zip with a predetermined value(or original file) and if it differs, then it copies a spare bootanimation.zip located somewhere(if possible in frameworks.apk, so users can't get it easily, without decompiling it) and then copies the original bootanimation over the one in /system/media.
Then on the next boot, the bootanimation will be the original one and users will be baffled why it changed again. Is there a way to write such a script to run on boot or include it in some runtime file in /system/bin perhaps?
You can change the default location of the bootanimation.zip, but where would be a good place to hide it and what to rename it too, will also need to keep it small under 5MB and without .zip extension? But this method might be easily discovered.
It is for protecting my work, so others can't take credit for it.
So I just want to make it a little harder for someone that tries to do such a thing.
You can store the boot animation somewhere with a different name. And then implement a service in init.rc for copying your boot animation to /system/media after checking the current bootanimation.zip file's checksum. If the user had replaced the bootanimation.zip then the checksum will be different compared to your bootanimation.zip.
I have an android app that is able to open a certain file type via a VIEW intent.
After a file is opened using my app for the first time, I would like the app to "remember" the file so that the user can choose to open it again from a list of "recent" files inside the app...
My question is: what is the best way to implement this kind of "remembering" - should I:
Automatically copy any files passed to my app into my app's own storage area, and then list "recent/old" files there?
Or, should I record a list of files that my app has been passed previously, and access them via the same path later if necessary? If that is recommended, is there any guarantee that I will be able to access them again later? (I guess not!)
Option 1. seems like more work and doubles the storage space needed for all files passed to my app, but will guarantee the files will be accessible in future. Option 2. is easy if the files are always readable by my app in future, and are not renamed/deleted for some reason - it seems there's no guarantee of that though...
If it helps, I expect most files passed to my app to come from "Downloads" via the user's browser, but some might come from email/other apps etc.
Thanks
I would go with Option #3: drop the proposed feature.
As DeeV pointed out in a now-deleted answer, Option #1 is not a great solution for a "recent files" list. It would be the right option for other verbs than "remember", such as "import".
Option #2 will not work much of the time. Your app needs to support the content scheme, in addition to (or even instead of) the file scheme. By default, you will only have rights to access the content at a content Uri until your process terminates (at best). You may be able to takePersistableUriPermission() to get durable access, but that will not work much of the time — it depends upon whether the other app is granting you such access. Hence, you might have a Uri that you can remember, but remembering will do you little good.
I am very new to Android development.
Suppose my application has a few static HTML files that I expect will need frequent updates. Suppose I do not want to publish a new version of my application every time a file changes, but I do want to keep these files up-to-date.
What I imagine I could do, is to write a piece of code within the app to go to a known URL and check for updates every few days. If the updated resources bundle is available, the code will download and unpack it, replacing old files, so that the user will see the most resent content.
Questions I have:
- is such approach a good/bad idea? In other words, are their specific disadvantages to doing update in such manner or is it a commoin practice?
- how can I implement something like that? Service? Is there an existing sample piece of code that I could reuse?
Thanks!
If the updated resources bundle is available, the code will download and unpack it, replacing old files, so that the user will see the most resent content.
This is fine, except for the "replacing old files" part. Resources are read-only and cannot be modified at runtime. However, you can adjust your code that uses these files to look for your downloaded-and-cached updated files first and use those, falling back to the resources if updates are not available.
how can I implement something like that?
If your app involves other data synchronization, and you are using something like SyncManager for that, just include these files as part of the synchronization work.
Otherwise, use AlarmManager to arrange to get control every so often to check for updates. You will probably need to use WakefulBroadcastReceiver or my WakefulIntentService to do the actual downloading, as the device will want to fall asleep right away otherwise, if the user is not using the device right then. Use HttpUrlConnection or your favorite HTTP wrapper library to download the files to getFilesDir() or getCacheDir().
We are building an android application, however this application have to make sure that there is a directory tree and some files in the SD or internal storage.
I think maybe I can package these files and then extract them to the user device.
However I have two problems:
1 Where to put the files? The asset or the raw folder?
2 Where to do the check job? Inside the activity? Is it necessary to create a Application object for my application and do this job?
Thanks.
1 Where to put the files? The asset or the raw folder?
Since you can read files from both folders, the possible difference is on reading speed and file size. Files in assets are zipped, so they take less space but probably takes a bit more time to read; while files in raw are not compressed, so no decompression is required to read them but they do take up the full space.
2 Where to do the check job? Inside the activity? Is it necessary to
create a Application object for my application and do this job?
The least you need to do is check it in your launcher Activity. But since the user or even other apps can modify the SD card at anytime in any way they wish, it's better if you do the checking when each Activity is resumed, and possible also before each usage.
1 Where to put the files? The asset or the raw folder?
This depends on what kind of files you want to put. So you should understand the difference between asset and raw. This similar question -The reason for Assets and Raw Resources in Android - may help you
2 Where to do the check job? Inside the activity? Is it necessary to
create a Application object for my application and do this job?
This depends on your design. You have to consider performance. For example, you can do the check job when your Activity resumed, but it may take a long time, which may cause bad user experience. So for this case, you'd better do the check job in a thread and send notification to front-end when checking finished. Alternatively, you can do the check job in service when system booted. or do the check job when your Activity created.