주석이 필요 없는 코드.key

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-002

주석 자체가 나쁜 것은 아니다. 개발자는 주석을 남기는 것을 귀찮아 한다. 그럼에도 주석을 작성해야 되겠다 생각이 들었다면 그것은 나쁜 코드를 작성하고 보완을 하려는 목적일 가능성이 매우 높다. 코드를 보완하는 것이 훨씬 낫다. 다시 말하지만 주석 자체가 나쁜 것은 아니다. 하지만 주석으로 보완하지 않는 코드를 작성하는 습관이 선행되어야 한다 주석을 잘 다는 습관은 그 다음에 익혀도 된다.

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-003

개발자라면 일정에 쫓겨 나쁜 코드를 작성한 후 나중에 수정해야지 라는 생각을 가진 경험이 있을 것이다. 그리고 개발자라면 그 ‘나중’이 단 한번도 온 적이 없다는 것을 경험으로 알 것이다.

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-004

선언 의도를 파악할 수 있는 이름, 의미가 있는 이름. 불필요하게 단순화 시킨 이름은 검색이 어렵다. 발음이 쉽지 않은 이름은 커뮤니케이션을 어렵게 한다. 동일한 행위에 대해서는 동일한 단어를 사용하는 것이 좋다. get receive fetch -> receive / 그러나 통일성을 위해 강박적으로 단어를 통일 시켜서도 안된다. 동일한 행위라도 차이가 있다면 구분을 해주어야 한다. add insert append

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-005%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-006

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-007

마지막으로 강조하고 싶은 것은 코드는 만들때 잘 만드는 것도 중요하지만 실상 코드는 수정, 추가를 거치면서 나쁜 코드로 가속화 된다. 남이 만든 코드든 자신이 만든 코드든 수정, 추가할때 더욱 유의해야 한다. pull 받은 코드는 push 할때 더욱 깨끗하게.

%ec%a3%bc%ec%84%9d%ec%9d%b4-%ed%95%84%ec%9a%94%ec%97%86%eb%8a%94-%ec%bd%94%eb%93%9c-008

반복된 디버깅에 지쳐 있다면 코드부터 뜯어 고치자. 같은 방식으로 개발하면서 버그가 발생하고 유지보수가 어렵다고 투덜 거리는 건 의미 없다.

Advertisements

WKWebView 사용 시 필수적으로 넣어줘야 하는Delegate 넷.

WKWebView를 사용한다면 아래의 넷은 반드시 넣어 주어야 한다. 복사->붙여 넣기 후 개발을 시작하면 된다.

우선, WKUIDelegate 셋.

func webView(_ webView: WKWebView, runJavaScriptAlertPanelWithMessage message: String, initiatedByFrame frame: WKFrameInfo,
completionHandler: @escaping () -> Void) {
    let alertController = UIAlertController(title: "", message: message, preferredStyle: .alert)
    alertController.addAction(UIAlertAction(title: "확인", style: .default, handler: { (action) in
        completionHandler()
    }))

    self.present(alertController, animated: true, completion: nil)
}

func webView(_ webView: WKWebView, runJavaScriptConfirmPanelWithMessage message: String, initiatedByFrame frame: WKFrameInfo,
completionHandler: @escaping (Bool) -> Void) {
    let alertController = UIAlertController(title: "", message: message, preferredStyle: .alert)
    alertController.addAction(UIAlertAction(title: "확인", style: .default, handler: { (action) in
        completionHandler(true)
    }))
    alertController.addAction(UIAlertAction(title: "취소", style: .default, handler: { (action) in
        completionHandler(false)
    }))

    self.present(alertController, animated: true, completion: nil)
}

func webView(_ webView: WKWebView, runJavaScriptTextInputPanelWithPrompt prompt: String, defaultText: String?, initiatedByFrame frame: WKFrameInfo,
completionHandler: @escaping (String?) -> Void) {
    let alertController = UIAlertController(title: "", message: prompt, preferredStyle: .alert)
    alertController.addTextField { (textField) in
        textField.text = defaultText
    }
    alertController.addAction(UIAlertAction(title: "확인", style: .default, handler: { (action) in
        if let text = alertController.textFields?.first?.text {
            completionHandler(text)
        } else {
            completionHandler(defaultText)
        }
    }))

    alertController.addAction(UIAlertAction(title: "취소", style: .default, handler: { (action) in
        completionHandler(nil)
    }))

    self.present(alertController, animated: true, completion: nil)
}

