Day 30 개발일지 iOS

30 화요일

UserDefaults를 구조체로

user구조체를 담을 userDefaults를 어떻게 사용해야 할 까 하다가 구조체 방식을 사용했다. static let key = "userCache" 를 구조체가 가지고 있어, 스트링값을 매번 주입하지 않게 했다.

또한, static 함수로 jsonEncoding을 해주어 UserDefaults에 저장하는 save기능과, 저장된 내용을 디코딩해서 사용하는 static get함수를 만들었다. 이로 인해 user를 편리하게 받아올 수 있게 됐다.

서버가 날린 json 키값 이름이 스네이크케이스 일 때

CodingKey를 사용하여 스위프트의 카멜케이스로 바꾸어 사용했다.

enum CodingKeys: String, CodingKey {
    case id, key, name, color, icon
    case isMain = "is_Main"
}

BackupPasswordView가 서버의 상태에 따라 다른 형태를 띄워야 함..

BackupPasswordView의 형태가 몇 가지 있다.

1. 처음 설치한 유저가 멀티디바이스 상태에서 백업을 켜놓았지만, 현재 디바이스의 비밀번호 값과 달랐을 때, 비밀번호를 한 번 더 확인해야 함. - 패스워드 TextFiled 1개 (비밀번호 입력)
2. 처음 설치한 유저가 백업을 하지 않았을때 - 패스워드 TextFiled 2개 (비밀번호입력, 비밀번호 확인)
3. 유저가 멀티 디바이스를 켜 놓은 상태에서 다른 디바이스에서 백업 비밀번호를 변경했을 때, 현재 디바이스의 토큰 복호화 비밀번호가 달라졌을 경우. - 패스워드 TextField 2개 (비밀번호 입력) ...등등

이런 유저의 상태에 따라 바뀌어야 했기 때문에 ( 토큰의 복호화가 잘 되는지도 판단해야 했기 때문에 ) 토큰을 get해야하는 상황이 있었다. 그래서 이 비밀번호 뷰가 뜰 때 처음에 몇개인지 판단하는 get요청 한 번, 백업 활성화 버튼을 누를 때 암호화하는 요청 한 번 이렇게 두번 요청을 해야했다.

이게 정말 좋은 방법 같지는 않지만. 최선의 방법으로 해결했다.

JSON 속성으로 UUID를 사용하면 망한다....

Token의 식별 값으로 UUID를 사용했다. 그런데 이것이 문제가 될 줄은 상상도 못했다. (어진님은 과거 남긴 주석에 이를 스트링으로 바꿔야 한다는 이야기를 적긴 했다.) 상상도 못했던 일이 벌어졌다. 백업 서버로 Token의 id를 스트링으로 바꿔서 보낸 후 다시 받을 때 이를 다시 UUID 값으로 돌려놓을 방법이 없었던 것이다. 정말 방법이 없다.

그래서 이를 String으로 바꾸는 작업이 필요해 졌다.

암호화 복호화

서버에 Token의 키값을 저장하기 위해 암호화 하고, 다시 받아서 열어볼 때 복호화할 알고리즘이 필요했다. 다행스럽게도 CryptoKit에서 ChaChaPoly라는 알고리즘을 제공해주었다. 이것을 사용하면, 대칭키로 data를 암호화 해주고, 대칭키를 복해 복호화까지 해준다. 암호화된 데이터에 잘못된 대칭키로 복호화를 시도하면 실패처리도 해준다.

개인 회고

(솔직히 쓰기 - 현재 파트너 또는 누군가가 본다고 생각하지 말고 미래의 내가 본다고 생각하며 쓰면 어떨까요??😏)

어진

• 이날 엄청 달렸다. 마감 기한이 있으니까 역시 잠을 자지 못하겠다!!!!! 할일은 다 해내고 싶기때문에ㅠㅠ
• 그래도 재명님이랑 오늘 호흡이 제일 시너지 효과가 났던 것 같다. 각자 할거 하고 딱 merge하니까 완벽하지는 않지만 원하던대로 작동했다. 카타르시스~~~~!
• 갓어진이라지만,, 갓재명이다 진짜다.

재명

• 수요일까지 슬랙에 배포 주소를 꼭 남겨달라는 JK님의 요청에 따라 잠을 잘 수 없게 되었다. 아직도 구현하지 못한 기능들 투성이었기 때문이다. 하지만, 어진님에게 할 수 있다는 최면을 걸었다. 성공적인 최면이었다. 어진님이 새벽 시간이 깊어짐에도 결코 포기하지 않고 백업 패스워드 뷰의 로직을 성공적으로 만들어 주셨다.
• 정말 못할 것만 같았는데 갓어진의 하드 캐리였다.