페이징이 활성화되고 확대 / 축소 된 UIScrollView 이미지 / 사진 뷰어

페이징이 활성화되고 확대 / 축소 된 UIScrollView 이미지 / 사진 뷰어

---

좋아요, UIScrollView이제이 문제에 대해 인터넷에 공식적인 장소를 만들 때라고 생각합니다 . 페이징과 확대 / 축소 기능으로 포토 뷰어 를 만드는 방법 입니다. 동료 UIScrollView해커를 환영합니다 .

나는이 UIScrollView페이징 활성화, 나는 표시하고있어 UIImageViews내장 된 사진 응용 프로그램처럼. (아직 익숙한 소리인가요?)

github에서 다음 프로젝트를 찾았습니다.

https://github.com/andreyvit/ScrollingMadness/wiki

페이징이 활성화되어있는 동안 스크롤 뷰에서 확대 / 축소를 구현하는 방법을 보여줍니다. 다른 사람이 이것을 시도하면 실제로 UIScrollView하위 클래스 를 제거 하고 네이티브 클래스를 사용해야했습니다. 그렇지 않으면 작동하지 않습니다. 스크롤 뷰가 터치 이벤트를 가로채는 방식과 관련된 3.0 SDK의 변경 사항 때문이라고 생각합니다.

따라서 아이디어는 확대 / 축소를 시작할 때 다른 모든보기를 제거하고 현재보기를에서 (0, 0)으로 이동하여 scrollview등을 업데이트하는 것입니다 contentsize. 그런 다음 1.0f로 다시 확대하면 다른보기가 다시 추가되고 모든 것이 순서대로 돌아갑니다.

어쨌든 그 프로젝트는 시뮬레이터에서 완벽하게 작동하지만, 장치에서 크기를 조정하는 뷰의 불쾌한 움직임이 있습니다. 이것은 크기가 조정 되는 뷰에 대해 contentsize/ offset등을 변경한다는 사실로 인해 발생하는 것처럼 보입니다 . 이보기를 이동해야합니다. 그렇지 않으면 다른보기가 남긴 공백을 통해 왼쪽으로 이동할 수 있습니다.

3.0 SDK 릴리스 노트 의 "알려진 문제"에서 흥미로운 노트를 발견했습니다 .

UIScrollView : 확대 / 축소 후 콘텐츠 삽입이 무시되고 콘텐츠가 잘못된 위치에 남아 있습니다.

이런 종류의 소리는 여기서 일어나는 일처럼 들립니다. 확대 후 오프셋 등을 변경했기 때문에 뷰가 화면 밖으로 이동합니다.

나는 이미 이것에 대해 몇 시간을 보냈고 이것이 작동하지 않을 것이라는 슬픈 깨달음을 느리게하고 있습니다.

Three20의 사진 뷰어는 의문의 여지가 없습니다. 너무 무겁고 불필요한 UI 및 기타 동작이 너무 많습니다.

내장 된 사진 앱이 마법을 부리는 것 같습니다. 이미지를 확대하고 먼 가장자리로 이동하면 현재 사진이 옆에있는 사진과 독립적으로 이동하며 이는 표준으로 시도 할 때 얻을 수있는 것이 아닙니다 UIScrollView.

의 중첩에 대한 토론을 보았지만 UIScrollView실제로 가고 싶지 않습니다.

누구든지 표준으로 이것을 관리 UIScrollView했습니까 (2.2 및 3.0 SDK에서 작동)? 나는 내 자신의 줌 + 바운스 + 팬 + 페이징 코드를 굴리는 것을 좋아하지 않습니다.

---

최신 정보

아래 뉴스 때문에 이전 답변을 삭제했습니다 ...

듣지 못한 사람들을위한 큰 뉴스. Apple은 iPhone 개발자 프로그램의 모든 구성원에게 2010 년 WWDC 세션 비디오를 공개했습니다. 논의 된 주제 중 하나는 그들이 사진 앱을 만든 방법입니다 !!! 그들은 매우 유사한 앱을 단계별로 빌드하고 모든 코드를 무료로 제공했습니다.

개인 API도 사용하지 않습니다. 다음은 샘플 코드 다운로드 링크입니다. 액세스하려면 로그인해야합니다.

이것을 확인하십시오

그리고 다음은 iTunes WWDC 페이지에 대한 링크입니다.

이것을 확인하십시오

---

MWPhotoBrowser 라는 간단하고 사용하기 쉬운 사진 브라우저를 작성했습니다 . Three20이 너무 무겁거나 부풀려서 제작하기로 결정했습니다. 필요한 것은 사진 뷰어뿐이었습니다.

MWPhotoBrowser는 UIImage 객체 또는 파일, 웹 이미지 또는 라이브러리 자산에 대한 URL을 제공하여 하나 이상의 이미지를 표시 할 수 있습니다. 사진 브라우저는 웹에서 사진의 다운로드 및 캐싱을 원활하게 처리합니다. 사진을 확대 / 축소하고 이동할 수 있으며 선택적 (사용자 지정 가능) 캡션을 표시 할 수 있습니다. 브라우저를 사용하여 사용자가 격자 또는 기본 이미지보기를 사용하여 하나 이상의 사진을 선택할 수도 있습니다.

---

UIScrollViews 중첩에 대한 논의를 본 적이 있지만 거기에 가고 싶지 않다고 말합니다.하지만 그게 방법입니다! 쉽고 잘 작동합니다.

