<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Router on Kelly Dev</title><link>https://kelly-chui.github.io/tags/router/</link><description>Recent content in Router on Kelly Dev</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 12 Nov 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://kelly-chui.github.io/tags/router/index.xml" rel="self" type="application/rss+xml"/><item><title>SniffMEET. 여러 VIPER 구현에서 Router 구조 비교하기</title><link>https://kelly-chui.github.io/posts/sniffmeet-dev-log-viper-router-comparison/</link><pubDate>Tue, 12 Nov 2024 00:00:00 +0000</pubDate><guid>https://kelly-chui.github.io/posts/sniffmeet-dev-log-viper-router-comparison/</guid><description>&lt;p&gt;VIPER에서 Router가 화면 전환을 담당한다는 원칙은 분명하다. 하지만 현재 화면을 어떻게 참조하는지, 다음 모듈은 누가 만드는지, AppRouter가 반드시 필요한지는 구현마다 달랐다.&lt;/p&gt;
&lt;p&gt;SniffMEET의 화면 구조를 정하기 전에 여러 VIPER 프로젝트를 비교하며 Router의 책임 범위를 확인했다.&lt;/p&gt;
&lt;h2 id="무엇을-확인했나"&gt;무엇을 확인했나&lt;/h2&gt;
&lt;p&gt;분석 기준은 다음 세 가지였다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Router가 현재 ViewController를 어떻게 참조하는가&lt;/li&gt;
&lt;li&gt;화면 전환 시 다음 VIPER 모듈을 누가 조립하는가&lt;/li&gt;
&lt;li&gt;여러 모듈에 걸친 전환을 AppRouter가 담당하는가&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="구현-비교"&gt;구현 비교&lt;/h2&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;구현&lt;/th&gt;
&lt;th&gt;모듈 조립&lt;/th&gt;
&lt;th&gt;화면 전환&lt;/th&gt;
&lt;th&gt;AppRouter&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href="https://github.com/amitshekhariitbhu/iOS-Viper-Architecture"&gt;iOS-Viper-Architecture&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;WireFrame의 정적 메서드&lt;/td&gt;
&lt;td&gt;출발 View를 인자로 전달&lt;/td&gt;
&lt;td&gt;없음&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href="https://github.com/tailec/ios-architecture"&gt;ios-architecture&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;정적 팩토리 메서드&lt;/td&gt;
&lt;td&gt;전환 사례가 적음&lt;/td&gt;
&lt;td&gt;없음&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href="https://github.com/ferranabello/Viperit"&gt;Viperit&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;프레임워크가 모듈을 관리&lt;/td&gt;
&lt;td&gt;모듈이 직접 자신을 표시&lt;/td&gt;
&lt;td&gt;&lt;code&gt;AppModules&lt;/code&gt;로 모듈 관리&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href="https://github.com/giftbott/iOS-Architecture-Sample"&gt;iOS-Architecture-Sample&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;모듈별 생성&lt;/td&gt;
&lt;td&gt;앱 단위 Router가 화면 계층 관리&lt;/td&gt;
&lt;td&gt;싱글톤 AppRouter&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;구현은 달랐지만 공통점도 있었다. View나 Presenter가 직접 다음 화면을 생성하지 않았고, 화면 조립과 전환을 UI 바깥의 객체로 분리하고 있었다.&lt;/p&gt;</description></item><item><title>Network. 네트워크 기기</title><link>https://kelly-chui.github.io/posts/cs-network-network-devices/</link><pubDate>Thu, 14 Mar 2024 00:00:00 +0000</pubDate><guid>https://kelly-chui.github.io/posts/cs-network-network-devices/</guid><description>&lt;h2 id="네트워크-기기의-처리-범위"&gt;네트워크 기기의 처리 범위&lt;/h2&gt;
&lt;p&gt;네트워크 장비는 주로 어떤 계층의 정보를 보고 전달 여부를 결정하는지에 따라 구분한다. 실제 장비는 여러 계층의 기능을 함께 제공할 수 있으므로 아래 구분은 대표적인 처리 기준이다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;애플리케이션 계층: L7 스위치&lt;/li&gt;
&lt;li&gt;인터넷 계층: 라우터, L3 스위치&lt;/li&gt;
&lt;li&gt;데이터 링크 계층: L2 스위치, 브리지&lt;/li&gt;
&lt;li&gt;데이터 링크·물리 계층: NIC, 무선 AP&lt;/li&gt;
&lt;li&gt;물리 계층: 리피터&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="애플리케이션-계층을-처리하는-기기"&gt;애플리케이션 계층을 처리하는 기기&lt;/h2&gt;
&lt;p&gt;애플리케이션 계층의 정보를 기반으로 트래픽을 처리하는 장비&lt;/p&gt;
&lt;h3 id="l7스위치로드-밸런서"&gt;L7스위치(로드 밸런서)&lt;/h3&gt;
&lt;p&gt;HTTP 헤더, URL 경로, 쿠키처럼 애플리케이션 계층의 정보를 읽어 요청을 적절한 백엔드 서버로 분산하는 장비 또는 소프트웨어&lt;/p&gt;</description></item></channel></rss>