페이징을 허용하기 위해 가로 스 와이프를 감지하는 UITableView를 어떻게 구현합니까?

Question

한 번에 20 행을 표시하는 UITableView를 구현하고 싶습니다. 하지만 실제로 120 개의 항목을 말할 수 있다는 사실을 감안할 때, 나는 일종의 페이징을 사용하여 이것을 처리하고 싶습니다.

처음 20 개 항목으로 표를 채 웁니다. 사용자가 오른쪽에서 왼쪽으로 스 와이프하면 다음 20 개 항목으로 UITableView를 다시로드하십시오. 왼쪽에서 오른쪽으로 스 와이프하면 이전 20 개 항목이 표시됩니다.

UITableView를 서브 클래 싱하고 거기에 UITouches를 처리하는 방법이 있다고 생각하지만, 표준 이벤트 처리를 방해하지 않기 위해 터치를 올바르게 처리하는 방법을 잘 모르겠습니다.

예 : 사용자가 행을 만지기 만하면 행을 강조 표시 (선택) 한 다음 선택한 행에 해당하는 데이터를 표시하는 상세보기로 전환합니다. 하지만 사용자가 가로로 스 와이프를하면 스 와이프 아래의 행을 강조 표시하지 않으므로 대신로드 사전 페이지/loadnext 페이지 처리를 트리거하고 싶습니다. 스 와이프 방향에 따라 20 개의 이전 또는 다음 항목.

제안 사항?

Answer 1

이것은 매우 비표준적인 UI 패러다임입니다. 확실히 연락처 앱처럼 120 개의 항목을 위아래로 스크롤 할 수 있습니다. 자신의 삶을 더욱 복잡하게 만들고 있습니다. 이상한 UI로 인해 애플이이 앱을 거부 할 심각한 위험이 있습니다.

이를 구현하는 것하는 실제 방법은 내가 거기에 코드를 읽었습니다 http://forums.macrumors.com/showthread.php?t=532573

에 설명되어 있으며,이 또한 touchUpInside을 처리 할 수 ​​있다는 것을 나에게 발생하지만, 현명한보고, horizonal swipe에서 셀을 선택하지 않으려면 [super touchUpInside]로 전화하지 마십시오.

Answer 2

테이블 행의 가로 스 와이프는 이미 해당 행을 삭제하도록하는 표준 UI 동작입니다. 표준 UI 패러다임을 변경하지 마십시오. 사용자를 혼란스럽게 만들고 앱을 싫어하게 만듭니다.

Answer 3

그냥 내가 정말 jQuery과 하위 클래스 것이이 작업을 수행하고있는 UIScrollView에 사본을 여러 개 추가하고 싶었다면 슬쩍 당신의 기능

Answer 4

을하지 터치 points.Then과 적외선을 발생되어 있는지 확인이 방법을 취소 터치 전화 . 이벤트를 풀어 놓는 것은 무서운 일이며 UI가 그만한 가치가 있다고 생각하지 않습니다.

Answer 5

실제로 나는 Airsource Ltd에서 언급 한 코드를 http://forums.macrumors.com/showthread.php?t=532573에 작성 했으므로 내 코드를 가리켜서는 어쨌든, 내 잘못이지만, 다른 포럼에서는 다른 스크린 이름을 사용하지 않는 사람이 도움이되지는 않습니까? ;-)

어쨌든, appstore에 제출 한 후 승인되었으며 IMHO는 긴 목록을 처리 할 때 매우 유용합니다. 페이징은 웹에서 일반적으로 사용되는 것으로, 사용자가 500+ (내가 500+? 1000+ 이상은 무엇이라고 말했습니까?) 행을 가진 목록을 아래로/위로 스크롤하도록 강요하고 싶지는 않습니다.

목록의 가로 스 와이프는 사용자가 기본 동작으로 행을 삭제/편집 할 수 있어야한다는 점에 동의합니다. 그러나 상황에 맞는 것은 아닌가?

사용자가 데이터의 "소유자"인 경우 행을 삭제할 수 있습니다. 그러나 AppStore에있는 앱 목록이나 Amazon 앱에있는 책 목록에서 행을 삭제할 수있을 것으로 기대합니까?

목록의 가로 스 와이프는 문맥에 따라 제스처 일 뿐이며 사용자가 기대하는 바를 수행해야합니다.

