반응형 iOS (Swift)19 [오늘의 코드 조각] [iOS 5-3] 데이터 전달의 정석: 화면 간 주고받는 3가지 패턴 완벽 가이드 안녕하세요! [생각하는 개발자]입니다.우리는 지난 시간에 뷰 컨트롤러가 태어나서 사라질 때까지의 타임라인(Lifecycle)을 지배하는 법을 배웠습니다. 이제 5부의 마지막 퍼즐이자, 앱에 유기적인 흐름을 만들어 줄 "화면 간 데이터 전달(Data Transfer)"의 정석을 마스터할 시간입니다.로그인 화면(A)에서 입력받은 유저 ID를 메인 홈 화면(B)으로 전달하거나, 반대로 프로필 수정창(B)에서 수정한 이메일 주소를 이전 메이페이지(A)로 안전하게 되돌려주어야 하는 상황은 앱 개발에서 매 순간 발생합니다. 상황에 맞춰 데이터의 핏줄을 꼬임 없이 연결해 줄 iOS 3대 데이터 전달 패턴을 완전히 정복해 보겠습니다.5.3.1 캔버스 위에 재료 얹기 (받는 쪽 화면 설정)데이터를 건네받을 목적지 화면(.. 2026. 7. 16. [오늘의 코드 조각] [iOS 5-2] ViewController의 일생: 언제 데이터를 불러오고 화면을 갱신해야 할까? 안녕하세요! [생각하는 개발자]입니다.우리는 지난 시간에 화면을 구성하는 큰 지도(Navigation, TabBar)와 이를 넘나드는 4가지 액션(Push/Pop, Present/Dismiss)을 체계적으로 정리했습니다. 이제 원하는 타이밍에 화면을 열고 닫을 수 있게 되었죠.하지만 진짜 프로 개발자가 되려면 한 단계 더 깊은 질문을 던져야 합니다."화면이 전환될 때, 우리가 원하는 서버 데이터는 어느 타이밍에 불러와야 가장 매끄럽게 보일까?"이 질문의 답을 찾기 위해, 뷰 컨트롤러가 메모리에 태어나 눈에 보이고, 결국 사라질 때까지의 모든 과정을 다루는 생명주기(Lifecycle)의 실무 활용 바이블을 준비했습니다.5.2.1 캔버스 위에 재료 얹기 (생명주기 메서드 오버라이딩)생명주기를 완벽히 지배하려.. 2026. 7. 16. [오늘의 코드 조각] [iOS 5-1] 화면 전환의 모든 것: Navigation Controller, TabBar Controller, 그리고 Segue의 한계 안녕하세요! [생각하는 개발자]입니다.우리는 지난 4부를 통해 현업 수준의 깔끔한 Git 협업 프로세스(Git-Flow, PR)를 완벽하게 정복했습니다. 이제 튼튼한 협업의 기반 위에서, 본격적으로 앱의 거대한 지도를 그려나갈 차례입니다.오늘 다룰 주제는 바로 화면 전환(Navigation)입니다. 앱에서 화면이 전환되는 방식은 단순한 '시각 효과'가 아니라, 사용자가 앱과 상호작용하는 흐름(UX) 그 자체를 결정합니다. iOS UIKit이 제공하는 대표적인 화면 전환 구조와 함께, 스토리보드가 제공하는 편리하지만 치명적인 독배인 Segue(세그웨이)의 실무적 한계까지 낱낱이 파헤쳐 보겠습니다.5.1.1 캔버스 위에 재료 얹기 (iOS 화면 전환의 2대 축)iOS에서 화면을 전환하는 물리적인 방법은 크게.. 2026. 7. 14. [오늘의 코드 조각] [iOS 4-4] 현업의 협업 방식: Git-Flow 구조 이해와 Pull Request(PR) 활용하기 안녕하세요! [생각하는 개발자]입니다.지난 시간 우리는 여러 브랜치(Branch)가 얽히며 발생하는 공포의 충돌(Conflict) 상황을 직접 제압하고, 특히 iOS 개발자의 골칫거리인 .xcodeproj 충돌을 물리적으로 해결하는 팁까지 조각내 보았습니다.이제 브랜치를 쪼개고 합치는 무기를 다룰 줄 알게 되었으니, 실제 현업 대형 프로젝트에서 이 무기들을 어떤 규칙과 질서 속에서 사용하는지 배울 차례입니다. 오늘 다룰 주제는 전 세계 IT 기업의 표준 브랜치 전략인 Git-Flow(깃 플로우)와 집단 지성으로 코드의 품질을 끌어올리는 Pull Request(PR) 시스템입니다.4.4.1 캔버스 위에 재료 얹기 (현업 브랜치의 5대 계급도)현업에서는 main 브랜치 하나에 모두가 달라붙어 개발하지 않습니.. 2026. 7. 14. [오늘의 코드 조각] [iOS 4-3] 협업을 위한 브랜치 전략: Branch 생성, Merge, 그리고 공포의 Conflict 해결법 안녕하세요! [생각하는 개발자]입니다.지난 시간 우리는 Git의 기본 저장 메커니즘과 동료들에게 신뢰를 주는 커밋 메시지 규약을 마스터했습니다. 이제 혼자 쓰는 저장소를 넘어, 여러 명이 동시에 하나의 프로젝트를 개발하는 실전 협업의 문을 열어보겠습니다.여러 개발자가 같은 파일을 동시에 수정하고 서버에 올릴 때, 필연적으로 마주치는 깃의 수호신이 있습니다. 바로 충돌(Conflict)입니다. 특히 iOS 개발자들이 가장 무서워한다는 .xcodeproj 파일의 충돌 원인과 이를 깔끔하게 해결하는 법까지 오늘 완벽하게 조각내 드리겠습니다.4.3.1 캔버스 위에 재료 얹기 (브랜치와 충돌의 원리)우리가 작업하는 메인 줄기를 main 브랜치라고 부릅니다. 이 줄기에서 나만의 독립된 개발 공간을 만드는 명령어가 .. 2026. 7. 14. [오늘의 코드 조각] [iOS 4-2] 소스코드 저장의 정석: Clone, Commit, Push, Pull과 좋은 커밋 메시지 작성법 안녕하세요! [생각하는 개발자]입니다.지난 시간에는 내 맥북에 단 한 번만 세팅해 두면 평생이 편해지는 iOS 맞춤형 글로벌 .gitignore를 구축해 보았습니다. 이제 불필요한 쓰레기 파일들이 완벽하게 필터링되는 쾌적한 환경이 마련되었으니, 본격적으로 코드를 저장소에 올리고 내려받는 Git의 기본 4대 흐름(Clone, Commit, Push, Pull)을 마스터해 볼 차례입니다.특히 오늘 다룰 주제 중 핵심은 "어떻게 하면 동료들이 내 커밋 내역만 보고도 고개를 끄덕이게 만들 것인가?"에 대한 커밋 메시지 작성 기술입니다.4.2.1 캔버스 위에 재료 얹기 (Git 4대 흐름 맛보기)우리가 작성한 코드가 원격 저장소(GitHub 등)와 주고받는 기본 흐름은 아래의 4가지 명령어로 귀결됩니다. # 1... 2026. 7. 14. 이전 1 2 3 4 다음 반응형
