I have an HTML5 application that allows users to drag-n-drop an image to a canvas, or alternatively, browse for it on their local disk. Once I got the image, I display it in the canvas using context.drawImage(). Got all the kinks out and it works great.
BUT. Now my customer want to use it on an iPad. Drag-n-drop is out of the question (the browser is a full window on iDevices). But the browse functionality, which is basically an input of type file, doesn't work either.
To clarify, the behavior I need is selecting an image from the gallery and displaying it in a canvas.
Any ideas on how I can achieve this?
Thanks for your time.
Unfortunately, there are no satisfying answers for this.
http://learnbythedrop.com/forum/iphoneipad-safari-image-upload-resrictions
Basically, mobile safari is pretty severely sandboxed – file uploads don't work, can't grab files from photos, etc.
With iOS 5 there may be a solution for this using iCloud. Content is stored and pushed to mobile devices. Perhaps you'll be able to access the image from your photo stream?
Alternately, you could use a service like photo bucket or flickr to store your images, then use the API to access them from your page.
Related
I am working on an iOS app where the users can add description/text when uploading images like Snapchat.
Do they render images and add the text to image so that it becomes part of the image itself or is it shown as a UILabel over the image?
For the 2nd option the text would have to be sent separately to server.
P.S. Just having an argument with Server side programmer and I'm suggesting the 2nd option.
If we check /ph/upload in Snapchat API (last updated 23-12-2013) we can see that you can upload either a photo or a video.
Of course, this is not the latest version (although this is the last documentation I could find) but I am assumming nothing has changed in that regard.
That means the text is inserted to the photo in the mobile client app, not on the server.
In my opinion, you shouldn't base any decisions about your API architecture on Snapchat because it's unlikely you have the same use cases. In general:
Sending data separately is more flexible and makes client implementation simpler.
Rendering data on the client is better for user experience (everything is faster and the user can see the final result) and also it saves a lot of server resources (the more users you have the more this will be visible).
Here im hitting my head againt the wall.
My client provided a pdf with buttons(just like buttons,when user tap on button,it will load next page and previous page etc.).
This buttons will work only when we open it in adobe reader.
I tried the QLpreviewview,quickview but it is not working,all what i can do is just to load the pdf in the webview.
Can anyone please help me in how to load an interactive pdf in iOS.
Thanks in advance.
Have a look at PSPDFKit, it is the most advanced framework I've found for PDFs in iOS. They have an impressive list of customers as well.
It is a bit pricy though, but you have the option to get the Source Code too if you need to modify anything. Could be worth it if your client need that kind of performance and other features as well.
(I am not in any way affiliated with PSPDFKit)
The limitations are due to the capabilities (or non-capabilities) of the PDF viewer used.
Currently the leading PDF viewer on iDevices is PDFExpert by Readdle. Adobe Reader for iDevices is weaker, but can deal to some extent with form elements.
For page navigation etc. you might use links instead of button fields (as far as you can live with the capabilities of links, and not use JavaScript). Links are said to be handled properly with many PDF viewers.
You may have to require certain PDF viewers on instructional level, because you don't have control over the viewer used by the actual user. And, as you noticed, many PDF viewers are simply too dumb do deal with active elements.
Another approach would be looking at PDF-to-HTML5 converters, and serve HTML5 from a server.
Like the title says. In an iPhone, in what directory do Instagram/Facebook (and similar applications) store the images they downloaded at runtime?
When is that directory wiped?
For non permanent images (e.g. post thumbnails but not user profile pics) I would imagine they get stored in the <Application_Home>/Library/Caches, other content probably goes in Documents
You don't need to know what facebook or instagram do, but If I understand your question right, you want to download images asynchronously from web and cache them. For that u can use a third party class to handle the caching instead of writing your own, I would suggest SDWebImage.
Does anyone have any ideas how I could package an external interactive slide that could be dynamically loaded by an iOS app? Is it at all possible?
e.g. Imagine having a presentation app on an iPad. There is a set of interactive slides held on the web somewhere, let's say they contain draggable elements.
Can I load one of these slide objects into the app and interact with it? If so, what format would the slide object be?
Thanks,
Mark
Technically it's possible to dynamically load bundles (NSBundle) components in an app. These bundles could even contain executable code, though AppStore guidelines prohibit use of dynamically loaded NSBundles in this way for security reasons.
Additionally you could just use a UIWebView to display some 'slides' on a webpage, though it will be very hard to make the app behave as if it's the same as the native slides - perhaps even impossible (due to how rendering of webpages work compared to native controls, for example).
Ok so lets say you have these "external interactive slides" on a web server somehow. Since you are not saying they are of a certain type (like powerpoint or such) I will just assume that these slides are of some rare format that is probably not supported by any existing apps or the Safari browser.
Then the answer to your question would be: Write your own iOS-app that can read, present and edit these slides. What format are they? Well it doesn't matter. Write an app that can download the slide data from the data and parse it, and present it on the phone.
Then let the user interact with it, and perhaps make the app upload the changes to the server.
You can do anything you like in your app, there are no limits. You just have to write the code for it. If there was some kind of standardised format, lets say you wanted your app to show powerpoint presentations, then you would have 3 choices. Use someone else´s app, or write your own app with a parser for the powerpoint files or make your own app that use some code that someone else wrote to do it (a third part library that you include in your app)
In your specific case, I can not tell if there are any third part librarys to interact with your slides, but my guess is that you will need to do most of it on your own. You could start with looking at how the web services that interact with the slides online works, and if you can interact with them from an iOS-app that you make yourself.
There is nothing stopping you from creating an app, read the slide data into the app, present it in any way you like, let the user change it, save it in your app, or upload the changes to a server. It's all up to you =)
Good luck!
I have a website written in php / javascript. It's quite simple, basically :
on the first page it shows a list of category
when a category is clicked, a new page is displayed with a list of pictures (that can be clicked to get a bigger version, using AJAX) and some text details
I'd like to be able to browse this site offline on an iPad, what would be the better way ?
I saw it is possible to add some html5 caching capability, would this be the way to go ?
You should try the HTML5's caching and/or persistent storage feature. You can save app data or even whole files, and either access them from JavaScript to display, or ask the browser to seamlessly display the cached files when there's no Internet connection. Some links may help:
http://www.html5rocks.com/en/tutorials/appcache/beginner/ <- this one is the caching-related
http://dev.w3.org/html5/webstorage/ <- and this is about persistent storage.
Hope that helps, Árpád