Chart의 장점

: can reveal subtleties in data that you cannot communicate easily through text. ( 텍스트로 쉽게 소통할 수 없는 데이터의 미묘함을 드러낼 수 있다. )

• Utility (유용성)
• Personality of your app (앱의 개성)
• Visual interest to your UI (UI의 시각적 흥미로음)

This year, we’re introducing Swift Charts. 

With this framework, making charts for Apple devices has never been easier. In the following sections, I will share the principles we follow when designing experiences with charts at Apple. 

In order to build a great experience with charts, we should consider three things: 

when to use charts

• showing historical or predicted values (과거의 값이나 예측된 값을 보여줄 때) ⇒ chart can vividly demonstrate changes in data. (차트는 데이터의 변화를 생생하게 보여준다.)

• By visualizing a portion of a whole (전체의 일부를 시각화할 때) ⇒ we can use charts to show the state of something that is completing, progressing towards a goal, or emptying. (완료된 정도나 목표까지의 진척도 혹은 미진척 부분을 표현할 수 있다.)

• Comparing items or categories (항목이나 범주를 비교할 때) ⇒ we can easily evaluate their values with charts. (차트로 값들을 쉽게 평가할 수 있다.)

우리는 앱을 디자인하기 전에 앱의 핵심 목표 달성에 차트가 어떻게 도움이 될까? 생각해볼 필요가 있다.

*Charts provide focus (적절히 사용되면 차트는 집중도를 높인다.) *

앱 제작자로서 우리는 다양한 것들을 시각화할 수 있지만, 가장 중요한 정보만 차트로 표현되어야 한다!!

As you consider your app, remember that charts should direct attention and provide focus to the most important information in your experience.

(앱을 구상할 때 여러분이 제공하고자 하는 경험에 핵심적인 정보가 차트에 집중돼야 함을 명심하자.)

how to use charts

Describe chart contents

A chart should be accompanied by text that describes the chart contents. If read in isolation, it should be informative.(차트는 그 내용을 설명하는 텍스트와 동반돼야 하며 따로 읽어도 유익해야 한다.) 차트를 설명하는 다른 방법은 제목에 데이터를 해석해서 설명하는 것

→ This technique can make a description more meaningful, particularly when the data is unfamiliar. (이런 방법은 설명을 더욱 의미 있게 하며 특히 익숙하지 않은 데이터에 효과적이다.)

이 데이터들의 이해를 돕기 위해 어떤 방법이 더 있는가 ??

Incorporate details