이건 iOS 9.0 이후 지원이긴 한데… WKNavigationDelegate 하나.

public func webViewWebContentProcessDidTerminate(_ webView: WKWebView) {
    // 중복적으로 리로드가 일어나지 않도록 처리 필요.
    webView.reload()
}

앱이 백그라운드 상태에서 포그라운드로 돌아 올때 간혹 WKWebView가 하얀 화면으로 되어 있는 경우가 있는데, 보통 자바스크립트 등으로 체크해서 대응을 하고 있지만 iOS 9이상에선 지원하고 있다.

‘아이슬란드 일주’ 5일만에 끝내기 – 2일차

2일차. 오늘도 달려야 합니다. 오늘 일정은 약 330km로 어제보다는 양호하지만 여전히 먼 길입니다. 거기다 아이슬란드 동쪽으로 넘어 가면서 관광 명소가 하나씩 나오기 시작합니다. 중요한 곳을 몇 추려서 방문을 해야 합니다. 시간은 확실히 어제 보다 부족할 지도 모르겠네요.

한국에서 가져 온 햇반, 캔 반찬 등으로 아침을 떼우고 아침 일찍 출발합니다.


첫 목적지는 바로 신들의 폭포라는 뜻의 ‘고다포스’

폭포의 나라이기도 한 아이슬란드에서 처음 마주하게 된 큰 폭포, ‘과연 신의 폭포!’ 라는 생각이 들 정도로 아름다웠습니다.

110716_1004_28.jpg110716_1004_29.jpg110716_1004_30.jpg

고다포스의 이름에는 여러 설이 있지만 그 중에는 종교적인 전설도 있다고 합니다.
약 천년 전 아이슬란드의 국교가 기독교로 공표되자 사람들이 이교도 신상과 숭배를 금지하는 기독교 교리에 의해 기존 북유럽 신들의 상들을 이 폭포에 버렸었다고 하네요.
그게 사실이라면 저 밑에 천년된 유물들이!

다음 목적지는 노천온천인 ‘뮈바튼 자연 온천’입니다.


한국에서 사전에 오픈 시간을 조사하고 도착하였으나… 우리가 조사한 시간은 아이슬란드의 매우 짧은 하절기 시간이었기 때문에 아직 온천이 오픈하지 않았더군요.


계획 변경!

먼저 데티포스를 다녀 오기로 합니다. 영화 ‘프로메테우스’에서도 나왔던 아이슬란드 최대 크기의 폭포. 고다포스가 아름답다면 데티포스는 크기와 회색빛으로 압도하는 웅잠함을 가지고 있죠.

한국에서 부터 기대를 가졌던, 그 웅장함을 보러 갑니다.




도착하였으나.. 횡합니다. 폭포가 보이지 않습니다…
고다포스는 차로 진입을 할 수 있었으나 데티포스는 주차장에서 약 10여분간 걸어서 이동해야 합니다.


우비로 무장하고 출발.

이동하는 중에도 계속 경이로운 모습을 보여 주는 아이슬란드…


 

도착!!!!!!!!



찍었던 사진들을 아무리 뒤져도 데티포스의 포스를 느끼게 해줄 사진은 찾을 수 없군요.

아쉽지만… 데티포스를 뒤로 하고 다시 뮈바튼 온천으로 이동합니다.


오픈 시간이라 그런지 아까와 달리 우리 외에도 다른 관광객들이 많네요.

뮈바튼 온천은 자연 온천이기 때문에 온도가 일정하지 않아요. 그래서 들어 가면 기대 했던 온천의 뜨거움 보다는 미지근하기 때문에 실망을 하게 되는데… 잘 찾아 보면 온도가 높은 곳도 있었습니다.

이미 관광객들이 많이 있었기 때문에 그런 곳을 찾는 노력을 하진 못했네요.

자 이제 온천을 즐기고 몸의 피로도 씻어 냈으니 다시 일주를 시작하겠습니다.

에이일스타디르에 잠시 들려서 저녁 식사를 하고 내일 아침에 먹을 거리를 장보고 숙소로 이동하도록 하죠.



이동하는 중간 중간 차 밖을 아무렇게나 찍어도 그림이 찍힙니다.
도로가에서 발견한 이름 모를 폭포도 그림입니다.


