I'm looking for a way to draw "Lines" above a UIWebView.
I have a UIWebView that display a PDF file, the user should be able to add "Lines" and "Sketches" (simple one color lines etc) for sure this could be done with a UIView on top of the UIWebView but i m running into 2 logical problems.
First can the UIView where the drawing is, be transparent beside the lines - so you can view the pdf through it?
How could i handle the zooming in the PDF, if a user zoom the WebView, the UIView have to zoom "with each other" - so the drawing stays at the same spot/zoom level?
Is there any other way to display a PDF and add drawings/annotations to it? Currently i m using a QLPreviewController where i see no way to add any kind of annotations?
Is three any best practice for this?
PSPDFKit handles this (and many other hard PDF problems) very well. Using a web view for this kind of problem is likely to have many little corner cases. Any commercial product that has non-trivial needs around PDFs should definitely start there. For open source projects I don't have a great answer beyond "yeah, PDFs are a pretty tough; good luck."
That said, here are some starting points that may help you.
You can turn off zooming with webView.scalesPageToFit = false
You can get the current zoom scale using webView.scrollView.zoomScale
I believe you can KVO observe zoomScale to track it while it changes, but you may only get the target value (which will cause you to lag).
You can disable zooming (scalesPageToFit) and then re-implement it yourself with a UIPinchGestureRecognizer and scrollView.setZoomScale(_:animated:). That way you could track the zoom changes better. You could also try to handle the animation yourself with a CABasicAnimation so that you could keep it in sync.
My experience with scroll views, web views, and PDF is that there are a lot of little funny interactions that will surprise you. Getting something that "kind of" works isn't that hard, but getting it really clean, smooth, and beautiful can be a nightmare. That's why I typically recommend PSPDFKit to clients. You'll generally spend much less on the license than on the custom development.
Related
How can I do this "grouping" animation like Apple mail or the Gmail iPad app?
Does this need to be hard coded, and completely done with the animation framework, or does Apple expose an API for this to be done. I checked the developer docs, and I don't see anything like this. But Gmail was able to exactly replicate Apple's animation, and that's why I am curious to know if it can be done in an easier way.
I am 95% sure Apple does not have a UIStackOfPaperViewController or anything like that. You would have to code this up yourself.
Conceptually, it isn't too complicated: a background view with a texture, and each subview tilted at a random angle and a drop shadow beneath. You could do the drop shadow by drawing a gradient in a view around the "real" view. Core Animation's default behaviors would probably do the right thing, e.g. if you create the page view off screen and then set the final location, it will fly onto the stack pretty much how you would like it.
If you don't need support for releases earlier than iOS 6, there's probably good stuff in the Collection View Controller to make this easier.
Hopefully that's enough information to get you started, but your question is really broad. It's difficult to answer "How do I do X?" if you don't specify your starting point, or answer "How can I do this in an easier way?" if you don't specify what you think the hard way is first.
TL:DR
What technique does Apple use to make Photo.app so fast, even with large images?
Long Version
I watched Apple's WWDC 2010 video about scroll views to learn how to replicate Photo.app pagination behavior and low memory utilization (PhotoScroller Demo). It works well, but since images are loaded only when they are needed, when I try to paginate to another image, the app locks while the JPEG is being decompressed.
The same video shows a tiling technique to get better performance, but since I'm using photos taken from the camera and stored in the app, that doesn't seem feasible (having multiple copies of each photo, in different resolutions, would consume too much space - 4MB vs 27MB). Also, using iExplorer I noticed Photo.apps has only a copy of each photo (it doesn't even have a small thumbnail copy for the gallery).
What technique did Apple use to make Photos.app so fast? How can I get that same performance in my app?
I'm a bit confused if this should be here or on Programmers,
since there's no code in the question, but F.A.Q. says that algorithm
questions are part of Stackoverflow, and the tags here match it
better.
So if you just show one image fullscreen you can do this:
In the WWDC11 Session 104 - Advanced Scroll View Techniques they talk about infinite scrolling and how to do it. The basic idea is to scroll the view and after scrolling reposition the (UIImage)view inside the scroll view so it appears centered or whatever you layout constraints are.You could then load the new UIImage into the UIImageView. Since you only have one UIImageView it should be pretty low memory consuming. I am not sure about how the loading times of the images will behave though.
Maybe preload the next UIImage to the left and right to the current image and then load it into the UIImageView after reposition the scrollView can help here.
For anyone who is still looking for simply implementation of scroll view that hold lot's of images.
https://github.com/sumofighter666/ReusableScrollView
It is as simply as implementing UITableView
I am spec'ing out an iOS app and there is a piece that is a run-on section that will need to scroll. I was thinking of doing it as a UIScrollView (have never used one but seems logical) but it sounds like the contentSize always needs to be calculated. This could be extremely variable in this case (UGC images etc...). Is this correct? Or is there a legitimate workaround? If not, would a UIWebView be the better solution?
The app functionality would be like a FB feed or Instagram. Is it known what they use (FB looks like UIWebView to me).
thx
Actually it depends on what you are trying to achieve. If you use the web view you will have to generate html code to feed it and if you have buttons, you probably have to generate more html/css/js to make everything work. Using the scroll view is not a pain... Calculating the content size is easy... All your elements' height + some offset between them. Its bounds will remain always the same, you should only set the content size.
In my experience , I have the client-side web application development experience before iOS development .For the first time, I though UIWebView is pretty easier than UIScrollView because I can handle html/css/javascript as my wish.
But I found some problem with UIWebView Performance. If you have complex functional usability and large amount of data loading. So I try to implement with UIScrollView, Of course, It's quite not easy for me to create complex View with UIScrollView but when I've been familiar with the implement instruction. I think UIScrollView have a better performance then UIWebView ,especially complex layout and usability.
I recommend you to use both of them base on situation.
For some simply ViewController that just display an information with less complicate use, UIWebView is fine if you have familiar client-side web application development.
For some complex usability, It may not easy to implement with UIScrollView but It's quite OK for performance issue.
I'm currently scoping out a project for the iPad which is rather text and font heavy. There are many pages of styled text, which also need custom fonts. I have toyed with the idea of simply rendering PDF or PNG files on-screen, but I think we need to be able to dynamically repaginate the text.
We've used UIWebView in a previous project quite successfully, however there are a few things I don't like about it... Firstly, you have to hide all the silly drop shadow elements to stop them showing when the user scrolls beyond the bounds, and we had to add some JavaScript to find out actually when a page had fully loaded. Overall, the experience seemed a bit clunky, as well as worrying if the project could potentially break if Apple decided to update the subviews...
The other thing we've been looking at is Core Text, which looks very powerful. The only worry with this is that it appears to be a rather steep learning curve for us since we've mainly been working in UIKit (with a bit of Core Graphics). I couldn't even work out how to change the size of the font after a morning's work.
Are there any other alternatives*? Should I stick with Core Text? Is there any way of using UITextView with multiple fonts and styles?
Thanks!
:-Joe
EDIT: *by alternatives, I am really looking for built-in iPhone SDK alternatives only please... I would rather not mess with third party frameworks because I don't have the time... Thanks :)
You could use Pango, which uses CoreText when on iOS.
I'd need to create a iPad-app which would be rendering multiple PDF-Files (one file contains one page).
Each page should be scrollable, zoomable and if the user taps on a part of the PDF a website or photo gallery should popup.
Currently i think i could do that either with:
A. UIWebView
Displays the pdf's nicely, scrolling and zooming works. But it looks like a lot of trouble to realize the clickable parts of the PDF.
I don't know if i could use CGPDFContextSetURLForRect
Getting the touch-events from UIWebView to do something like CGPDFContextSetURLForRect my self looks like it would be some "quite bad" hack. See: http://github.com/psychs/iphone-samples/blob/master/WebViewTappingHack/Classes/PSWebView.m
B. Quartz
I found some resources describing how to display PDF's directly via Quartz.
See:http://developer.apple.com/iphone/library/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_pdf/dq_pdf.html
This would allow using CGPDFContextSetURLForRect
But i have no idea if this would - like UIWebView - support scrolling and zooming out of the box?
Anybody could enlighten me on this please?
Thanks for your time!
[Edit: changed 3.0 to 3.2]
[Edit: my "solution"]
Hi!
I could come up with a working implementation for PNG but not for PDF's.
[Abstract]
My sollution was Rendering the content, intercepting the touches on it, retreiving the coordinates relative to the displayed content if it is one touch and finally looking up what to do from a mapping containing the interactive areas as coordinates and what to do if they get clicked.
[For PNG]
It was way more cumbersome to implement somethink like that than i would have imagined...
And the implementation i got working depends heavily on the content you want to display because this does work for UIImageView but i could not get it working with UIWebView.
First you need a UIScrollView and UIImageView to render the content and support scrolling/zooming.
Then you need to implement some handling to get the touches/gestures you are interested in.
See: developer.apple.com/iphone/library/samplecode/ScrollViewSuite/Listings/1_TapToZoom_Classes_TapDetectingImageView_h.html
This sample from apple provides everything you need to get this part working.
As a bonus it also takes care about transforming the coordinates relative to the viewport of the content which is very handy! (else you would only know where the tap happend on the screen wich only one half of the info you need if your content is zoom-/scrollable)
[For PDF]
If you want to do this with PDF the first thing would be that you need to use a UIWebView (probably you could do it via Quartz or something else too)
Getting the touches with a UIWebView is a real pain!
There are a lot of ways proposed on the web and besides one noone did what it should do.
After days of googling i found this gem: cocoawithlove.com/2009/05/intercepting-status-bar-touches-on.html
So... subclassing UIWebView does not get you anywhere unlike UIImageView and you have to subclass UIApplicationMain and implement its method for handling touch-events.
Here you could reuse some of the "Touch-Handling-Stuff" from the apple-examlpe from above.
Now you would need to translate the coordinates of the touch to your content if it is zoom-/scrollable. UIWebView DOES NOT do this for you unlike UIImageView!
I could never figure out how to get the required information(what part of the content at which zoomlevel) from a UIWebView to translate the coordinates but due to the changed requirements from PDF to PNG i didn't care to get it working too much.
hope this helps.
Using the CGPDF* operators will allow you to write a UIPDFView, which operates exactly as UIImageView but uses a PDF as the source image. Create your own custom subclass of UIView and implement drawRect: to, eventually, call CGContextDrawPDFPage. Based on a quick Google search (because I know the keywords), this page seems to explain that side of things quite well.
You can then directly substitute your custom UIView subclass for the UIImageView and proceed exactly as you have with the PNG solution.