I am trying to save my NSData using writeImageDataToSavedPhotosAlbum.
My NSdata size is '49894' and I saved it using writeImageDataToSavedPhotosAlbum. if I read my saved image raw Data bytes using ALAssetsLibrary, I am getting my image size as '52161'.
I am expecting both as same. Can somebody guide me what is going wrong ?
Below link also not providing the proper solution.
saving image using writeImageDataToSavedPhotosAlbum modifies the actual image data
You can not and should not rely on the size, firstly because you don't know what the private implementation does and secondly because the image data is supplied with metadata (and if you don't supply metadata then a number of default values will be applied).
You can check what the metadata contains for the resulting asset and see how it differs from the metadata you supplied.
If you need to save exactly the same bytes, and / or you aren't saving valid image files then you should not use the photo library. Instead you should save the data to disk in your app sandbox, either in the documents or library directory.
Related
Given 2 RenderPasses, A and B, and an attachment X accessed by both, if A does a .storeOp=store on X on its last subpass, and B does a .loadOp=load on X on its first subpass, can B read from X as an input attachment?
Futhermore, I can think of 3 ways of reading attachment data from a previous RenderPass.
Using a sampler.
(Potentially) as an input attachment.
As a storage image.
Are there any other ways?
Once a render pass instance has concluded, all attachments cease to be attachments. They're just regular images from that point forward. The contents of the image are governed by the render pass's storage operation. But once the storage operation is done (subject to the correct use of dependencies), the image has the data produced by the storage operation.
So there is no such thing as an attachment "from a previous RenderPass". There is merely an image and its data. How that image got its data (again, subject to the correct use of dependencies) irrelevant to how you're going to use it now. The data is there, and it can be accessed in any way that any image is access, subject only to the restrictions you choose to impose.
So if an image has some data, and you use it as an attachment, and you use a load operation of load, the data in that attachment will have the image data from the image before becoming an attachment regardless of how the data got there. That's how load operations work.
I understand that in order to upload a file to Amazon S3 using Multipart, the instructions are here:
http://docs.aws.amazon.com/AmazonS3/latest/dev/llJavaUploadFile.html
How do I go about replacing the bytes (say, between the range 4-1523) of an uploaded file? Do I need to make use of Multipart Upload to achieve this? or do I fire a REST call with the range specified in the HTTP header?
Appreciate any advice.
Objects in S3 are immutable.
If it's a small object, you'll need to upload the entire object again.
If it's an object over 5MB in size, then there is a workaround that allows you to "patch" a file, using a modified approach to the multipart upload API.
Background:
As you know, a multipart upload allows you to upload a file in "parts," with minimum part size 5MB and maximum part count 10,000.
However a multipart "upload" doesn't mean you have to "upload" all the data again, if some or all of it already exists in S3, and you can address it.
PUT part/copy allows you to "upload" the individual parts by specifying octet ranges in an existing object. Or more than one object.
Since uploads are atomic, the "existing object" can be the object you're in the process of overwriting, since it remains unharmed and in place until you actually complete the multipart upload.
But there appears to be nothing stopping you from using the copy capability to provide the data for the parts you want to leave the same, avoiding the actual upload then using a normal PUT part request to upload the parts that you want to have different content.
So, while not a byte-range patch with granularity to the level of 1 octet, this could be useful for emulating an in-place modification of a large file. Examples of valid "parts" would be replacing a minimum 5 MB chunk, on a 5MB boundary, for files smaller than 50GB, or replacing a mimimum 500MB chunk on 500MB boundary for objects up to 5TB, with minimum part sizes varying between those to extremes, because of the requirement that a multipart upload have no more than 10,000 parts. The catch is that a part must start at an appropriate offset, and you need to replace the whole part.
Michael's answer is pretty explanatory on the background of the issue. Just adding the actual steps to be performed to achieve this, in case you're wondering.
List object parts using ListParts
Identify the part that has been modified
Start a multipart upload
Copy the unchanged parts using UploadPartCopy
Upload the modified part
Finish the upload to save the modification
Skip 2 if you already know which part has to be changed.
Tip: Each part has an ETag, which is MD5 hash of the specified part. This can be used to verify is that particular part has been changed.
I have a NSData object, obtained from a URL request.Now I don't know how to read it.
However in my application I don't know if the data contains a video or not, so I would know:
How to know if NSData has some video inside it?
How to interpret the data, reading it byte per byte?
I'm not familiar with the particular API you're using so I can't say what the code should be, but any web/HTTP client library should provide you the Content-Type of the data as well as the data itself. Use the Content-Type (and only the Content-Type; doing otherwise can lead to security bugs) to determine how to interpret the content. For example, if the Content-Type (also known as MIME type) starts with video/, then the content is definitely video; the part after the slash will tell you the specific format to interpret it as.
If you intend to play the video that the data may contain, then just do that. Whichever playback API you use should give you an error if the data isn't anything it recognizes.
I have a requirement where user can upload files present in app to SharePoint via same app.
I tried using http://schemas.microsoft.com/sharepoint/soap/CopyIntoItems method of sharepoint. But it needs file in base64 encoded format to be embedded into body of SOAP request . My code crashed on device when I tried to convert even a 30 MB file in base64 encoded string? Same code executed just fine on simulator
Is there any other alternative to upload files (like file streaming etc) onto sharepoint?? I may have to upload files upto 500 MB? Is there more efficient library to convert NSData into base64 encoded string for large file???
Should I read file in chunks and then convert that into base64 encoded string and upload file once complete file is converted? Any other appraoches???
First off, your code probably crashed because it ran out of memory. I would do a loop where I read chunks that I converted and then pushed to a open socket. This probably means that you need to go to a lower level than NSURLConnection, I have tried to search for NSURLConnection and chunked upload without much success.
Some seem to suggest using ASIHttp, but looking at the homepage it seems abandoned by the developer, so I can't recommend that.
AFNetworking looks really good, it has blocks support and I can see in the example on the first page how it could be used for you. Look at the streaming request example. Basically create a NSInputStream that you push chunked data to and use it in a AFHTTPURLConnectionOperation.
Im currently implementing an update feature into an app that I'm building. It uses NSUrlConnection and the NSURLConnectionDelegate to download the files and save them to the users device.
At the moment, 1 update item downloads multiple files but i want to display this download of multiple files using 1 UIProgressView. So my problem is, how do i get the expected content length of all the files i'm about to download? I know i can get the expectedContentLength of the NSURLResponse object that gets passed into the didReceiveResponse method but thats just for the file thats being downloaded.
Any help is much appreciated. Thanks.
How about having some kind of information file on your server, which actually gives you the total bytes. You could load that at first and then load your files. Then you can substract the loaded amount for each file from the total amount.
Another method would be to connect to all files at first, and cancel the connection after you received responses. Add the expected bytes of all files and then use that as a basis for showing the total progress while loading files.
Downside of #1: you have to manually keep track of the bytes.
Downside of #2: you'll have the double amount of requests, even though they get cancelled after the response.
Use ASIhttp opensource framework widely used for this purpose,
here u just need to set progressview delegate..so it will keep updating your progress view
Try this
http://allseeing-i.com/ASIHTTPRequest/