본질적으로 Apple이 PhotoScroller 예제에서 수행하는 작업입니다 (및 Jonah의 답변에 연결된 2010 WWDC 토크). 이 예제에서만 복잡한 타일링 및 기타 메모리 관리를 추가했습니다. 타일링 등이 필요하지 않고 이러한 예제를 살펴보고 관련 비트를 제거하고 싶지 않다면 UIScrollViews 중첩의 기본 원칙은 실제로 매우 간단합니다.

• 외부 UIScrollView를 만들고 pagingEnabled = true로 설정합니다. 기본보기에 추가하고 너비와 높이를 기본보기의 너비와 높이로 설정합니다.

• 이미지를 원하는만큼 내부 UIScrollView를 만듭니다. 너비와 높이를 기본보기의 너비와 높이로 설정합니다. 왼쪽에서 오른쪽으로 나란히있는 외부 UIScrollView에 하위보기로 추가합니다.

• Set the content size of the outer UIScrollView to the total of the widths of all the inner UIScrollViews side by side (which is equal to [your main view's width]*[number of images]).

• Add your images' UIImageViews to the inner UIScrollViews, one UIImageView to each inner UIScrollView. Set each UIScrollView's content size to each UIImageView's size.

• Set min and max zoom scales for each inner UIScrollView and set each of the inner UIScrollView's delegate to your View Controller. In the delegate's viewForZoomingInScrollView, return the appropriate UIImageView for the UIScrollView that is passed. (To do this, just keep each of the UIImageViews in an NSArray and set the corresponding UIScrollView's tag property to the index of the appropriate UIImageView. You can then read the tag in the UIScrollView passed to viewForZoomingInScrollView and return the appropriate UIImageView from the NSArray).

That's it. Works just like the photo app.

If you have a lot of photos, to save memory you can just have two inner UIScrollViews and two UIImagesViews. You then dynamically flip between them, moving their position within the outer UIScrollView and changing their images as the user scrolls the outer UIScrollView. It's a bit more complex but the same principle.

---

I did some playing around with the native Photos app, and I think I can say with confidence they are using a single UIScrollView. The giveaway is this: zoom in on an image, and pull to the left or right. You will see the next or previous photo. If you tug hard enough, it will even page to the next photo at 1.0f zoom. Flip back and the previously zoomed photo will be back to 1.0f zoom as well.

Obivously I didn't write Photos.app, but I'll take a wild guess at how they did it:

• A single UIScrollView and a single UIScrollViewDelegate
• Populate the UIScrollView with UIImageView children
• Listen for scrollViewDidScroll:
• Do some math and figure out what page you are currently on
• Listen for viewForZoomingInScrollView:
• Return a different view depending on the page index
• Listen for scrollViewDidEndZooming:withView:atScale: and optionally do some anti-aliasing, etc based on the content

If you decide to try that out, let me know how it works out for you. I'd love to know how you finally end up getting this to work. Even better, post it to github.

---

I did some playing around with the native Photos app, and I think I can say with confidence they are using a single UIScrollView. The giveaway is this: zoom in on an image, and pull to the left or right. You will see the next or previous photo. If you tug hard enough, it will even page to the next photo at 1.0f zoom. Flip back and the previously zoomed photo will be back to 1.0f zoom as well.

This is wrong. I'm using nested scrollviews, and getting exactly the same effect. If you're using some memory management scheme (which I had to start using... my page number is fairly high ('bout 50 each in 2 scrollViews)), then you can use a mechanism similar to whatever you have triggering your page loads / unloads to trigger a zoom reset for the pages -1 and +1 from the current page.

I suspect that apple sets this off as soon as the previous pic has disappeared.

What I don't understand is how to achieve smooth scrolling between pages - there's always a very short hang at the moment of transition. Do not get it. I've gotten pretty deep into fixing it - NSInvocationOperations were my first stop, then I made a reusable views queue for the page views (which retain their image views)... still this durned hang.

I only have one NSOperationQueue running, and I've tried fiddling with the max number of concurrent operations. My thought was that the main thread was getting clogged by competing Queues, or maybe even one queue trying to do to much... still, the hang.

I even tried creating super low-qual versions of my media, in case that was the problem. With each image weighing in at around 10k (these are jpegs, mind you)... you guessed it. The hang's still there.

I'm pretty much resolved to do what I've done before and use TTPhotoViewController from Three20. I've spent some hours swimming through that code, and it's always a great education. At this point, though, I would really like to know where the heck this hang comes from, if only so I can spend my can't-sleep hours wondering about something less brain boiling.

---

sure would be nice if apple built an image viewer like the photos app into the SDK for us to use. I'm currently using three20 and it works great. But it is a lot of extra stuff to carry around when all you really want is the photo viewer.

---

나는 그것에 대한 코드를 작성하고 참조로 사용할 수 있습니다.

1. 현재보기 scrollview 및 imageview ..로드 및 현재보기 옆에있는 화면의 경우 imageview 만

2. 현재 페이지가로드 될 때 모든보기를 제거하여 메모리를 절약하므로 많은 사진 프로젝트에 적합합니다.

3. 태그를 사용하여 다른 스크롤보기를 구별하십시오.

_xxxx xxx

다운로드 링크는 여기를 클릭하십시오

---

https://github.com/facebook/three20/blob/master/src/Three20UI/Headers/TTPhotoViewController.h를 살펴보십시오. 원하는 항목인지 확실하지 않습니다.

참조 URL : https://stackoverflow.com/questions/975708/uiscrollview-image-photo-viewer-with-paging-enabled-and-zooming