210422 - TIL

CollectionView의 item이 하나만 선택되도록 하기

이전에 collectionView에서 발생한 문제를 해결하기 위해서 가장 필요한 부분이 collectionView(_:didSelectItemAt:) 에서 선택한 item 말고 나머지 item의 상태를 바꿀 수 있어야 했다.

 

그래서 해결을 한 방법은 

 

	func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
	selectedItemIndex = indexPath.item
	for index in 0 ..< buttonImageNames.count {
	let myIndexPath: IndexPath = IndexPath(item: index, section: 0)
	guard let cell = collectionView.cellForItem(at: myIndexPath) as? RecordContentsCollectionViewCell else { continue }
	if index == selectedItemIndex {
	DispatchQueue.main.async {
	self.moveUp(to: cell)
	}
	} else {
	DispatchQueue.main.async {
	self.moveDown(to: cell)
	self.showHistoryDataIfDataIsNil()
	}
	}
	}
	}

view raw didSelect.swift hosted with ❤ by GitHub

이렇게 selectedItemIndex를 생성하고 for 반복문을 돌면서 index와 비교해서 같은 것은 선택된 것이고 아닌 것은 선택되지 않은 것으로 해서 상태를 바꿔주면 됐다.

이렇게 하니 collectionView(_:didDeselectItemAt:)를 사용할 필요가 없어졌다.

기억해야 할 점은 이 코드를 collectionView(_:cellForItemAt:)에도 추가시켜야 화면에 보이지 않는 item이 나타날 때 상황에 맞는 화면이 나오게 된다.

 

잘 해결했지만 한 가지 문제가 발생했다.

 

왜 안되는 거야??

 

바로 선택이 해제될 때 애니메이션의 적용이었는데 왜 그런지 알 수는 없지만 애니메이션을 적용하면 2번째 또는 3번째 셀부터 애니메이션 적용이 안됐다.

안될 거면 다 안되던가 해야 하는데.... item들이 따로 만들어진 것도 아닌데 왜 이런 상황이 발생한지는 모르지만

일단 아쉬운 대로 선택이 해제가 될 때의 애니메이션은 적용하지 않기로 했다.

 

 

아쉬운대로 선택해제 애니메이션은 빼자ㅠㅠ

---

 

서버에서 데이터 가져오기

DB에서 원하는 정보를 가져오려고 하는데 되도록 한 화면에서 한 번의 네트워크 요청만을 보내고 싶었다

하지만 가져와야 하는 정보가 많았고 nickname이라는 정보를 가져오기 위해서 아래와 같이 타고 타고 한참을 들어가야 했다.

Pet -> History -> FamilyMember -> User.Nickname 

 

그래도 뭐 그냥 하면 되겠지 하고 ApplicationDbcontext를 parameter로 보내면서 데이터를 연결했는데...

 

또 만난 DataReader error

반가워ㅜㅜ

DataReader에 대해서 이해하고 이를 해결하고 넘어가고 싶어서 검색해보며 공부를 해보았지만...

C#을 필요한 문법만을 배운 탓에 이해가 가지도 않고 어느 부분이 문제인지도 알 수 없었다.

그래서 지금은 프로젝트를 마무리하는 게 중요했기 때문에 많은 시간을 할애하지는 못하고 다른 방식으로 접근해야 했다.

바로 한 번의 네트워크 요청이 아닌 두 번을 보내는 것 ㅠㅠ

그래서 Pet -> History 이렇게 얻어오고 History에 있는 FamilyMemberId를 파라미터로 보내 

FamilyMemberId -> User.Nickname을 얻어오도록 만들었다.

아쉽지만 일단 급한불은 끈 상태

프로젝트를 마무리하면 한 번에 하거나 더 효율적인 방식을 공부해 봐야겠다.

그리고 꼭 dataReader도 공부하자!!

 

 

---

Git

git 공부는 이제 오늘로 끝!!

대부분의 기능들에 이해는 끝냈다. 프로젝트를 진행하며 꾸준히 배운 개념들을 사용해봐야겠다.

분명 이 많은 기능 중에 사용하지 않는 기능도 있을 테고 그러면 까먹겠지만...

그 기능을 쓸 일이 있다면 다시 돌아와서 공부하고 가지 뭐..

 

Git으로 협업해보기

 

• Github에 remote repo를 만들고 Setting -> Manage access -> 아이디 입력
• 그러면 초대 메일이 가고 승인해주면 된다.
• pull을 하지 않고 같은 부분을 수정하면 error가 발생한다.
• 그럼 pull을 하면?? merge conflict가 난다. 그럼 고치면 된다!
• 이렇게 합친 commit을 merge commit이라고 한다.

 

Fetch란??

 

• master
• local 저장소의 master branch
• origin/master
• remote의 master branch
• 원격에서 마지막으로 가져온 master

• 원격 저장소에 있는 데이터를 가져오지만 지역 저장소에는 merge 되지 않았다.
• origin/master애 merge를 하면 master가 따라가게 된다.
• pull은 fetch + merge라고 생각하면 된다!
• fetch의 활용법은 fetch를 하고 test brach를 딴 다음 merge 해보고 그 이후 master를 merge 하는 방식으로 활용 가능하다.

 

Pull request

 

