화면 구성이 복잡하고 너무 많은 정보와 기능을 가지고 있는 View의 경우 view와 viewModel 각각 하나만 가지고 코드를 작성하기에 크기가 너무 커질 수 있다\-> 그래서 휴대폰에 보여지는 큰 뷰를 세분화 시킨 뒤 각각의 뷰가 뷰모델을 가질 수 있도록 프로젝트
프로젝트에서 아이디/비밀번호 찾기를 구현중인데 인증 문자를 보낸 뒤 5분이 경과하면 이전화면인 로그인화면이 아니라 전전 화면인 메인 화면으로 이동을 해야했다처음에는 pop을 두번을 했으나 화면이 뒤로 넘어가는게 두번이나 보여 좀 민망허기두 하고... 암튼 그런 기능이
fullScreen일 경우 모달을 불러오는 뷰(모달 아래에 있는 뷰)의 뷰 라이프 사이클이 돌아간다overFullScreen일 경우 모달을 불러오는 뷰(모달 아래에 있는 뷰)의 뷰 라이프 사이클이 돌아가지 않는다.fullScreen의 경우는 화면을 갈아끼우는 느낌이고
이 그림을 이해하기까지 한참이 걸렸다(어쩌면 노력을 안했을 수도...?)그러던 중 두 개의 블로그(1번, 2번)와 주변 지인분들께 물어보며 이해를 차츰 하기 시작했고 이해한 대로 나름 정리를 한 것이 아래 그림이다(각 명칭에 대한 설명은 다른 블로그에도 더 잘 정리가
회사 어플의 안드로이드 버전을 보면 api통신 에러가 발생했을 때 이렇게 오류가 토스트 메시지로 화면에 표시가 된다(물론 이렇게 에러메세지를 화면에 바로 표시하는건 썩 그렇게 좋은 방법은 아니라고 생각하지만...)그치만 난 표시를 하고 자시고를 떠나서 서버로부터 내려오
얼마전 \[Alamofire 사용법 - GET] 포스팅을 통해 Alamofire의 GET에 대해 다뤄보았다그런데 더 전에 \[async/await를 이용한 비동기 통신] 포스팅을 통해 다룬 async/await도 적용을 해볼 수 있지 않을까?? 하는 생각에 여기저기 찾
지금까지 모든 프로젝트에서 API통신을 URLSession을 통해 진행해 왔다가장 큰 이유는 네이티브로 어떻게 작동이 되는지 모르는데 라이브러리만 떡칠한다면 분명 나중에 큰일이 생길 것이라는 생각때문에...그렇기도 하고 크게 필요성을 느끼지 못했었다그런데 지금 회사에서
사용법은 다르지만 UIKit의 TableView와 같은 역할을 함사용법 매우 간단!끝.dataSource 어쩌고... 채택 어쩌고... 할 필요 없다 그냥 끝임 이 코드가 ㄷㄷText를 image로 바꾸면?바로 추감됨...(물론 size같은건 직접 일일이 지정해 줄 수
1-2 BuildingListsAndNavigationlistUIKit의 tableViwedatasource같은 걸 따로 설정해 줄 필요도 없이 그냥 어떤 배열만 넘겨주면 알아서 만들어줘서 좀 충격;;cell을 눌렀을 때 어떤 화면으로 이동하거나 하려면 아래에서 말하는
최근 SwiftUI를 공부하고 있는 중 SwiftUI요소가 아니라 문법적인 요소에서 아예 처음 보는 것이 나왔고 지금까지 이 기능을 구현하기 위해 애를 썼던 과거의 모습들이 떠올라 TIL로 남기게 되었다 Dictionary(grouping: , by: ) 사용법은 아
2022.11.23 애플의 공식 튜토리얼 시작스터디 내용Creating and combining Views (1-1 챕터) 수강완료image, map, text, stack 등에 대한 기본적이 사용법 숙지궁금한점컨텐츠 뷰를 구성하는 CircleImage와 MapView
비동기 통신 과정에서 한 번의 통신으로 여러개의 정보를 가져오는 경우 모든 과정에 대한 에러처리가 힘듬가능은 하나 방대한 양의 코드가 추가됨컴파일러가 에러에 대한 부분을 언급해주지 않기에 만약 개발자가 적절한 에러처리를 하지 않고 넘어갔고 그 부분에서 에러가 발생했다면
비동기적으로 코드를 작성하게 된다면 최종적으로 UI 업데이트는 메인스레드에서 진행되어야 한다(swift에서는!)그렇기에 우리는 이런 코드를 통해 작성하곤 했는데 이 DispatchQueue의 메서드들은 @escaping 클로저로 구현이 되어있어서 참조 관리를 해줘야 하
< 로아랑 >('https://velog.io/@doogie97/%EB%A1%9C%EC%95%84%EB%9'이하 '로아랑')은(는) 「개인정보 보호법」 제30조에 따라 정보주체의 개인정보를 보호하고 이와 관련한 고충을 신속하고 원활하게 처리할 수 있도록
최근 취업을 하게 되어 블로그건 개인 플젝이건 건들일 시간이 없었다...일단 회사에서 주어진 업무는 앱을 완전히 인수인계 받기 전에 firebase에 대한 조사(?) 및 어플에 기능을 심는 것이었는데(일단 로아랑에 테스트 해봄)어플에 심는 것 자체는 어렵지 않았다 fi
로아랑 프로젝트 진행 중 Realm에 저장되는 객체에 대한 수정 사항이 생겼다 물론 아직 출시 전이라 수정하고서 그냥 어플 삭제하고 다시 빌드하면 되지만 만약 출시를 했다고 가정했을 때 이렇게 DB모델에 수정사항이 생긴다면 마이그레이션을 필수이기에 출시 전 이에 대해
개인 혹은 기업에서 사용되는 api key는 외부로 노출이 되면 안된다.악용될 수 있을 뿐더러 회사의 api key를 깃허브에 push를 하여 외부에 노출되어 손해가 발생해 소송이 걸린 사건도 있다고 한다이처럼 중요한 api key를 숨기는 방법은 여러가지 있지만 오늘
Book Finder App 프로젝트 진행 중 14.1버전 시뮬레이터에서 아래와 같은 문제가 발생되었다어떤 코드차이도 없고 둘 다 라이트 모드인데 Collection View의 background Color만 검은 색으로 표시되는 현상이다(추가적으로 다른 뷰 또한 이런
로아랑의 기능 중 검색 한 유저의 보유 캐릭터를 가져오는 기능이 있다원래는 위와 같이 서버 구분 없이 가져오도록 되어있었으나 이를위 공식 홈페이지와 같이 서버별로 구분해주고 싶었다TableView의 header를 사용하면 간단하게 해결이 되지만 이 프로젝트는 rx를 이