500 개 이상의 행이있는 목록의 시나리오가 주어지면 어떻게 할 것입니까? 첫 번째 25 개의 행을 "더보기"-Footer로 표시 하시겠습니까? -> 그런 다음 50 행이 있습니까? 등등? 결국에는 527 개의 행이 있습니까? 당신이 하드 코어가 아니라면 셀을 그리면 테이블이 너무 고르지 않게됩니다. 그러나 부드럽게 스크롤해도 2,000 밀리 픽셀을 위/아래로 스크롤하는 문제는 해결되지 않습니다.

또는 "이전 페이지/다음 페이지"- 단추가있는 머리글/바닥 글을 넣으면 한 번에 25 행만 표시됩니까? 그런 다음 사용자가 위 또는 아래로 스크롤하여 이전 또는 다음 페이지로 전환하도록하십시오. ...

나는 제안 사항이 있으니 열려 있네. "이전/다음"무언가가있는 곳에서 왼쪽 또는 오른쪽으로 쓸어 넘기위한 자연스러운 동작으로 보입니다.

Answer 6

대안으로 UITableView의 섹션 색인을 사용하는 것은 어떻습니까?

- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView; 

- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index; 

이것은 사용자가 테이블의 맨 아래로 빠르게 이동 할 수있는있는 tableview의 오른쪽에 당신에게 인덱스 줄을 줄 것이다 (당신이 경우 참조를 위해 아이팟 응용 프로그램을 참조하십시오

다음과 같은 재정

내가 무슨 뜻인지 모르겠다.) 인덱스에 모든 섹션을 포함시킬 필요가 없으므로 100 개의 섹션으로 오버로드하지 않아도된다.

필자의 테이블 섹션은 알파벳이 아니기 때문에 학위 기호를 사용합니다.

뒷받침 데이터 구조가 여전히 큰 목록 인 경우 섹션으로 나누어야합니다. (섹션에 대한 헤더 표시가 없으므로 기존 표와 동일하게 표시 될 수 있습니다.)

표준 UI 동작을 벗어나는 경우 가끔 앱 업데이트를 발행 할 때 다음과 같이 할 수 있습니다. 앱의 이전 버전에 있던 "문제"에 대한 업데이트를 거부 할 수있는 숙련 된 리뷰어를 확보하십시오. 중요한 경고를 풀려고 할 때 경고하는 것처럼, 그것은 세계에서 가장 악화되는 것입니다. 은 애플을 주먹으로 흔들다.

성능면에서 볼 때, 나는 최대 900 개의 항목에 대해 탁월한 스크롤 성능을 보였다. chunky가되면주의해야 할 사항 ... 1) 셀을 dequeing 할 때 Reuse Identifier를 올바르게 사용하는지 확인하십시오. 2) 복잡한 컨트롤이있는 사용자 정의 표 셀. (테이블 셀에 하위 뷰를 추가해야하는 경우 투명도가없는 UILabel이 가장 빠릅니다.) 3) 비표준 높이의 표 셀 (a.k.a.가 40이 아님)을 피하십시오. (인정 된 사과 성능 버그. 비록 이것이 실제로 문제가되는지는 확인하지 못했습니다.)

Answer 7

여기에서 묻는 질문은 "이유"입니다. 왜 사용자가 항목 # 527에 가고 싶다고 생각합니까? 그는 6 페이지에 그가 원하는 항목을 어떻게 알게 될 것으로 예상됩니까? 17 페이지에?

정확하게 1000 개의 항목을 스크롤하는 것은 이상하지만 1000 개의 항목을 페이징하는 것은 똑같이 이상하다고 지적합니다. 응용 프로그램의 필터링 또는 정렬 기능을 개선하려고합니다. 수천 개의 항목을 스크롤하는 것은 사용자가 각 항목을 읽거나/스캔 할 것을 기대하지 않는 한 정신 나간다. 선형 목록을 갖는 것이 문제가되지 않는다.

UITableView의 오른쪽에 섹션 색인이있어서 컨텍스트에 따라 문제가 해결 될 수 있습니다.연락처 목록에 대한 문제를 확실히 해결합니다. 연락처가 2000 명이라도 시작 문자를 선택하면 약 100 개를 스크롤하면됩니다. (UITableView는 결코 화면에 보이는 것보다 많은 행을 생성하거나 요구하지 않기 때문에 성능은 문제가되지 않습니다.)

마지막으로 필자는 유사한 페이징 + 테이블 뷰를 사용한 하나의 앱을 사용하여 경험. 완전히 iPhonish가 아닌 느낌.