개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

kakao developer

Kakao API

삽질을 돌고돌아하긴 했지만, 제 글이 조금 불친절할 수도 있습니다.
우선 환경이 iOS10기준으로 진행될 것이기 때문에 iOS SDK v1 으로 진행됩니다.

위 카카오 개발자 링크를 따라 들어가면 당연하게도 xcode와 kakao SDK 설치를 하여야 합니다.

개발 환경을 맞추기 위해(우리는 iOS개발을 하기에) xcode를 필수적으로 설치해야하고, 카카오 플랫폼 서비스에서 제공하는 기능을 사용하기 위해 카카오에서 제공해주는 kakao SDK를 설치해야겠지요~ kakao SDK를 설치해야할 때는 본인의 iOS 환경에 맞춰 설치하는 것이 중요합니다. 현재는 iOS13까지 나왔기에 최신 버전을 설치하면 되겠지만, 간혹 기업에서 제공하는 환경이 그 이하일 경우에는 그에 맞는 SDK 설치는 필수! 잘 확인합시다.

시작하기

1. kakaoSDK 프레임워크 추가하기

Frameworks, Libraries and Embedded contents 에 우리가 다운받은 SDK를 넣어줍니당
여기서 중요한건 KakaoOpenSDK.framework 파일만 넣어주는 것입니다.

이렇게 추가된 프레임워크가 잘 들어가져있는지 위 사진과 같이
[Target] > [build phase] > [Link Binary With Libraries] 에서 확인해봅니다.

그리고 Other Linker Flags에 “-all_load” 를 추가해야합니다. 이때 순서 및 주요한 부분은

1. [Target] > [Build settings]에 들어간다
2. [All] & [Combine]으로 체크되어있는지 확인하고(all로 체크되어있는지 확인하는 것이 중요)
3. 검색에 other linker 를 검색해
4. Other Linker Flags에 + 버튼을 눌러 all_load 추가해준다.

2. 앱 등록하러 가기

kakao developer 바로가기

kakao developer로 들어가 로그인 후 내 어플리케이션 등록을 해줍니다. [내 어플리케이션] > [앱 만들기] 클릭!

사진은 굳이 등록하지 않아도 되며(지금은) 앱 이름과 회사 이름만 등록해주면 된다. 그러면 아래와 같이 앱 키가 만들어진다.

그리고 이제 중요한 것! 플랫폼을 추가해주어야 한다.

플랫폼 설정하기 클릭! 우리는 iOS 플랫폼을 설정할 것이기 때문에 iOS 플랫폼 설정하기 클릭합니다.

필수적으로 적어줘야하는 것은 번들 ID인데 여기에는 우리가 만든 프로젝트의 번들 ID를 적어주면 된다.
번들ID가 무엇인지 모르겠다면 [Target] > [General] > [Bundle identifier] 에서 확인하면 된다.

그리고 이제 또 중요한 부분!

다시 우리 프로젝트 xcode로 돌아와 URL types 를 추가해준다.

[Target] > [Info] > [URL types]에 들어가 위 사진처럼 설정해주는데 이떄 중요한 것은

URL Schemes에 kakao 문자열을 붙인 뒤 카카오 앱 키를 적어줘야 한다는 것이다.
그리고 중요한 것은 이때 이 카카오 앱 키라는 것이 우리가 kakao developer에서 어플리케이션 등록을 하면서 받은 네이티브 앱 키 라는 것이다. 따라서 **kakao<내 어플리케이션의="" 네이티브앱="" 키="">** 를 적어주면 된다.

그리고 이제 info.plist로 간다.

위 사진과 같이 KAKAO_APP_KEY 라는 키를 만들어 그 안에 밸류값으로 네이티브 앱 키 를 입력해준다.
이때는 kakao 문자열을 붙이지 않아도 된다.

그리고… 아직 끝나지 않았다

3. 화이트리스트 설정과 헤더파일 만들기

info.plist를 [Open As] > [Source Code]로 열어준다.
그리고 kakao SDK 화이트리스트 설정으로 가서 해당 소스코드를 추가해준다.

해당 스트링 값들을 추가해주면 되는데, 이때 처음 스트링값은 우리가 적어주었던 **kakao<네이티브앱 키="">** 를 적어주면 된다.

그리고 이제 거의 마지막으로 다다르고 있는데! 이제 bridge header 를 만들어줍니다.

말그대로 헤더 파일을 만들어주는 것이고 헤더파일을 만들었으면
SDK Header 불러오기 해당 페이지에서 제공하는 소스코드를 복사붙여주기 해줍니다!

그리고 최종적으로 [Target] > [Build Settings] > [Swfit Compiler] & [Objective-C Bridging Header]에서 브릿지헤더파일의 경로를 잡아줍니다! 이떄 에러가 날 수 있는데, 해당 에러의 이유는 우리가 헤더파일에 SDK의 경로를 설정해주었는데 해당 경로에 SDK 파일이 존재하지 않기 때문이다.

즉, 우리 프로젝트 내에 SDK 파일이 존재해야한다는 것이다.