Try to incorporate details from other perspectives. (다른 관점에서의 세부 사항들을 포함하는 방법이 있다.) It’s important to summarize your data, but when we find ways to elevate categories or highlight individual records, a chart becomes multi-dimensional. (차트를 더 큰 범주에서 보거나 개별 기록을 강조하면 차트를 다각화할 수 있다.

• Chart functionality → 이러한 세부 사항을 이용해 최근 판매량 차트를 보강하면 더 유용하다.

• Smaller charts tend to be static As they are generally small, static charts don’t require grid lines, labels, or interactivity, since they create the expectation that additional detail is just a tap away. (보통 정적 차트들은 작고 누르면 추가적인 세부 정보를 확인할 수 있을 것으로 기대되므로 격자 선이나, 라벨, 상호작용이 필요 없다.

Progressively reveal complexity

As charts become more powerful, it’s important to introduce additional functionality gradually. You should progressively reveal chart complexity so that someone can choose the level of information that matches their interest. (차트의 복잡성을 단계적으로 공개해서 사용자가 그들의 관심과 일치하는 수준의 정보를 선택할 수 있도록 한다.)

• Progressive complexity
  • 점진적인 복잡도 : 관심사에 맞는 정보 수준을 선택할 수 있도록 (확장 버전을 제공하자)
• Chart continuity
  • 차트 연속성을 유지하며 : This means that a chart should retain its shape and any numbers apparent in an earlier view should be preserved. (이것은 차트가 그 모양을 유지해야 하고 이전 보기에서 보이는 모든 숫자는 보존되어야 한다는 것을 의미한다. → 값, 상태, 맥락을 보존)

시각화 ➡️ 정적 차트 ➡️ 차트를 탭 하면 상호작용이 되는 차트로 확장

how they relate to each other in a chart design system

Here are some things to remember when planning multiple charts. (여러 개의 차트를 계획 중이라며 다음의 몇 가지를 명심하자.)

Use familiar forms

Bar charts and line charts are forms that many people encounter and use daily, while a scatter plot is less common and may require extra guidance to ensure that it is interpreted correctly. ( 막대와 선 차트는 일반적이고, 산포도는 덜 일반적이라 올바르게 해석하기 위해 추가 지침이 필요할 수 있다.)

If you want to do something unique, it should be introduced clearly, as demonstrated here in the onboarding flow for Activity. (독특한 것을 시도하려면 여기 활동 앱에 보이는 흐름과 같이 명확하게 소개돼야 한다.)

Differences matter

Differences matter, and the variations between charts are a signal that something has changed. (차트 간의 변화는 무언가 변경되었음을 의미한다.)

• Chart variations intentionally create differences between your charts to improve their interpretation. (차트 간의 의도적인 차이를 만들어 더 쉽게 해석되도록 한다.)

The End ..

헉.. 코드와 관련된 세션은 이거였넴…. 😅

Hello Swift Charts - WWDC22 - Videos - Apple Developer

매달 첫째 주 일요일에 데보션영 밋업이 열리는데요. 이번 달 데보션영 밋업에서는 아래와 같은 주제로 데보션영들을 위한 밋업을 진행했습니다.

요즘 PM의 효과적인 프로젝트 관리

1. 핵심 목표에 집중하자
2. 과제별 일정은 중요하다
3. 검증하고 확인하자
4. 배웠는지 생각하자

그러면 프로젝트 관리를 어떻게 하면 잘 할 수 있을까 ??

• 프로젝트 관리를 위한 최고의 도구와 기술 ⚒️
  • Confluence (프로젝트를 시작하는 단계)
  • Jira (프로젝트 구체화&상세화)
  • Gitlab (프로젝트 코드를 관리하고 배포)

[ 신기술 도입의 목적과 방법 ]

• 목적
  • 프로젝트의 특성과 목표에 기여하는지 분석
  • 개발 생산성, 안정성과 성능, 경영 효율화 = 클라우드, AI, IT요소 기술 등 다양한 새로운 기술들을 도입하여 프로젝트 성과 지속 향상
• 도입을 위한 기술 습득
• 도입 후 유지보수 전략 수립

[📍결론 ]

1. 시작하자

• 기업의 프로젝트 활동에서 협업/팀워크 중요
• 현업 관점에서 프레임워크 구성해 보기

2. 학습하자

• 협업 도구 사용법 공부하기
• 헙업 도구 사용해서 토이 프로젝트 수행하기

3. 익히자

• 협업 툴을 반복 이용하여 익숙해지기
• 단축키/템플릿으로 효율성 확보하기

요새 공모전을 준비하면서 Jira를 사용하고 있었는데 처음에는 어색해서 불편했지만, 익숙해지고 개발을 시작하다 보니 이슈와 버그를 Task로 생성하고 팀원에게 바로 할당할 수 있는 등의 기능이 있어서 야무지게 잘 사용하고 있습니다. 추천해 주신 다른 도구들도 꼭 한 번 사용해 보겠습니다!! ໒(⊙ᴗ⊙)७✎▤

지극히 개인적인 취업준비 & 신입 개발자로 살아남기

• 코딩 테스트
  • 개념 + 적용
  • 빈출 개념 위주로 공부
    • e.g. 자료구조,
  • 공부한 개념 문제에 적용하기
    • 왜!! 그 개념을 적용하는게 적절한지 이해하기
• 기술 면접
  • CS + 선택한 도메인
  • 기초 Computer Science
    • 자료구조, 알고리즘, 운영체제, 데이터베이스, 네트워크
      • 디자인 패턴, 아키텍처, 객체지향 등등
      • 죽은 지식으로 두지 말 것
      • 결국 기초 CS를 바탕으로 모든 것이 이루어져 있음
      • 공부한 것들을 개인 프로젝트에 적용

개인적으로 추천하는 것

• 못먹어도 고
  • 준비가 되어 있든, 안 되어 있든 4학년 초부터는 지원해보기
• 하루라도 빨리 컴퓨터에 재미 붙이기
  • 커뮤니티 활동
  • 내가 필요한 무언가를 만들어보기

신입 개발자의 마인드셋

• 내가 찾아보는 것보다 물어보는게 빠르다
  • 1부터 10까지 물어보라는 의미 X
  • 감이 아예 안 올 때는 솔직하게 말하고 방향성 가이드 받기
• 사고만 안 쳐도 신입 개발자 몫을 해내는 것
  • 배우려는 태도
  • 주눅들지 않기

마지막으로 SKT 복지와 개발자로서 성장할 수 있도록 여러 가지 지원해주시는 정보도 알려주셨는데요..!! 들어보니 더욱 더... SKT에 들어가고 싶어졌어요... 아직 3학년이지만 4학년 초에 SKT iOS 개발자가 되기 위해!! 코딩 테스트랑 기술 면접을 미리미리 준비해야겠어요! (｡•̀ᴗ-)✧

폐쇄망을 여행하는 히치하이커를 위한 안내서

• 폐쇄망 개념 💬
  • 망분리된 환경으로 외부 인터넷망과 분리, 차단된 업무망
• 망분리
  • 외부 인터넷망을 통한 불법적인 접근과 내부정보 유출을 차단하기 위해 업무망과 외부 인터넷망을 분리하는 망 차단조치를 말함
• 도입 배경
  • 개인정보 유출등의 사고에 의해 시작 ( 여러가지 예시를 들었는데 스케일이 커서 놀랐어요...!!)

동아리에서 사이드프로젝트를 준비하고 출시하기 직전에 동아리 legal 팀의 도움을 받아서 개인정보처리방침과 이용약관을 만들어 보았는데요..! 생각보다 개발할 때 개인정보에 대해서 신경 쓸 부분이 많았었어요..! 다음 프로젝트에서는 맨 처음에 개발할 때 부터 개인정보에 대해서 고민하면서 개발해야 겠다고 생각했습니다!!

• 망분리 방식
  • 물리적 망분리: 통신망을 물리적으로 업무용과 인터넷용으로 분리하고 별도 PC 혹은 장비를 사용하는 방식
  • 논리적 망분리: 통신망을 SW적으로 업무용과 인터넷용으로 분리하고 논리적으로 분리된 PC를 사용하는 방식

그리고 마지막으로 여행자들을 위한 설명을 해주셨습니다!

사실 예전에 인턴 다닐 때 폐쇄망에서 개발 환경을 세팅하고 개발하기 정말 너무 힘들었던 기억이 있어요..! 학교에서는 절대로 보지 못할 경험을 해서 좋았지만...! 그때는 정말 하루하루가 너무 힘들었던 것 같은데 이런 내용으로 발표를 해주시고 설명을 자세히 해주셔서 발표자님께 너무 감사드려요!! ( ˶˙ᵕ˙˶ )

지금 알고 있는걸 그때도 알았더라면 좋았을 것들

취업을 준비하면서의 멘탈 관리

• 포모(Fomo) 증후군
  • Fear Of Missing Out의 약어. 유행에 뒤쳐지는 것 같아 두려움과 스트레스를 받는 상태를 말한다. 포모 증후군(FOMO syndrome)이라고 알려져 있으며 소외 공포증이라고 순화하기도 한다.
  • 대표적인 사례: Al
• 그땐 몰랐던 것
  • 취업은 소개팅과 같더라 (서류:내가 정할 수 있는 것은 없다, 면접:면접을 통한 배움)
• 인생은 길다 돌아가는 것에 두려워 할 필욘 없다.
  • 먼저된 자가 나중되는 경우
• 대학생 때 알았더라면 좋았을 것들 (추천)

• 그래서 취업은 했는데요 ??
  • 개발이 전부는 아니다!
  • 멘탈 관리에 힘쓰자
  • 스트레스 관리를 위한 자신만의 노하우를 만들어야 한다. (저는 지금 절망에 계곡에 있는것 같아요...! ㅜㅅㅜ )

[📍결론 ]

1. 취업은 생각보다 쉽지 않다.
2. 멘탈 관리가 가장 중요하다.
3. 회사 생활에서의 괴리감을 잘 맞서자.
4. 미움받을 용기
5. 회사와 나를 동일시 하지 말자
6. 언제나 중요한건 나 자신
7. 혼자가면 빨리 갈 수 있지만 같이 가면 멀리 갈 수 있다.

사실 요즘 개발뿐만 아니라 하고 있는 일이 너무 많아서...ㅜㅜ 번아웃?이 왔다고 생각하고 있었어요... 항상 저처럼 바쁜 친구도 일에 힘듦을 느끼고 최근에 드럼을 취미로 배우기 시작했더라구요! 저도 뭔가 신경써야하는 일이 너무 많아서 받는 스트레쓰를 취미로 풀어 건강한 멘탈 관리에 힘써 볼게요!! ( °̀ᗝ°́)و.*･ﾟ✧

⭐️ 8월에도 좋은 밋업 진행해주신 데보션분들 너무 감사합니다~!! 🫶🏻

T.um 정보 및 예약

체험을 하기 전에 데보션영 담당자님과 데보션영 사람들과 점심 먹기 위해 일찍 만났습니다.

원래 점심을 먼저 먹고, T타워를 잠깐 구경하려고 했는데 점심시간에 음식점에 사람이 너무 많아서 T타워를 먼저 구경하기로 했다 ! 31층 휴게 공간 구경하러 총총..

점심은 매드포갈릭에서 먹었는데 완전 푸짐하게 시켜주셔서 맛있게 먹었습니다~!! 🍽

이제 드디어 (두그두그) 대망의 Tum 투어를 하러 갔다!

본격적으로 투어가 시작된 후 하이퍼루프 라는 초고속 기차를 타고 하이랜드를 들어가게 되는데 기차 움직임이 놀이기구 같아서 재밌었다!

마지막으로 최첨단 의료 기구와 로봇을 VR로 조정하는 시뮬레이션 그리고 해저 도시까지 보았다.

끝으로 Tum 투어의 후기를 말해보자면...!!

내가 잘 모르는 분야에 있는 최첨단 기술을 보고 심지어 무료로 체험까지 해볼 수 있다는 점이 너무 좋았고, 특히 설명 도슨트의 내용이 좋아서 어려운것 없이 이해가 잘된다. 곧 이런 미래를 맞이하게될 중,고등학교 학생들도 와서 꼭 체험 해봤으면 한다. 곧 리뉴얼을 시작한다고 해서...!! 리뉴얼이 끝난 뒤 꼭 한번 방문해 볼 것을 추천한다 !! 👍🏻☺️

매달 첫째 주 일요일에 데보션영 밋업이 열리는데요. 이번 달 데보션영 밋업에서는 아래와 같은 주제로 데보션영들을 위한 밋업을 진행했습니다.

저도 이제 3학년이다 보니 취업 준비를 걱정하고 있었는데 이번 밋업을 통해서 많은 것을 다시 생각해 보게 되고 여러모로 유익한 밋업이었습니다. 저에게 크게 다가왔던 것들을 위주로 다시 회상하면서 밋업 후기를 작성해 보겠습니다 ~

영업맨 왕대리는 어떻게 데보션 전문가가 되었을까?

해당 세션에서는 '이직'에 대해서 설명을 해주셨는데요. 이직은 밑과 같은 순서로 진행된다고 해요.

1. 관심 분야를 찾고
2. 준비하고
3. 실행한다.

특히, 준비 단계에서 최대한 열심히 그리고 제대로 준비하는 것이 중요하다고 생각해요! 왕태웅 님께서 말씀해 주셨듯이 기회는 갑자기 오기 때문이죠..!! 작년에 제가 회사에서 잠깐 견습 인턴 생활을 할 수 있었던 것도 갑자기 온 기회를 놓치지 않았기 때문이라고 생각해요.. 근데 사실 작년에 저한테 저런 기회가 왔을 때 저의 실력이 너무 부족하다고 생각해서 기회를 놓칠뻔했는데 추천해 주신 분을 믿고 시작해서 결국 너무나 좋은 경험을 할 수 있었습니다. 그리고 학교에서 좋은 행사 같은 것도 대부분 필수 자격증? 같은 것들이 있어서 그런걸 사전조사해보고 미리미리 준비해 두는 것도 필요한 것 같아요 ㅜㅜ 나중에 활동 공지가 나오고 나서 준비하기에는 준비 시간이 턱없이 부족하거든요...ㅜㅜ

⭐️ 좋은 기회가 왔을 때 두려워하지 말고 기회를 받아들일 용기와 그만한 역량을 미리미리 준비해 두는 게 정말 중요하다고 생각해요!!

개발자의 성장과 오픈소스, 그리고 커뮤니티

해당 세션에서는 박정환님이 오픈소스와 커뮤니티에 관해서 설명을 해주시고 중간에 질문을 하나 던져주셨어요 !

📍 이번 주에 무슨 일들을 하셨나요? 지금 하고 있는 일들이 내일, 다음 달, 내년에 어떻게 도움이 될 것 같으신가요? 시간이 지나며 쌓이는게 있으신가요?

저 스스로 이 질문에 대해서 답변을 생각해봤는데... 저에게 조금 실망하게 되었답니다.. 사실 지금 너무나 많은 프로젝트를 진행하고 있어요... 그래서 어느것 하나에 집중하지도 못하고 개발도 맨날 구글링으로 서치하고 바로 복붙을 하고 있어요...ㅜㅜ 항상 그러지 말아야지 다짐하면서도 빨리 좋은 결과물을 만들고 싶은 바람에...ㅜㅜ 하지만 이런 행동이 나중에 저에게 독이 된다는 사실을 알고 있으면서도 고치기가 쉽지 않네요.. 특히 저 질문에 답변을 해보자면... 제가 지금처럼 계속 프로젝트를 진행하면 과연 내일, 다음 달, 내년에 저에게 남는 것이 있을지... 고민해보면 제 대답은 없습니다...였습니당... 현재 상황을 극복하기 위한 개발은 그만! 문제를 정확히 짚고 해결 방법을 이해하면 개발하는 습관을 하루빨리 들이도록 노력하겠습니다 !!!!

컴공 후배들이 3~4학년때 가장 많이 하는 질문 Top 10

지금 저에게 가장 필요한 자세들이에요...ㅎㅎ

개발자에게 필요한 덕목? 자세? 태도?

• 구글링 말고 공식문서를 보세요 !!
• Just Do It !
• 소통 !!
  • 이해가 안되면 물어보세요.
  • 🔥 감으로 얘기하지 말고 Fact(=Data)로 승부합니다.

사실 머리로는 잘 알고 있지만... 실천하기 어려운 것들이라고 생각해요! 하지만 저런 태도를 가져야 진정한 개발자로 성장할 수 있을 것 같아요..!!!

생생한 취업 후기

해당 세션에서는 취업 준비 팁에 대해서 설명을 해주셨습니다! 저도 지금 코테 준비를 시작하고 있는데 ㅜㅜ 풀기 어려운 문제가 나오면 의욕이 너무 떨어지지만... 취업을 위해서라면.... 열심히 해야죵... 아자아자 !!!

이제 능률이 오르게 에어팟을 끼고 코테 공부를 하러 가보겠습니다!!

좋은 밋업 진행해주신 데보션분들 너무 감사합니다~!! 🫶🏻

웹 성능 최적화를 수행하는 이유

• 서비스 관점에서도 웹 성능 최적화는 중요하다. (로딩시간, 이탈률)

  • 백엔드 개발자, 디자이너, PM도 웹 성능 최적화를 알아야 한다.

• Site speed improvement of just 0.1s leads to an increase in conversion rates & average order value

• 속도 정의 (=Core Web Vitals)

  • LCP (Largest Contentful Paint)
  • FID (First Input Delay) → 대체 → INP (page’s overall responsiveness)
  • CLS (Cumulative Layout Shift)

• 속도 측정 도구

• 사용자의 데이터 (RUM)

• 발표자 분은 웹 페이지 테스트 라는 것을 주로 사용

• RUM에서는 web-vitals JS를 주로 사용

웹 성능 최적화 방법

1. LCP Optimization a. LCP 자원(이미지 파일)이 HTML에서 빨리 찾아져야 한다. b. LCP 자원이 우선시 되어서 다운로드 돼야 한다. c. CDN 사용 (TTFD 자원)

2. CLS Optimization a. 동적으로 크기가 할당되는 것들에 사이즈를 fix 해주자 b. animations/transition 사용을 피하자 c. bfcache를 사용하자

3. FID Optimization a. 긴 작업을 피하거나 분할하자 b. 불필요한 JavaScript 사용을 피하자 c. 대규모 렌더링 업데이트를 피하자

세션2. ifland 웹 프론트엔드 성능 최적화 적용 사례

ifland 및 ifland studio 소개

• Social Metaverse Service
• ifland studio
  • ifland에서 아바타(ifme) 의상을 만들 수 있는 곳

ifland studio 웹 성능 최적화 사례 공유

• 앱 성능 최적화 대상 페이지는?
  • 사용자들이 가장 많이 사용하고, 서비스의 진입점인 home(메인 페이지)

웹 성능 최적화 경험 및 팁 공유

• WebPageTest랑 Google Lighthouse 주로 사용

< 문제 상황 >

1. Render Blocking Resource 다수 존재 (이미지 로딩이 느리다.)

💡 불필요 스크립트 제거 및 스크립트 로딩 옵션 지정을 통한 render blocking 요소 제거 (ex. defer 사용)

2. 이미지 용량 문제

💡 WebP, AVIF가 PNG,JPEG에 비해 압축률 우수

3. 해상도에 맞지 않는 이미지 사용, 즉 Desktop과 Mobile 공통 이미지 사용

💡 picture source 태그를 사용하여 Desktop과 Mobile 별도 이미지 적용

4. 네트워크 요청 낭비 (페이지 로딩시 불필요한 이미지 한번에 로드)

💡 메인 이미지 제외한 이미지에 대해 lazy loading 적용 불필요한 네트워크량 감소를 위해 페이지 초기 로드시 이미지 요청 수 20개에서 2개로 감소

5. 메인 이미지가 늦게 로드 (LCP. UX 영향)

💡 메인 이미지 Preload 적용하여 로딩속도 개선

6. 모바일 해상도에서 Header 아이콘 및 로고 이미지 늦게 로드 (UX)

💡 Header 아이콘을 html 내 inline svg로 추가, 로고 이미지 preload 추가

7. CSS, JS 용량 감소 여지 존재

💡 CSS, JS gzip, minify 작업 → 서버 네트워크 요청 용량 감소

8. 화면 영역에 불필요한 움직임 존재

💡 CSS 수정을 통해 CLS 수치 0으로 개선 (콘텐츠 로드 부분 영역 확보)

9. html, JS 중복 코드 발견 (Desktop, Mobile)

💡 코드 개선을 통한 소스 경량화

10. 재방문자 페이지 접속시간 단축 개선점 발견

💡 백엔드에서 브라우저 캐싱 설정 (Request header 옵션 추가)

[ 결과 ]

[ Lessons learned & tips ]

1. Script에 옵션 추가 (defer, async)
2. WebP, AVIF 이미지 포멧 적용
3. Image lazy loading 적용
4. 리소스 Preload 옵션 적용
5. 개발코드는 작품을 만들 수 있지만, 부채가 될 수도 있음 (항상 경량화를 염두)
6. CWV 개선은 지속적인 노력이 요구되는 작업
7. 웹과 그를 위한 기술은 지속적으러 변화하고 발전함

[ Conclusion ]

1. 웹 프론트엔드 개발자는 웹 성능 개선을 통해 서비스 향상에 크게 기여할 수 있다.
2. 웹 프론트엔드 성능 개선은 비즈니스 관점에서 상당히 중요하다. (로딩 시간이 길면 사용자는 이탈한다.)
3. 사용자 중심으로 사이트를 지속적으로 개선하는 문화를 만들 필요가 있다.
4. 측정 가능한 지표를 정의하고 목표를 설정하고 달성하는 일은 재미있다.

자료

발표자료

테크 세미나 다시보기

Ch1-3. Handling User Input

1. Mark the User’s Favorite Landmarks

(간단요약) step1 ~step5: data Struct에 isFavorite 변수를 추가해주고, LandmarkRow에서 해당 변수가 보이는 별 이미지 추가

var body: some View {
        HStack {
            landmark.image
                .resizable()
                .frame(width: 50, height: 50)
            Text(landmark.name)

            Spacer()

            if landmark.isFavorite {
                Image(systemName: "star.fill")
                    .foregroundColor(.yellow)
            }
        }
    }

2.Filter the List View

(간단요약) step1 ~step6: ListView에서 필터 기능 보여주기

• LandMarkList에서 새로운 filteredLandmarks 배열을 만들어준다.

  • 조건 1: !showFavoritesOnly가 ture 이거나?
  • 조건 2: isFavorite이 true 인가?

    그래서 showFavoritesOnly가 false인경우는 모든 배열의 요소가 새로운 배(filteredLandmarks)에 들어가고 true인 경우 isFavorite이 true인것만 새로운 filter 배열에 들어간다.

• 마지막으로 filter 배열을을 body 안에 있는 List 안에서 보여준다.

    @State private var showFavoritesOnly = false
  
    var filteredLandmarks: [Landmark] {
        landmarks.filter{
            landmark in (!showFavoritesOnly || landmark.isFavorite)
        }
    }

3. Add a Control to Toggle the State

(간단요약) step1 ~step4:Toggle 버튼 생성해서 변수 관리하기

• Toggle을 사용하여 showFavoritesOnly 변수를 연결해준다.

  Toggle(isOn: $showFavoritesOnly) {
      Text("Favorites only")
  }

4. Use an Observable Object for Storage

(간단요약) step1 ~step4: import Combine해주고 ObservableObject class 생성

import Combine

final class ModelData: ObservableObject {
    @Published var landmarks: [Landmark] = load("landmarkData.json")
}

Combine이란?

시간 경과에 따라 변경되는 값을 내보내는 Publisher와 이를 수신하는 Subscriber로 시간 경과에 따른 값 처리를 위한 선언적 Swift API입니다.

• Publisher
  • Publisher는 하나 혹은 여러 개의 Subscriber 객체에 시간이 흐름에 따라 값을 내보낼 수 있는 타입을 선언하기 위한 프로토콜입니다.
  • Output, Failure 타입이 제네릭으로 구현되어 있습니다.
• Subscriber
  • Subscriber는 Publisher에게 값을 받을 수 있는 타입을 선언하기 위한 프로토콜입니다.
  • Input, Failure 타입이 제네릭으로 구현되어 있습니다.
• Operator
  • Operator는 Publisher를 반환하는 Publisher 프로토콜에 정의된 메서드들입니다.
  • 여러 종류의 Operator를 Combine 하여 사용하여 Publisher가 내보내는 값을 처리합니다.
  • Upstream, DownStream이라고 하는 Input, Output을 가지고 있습니다.
• Subscription
  • Subscription은 Publisher와 Subscriber의 연결을 나타내는 프로토콜입니다.
  • 간단하게 말해서 Publisher + Operator + Subscriber로 이뤄진 하나의 작업이 Subscription입니다.

참고자료 1 참고자료 2

Observable Object란?

기본적으로 Combine에 포함된 기능으로 ObservableObject는 @Published 프로퍼티 래퍼가 붙은 값이 변경되기 전에, 변경된 값을 방출(emit)하는 objectWillChange 퍼블리셔를 사용할 수 있도록 하는 프로토콜입니다. (클래스에서만 사용 가능한 프로토콜입니다.)

@Published 속성 래퍼(Property Wrapper)란?

SwiftUI에서 가장 유용한 속성 래퍼 중 하나이며 변경이 발생할 때 자동으로 알리는 관찰 가능한 오브젝트(observable object)를 만들 수 있습니다. SwiftUI는 이러한 변경 사항을 자동으로 모니터링하고 데이터에 의존하는 모든 View의 body 속성을 다시 호출합니다.

참고자료

5. Adopt the Model Object in Your Views

(간단요약) step1 ~step7: 기존의 landmarks를 위에서 만들어준 ModelData().landmarks로 바꿔준다.

@EnvironmentObject 란?

@Environment라는 프로퍼티 래퍼는 읽기 전용 으로 특정 뷰에서 EnvironmentValues의 특정 요소를 읽어와 뷰 구성에 반영할 때 사용합니다.

참고자료

@StateObject란?

@StateObject 프로퍼티 래퍼는 겉보기엔 @ObservedObject와 비슷하게 작동합니다. 하지만 사용하는 것에는 명확한 차이점이 존재합니다. @StateObject를 통해서 관찰되고 있는 객체는 그들을 가지고 있는 화면 구조가 재생성되어도 파괴되지 않습니다.

참고자료

6. Create a Favorite Button for Each Landmark

(간단요약) step1 ~step7: 각 페이지 별로 즐겨찾기 버튼 만들기

• @Binding을 사용하여 변수 만들어주고

  Binding이란?

  @State 로 선언된 속성을 다른 뷰에서 사용하려 한다면 @Binding 을 사용해 줄 수 있다. 사용시에는 앞에 $를 사용해 Bining 변수임을 나타낸다. @State 로 선언된 속성에 변경이 생기면 @Binding 변수에서 이를 인지하고 해당 값에 따른 뷰 변화를 바로 반영할 수 있도록 하는 방식입니다.

참고자료

• FavoriteButton 만들어주기

  struct FavoriteButton: View {
    @Binding var isSet: Bool
  
    var body: some View {
        Button {
            isSet.toggle()
        } label: {
            Label("Toggle Favorite",systemImage: isSet ? "star.fill" : "star")
                .labelStyle(.iconOnly)
                .foregroundColor(isSet ? .yellow : .gray)
        }
    }
  }

깃헙 코드: https://github.com/LeeJoEun-01/SwiftUI-Study

Ch1-2. Building Lists and Navigation

1. Create a Landmark Model

(간단요약) step1 ~step11: data파일을 json으로 넣고 codable 프로토콜을 사용하여 데이터를 읽기 쉽게 구조체를 만들어준다.그리고 각각의 파일들을 Views, Model, Reaources 폴더에 넣어준다.

2. Create the Row View

(간단요약) step1 ~step7: HStack을 사용하여 이미지와 텍스트 row로 정렬하기

HStack {
            landmark.image
                .resizable()
                .frame(width: 50, height: 50)
            Text(landmark.name)

            Spacer()
        }

3. Customize the Row Preview

(간단요약) step1 ~step4: PreviewProvider를 사용하여 두 화면으로 볼 수 있고, Group으로 묶을 수도 있다.

Group이란?

여러개의 View 들에 동일한 속성을 부여하고 싶을때 사용한다. 그러나 VStack과 차이점을 잘 알고 있어야한다. VStack(HStack, LazyVStack, LasyHStack)은 최대 10개의 자식을 가질 수 있습니다.

4. Create the List of Landmarks

(간단요약) step1 ~step2: 정적 리스트 만들기

    var body: some View {
        List {
            LandmarkRow(landmark: landmarks[0])
            LandmarkRow(landmark: landmarks[1])
        }
    }

List란?

List는 이름 그대로 목록(List) 인터페이스를 구현하기 위해 존재합니다. SwiftUI의 리스트는 UIKit의 UITableView와 하는 일이 상당히 비슷합니다.

5. Make the List Dynamic

(간단요약) step1 ~step4: 동적 리스트 만들기

• 동적리스트를 만드는 방법

    List(landmarks, id: \.id) { landmark in
        LandmarkRow(landmark: landmark)
    }

• Identifiable protocol 사용

    List(landmarks) { landmark in
        LandmarkRow(landmark: landmark)
    }

Identifiable protocol이란?

Hashable프로토콜을 준수하는 id 프로퍼티 하나만 가지는 아주 단순한 프로토콜 입니다. 어떤 struct, class를 정의할 때 ID값이 필요한 경우 해당 protocol을 conform하면 됩니다. (위의 코드 참고!!) 참고자료

6. Set Up Navigation Between List and Detail

(간단요약) step1 ~step7: 네비게이션뷰 세팅하기

• ContentView
  • LandmarkList()
    • NavigationView {}
      • NavigationLink{} label: {}
      • navigationTitle("제목")

        NavigationView {
        List(landmarks) {
            landmark in
            NavigationLink {
                LandmarkDetail()
            } label: {
                LandmarkRow(landmark: landmark)
            }
        }
        .navigationTitle("Landmarks")
        }

NavigationView

NavigationView는 최상위에 위치해야합니다. NavigationLink는 네비게이션 형태로 presentation을 제어하는 뷰입니다. 위의 코드처럼 도착지에 해당하는 뷰와 타이틀에 들어갈 label를 넣어서 사용합니다. 참고자료

7. Pass Data into Child Views

(간단요약) step1 ~step11: List의 child View에 데이터 연결하기

• 여기서 VStack을 ScrollView로 바꿔준다.

  ScrollView

  ScrollView {...} 안에, 추가할 다른 view를 넣으면 됩니다. default axes는 .vertical이지만 ScrollView(.horizontal) {}을 넣어주면 가로로 스크롤이 되는 뷰가 나옵니다.

8. Generate Previews Dynamically

(간단요약) step1 ~step4: 프리뷰에서 보는 기기 동적으로 만들기

struct LandmarkList_Previews: PreviewProvider {
    static var previews: some View {
        ForEach(["iPhone SE (3rd generation)", "iPhone XS Max"], id: \.self) { deviceName in
            LandmarkList()
                .previewDevice(PreviewDevice(rawValue: deviceName))
                .previewDisplayName(deviceName)
        }
    }
}

여기서 주의!!

forEach문 안에 들어갈 수 있는 자신의 Xcode 시뮬레이커에 해당 device가 들어있어야 한다. => 위의 사진에서 iOS Simulators안에 들어있는 목록을 preview에서 사용할 수 있는 디바이스들이고 만약 위의 목록에 없는 디바이스가 사용하고 싶다면 Add Additional Simulators에서 해당 디바이스를 추가해주면 된다!!

Chapter 1. SwiftUI Essentials

> Creating and Combining Views

Section 1.

Create a New Project and Explore the Canvas

(간단요약) step1 ~step7: 프로젝트를 생성하는 방법과 기본 세팅에 대해서 설명해준다.

Step5

SwiftUI에서 view 파일이 기본적으로 두 구조체로 만들어진다. 첫번째 구조체는 View protocol를 준수하고 view의 콘텐츠와 레이아웃을 묘사한다. 두번째 구조체는 해당 미리보기에 대한 view이다.

그렇다면 View Protocol 이란??

• 프로토콜이고, body라는 computed property를 가지고 있는 타입
• view를 입력할 수 있게하는 인터페이스를 제공하는 역할

SwiftUI에서 뷰들을 Struct으로 정의하는 이유

• 성능 🛠

  • Struct는 Class보다 단순하고 빠른 특징이 존재

  • UIView같은 경우에는, constrant, layer 등 많은 property와 메서드를 가진 클래스에의 subclass인데, UIView의 서브클래스들은 모두 UIView의 속성을 그대로 가져가야만 하는 구조 ( 애플 문서만 봐도, UIView관려 속성이 200개 넘게 존재)

  • SwiftUI에서는 상속을 대신하여 ViewModifier 개념을 사용하여 컴포넌트화 할 수 있도록 제공

• 가변성을 최소화 (함수형 프로그래밍의 핵심) 🩹

  • class는 reference type이므로 어디에서도 값을 쉽게 바꿀 수 있지만, Struct는 value type이므로 앱의 전체 상태를 고려할 필요 없이 코드의 일부에 대해서 더 쉽게 추론할 수 있는 장점이 존재
  • 가변성을 최대한 멀리하는게 함수형 프로그래밍의 핵심인데 이때 class보다 Struct가 더 유리 (=프로그램 실행 중에 상태가 변화하는 것을 최소화하는게 좋은 코드)

• 메모리릭 방지 🧰

  • Reference type을 사용하다보면 retain cycle때문에 메모리에서 해제가 안되는(memory leak) 현상이 발생하는데, 이 때 계속해서 메모리를 차지하는게 늘어나면서 크래시가 나는 반면에, value type인 struct을 쓰면 Memory leak에 안전한 프로그래밍이 가능

참고 자료

Section 2.

Customize the Text View

(간단요약) step1 ~step6: Text View 요소 변경하는 방법

• Show SwiftUI Inspector 보는 법!! => command + click

  

• SwiftUI Inspector : 여기서 들어가야 하는 Text or Font or Color 등을 바꿀 수 있고, Inspector에서 요소르 바꾸면 코드가 알아서 변경된다!!

  

Section 3.

Combine Views Using Stacks

(간단요약) step1 ~step9: SwiftUI에서 레이아웃과 컨텐츠 등을 body property 안에 구성하는데, body property는 하나의 뷰만 반환하기 때문에!! stack안에 여러 개의 view를 combine하거나 embed 해야한다. (방법: horizontally, vertically, or back-to-front)

• Embed in VStack & Embed in HStack
  • stack 종류를 embed 해주고, library에서 text를 추가해준다.
• 정렬
  • Inspector에서 정렬 옵션을 선택해준다. (default: center)
  • VStack(alignment: .leading) 코드에 해당 문장이 생성된다.
• Spacer() : view 간의 간격을 "띄우고 싶을 때" 사용하는 것!
  • Stack안에서 사용되며, Stack의 크기만큼 내부 크기의 공백이 채우고 싶을때 사용 ```swift HStack { Text("Joshua Tree National Park") .font(.subheadline) Spacer() Text("California") .font(.subheadline) } ``` ### Section 4. #### Create a Custom Image View (간단요약) step1 ~step7: 이미지 추가하는 방법을 배우고 mask, border 그리고 drop shadow까지 만드는 방법에 대해서 설명해준다.
• asset catalog’s editor에 사진을 Import 해준다.
• mask, border, drop shadow를 만들어본다. + 사이즈 조절 - 이미지를 유지하고 이미지가 담긴 뷰의 크기를 조절하려고 할 때 - `Image("imageName").frame(witdh: 200, height: 200)` - 이미지 크기를 리사이징 하기 ( resizable()은 frame 앞에 있어야 한다.) - `Image("imageName").resizeble().frame(witdh: 200, height: 200)` ```swift var body: some View { Image("turtlerock") .resizable() .frame(width: 200, height: 200) .clipShape(Circle()) .overlay{ Circle().stroke(.white, lineWidth: 4) } .shadow(radius: 7) } ``` [참고 자료](https://lazyowl.tistory.com/235)

Section 5.

Use SwiftUI Views From Other Frameworks

(간단요약) step1 ~step5 MapKit 사용해서 map render 해보기

• Frameworks 사용해보기

  • import MapKit
  • map 정보를 받아올 수 있는 state 변수 만들어주기
  • body에서 Map함수를 불러와서 보여준다.

    import MapKit
    

  struct MapView: View {

  @State private var region = MKCoordinateRegion(
      center: CLLocationCoordinate2D(latitude: 34.011_286, longitude: -116.166_868),
      span: MKCoordinateSpan(latitudeDelta: 0.2, longitudeDelta: 0.2)
  )

  var body: some View {

    Map(coordinateRegion: $region)

  } }

• @State: state property

  • State value 값이 변경되면 뷰는 해당 value의 appearance를 무효화하고 다시 body 값을 계산
  • state 변수값이 변경되면 view를 다시 랜더링 하기 때문에 항상 최신 값을 가진다.
  • 현재 뷰 UI의 특정 상태를 저장하기 귀해 만들어진 것이기 때문에 보통 private
  • state 변수를 사용 할 때는 변수 이름 앞에 $(달러) 표시를 해줘야 한다.

참고 자료

Section 6.

Compose the Detail View

(간단요약) step1 ~step10 뷰 위에 여러 뷰 올리기

• view 위에 view를 올릴 때 height만 적으면 width는 알아서 계산해서 만들어 준다. MapView().frame(height: 300)

• offset -> relative position : 오프셋이란, 기준이 되는 주소에 더해지는 값을 의미

  • 주의할 점 !! offset modifier을 사용하더라도 view의 original dimension은 변하지 않는다.
  • .offset(x: 100, y: 100)

• Position -> absolute position : View의 available한 space를 모두 사용

  • position(x: 100, y: 100)

• ignoresSafeAreaEdges : safe area 를 무시할 edges 를 지정한다.

  • 옵션 지정 안했을 때 (좌)
  • .ignoresSafeArea(edges: .top) top에 있던 safe area가 없어진다. (우)
    
    ო͈̮
  • .ignoresSafeArea(edges: .bottom) bottom 있던 safe area가 없어진다. (좌)
  • .ignoresSafeArea(edges: .all) bottom 있던 safe area가 없어진다. (우)
    
    ო̤̻

참고 자료 ദ്ദി˶˙ᵕ˙˶ ) 참고 자료2