에이일스타디르 도착.

맛난 저녁을 먹고 근처에 있던 ‘보너스’ 마트로 향합니다.
오늘 숙소는 외딴 곳이라 아침 식사 거리를 장보기 위해서였죠.


이름 처럼 우리에게 보너스였던 보너스 마트.

한국보다도 비싼 차량 주유비, 식당에서 먹으면 한끼 3만원 가량하는 밥값.
살인적인 물가에 움추려든 우리 지갑에 보너스 마트의 저렴한 식재료 가격은 우리에게 정말 보너스였습니다.

이제 숙소로 향합니다.

에이일스타디르에서 이미 해가 지기 시작해서 숙소에 도착했을 때는 이미 어두컴컴했습니다.


주위에 아무것도 없이 숲속에 오두막 하나…

주위에 아무것도 보이지 않는데 집 한 채만 달랑 있으니 살짝 으스스한 분위기입니다.

하지만 덕분에 별이 잘 보입니다. 어쩌면 오늘 오로라를 볼 수 있을 지도 모르겠네요.

그런데… 새벽이 되니 비가옵니다. 집이 흔들릴 정도로 바람도 불어대구요.

아늑하고 따뜻한 집이었는데, 아이슬란드의 바람 앞에선 이 집도 어쩔 수 없었죠.

결국 오늘도 오로라 헌팅은 실패. 가장 가능성이 컸던 날인데…

이후로도 오로라 헌팅은 계속 실패했으니 가장 가능성이 있었던 날을 비때문에 망친셈이네요.

110716_1004_51.jpg110716_1004_52.jpg

‘아이슬란드 일주’ 5일만에 끝내기 – 1일차

아이슬란드는 대한민국 남한보다 살짝 큰, 비슷한 면적의 섬나라입니다.
우리는 아이슬란드 외곽을 한바퀴 도는 일주 계획을 잡았습니다.
인터넷, 방송으로만 접한 아이슬란드의 기후, 지형, 언어(아이슬란드어) 여러 악조건은 ‘도전’을 하고 싶게 만들었습니다. 안락한 문명 속에 길들여져 있는 직장인들에겐 소소하지만 의미있는 도전이었죠.

아이슬란드 일주, 레이캬비크를 시작으로 섬을 한 바퀴 돌아 레이캬비크로 돌아 오는 약 2,000km의 여정은 그렇게 시작되었습니다.

한국에서 아이슬란드까지 직항 노선이 없기 때문에 파리를 경유하여 레이캬비크 공항에 도착을 합니다. 아이슬란드는 유럽연합 가입국은 아니지만 솅겐 조약으로 인해 유럽 대부분 국가에서 입국 시 입국 심사가 없습니다.

아쉽게도 여권에 도장도 없습니다. ㅜㅜ

어쨌든 덕분에 빠르게 케플라비크 국제공항을 벗어 날 수 있었네요.

20161003_093332

이 곳까지 오면서 거쳤던 인천 국제공항이나 샤를 드 골 국제공항에 비해선 확실히 소박한 모습입니다.

입국 심사가 없을 거라는 예상을 하지 못해 예정보다 공항을 일찍 벗어 났지만 다행히 일찍 도착하여 기다리고 있던 렌트카 직원을 만났습니다.
한국에서 차량을 렌트하면서 공항 픽업도 요청을 해 놓았었거든요.

렌트 사업장까지 가는 길은 허허벌판에 회색 하늘만 보이고 소박한 국제공항의 모습도 그렇고  ‘여기가 아이슬란드구나!’하는 실감도 하지 못하고 너무 거센 바람에 짜증만 난 채로 렌트 사업장으로 이동하였습니다.

포장도 되어 있지 않은 공터에 가건물로 된 사무실, 첫 인상도 좋지 못하였는데 우릴 픽업해 온 직원에게 안 좋은 소식을 전달 받게 됩니다.

“님들이 예약한 차량은 고장나서 우리한테 없음 더 비싼 다른 차 줄게.”

그렇게 받은 차량은 더 작았습니다. 결코 더 좋아 보이지도 않았어요. 그럼에도 더 비싸다니. 차량이 작기 때문에 짐을 다 실을 수 없어서 추가로 설치한 루프박스의 비용때문에 1달러 가량 더 비싸더군요. 어이없지만 업체가 거짓말 한 것은 아니었어요. ㅎㅎ