위 사진과 같이 헤더파일이 가리키고 있는 곳에 SDK 파일이 존재해야한다는 것이다.
그러면 에러없이 빌드가 되는 것을 볼 수 있을 것이다!

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

SceneDelegate 삭제하기

xCode 11.2로 새 프로젝트를 만들면 SceneDelegate.swift파일이 추가 된다.
이를 그냥 지우고 빌드하면 검은 화면이 나오고, iOS13이상으로 강제하여야 하기 때문에 제거하는 법을 정리해보려 한다.

1. Info.plist에서 Application Scene Manifest 삭제

2. SceneDelegate.swift 파일 삭제

3. AppDelegate.swift 내 UISceneSession Lifecycle 함수 삭제

// MARK: UISceneSession Lifecycle

func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {
    // Called when a new scene session is being created.
    // Use this method to select a configuration to create the new scene with.
    return UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role)
}

func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set<UISceneSession>) {
    // Called when the user discards a scene session.
    // If any sessions were discarded while the application was not running, this will be called shortly after application:didFinishLaunchingWithOptions.
    // Use this method to release any resources that were specific to the discarded scenes, as they will not return.
}

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

error: Build input file cannot be found 에러

info.plist 파일을 옮기게 되면 해당 에러가 발생한다.

에러내용은 위와 같이 빌드 입력 파일을 찾을 수 없다는 의미로, 프로젝트를 생성할때 자동적으로 Xcode 최상위의 info.plist파일을 생성하는데 내가 그 파일을 다른곳으로 옮겼기 때문에 찾을 수 없다고 에러를 띄워주는 것이다. 따라서 info.plist가 어디에 있는지 정확히 알려주면 된다.

Solution

1. Xcode내 프로젝트 targets의 Build Settings에서 infoplist라고 키워드를 검색
2. infoplist에 관한 항목들이 나오면 Info.plist 파일의 위치를 수정

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.

프로젝트를 진행하면서 scroll view를 구현할 일이 생겼는데, 그냥 뷰컨트롤러 위에 스크롤뷰를 올리고 (0,0,0,0)을 하는데 적용은 되지않고 계속 빨간줄만 뜬다.

찾아보니 이번 Xcode 11 버전에서 인터페이스 빌더로 스크롤뷰를 만들때 contentLayoutGuide, frameLayoutGuide가 기본적으로 활성화 되도록 추가되었다고 한다.

Xcode 11 Release Notes

Interface Builder

Content and Frame Layout guides are supported for UIScrollView and can be enabled in the Size inspector for more control over your scrollable content. (29711618)

릴리즈 노트를 보면 content 및 frame 레이아웃 가이드는 UIScrollView에서 지원되며, 스크롤 가능한 컨텐츠를 보다 효과적으로 제어할 수 있도록 Size inspector에서 활성화할 수 있다고 나와있다.

Size inspector에서 확인해보면 Content Layout Guides 체크박스가 추가되어있습니다. 스크롤뷰 생성시 기본적으로 활성화 되어있기 때문에 따로 체크할 필요는 없습니다.

contentLayoutGuide

ScrollView의 변환되지 않은 컨텐츠 사각형을 기반으로 하는 레이아웃 가이드
ScrollView의 컨텐츠 영역과 관련된 오토 레이아웃 제약 조건을 만드려면 이 레이아웃 가이드를 사용하면 된다

frameLayoutGuide

ScrollView의 변환되지 않은 프레임 사각형을 기반으로 하는 레이아웃 가이드
컨텐츠 사각형 반대로 ScrollView 자체의 프레임 사각형을 포함하는 오토 레이아웃 제약 조건을 만드려면 이 레이아웃 가이드를 사용하면 된다

Interface Builder로 ScrollView 만들기

ScrollView 추가

ScrollView를 추가하고 화살표를 눌러 ContentLayoutGuide와 FrameLayoutGuide가 포함되어있는걸 확인할 수 있다.

가장 간단하게 스크롤뷰를 구현하는 방법은 size inspector에 체크되어있는 content layout guids를 해제하면 이전에 했던 방법처럼 적용이 가능해진다.

ScrollView Constraints 설정

ScrollView를 추가했으니 알맞게 제약을 설정해준다.

우선 릴리즈된 xcode에서는 safe area에 맞춰 (0,0,0,0)을 해주면 아래와 같이 빨간줄이 뚝! 뜨게된다.

Content Layout Guide 설정

ScrollView안에 컨텐츠를 넣기 위한 상위 View 하나를 추가해준다.
이때 View의 제약조건을 ScrollView에 걸지 않고 Content Layout Guide에 걸어준다.

여전히 빨간줄이 떠있다.

Frame Layout Guide 설정

이제 Frame Layout Guide 에 Equal Widths 나 Equal Heights 제약을 추가해 고정시킬 방향을 설정한다.

• Equal Widths는 가로길이를 Frame Layout Guide에 고정시켜 세로 스크롤이 필요할때 사용
• Equal Heights는 세로길이를 Frame Layout Guide에 고정시켜 가로 스크롤이 필요할때 사용

