hyun9iOS

modal 창으로 뷰컨트롤러를 present 한 경우 아래로 쓸어내리면 창이 닫힌다 하지만 .fullScreen 속성을 주게되면 dismiss 로 쓸어내려도 창이 닫히지 않는다. fullScreen 형태의 화면을 제스쳐를 활용해서 dismiss 기능을 구현해보자. 1) Add addGestureRecognizer to View override func viewDidLoad() { super.viewDidLoad() view.addGestureRecognizer(UIPanGestureRecognizer(target: self, action: #selector(handleDismiss))) } 2) Create HandleDismiss Function @objc func handleDismiss(sender..

다른 스토리보드로 화면전환 1개의 스토리보드에 1개의 뷰컨트롤러가 존재하는 것이 이상적이다라고 해서 그렇게 진행해보았다. 평소에는 같은 스토리보드에 있는 뷰컨트롤러를 identifier 로 구분해서 가져올 수 있었다. 이 사진을 첨부한 이유는 코드로 TabBarController 로 화면전환 할때 첫번째탭으로 전환을 해야하는지에 대한 물음이 생겨서 첨부했다. 코드에서 확인 가능하듯이 UITabBarController 의 뷰컨으로 화면 전환하면 된다. guard let nextVC = self.storyboard?.instantiateViewController(identifier: "TabBar") as? UITabBarController else { return } self.navigationContro..

Issue 다루기 make project, issue, milestone make feature branch merge #1 pull request 되면 자동으로 close 된다.(default branch 에 merge 할 경우만 가능) local #1 branch 에서 commit 과 push 를 remote #1 로 하고 깃허브에서 풀리퀘를 통해 코드리뷰하고 develop remote branch 를 선택해서 merge 하면된다. 그렇지 않고 develop remote branch 로 push 하면 풀리퀘없이 머지 되었다. Fork 프로그램을 사용할 경우에도 동일하게 진행하였다. 이와 같은 방식으로 해줘야 pull request가 등장한다. 졸작 포포 협업을 연습하기 위해서 한동안 깃허브에 프로젝트..

Commit,Issue,PR Commit Type feat: 새로운 기능 추가 (new feature) fix: 버그 수정 (bug fix) docs: 문서 작성, 수정 (documentation) style: 코드 포맷팅, 세미콜론 누락 등 코드 변경이 없는 경우 refactor: 코드 리팩토링 (refactoring) test: 테스트 코드, 리팩토링 테스트 코드 추가 chore: 빌드 업무 수정, 패키지 매니저 수정 등 (production code 변경이 없는 경우) perf: 성능 개선 issue title [Commit Type] 이슈 제목 Commit type label 과 개발자 각자의 label 추가하기로 함. issue body 는 checklist type 으로 작성하기로 함. com..

Code Convention style share(https://github.com/StyleShare/swift-style-guide) 를 기초로 필요한 부분만 수정. function naming 만 수정이 필요하다고 판단함. 서버통신 서비스함수명 + WithAPI IBAction 동사원형 + 목적어 ex) touchBackButton 뷰 전환 pop, push, present, dismiss 동사 + To + 목적지 뷰 (다음에 보일 뷰) ( dismiss는 dismiss + 현재 뷰 ) 데이터 다루기? 데이터 파싱 - parse + 모델 + 결과물 parseDiaryUserID 초기세팅 init + 목적어 ex) initPickerView hidden unhidden show + 목적어 hide +..

Branch develop 다음 출시 버전을 개발하는 브랜치 기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)한다. 평소에는 이 브랜치를 기반으로 개발을 진행한다. feature 기능을 개발하는 브랜치 feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다. 개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다. release 출시 버전을 준비하는 브랜치 ‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기..

Branch rules git-flow 사용 feature 브랜치에는 이슈번호로만 작성 featrue/#1 main develop featrue/#(issue_number) release/(version_number) hotfix/#(issue_number) fork, xcode 에서 .../#(issue_number) 로 브랜치를 만들게 되면 자동으로 트리가 만들어짐.

Automated kanban 을 사용하여 project 생성 'Automated kanban' 으로 프로젝트 템플릿을 설정해주어야 close 된 issue 가 자동으로 'Done' 으로 이동한다.