그 상황에서 계약을 파기하고 다른 업체와 차량을 찾는 것도 힘든 일이었고 무엇보다 바람을 피해 빨리 벗어 나고 싶었기 때문에 원래 계획과 다른 좁은 차량을 타고 우리의 도전을 시작했습니다.

20161003_095630

주차장 곳곳에 보이는 파손된 차량들. 예약한 차량이 파손되었다는 것이 거짓말이 아닐 수도 있을 것 같군요.

모험보단 안전. 소심한 우리는 안전을 위해 애초에 지형이 매우 험한 내륙으로 진입은 포기하였고 겨울이면 오로라를 볼 수 있는 가능성 더 높지만 역시 안전을 위해 겨울을 피하고 그나마 오로라를 볼 수 있는 가능성이 있는 10월 초를 선택했습니다. 그럼에도 이런 부서진 차량들을 보니 살짝 불안해 지는 군요.

20161003_095402

5일간 우리의 애마. 이 애마를 타고 이제 5일간의 여정을 시작합니다.

오늘의 목표는 아이슬란드 서쪽에서 시작하여 시계 방향으로 이동, 북쪽에 있는 ‘제 2의 도시’ 아쿠레이리에 도착하는 것입니다. 총 430km. 서울에서 부산으로 가는 거리보다 약 100km 더 먼 거리.

사전 조사에 따르면 남쪽은 관광객이 많이 몰려 도로도 잘 닦여 있고  관광 명소도 많지만 북쪽은 그에 반해 도로가 험하다고 하더군요. 그럼에도 북쪽부터 도는 것을 선택한 이유는

‘매도 먼저 맞는 게 낫다.’

하지만 다행히 도로가 생각보다 잘 닦여 있고 나중에 안 사실이지만 그 당시 남쪽에선 비가 쏟아 지고 있었다더군요. 일정상 우리가 남쪽에 있을때는 북쪽에 비가 쏟아 졌기 때문에 남쪽부터 도는 계획을 세웠다면 일정 내내 비를 만날 뻔 했습니다.

순간의 선택이 5일을 좌우하였습니다.

우린 그런 기후의 혜택도 당시엔 모른채 “바람 짜증나!”를 외치며 출발을 합니다. 갈길이 멉니다. 심지어 아이슬란드는 한국처럼 가로등이 많지 않아 해가 지면 칠흙처럼 어두워서 그만큼 위험. 해가 지기 전에 목적지에 도착해야 합니다.
서둘러서 이동하기 위해 아이슬란드 수도 레이캬비크를 지나쳐 북쪽으로 달립니다.

파리에서 출발 전 간단히 빵과 커피로 떼운 아침은 부실하였기 때문에 다들 허기진 상태, 점심 식사를 위해 “The Settlement Center”에 방문하였습니다.

1

img_2276

아이슬란드 가정식을 뷔페로 제공하는 곳입니다. 처음으로 아이슬란드 음식을 접했는데 예상외로 너무나도 입에 잘 맞아서 행복했습니다. 배가 불렀습니다. 버터도 너무 맛있어서 계속 먹었네요.

4321

식사 후 다시 달립니다.

식사는 맛있었지만… 아직 “이 곳이 아이슬란드구나!”하는 감흥은 없습니다. 주행 중 차가 밀릴 정도의 바람은 짜증만 나고 보이는 건 하늘과 벌판 뿐입니다.
어쨌든 계속 달립니다. ‘아쿠레이리’에 있는 숙소를 향해 달립니다.

어느 정도 달리자 창밖 경관이 바뀌기 시작합니다. 입은 점점 벌어지고 탄성이 나옵니다.

“와… 이게 아이슬란드구나!”

img_229020161003_17375620161003_17370020161003_180610

잠시 차를 세워 기념 사진도 찍고 아이슬란드의 자연을 감상해 봅니다.

20161003_14521320161003_14490720161003_144738

가는 중간 중간 차를 멈춥니다.

특별한 관광 명소가 아님에도 멋진 경관은 차를 멈추게 했고
거센 바람에도 더 이상 짜증을 내지 않으며 찰칵 찰칵 사진 찍기에 바쁩니다.

SAMSUNG CAMERA PICTURESimg_2327img_2310