새롭게 릴리즈된 xcode를 살펴보았으나.. 나는 스크롤뷰에 있어서 사실 더 편한 건지는 잘 모르겠다.

개인 공부 내용을 정리한 글입니다.
잘못된 내용이 있다면 편하게 댓글 남겨주세요!

프레임워크

프로그램 개발에 투입되는 개발자들이 늘어남에 따라서(특히 객체지향 프로그래밍) 다양성 또한 비례되어 늘어나고, 전체 시스템의 통일 & 일관성의 부족함을 느끼게 되었다. 그래서 개발자의 자유를 제한하는 대신 일정한 테두리 안에서 일관되고 유지 보수를 쉽게 개발할 수 있는 환경인 프레임워크를 도입했다. 즉 프레임워크는 기본적인 뼈대가 이미 완성되어 있고 규칙이 존재하는 개발환경 을 생각하면 쉽게 이해 가능하다.

우리가 꼭 개발이 아니더라도 무언가를 조립하고자 물건을 구매했을때 기본적인 뼈대는 주어지는 상태에서 물건을 조립하게 된다. 책장을 조립한다고 하면 기본적으로 책장을 조립하는 뼈대는 비슷할 것이고 그 뼈대 안에서 원하는 책장을 조립해나가는 과정을 생각해보도록 하자. 즉, 특정한 틀을 만들어 놓고 거기에 살을 붙여 놓음으로써 프로그램을 만들 때 작업시간을 줄여주게 된다. 뼈대가 이미 만들어져 있어 거기에 살만 덧붙이면 완성이 되도록 공통된 함수 또는 클래스를 미리 만들어 놓는 것을 의미한다.

• 개발자들이 따라야 할 가이드라인을 가진다.
• 개발할 수 있는 범위가 정해져있다.
• 개발자를 위한 다양한 도구들이 지원된다.

프레임워크는 뼈대나 기반구조. 프로그래밍을 진행할 때 필수적인 코드, 알고리즘 등과 같이 어느 정도의 구조를 제공해주기 때문에 프레임워크를 사용하는 프로그래머는 이 프레임워크의 뼈대 위에서 코드를 작성하여 프로그램을 개발하면된다.

프레임워크 장단점

• 장점
  1. 개발 편의성 증가로 시간 단축에 용이
  2. 오류의 폭을 감소
  3. 코드 품질의 보장(어느정도)
  4. 유지보수에 용이
• 단점
  1. 프레임워크 의존도가 높아지면 개발 능력이 저하됨
  2. 개발자의 자유도 저하

라이브러리

개발을 하다보면 공통적으로 반복되어 사용되는 기능들이나 특정한 기능들을 자주 마주하게 되고 그때마다 새로 알고리즘 혹은 코드를 짜는 것은 매우 비효율적이다. 따라서 잘 만들어진 모듈화된 코드를 가져다 쓰는 것이 간편하고 안정적인 필요와 수요가 생기며 만들어진 것으로 개발 시 활용 가능한 도구들을 모아 모듈화한 것 이라고 이해하면 된다.

잘 만들어진 네이게이션이 있다고 하자. 그러면 우리는 네비게이션을 만들기 위해 처음부터 하나하나 기능을 구현하기 보다는 잘 만들어진 네이게이션 기능을 쏙쏙 내가 원하는 곳에 넣어주면 된다. 즉 여러 라이브러리중에서 우리가 원하는 함수, 클래스들을 가져다 쓰는 것을 의미한다.

라이브러리는 특정 기능에 대한 도구 또는 함수들의 집합. 프로그래머가 어떠한 기능을 수행하기 위해서 도움을 주는 또는 필요한 것을 제공해주는 역할을하는 것이죠. 간단히 정리를 하자면 프로그램 기능 수행을 위해 활용 가능한 도구의 집합이다.

둘 사이의 차이점

프레임워크는 개발자들의 환경을 제한하는 대신 일정한 환경을 제공한다. 그러나 라이브러리는 내가 우너하는 코드를 내가 원할 때 원하는 곳에 가져다 넣으면 된다. 이때 환경은 없고 오로지 의도와 목적성만이 존재한다.

프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.
프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다.

라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.
단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.

반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 합니다.

애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 합니다.

프레임워크는 전체적인 흐름을 자체적으로 가지고 있어 프로그래머는 그 안에서 필요한 코드를 작성한다. 반면에 라이브러리는 프로그래머가 전체적인 흐름을 가지고 있어 라이브러리를 자신이 원하는 기능을 구현하고 싶을 때 가져다 사용할 수 있다. 흐름에 대해서 잘 이해하시는 것이 가장 중요하다.

간단히 프레임워크는 가져다가 사용한다는 것보다는 프레임워크라는 특정 공간에 들어가서 사용한다는 느낌이 더 강하다고 말할 수 있으며 라이브러리는 라이브러리 자체를 가져가 사용하고 호출하는 용도로 사용된다고 생각하시면 쉽게 이해하실 수 있을 것이다.