• git이 제공하는 기능이 아니라 git hosting service( ex] git hub)가 제공하는 기능이다.
• 오픈소스는 pull은 누구나 가능하지만 push는 아무나 못한다.
• 당연! 아무나 막 하면 엉망진창
• 오픈소스에서 내가 개발한 코드를 pull 해가라고 요청하는 것
• 내가 이러한 기능을 추가했는데 이거 pull해가요~~

• 다른 오픈소스를 clone 하는 게 아니라 fork 한다.
• Fork??
• 내가 만들지 않은 다른 저장소를 내 거인 것처럼 가져오겠다.
• Fork하면 내이름/저장소이름 으로 저장소가 생긴다.
• 그럼 이 저장소를 clone해서 가져온다.
• 그리고 이것의 코드를 수정하고 push하면 fork한 저장소에 올라가게 된다.
• Pull request와 Compare 버튼이 있다
• compare는 말 그대로 original과 fork를 비교해준다.
• pull request를 보내면 원작자에게 뜨게 된다.
• Merge pull request를 해주면 original에 추가된다.

 

Reset vs Revert

 

• HEAD의 개념
• Working dir를 그 버전의 상태로 바꾸겠다.
• Working dir는 그 버전을 기반으로 수정되고 있다.

• CheckOut
• Head를 바꾼다.
• Head -> master -> version3 ==> Head -> version2
• master는 바뀌지 않았다.
• head가 branch를 가리키지 않는 것을 Detatched Head라고 한다.
• version을 가리킨다던지 그런 상황
• 꼭 마지막에 branch로 돌아오도록 하자

• Reset
• Head가 brach를 가리키고 있을 때 그 branch가 가리키는 version을 바꾼다.
• Head -> master -> version3 ==> Head -> master -> version2
• version3는 삭제된 게 아니다 가리키고 있는 게 하나도 없으므로 안 보이는 것뿐
• reset된 version의 CommitId를 알고 있다면 다시 살릴 수도 있다.
• git은 웬만하면 version을 지우지 않는다.

• Reset의 Hard, Soft, Mixed
• working dir -> stage area -> repository
• 일단 3개 모두 다 brach가 가리키는 version은 바뀌게 된다.
• Soft
• working dir, stage area는 그대로 남아있다.
• repo만 바뀌게 된다.
• version2, version3를 모두 추가했는데 version2,3의 내용을 합한 새로운 version4를 만들고 싶다면!!
• soft version1로 돌아가고 version4로 commit push하면 된다.
• Mixed
• working dir만 그대로 남아있고
• stage area, repo이 바뀌게 된다.
• version3까지 했는데 커밋을 새로 하고 싶다면
• mixed version2로 돌아가고 새로 commit 해주면 된다.
• Hard
• working dir, stage area, repo 모두 다 바뀐다.
• 주로 예전으로 다 돌리고 싶을 때 사용한다.

• Revert
• 실수를 해서 돌아가려고 하는데 그 실수마저 기록한 새 버전을 하고 싶다!
• 일단 version1으로 reset하고 싶다면 version1으로 reset
• version1으로 revert하고 싶다면 version2를 revert!!
• 이 차이는 중요하다.
• 그리고 revert의 주의점은 또 있다.
• 취소할 내용을 수정해버리고 revert로 그 부분을 revert 하려고 하면 충돌이 난다.
• 취소할 건데 수정해서 뭘 취소해야 할지 몰라 너가 직접 수정해줘 conflict
• 3WayMerge

Cherry-Pick

 

• 특정한 commit만 pick 해서 다른 version에 붙여 새로운 version을 만드는 것!
• working copy의 전체를 가져오는 게 아니라 해당 변화만을 가져오는 것이다.
• 가져오고 싶은 working copy에서 진행해야 한다.
• 3 way merge를 통해 진행되게 된다.
• 3개를 놓고 비교하며 진행돼서 특정 변화만을 가져와서 변하게 되는 것이다.
• Conflict가 발생한다면 지금까지 발생한 conflict들과 똑같다. 우리가 정해주기만 하면 된다.

Rebase

 

• master version1의 base를 other Branch로 바꿔서 두 가지를 하나의 가지로 나타내고 싶다.
• 즉 우리의 나눠진 log를  하나의 log로 바꾸고 싶다.
• base
• 두 branch의 공통조상인 base를 알아야 한다.
• 이동시킬 branch에서 작업해야 한다.
• HEAD는 base가 될 branch를 가리키게 된다.
• Rebase 하면 하나하나 한 단계씩 vsrsion을 하나씩 생성해가며 올려나간다.
• 한 번에 몽땅 옮기지 않는다.
• Merge를 하게 되면 두 개의 가지가 나뉘어있다가 하나의 가지로 합치는 모습이지만 rebase는 하나의 가지로만 쭉 가는 모습이 된다.
• 이러면 log를 보는 입장에서 보기 좋게 된다.
• fetch를 활용해서 할 수 있다.
• 기억해야 하는 것!!
• 이동할 버전을 remote에 push하기 전에 rebase를 해야 한다. push를 하고 난 후라면 하지 말자.
• merge를 한것과 rebase를 한것의 결과는 같아야 한다.

공부해볼 것

 

• Code review
• Gerrit - google에서 만든 도구
• 투표 같은 느낌