그렇게 우리가 지금 아이슬란드에 있구나!!!! 를 만끽하며 다행히 해가 질무렵 아쿠레이리에 도착합니다. 관광을 위해 샛길로 빠졌던 것을 제외해도 자그마치 114 + 314 = 428km를 달렸군요. 사고가 없었던 것에 다시 한번 감사드립니다.

2

사람이 없이 전화 통화만으로 체크인을 하고, 키박스에서 숙소 열쇠를 입수하여 3층의 숙소로 올라 갑니다.

img_233420161003_191445

깨끗하고 인테리어도 너무 멋지고 집이 너무 좋네요.
빠른 휴식을 위해 짐만 내려 놓고 밖으로 나옵니다. 저녁 식사를 위해서죠!

숙소에서 매우 가까운 위치에 있는 맛집에서 냠냠냠.

img_234420161003_193838img_20161003_221707

파리에서와 달리 직원들의 친절함에 감동.
샌드위치의 환상적인 맛에 두번 감동.

계획은 식사 후 아쿠레이리 시내를 돌아 볼 예정이었지만 ‘제 2의 도시’라는 이름에 비해 작은 규모와 피로로 이해 식당 근처, 눈에 보인 아쿠레이리의 명소에 방문하고 내일 아침 다시 시작될 여정을 위해 빠른 귀가를 합니다.

20161003_20332820161003_203759

아쿠레이리라고 하면 역시! 아쿠레이리 교회죠!

이렇게 1일차 일정은 끝!

일뻔 했지만,
멋진 인테리어와 깨끗함으로 맘에 쏙 들었던 숙소는… 밤이 깊어 질수록 배신을 때리고…
바람 때문에 삐그덕 거리는 이상한 소리를 내고, 창문은 흔들리고 결국 새벽에 깨고 맙니다.

잠 못 이루고 있는 동안 마찬가지로 잠을 못 이루던 일행 한 명의 ‘오로라 헌팅’ 제안!
하늘에 무늬가 보이는 것이 오로라 같았기 때문입니다.

두 사람은 함께 차를 타고 나갑니다. 산을 넘어 가자는 계획으로 산으로 향하고… 점점 시내에서 멀어 질 수록 뚜렷해 지는 무늬. 그리고 발견합니다. 초록색 오로라를!!!!!!!

더 크고 더 뚜렷한 오로라를 보기 위해 더 멀리 나가야 하는데… 숙소에 두고 온 일행이 걸립니다.
다시 숙소로 복귀!
일행들 모두 챙겨서 다시 떠나지만… 오로라를 보았던 장소로 돌아 오지만 이미 오로라는 안 보이네요.

사진을 찍지 못한 것이 너무 아쉬웠지만. 그래도 오로라를 보았습니다.

maxresdefault

딱 이런 느낌의 오로라. 꽃청춘의 오로라보단 더 작았지만 그리고 이후 일정 내내 다시 볼 수 없었지만
그래도 우리(2명만)는 오로라를 보았습니다.

HTTP 주소로 iOS 앱을 실행하여 보자. (Support Universal Links)

아래의 방법은 iOS 9 이상에서 정상적으로 지원합니다. 또한 서버는 HTTPS를 지원해야 합니다.
참조 문서 : Support Universal Links

아이폰으로 서핑하다보면 유투브 링크가 있고 해당 링크를 누르면 유투브 앱이 열리는 상황을 경험한 적이 있습니다.

본인이 만든 앱도 이렇게 하고 싶다는 생각을 했을 것입니다.

앱을 설치하지 않은 사용자는 간략한 정보가 표시되는 모바일웹을, 앱을 설치한 사용자는 풀서비스를 이용할 수 있도록 앱으로 연결을.

애플은 이런 개발자들의 욕구를 수용해 Universal Link 기능을 추가하였습니다.
하지만 간단히 앱에서 설정하는 것만으로 해당 기능을 이용할 수 없습니다.
보안을 중요시 여기는 애플 답게 우선 해당 HTTP 주소에 대해 앱이 권한을 가지고 있는 지 확인을 합니다.

우선 해당 HTTP 주소에 앱이 권한을 가지고 있다는 것을 명시하는 방법 부터 소개 하겠습니다.

서버의 https://[당신의 도메인]/ 또는 https://[당신의 도메인]/.well-known/ 으로 접근 가능하도록 apple-app-site-association 파일을 생성해야 합니다.

