I'm using parse as my backend and would like to use the rest api to store files.
I've already successfully tested creating new data with the curl request here https://www.parse.com/docs/rest#files Now I would like to see what files I have on my parse.
I don't see any view for these in the data browser. Maybe there's a way to get a listing via a get request? How do I list the files stored on my parse backend?
Note that the column type in the parse data browser will be 'file' denoting 'pointer to a file in the parse CDN'....
treat that like a third party CDN where you also, do not have the 'fileList' capability u ask 4.
live with what u get from the parse browser's inclusion of the pointer, click the field in the browser and , depend on your OS/browser/plugins, it will automatic download/play the file depending on the MIME type you supplied in the headers when u uploaded it.
Remember that you can use the parse dashboard to ask it to delete or GC any files no longer pointed to by active class.rows.
IMO - its not hard to live without what you've asked for as long as you know the other features parse includes with these file type pointers/ refs.
Related
I am using Slim API for my Project. I want to offer Files for Download (Mostly PDF files). I found several Ways sending out a public link to the file, which i dont want. I also found an Middleware for the Version 2.4 of Slim, but I am using 3.x.
I just want to access the Route e.g. /downloads/version/2183
And the a Downlod with this certain File ID should start. I have a Path to the File on the Server in a variable available.
The Basic Idea behind is different restrictions, which user can download the file - but i can do that myself - the problem where I am stuck is, how to bring the Download over the Route to the Clients Browser
Does anyone know how to achieve this?
Cheers,
Niklas
This is actually very easy.
Set the Proper Headers for the file on the Response Object
Read the contents of the file into the body of the Response Object
$app->get('/my/file', function ($req, $res, $args) {
return $res->withHeader('Content-Type', 'application/octet-stream')
->withHeader('Content-Disposition', 'attachment')
->write(file_get_contents("file.txt"));
});
I've experimented with several ways on seeing if I need to update my user's UITableView data source only if the server one is newer. Over the past few years I've done these scenarios: 1: Having a seperate .txt file with a character as the version # then simply comparing them through code and downloading the new .plist, then saving that .txt to the user's NSDocumentDirectory along with the .plist to compare again in the future, and 2: Actually checking the server's file modification date, which worked even better, as there was no .txt file to download along with the .plist (the less stuff to download the better)
But, now I want to try a different way to account for the fact that I ship a .plist file in the App Bundle. Since the .plist file creation date is always later then the server date for new users, they don't get the new .plist file, whereas older users of the app get the new file. Sure, on the first app launch I could grab the server's modification date and overwrite the app's since I copy it from the main bundle to the NSDocumentDirectory, but I don't think I want to go that route, as I've never liked checking launch counts.
Basically, it needs to continue to be lightweight in network request time and be reliable like it's been for me. I was thinking about creating a version # key in my .plist and simply comparing that with the local .plist, but I highly doubt this will be as lightweight, as I would have to download the whole .plist into an NSDictionary first before I can compare the key values.
I'm really sorry this post is long, and I appreciate your help!
Why not ship the app with out the data_source.plist file and download it on first launch, or any other time it does not exist on disk (you never know). After that, you could send a HEAD request and check the modification date (maybe even the e-tag), and download as necessary.
UPDATE:
Depending on how much control you have over the server, you could add a hash of the file to the response headers (as mentioned in the comments: MD5,SHA*) along side Last-Modified.
You could add the data_source.plist to the bundle at build time, along with last_modified.plist where you can set the hash, last modified, and any other meta data you want, as starting point.
Checking for updates could look something like:
Send HEAD request for http://server.com/data_source.plist
Pull Last-Modified (and hash if you can send it) from the response headers
Validate against corresponding values in last_modifed.plist
Download updated data_source.plist if needed
If the download was successful, update last_modifed.plist with new meta data (last modified and has, be sure pull this from actual download response headers).
This way, the user has something to start with, and the app can download the resource when needed.
The advantage of a HEAD request is it is light weight since there is no message body, but returns the same response headers as a GET request. It is a common method to check if a resource has been updated. The trick with your scenario is to get a starting point onto the device at build time.
i'm beginner with GXT and i'm wondering if there is a way to parse a file and extract some informations without uploading it.
i created a formpanel that contains an uploadFile form but i don't know waht's next, how to get the complete path of the file so i can read/write with java io or how to retrieve the file or is there an alternatif solution, thank you.
Best Regards.
You can do it in some modern browsers using bleeding edge HTML5 apis for which you would need to use GWT JSNI code. There are no api's from GWT team as is.
HTML5 FileReader
FileReader includes four options for reading a file, asynchronously:
FileReader.readAsBinaryString(Blob|File) - The result property will contain the file/blob's data as a binary string.
FileReader.readAsText(Blob|File, opt_encoding) - The result property will contain the file/blob's data as a text string.
FileReader.readAsDataURL(Blob|File) - The result property will contain the file/blob's data encoded as a data URL.
FileReader.readAsArrayBuffer(Blob|File) - The result property will contain the file/blob's data as an ArrayBuffer object.
Example of GWT wrapper over these -
https://github.com/bradrydzewski/gwt-filesystem
You can read about it more from here - How to retrieve file from GWT FileUpload component?
IMHO you cannot read it .
Due to security reasons javascript(gwt) doesn't have access to the system drives files.
http://en.wikipedia.org/wiki/JavaScript#Security
see Opening a file in local file system in javascript
In order to get the file you need to make a server call.
Instead you can do your validation server side and throw proper messages to user.
P.S : i am not considering modern browser concept.What happens if someone opened in other than so called modern browsers?? Will the programm runs same?? Its always better to do server side validation..
I wanted to auto fetch data(gold price) from a website and update a variable. Do i have to load the whole .html file in a string and find the price? Is there any other way? Even if I updated the variable, how do i save it, so it retains it's updated value(price)?
Do i have to load the whole .html file
in a string and find the price?
Yes
Is there any other way?
Only if the web site also provides an API that gives you access to just the data you need.
Even if I updated the variable, how do
i save it, so it retains it's updated
value(price)?
A variable will keep it's value until you change it. However if you want to preserve it even when the user quits your app, so that it starts again from the same value, you could save it in NSUserDefaults for example.
Do be aware however, that the data is almost certainly copyright, you can't just scrape data from a website and publish an app based on that data without considering the legal perspective. Price data is normally owned by the exchange and you will need a license to re-publish it.
I have a .NET web service that takes a byte array.
I have a GWT client where I want the user to select a file using the FileUpload control and send it to the web service via HTTP stream.
The file upload control contains a method to get the file path of the selected file. How can I then get that file and convert it to a byte array?
I'm open to suggestions on how to get the file to my web service, not quite sure the Byte array will work...
If you want to convert the file in GWT, meaning in the browser. It's not possible to do in the browser using only JavaScript. FileUpload is a html input type file upload can only send the file to a server as in submit a form. For security reasons browsers can't read files from your file system. (You could use a plugin like a flash plugin to get it to work, although I have no examples at hand).
If you want to send the file content to your webservice, you need to or upload it directly to the webservice or send it to another server, convert it and from that server submit it to your webservice or write or find some (flash) plugin that does it for you.
This link maybe helpful yo you How to convert a byte array to a string, and string to a byte array with GWT
The String(byte[] bytes) constructor and String.getBytes() method are not implemented by GWT JRE emulation String class.
This is not possible purely in Javascript(yet) but could be done with flash or a signed applet. Personally what I would do is create a signed applet that would be somewhere on the page but not visible. When the user selects a file to send to the server you would get the file location from the input and send it to the applet which will load the file and return the data to Javascript as a byte array. If you are flexable with changing the web service to accept multi-part form data then you can do so and just include the file upload field as part of a form and submit the form. Now what you want to do is possible with HTML5 and a demonstration can be seen here, so if you are capable of specifying that the users be using at least a semi-HTML5 compliant browser such as FF3.6 or Chrome 6 you may be in luck.