UI를 구성하다 보면 반복적인 사용 혹은 동적인 생성 해서 구성하는 경우에 custom view를 만들어서 사용하게 되는데
custom view를 만드는 방법에 대해서 정리하려고 한다.
만들고 싶은 customview는 UIView를 base로 하고 Label 1개, Button 1개 있는 파란색 View로 가정한다.
만들고 싶은 custom view
< xib 없이 custom view 만들기>
1. UIView를 상속 받은 클래스 파일을 추가한다.
2.. 초기화 함수를 선언해준다.
3.. 필요한 UI 요소들들 추가해준다. - 필요한 constraint를 추가한다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UI를 모두 코드로 만드는 것에 익숙하지 않거나 스토리보드를 이용하고자 한다면 다음과 같이 추가하시면 됩니다.
< xib 를 이용해서 custom view 만들기>
1. UIView를 상속받은 클래스 파일을 추가한다.
2. 1번에서 추가한 클래스가 사용할 xib 파일을 추가합니다.
- 1과 2번의 파일 이름이 동일해야 하는 것은 아니지만 가독성을 해치지 않기 위해서 가급적 동일하게 맞추는 것이 낫습니다.
3. 초기화 함수를 선언해줍니다. 이때 어떤 xib를 읽어올지에 대한 코드가 추가되어야 합니다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ios 개발 전업을 선언하고 5개월 가량을 다음 정도의 spec?을 가진 앱을 2개를 유지 보수 작업을 진행하였다.
전혀 다른 성향의 개발자(혹은 복수의 개발자)가 만들어 놓은 2개 앱을 어떠한 가이드 문서 없이 보면서
이런 부분은 배워야지 혹은 이렇게하지 말아야지에 대한 회고를 정리해보려고 한다.
1. 2개 앱 Spec: 서버가 있고 안드로이드를 지원하고 앱의 화면은 크게 2가지로 구성된다.
네이티브로 구성된 화면이 있고 필요에 따라서 웹페이지를 보여주는 화면이 있다.
앱의 주요 설정 및 공지사항 등은 서버에서 내려 받아서 보여준다.
local에는 사용자 설정 정보 이외의 데이터를 저장하지 않는다.
2 카테고리 혹은 키워드 별로 정리해보았다.
- Naming
변수 네이밍은 내용이 명확하게 반영되어야 한다.
예. isNickDuplicate 개발자는 닉네임 중복을 확인한 상태를 저장하는 변수라고 썼지만 이름만 보면 닉네임이 중복인지 아닌지로 읽힌다?
> 나는 이것을 isNickDuplicateCheck 이런 식으로 바꿔 보았다.
- 조건문 처리
early return pattern을 가급적 쓰려고 노력해야 겠다.
- uicomponent
자주 사용하는 component의 경우 base를 선언하고 필요한 스타일이나 프로퍼티를 만들어두는 것이 좋더라.
예. 빨강색 글씨에 파랑색 배경색을 가진 버튼이 기본 버튼, 회색 글씨에 오렌지색 배경을 가진 버튼이 subbutton으로 쓰인다고 하면
UIButton을 extension으로 선언해서 스타일을 미리 정의하던지 아니면 baseButton을 만들고 그걸로 UI를 구성한다면 메인 색 변경 같은 정책 변경시 쉽게 대응이 되고 화면을 새로 구성할 때도 유용하다.
- tableview cell 구성시
index를 가지고 어떤 cell을 그릴지 혹은 어떤 동작을 할지를 정해진 코드가 한 앱에 많았다. 그러니 어떤 cell이 그려지는 것이 맞는지 index 값을 보고 판단하지 못하니 가독성이 떨어지고 순서를 바꾼다고 하더라도 실수의 여지가 생긴다.
그래서 각 cell이 그려지는 바가 나타나도록 string array를 이용하거나 데이터의 특정 값을 이용해서 처리하게 수정하는 것이 좋더라.
이것은 button.tag를 이용해서 처리하는 부분에서도 동일하다. tag 0, 1,2로 처리하면 당사자도 만들 당시에만 명확하게 아는 것이지
가독성이 떨어진다. 이것 역시 처리할 array를 목록을 가지고 동작하게 하는 것이 가독성이 높아진다.
- webview
앱의 특성상 webview base를 잘 만들어 놔야 어디서든 잘 쓸 수 있다.
- 파일 및 폴더 관리, static string 등등
한 앱의 경우 하나의 폴더에 파일이 20개씩 있으니 어떤 의미를 가지는지 알수 없고 찾기도 어렵다.
controller를 구성할 때도, view 폴더를 구성할 때도 의미 없는 하나의 나열로 구성된 것은 찾기가 어렵다.
특히 xcode 11.7에서 빌드해야 한 앱은 xcode가 하나의 폴더를 여는 것 조차가 버벅인다.
이 관리는 assets 관리도 동일하다. 이미지 관리를 위한 폴더를 거의 사용하지 않고
거의 하나의 폴더를 이용하다보니 assets의 미리보기도 제 역할을 할 수가 없다.
그래서 depeth 혹은 폴더수가 늘더라도 하나의 완결된 화면 혹은 분리 가능한 폴더로 나누어서 관리하도록 하는 것이 좋더라.
> context 단위이면 좋겠다는 표현일수 있겠다.
- ui 구성시에
여러 구역으로 나눠진 UI에서 UIView를 단독으로 사용하는 것은 지양해야 하고 작은 단위가 보여서 하나의 구역을 이루는 경우
UIStackView를 적극적으로 사용하자.
UIView 하위에 UIView 한땀한땀 그리면 순서가 바뀌거나 중간에 하나의 요소가 빠지면 수정하는데 시간이 많이 걸린다.
- viewModel은 꼭 쓰자
이상하게 2 앱 모두 viewModel을 쓰지 않는다. 그러다 보니 viewcontroller안에 로직이 있다보니 UI 관련 내용과 데이터 관련 내용이 혼재 되어 있어서 가독성이 떨어지면 비동기 처리 부분이 애매한 곳들이 있다.
- 뜬금없는 snapkit?
하나의 앱은 코드의 일관성이 있어서 한명이 만든 것인지 혹은 하나의 rule을 잘 지킨 것인지 알수 없지만
하나의 앱은 최초 개발자와 최초 개발자의 코드를 따르지만 수준이 조금 떨어지는 개발자, 그리고 앞에 두 사람과 다른 소속의 한사람이 짠 코드로 나눠진다. 3번째 사람이 만든 화면은 모두 snapkit을 짜여 있다. snapkit 쓰는 것 자체가 문제는 아니지만 전반적으로 스토리보드로 짠 앱에서 혼자 아는 snapkit으로 넣는 것...
난 개인 적으로 반대하는 편이다. 정답은 없겠지만.
- Mappable 사용시
서버에서 주는 값이 어떤 타입을 의미해서 그 비교를 하는 값들이 하드코딩된 어떤 string이라면, 다음과 enum으로 정의하고 그 enum으로 비교하는 것이 오타를 줄이는 방법이더라.
nameType을 바로 사용하지 않고 enum을 정의해서 사용하게 mapping에서 구현함.
- appStore.
겪었던 것중에 특이했던 것은 앱의 어떤 화면에서도 안드로이드 혹은 다른 플랫폼에 대한 내용이 나와서는 안된다. 그것이 실제 동작과 무관한 공지사항 내에 이미지여도 마찬가지다. 나오면 무조건 심사 reject이다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Data 형을 쓰면 되는데 이 때 codable을 상속 받은 structure를 쓴다면 아주 쉽게 get / set 이 가능해진다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1-1. app delegate에 Session handler를 이용해서 지원 여부를 확인하면 좋다
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
해당 프로토콜을 이용해서 쉽게 json 데이터를 다룰 수 있다. 특히 파일 저장이나 rest api 응답을 받아서 처리할 때 유용하다.
임의의 구조체를 선언하고 codable을 상속 받기만 하면 일단 사용할 준비가 완료 된다.
다음과 같은 임의의 구조체가 있다고 가정해보자.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
해당 구조체를 이용해서 생성한 데이터를 json string으로 바꾸어서 파일까지 저장한다면 다음과 같이 구현할 수 있다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
json 으로 저장된 파일에서 원하는 구조체로 읽어 내는 것은 다음과 같이 사용할 수 있다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
codable 프토로콜을 상속 받더라도 json 문법에 맞지 않는 Date 같은 데이터는 처리할수가 없는데
명시적으로 처리하는 방법을 알려준다면 encode/decode가 가능해진다.
encoding 할 경우 다음과 같이 추가해준다면, Date 형식을 읽고 쓰는데 문제가 없다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RECENT COMMENT