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.
Related
I have an app that wants to have the ability to download files locally. A user can download a file (no restrictions to file type) and should be able to save it on the device so it can be used for other purposes. I would also like the user to be able to delete the file from the app (they would know which file is downloaded and which isn't, a ticker would indicate if it's backed up locally). Say it is a pdf file -- the user would want to open it with different apps or edit it if they have the ability to, or just share it via email. Considering we cannot opt out of scoped storage anymore (requirement to target 30), I got a couple of questions.
I've tried to use Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS).getAbsolutePath()) and also getExternalFilesDirPath(ctx, Environment.DIRECTORY_DOWNLOADS)). While the former is deprecated, it works for me in that the Files app can be used to navigate to the file in question (and possibly open/delete the file). On the other hand, I am not being able to delete this file from my app due to lack of permissions. Obviously, the latter path is unable to be navigated to by another app (or is it? I haven't found a way, hence the question).
The other thing I've considered using is the MediaStore API but I'm struggling to see how this is an improvement over the old ways in terms of function. Disregarding moving back to manual content resolver and cursor usage, how should arbitrary files be sorted? Should I manually sort by mime types and have different methods for saving for specific media types? It sounds exceptionally tedious and counter intuitive. If this is the way, so be it, I will implement it, but it does not sound like the way to go. On the positive side, it at least sounds like a solution due to the content resolver's CRUD abilities.
I'm working on a RN app that uses a 3rd party library for the download paths, which old/new versions, respectively, use different paths (rn fetch blob and rn fetch blob util). Additionally, MediaStore API doesn't have a RN implementation as of right now, so everything would have to be done from scratch, too.
What are my options? In the short term I'm considering disabling the erase feature from the app (at least for now). Anything I am missing and should consider? Thanks in advance.
I did some testing and, with an Android emulator, outputted a few pathways:
Internal Storage context.getFilesDir() has path /data/data/package_name/files
Private External Storage with context.getExternalFilesDir(null) has path /storage/emulated/0/Android/data/packagename/files/
Public External Storage with Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES) has path /storage/emulated/0/Pictures/
In my app, I've defined an object that has a timestamp string and an array for images (more specifically, paths to those images), and this information is stored in a sqlite database.
But is this a bad idea? Because if someone wanted to move this app to another device, wouldn't the paths change? I'm a little confused as to how files can be moved around, how different devices impact this situation, etc. I am confused as to what the correct approach is for storing image references in the sqlite table. Do you store absolute paths like above? Or do you store a number representing whether the pic is internal/private external/public external and pull that way regardless of device/file structure?
I'm just trying to make sure I don't publish an app that lacks some critical feature simply because I misunderstood something. Like if I start using an app that can take pictures/store them internally, it's all on internal storage, all on this phone. But if I want to start saving pics to an SD card or something else, I have to change where I store the pics and how I reference them. And what if I upgrade my phone? I'd have to somehow carry/transfer all that stuff to a new infrastructure, etc. Or the "cloud", even.
In other words I am just trying to understand all the possible use cases, here, in terms of how Android app data is stored and transferred.
Your questions are a little broad. I will try to answer them in turns:
But is this a bad idea?
Not in itself. The issue here is how are you managing changes and the Android alterations that may occur in the future (as well as the versions you are currently supporting)
Because if someone wanted to move this app to another device, wouldn't the paths change?
Relative paths would never change. They were implemented (I am guessing around API 2~6) to ensure that hard disk management would not be necessary in apps. By getting the Enviroment.getExternalFilesDir(stuffs..) you would garantee a path to the same file, regardless of readl disk allocation.
how files can be moved around, how different devices impact this situation, etc.
Files from Desktops (PC, Mac, Linux, Ubuntu, etc) follow a contracted with Android devices, that simulate the same disk system. This way, a PC can save a file (png, mp3, custom, etc) in a "root folder" that becomes the same root for Enviroment.getExternalFilesDir(stuffs..) BUT data private to your application is never accessible (on non-rooted devices), to the outside system.
Do you store absolute paths like above?
You can. But I believe this goes against the system best-practices. Saving a relative path, then building a File object, in regards to that path is the correct approach. Do note that the File class in Android expects you to know a bit about the file you are refferencing.... either its extension, name regex, physical location, relational location, etc... you need to know at least one of those.
Finally, what I think you asked:
Can the user replicate the same content in different devices?
For this, you must ensure that the user is "know" for instance, using the Play Store account, you can then have a repository, and have devices syncronize with that repository. Or even add a "export" function, that copies files, and imports them somewhere else.
I'm developing an app which reads content loaded on my company's server. How can I detect if new files are loaded into the designated folder online or whether any of the existing files has been overwritten in that folder?
From what I've researched so far,
(1) FileObserver seems to be a likely solution, but can it check on a specific URL?
(2) I've used Json's Request.Method.HEAD on a single file to detect updates, but I currently have close to 500 over files (and growing) in that folder and it seems like a potential resource hog to process the header information every time the app loads.
Anyone has suggestion on what functions to use, or library which can help in this scenario?
Many many thanks!
How can I detect if new files are loaded into the designated folder online or whether any of the existing files has been overwritten in that folder?
Have the server notify your app of changes, such as via GCM.
Or, have the server publish some sort of a changelog that you monitor.
FileObserver seems to be a likely solution, but can it check on a specific URL?
FileObserver is for local files.
I've used Json's Request.Method.HEAD on a single file to detect updates, but I currently have close to 500 over files (and growing) in that folder and it seems like a potential resource hog to process the header information every time the app loads.
Agreed. Your problem is on the server. Your server needs to provide the change details in a more efficient fashion.
Create a small API that will have method smth like
List<String url> getAllChangedFiles(long timestamp) that return all files that had been changed from your date. In this case all time consuming logic (like searching for such files) will be on the server, you even could cache it for some reasons.
GCM is not a perfect solution 'cause there is no guarantee that your push notification will be delivered.
I'm developing an app which stores items for the user, and the user has an option to sync with Google Drive. Each item consists of text and image.
My current method is to save a .json and .jpg file for each item internally to the device, and then once onConnected is called from Drive APIs, upload these files to the user's APP folder in Google Drive. Similar with deletion, I would create a flag that an item with name 'foo' has been deleted, then try to see if the files 'foo.jpg' and 'foo.json' exists in Drive, and delete accordingly.
This works for me now, but often I get the app to crash because of googleApiClient errors and I realize that this is not an efficient method. So what I'm wondering is whether any of you guys know a more efficient method to do this?
In the ideal world I would love to have something like this: I save the files for each item to the device internally, and a library tracks these and sync Drive accordingly.
Thanks for advice!
Based on the fact that you are referring to 'onConnected' and 'googleApiClient', I assume that you're using GDAA not the REST Api.
You should re-think the idea of using file names when dealing with GooDrive. They are not unique in GooDrive and the GDAA's latency will sooner or later cause a problem with presence of multiple files with the same name, created by ubiquitous construct:
if file.name not exist
create file.name
The fact that you use APP folder makes debugging even harder since you don't have feedback by looking at the http://drive.google.com.
You should refer to your files by the DriveId (if using only a single Android device) or by the ResourceId (if you intent to send/broadcast the IDs to a different device/app). And if you decide to use the ResourceId, make sure you handle the latency issues caused by delayed GDAA's promotion of objects to the Drive.
This certainly does not fully cover your question, but it is too broad to answer correctly anyway.
Good Luck
this should be an easy one for whoever published Android Apps before...
Here is my situation:
I'm trying to develop a "city guide" app and I was wondering if my idea of working with .XML files to structure my data (the client provided a .PDF file with pictures, address, tel. no, websites, opening hours of the different destinations) is the best way to go.
I was hoping to be able to write this app as an "interpreter" for this type of .XML and then easily include other cities or destinations in a city by updating that input XML file.
So this is not a technical question, I know how to pull this off, the question is if this is a good way to go? How do you keep an app easily up to date? Would a altered XML trigger a Market wide update notification ?
My research lead me to believe that this is a comfortable way to update a published Android Market app (prior to this inquiry I consulted:
http://developer.android.com/guide/publishing/publishing.html
All helpful hints and suggestions will be greatly appreciated.
Regards,
Veo.
Once I developed such kind of an app that had to contain the whole information in itself. I structured it in SQLite database that I was shipping along with the application. The file was not directly readable (or at least easy to read) from the assets folder, but every time when the file was altered I copied the sqlite file to the application storage and used it as ordinary application database. The cool thing is that this way I did not have to pay for the parsing of xml every time the application ran.
Several notes here:
My database grew too big and I had to split it in files of 1MB, because this is the limit for a file in the asset folder. For more info see here:
The database update mechanism with the database version still worked well.
When you create the database manually you need to take into account that Android expects one system table to exist in it (it is automatically created if the database is created in Android code). Basically see this answer here for more info on that.