I could not find the location in my phone for the data stored when using the App-inventor Companion. Can somebody help me in this?
The "AppInventor>assets" contains the pictures used in the app when using the companion but there is no database. I am using TinyDB.
to delete the assets, delete the directory /AppInventor on your device using a file manager app
to delete TinyDB, use the method TinyDB.ClearAll
Related
We are using Apple's new api NSFileProviderReplicatedExtension to implement a file provider extension.
We can use this extension to synchronize files from a remote file server.When there are changes on the server，we can signal workingset to update the local copy.
But when a directory with many files is deleted on the server, we can't delete this directory by calling observer.didDeleteItems.Can someone give me some advice?
The Apple's documents is here:enter link description here
I am writing an app which uses CoreData using NSPersistentContainer to save data.
While I am developing the app, I would like to:
examine the data directly
back up the data
see what happens when I change the bundle id
I assume the data is physically stored somewhere, but I’m not sure where to look.
By default NSPersistentContainer stores the database inside app container under directory Libray/Application Support
To locate the full path, in simulator, you can print the applicationSupportDirectory using urls(for:in:) function of the default FileManager:
print(FileManager.default.urls(for: .applicationSupportDirectory, in: .userDomainMask).first?.path ?? "nil")
If you are running your app on an actual device you can download the application container following this answer.
For sandboxed apps the location goes like this:
~/Library/Containers/…/Data/Library/Application Support/…
im fairly new to laravel and im currently working on a project that needs to store files in the server. What im doing is store it under public/docs the problem is the files under that directory is accessible all the time given that they know the url to the certain file. for example even if they are logged out if they know this url http://localhost/dummy/public/uploads/docs/2016-06-02-10-52-43-oth-content-inventory-and-planning-spreadsheet.pdf they would be able to access it what im thinking is to do something like this
in my routes i would do something like
Route::any('uploads/docs/' , 'go to some controller to check if user can acces');
is this possible? thanks in advance!
it's called public for a reason...
you should use storage instead (laravel 5) in storage you dont restrict access, actualy the opposite, you grant access to the file .
try this for laravel 4.2 (move the file after upload like this to a storage folder)
Input::file('file')->move(__DIR__.'/storage/',Input::file('file')->getClientOriginalName());
});
Anyway ,the conclusion is that you can't restrict access (you shouldn't even if there is a way) because it's meant to be public ! so you should use storage folder(or whatever its called in laravel 4)
We are collaborators on a Parse.com App and we need to recreate the App in another account as we are ending our relationship with the original App creators.
We have copied all the classes and exported all the data from the previous App but are getting errors with the JavaSript API (Access Denied/403 issue). Has anyone else experienced this? What did you do to overcome the problem?
Thanks!
The Parse.com dashboard has export to JSON which you can then import from the data browser on your second app.
Object IDs will not be preserved.
One big thing to be aware of:
Any referenced PFFiles are NOT exported, so all the references in your rows are not valid, as the new database is not part of the ACL of the old PFFiles.
Either export+import the PFFiles manually, or change the ACLs, if that is indeed possible.
Is it possible for extensions access the containing-app's container directory?
For iOS5-based app, i don't want to move all my old data into shared-contatiner, i wish that main-app can remain the same, and the extension just read & write the old data directly, that will be perfect!~
Your widget may never access the containing app's data directly, only if the containing app puts that data into a shared container using app groups. The documentation (including the WWDC videos) is pretty clear about this.
There's a high chance that your iOS-5-based app needs major changes anyway to work nicely on iOS 8.