https://[당신의 도메인]/apple-app-site-association 또는 https://[당신의 도메인]/.well-known/apple-app-site-association 되겠죠.

명심해야 될 2가지는 https를 지원해야 한다는 것과 파일에 확장자가 없어야 한다는 것입니다. 아래의 예제를 보시면 아시겠지만 apple-app-site-association 파일은 JSON 형태입니다. 하지만 .json 을 붙이지 마세요.

{
"applinks": {
    "apps": [ ],
    "details": [
        {
            "appID": "[Prefix].[앱의 Bundle ID]",
            "paths": [ "*/members/*", "/detail/*", "NOT /detail/old" ]
        },
        {
            "appID": "[Prefix].[두번째 앱의 Bundle ID]",
            "paths": [ "*" ]
        }
    ]
}
}

위의 apple-app-site-association에는 2개의 앱이 선언되어 있습니다.
apps는 비워 둡니다.
details에 등록할 앱 정보를 기입합니다.
appID에 Prefix와 앱의 Bundle ID를 기입합니다.
paths는 중요합니다. 모든 HTTP 주소에 앱을 연결 시킬 수 있고 특정 HTTP 주소에만 앱이 연결 되도록 할 수 있기 때문입니다.
당연히 NOT는 제외할 주소입니다. /detail/*는 허용하지만 /detail/old 는 거부할 수 있죠.
* 만 해 놓으면 모든 주소를 연결 시킬 수 있습니다.

유투브의 경우엔 모든 주소를 앱으로 연결 되도록 하고 제외할 주소를 추가하는 방식을 썼습니다.
실용 예제로 삼아 한번 보시기 바랍니다.(Document Root에 파일을 두기 싫었는 지 .well-known 아래에 두었군요.)

http://youtube.com/.well-known/apple-app-site-association

유투브 앱의 Prefix는 EQHXZ8M8AV 이었군요. 모르시는 분은 없으시겠지만 Prefix는 https://developer.apple.com 에서 알 수 있습니다.

Developer > Certificates, Identifiers & Profiles (https://developer.apple.com/account/ios/certificate) > App IDs (https://developer.apple.com/account/ios/identifier/bundle) > 원하는 앱 선택.

teamid

자, 이제 정상적으로 설정이 끝났는 지 확인을 해봅시다.

https://branch.io/resources/universal-links/

간단히 도메인만 넣어 주면 apple-app-site-association 파일을 찾아 테스트를 하여 줍니다.
모든 항목이 초록색이 나오면 준비 끝.
(애플에서도 테스트를 할 수 있는 툴(https://search.developer.apple.com/appsearch-validation-tool/)을 제공하고 있고 앱 설정까지 확인해 주기 때문에 더 정확합니다. 하지만 개발 단계에서 서버에서의 작업만 확인 하기에는 위 툴이 더 편리합니다.)

다음은 앱으로 넘어 갑니다.

Xcode에서 간단히 처리 가능합니다.

associateddomains

Associated Domains 항목을 활성화 후 Domains에 applinks:도메인 을 입력합니다.

끝!

이제 링크를 눌렀을때 앱이 실행됩니다. Custom Scheme를 이용한 Deep Link 시에는 앱을 열 것이냐는 물음이 뜹니다. Universal Link는 그런 물음도 없이 자연스럽게 앱이 실행됩니다.

위 작업을 모두 끝낸 후 테스트 할때 주의 하실 점.

  1. 사파리에서 직접 주소를 치면 웹으로 가고 싶어 하는 의사로 판단 Universal Link가 작동하지 않습니다.
  2. 테스트를 위해 링크를 삽입한 웹페이지가 동일한 도메인이면 웹 내의 정상적인 서핑으로 판단 Universal Link가 작동하지 않습니다.

테스트에 성공하였나요? 축하 드립니다.

참고로 이거 달고 앱 설치하면 Safari에서 모바일 웹 상단에 ‘열기’가 생깁니다. 사용자의 앱 이용을 유도할 수 있는 것이죠.

앱을 실행 시킬때는 HTTP 주소를 함께 전달해 줍니다. AppDelegate.swift 에서 받아서 처리할 수 있습니다.

func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Swift.Void) -> Bool {
    // 이곳에서 userActivity.activityType 과 userActivity.webpageURL 을 이용하여 필요한 ViewController 를 띄우는 처리를 하면 됩니다.
    return true
}