iOS2019.05.21 12:36

Cookie?
쿠키는 브라우저세계에서 주로 세션관리, 사용자 프리퍼런스와 상태등을 주로 다루며 일반적이고 널리 사용된다.
서버에서 제공하는 작은 속성데이터이다. 웹브라우저에서 저장되며 서버에 요청시 공유된다.

쿠키구조
적은양의 데이터이지만 구조적이고 속성들은 쿠키의 동작을 정의한다. RFC6265, RFC2109

쿠키와 모바일앱
쿠키는 웹세계에서 사용되며 대부분 모바일개발자는 다룰필요가 없다. REST API 로 서버에 데이터를 요청한다. 대부분의 유스케이스와 앱에 맞다. 하지만 간혹 경계가 모호해지는 경우가 있다. 쿠키를 조작해야 하고 모바일앱은 이를 잘 수행한다.
SSO를 예를 들면 여러 시스템에서 세션을 공유해야 할것이다. 이때 쿠키가 이 목표를 달성할수 있게 해준다.

iOS에서 쿠키 다루기
NSHTTPCookie, NSHTTPCookieStorage라는 아주 잘 설계된 클래스 2개가 제공된다.

NSHTTPCookie클래스는 쿠키 데이터 클래스이며 필수 파라메터가 있다. name, value, domain or originalurl, path이다, 모두 제공되지 않으면 nil리턴된다.

NSMutableDictionary* cookieProperties = [NSMutableDictionary dictionary];

//set rest of the properties
[cookieProperties setObject:@"MyCookie" forKey:NSHTTPCookieName];
[cookieProperties setObject:@"cookie12345ytehdsfksdf" forKey:NSHTTPCookieValue];
[cookieProperties setObject:@"/" forKey:NSHTTPCookiePath];
[cookieProperties setObject:@".example.com" forKey:NSHTTPCookieDomain];
//create a NSDate for some future time
NSDate* expiryDate = [[NSDate date] dateByAddingTimeInterval:2629743];
[cookieProperties setObject:expiryDate forKey:NSHTTPCookieExpires];
[cookieProperties setObject:@"TRUE" forKey:NSHTTPCookieSecure];

NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];

HttpOnly같은 속성은 쿠키에서 중요하며 딕셔너리로 셋팅할수 없다. 위와 같은 방식의 쿠키생성은 유용하지 않은것 같다. 

권장되는 방식은 다음과 같다.

NSHTTPCookie에 더 훌룡한 API가 제공되는데 http response 문자열을 모두 덤프할 수 있고 HttpOnly를 포함해서 모든 필요한 속성이 셋팅된 완전한 쿠키를 리턴한다.

NSArray* httpCookies = [NSHTTPCookie cookiesWithResponseHeaderFields:[httpresponse allHeaderFields] forURL:url];

서버응답인 http response에는 키/밸류 쌍인 "Set-Cookie"로 일반적으로 넘어온다. 위 API는 쿠키문자열을 response로부터 취해서 cookie를 만든다. 여기서 URL이 중요하면서도 유용한다. 앞서 얘기한데로 쿠키는 필수파라메터로 name, domain, value, path가 있다고 했다. 하지만 RFC문서에는 Domain은 옵션이다 이는 빈도매인이 있을 수 있다는 것이다. NSHttpCookie클래스에는 originURL을 셋팅할수 없다. 딕셔너리로 쿠키를 생성하는 방법은 완전히 쓸모가 없다. 하지만 이 방법은 쿠키문자열에 domain이 없으면 originURL을 채우고 유효한 쿠키를 제공한다. 이에 더해 서버에서 전달한 추가적인 정보를 알아서 셋팅해준다. 이 방법이 경험적으로 쿠키를 만드는 가장 좋은 방법이다.

쿠키 저장
NSHTTPCookieStorage가 쿠키를 저장해준다.

[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:cookie];

여기서 가장 중요한 특성은 iOS가 네트웍 요청에 도메인이 매칭된다면 자동으로 추가해준다는 것이다. 예를 들어 domain이 ".example.com"인 쿠키가 저장되어 있고 "www.test.example.com"으로 요청을 하게된다면 추가코드없이 자동으로 추가된다.

NSURLSession요청은 URL이 domain이 매칭되면 요청에 쿠키를 셋한다.  webview의 경우 아래와 같이 초기로드를 위해 저장소에서 액세스하여 쿠키를 추가 할 수 있다

NSURLRequest* request; //your request
[request setAllHTTPHeaderFields:[NSHTTPCookie requestHeaderFieldsWithCookies:[NSHTTPCookieStorage sharedHTTPCookieStorage].cookies]];
[request HTTPShouldHandleCookies];

Posted by 삼스
iOS2019.05.10 16:47

이게 개념이 잡히지 않으면 개발환경 설정 시 마다 고생하기 마련이다.

이참에 정리를 좀 하자.

 

일단 기본적으로 애플은 앱실행권한을 관리를 하고 있다. 이 권한이 획득되지 못하면 앱이 실행이 될수 없다.

그러기 위해서는 애플로부터 인증서를 발급받아야 한다. 그리고 단말에서 실행을 하려면 프로비저닝이 단말에 설치가 되어야 한다.

프로비저닝은 단말과 애플인증서의 연결해주는 역할을 하며 권한을 획득하여 얻어지면 앱이 실행이 된다.

 

이 과정은

1. 애플인증서 생성

2. 프로비저닝 생성

3. 빌드 및 실행

이 되는데 하나하나씩 정리해 보자

 

1. 애플인증서 생성

개발자 PC에 키체인앱은 개인키와 공개키를 가지고 있다 이를 기반으로 먼저 CSR(Certificate Signing Request)을 먼저 만들어야 한다.

(1) 키체인 앱 실행

(2) 키체인접근 > 인증서 지원 > 인증기관에서 인증서 요청 선택

(3) 개발자의 이메일주소와 이름을 입력

(4) 요청항목의 "디스크에 저장됨" 선택

(5) 계속을 누르면 CertificateSigningRequest.certSigningRequest 파일이 저장된다.

 

저장된 CSR파일을 애플개발자 콘솔에 인증서 추가 화면에서 등록한다.

(1) https://developer.apple.com/ 접속 및 로그인

(2) Certificates, Identifiers and Profile > Certificates > Development 이동

(3) 추가버튼 누르고 iOS App Development선택하고 화면 안내에 따라 CSR파일 등록 

(4) 등록 완료되면 인증서 파일 다운로드

 

동일한 방법으로 Production의 AppStore and Ad Hoc선택하여 배포용도 등록

 

2. 프로비저닝 생성

프로비저닝은 앱아이디별로 생성이 가능하며 앱아이디를 먼저 등록해주어야 한다.

등록된 앱아이디로 Provision Profiles 화면에서 안내에 따라 개발과 배포용을 등록한 후 프로비저닝 파일을 다운로드 한다.

이 때 개발용의 경우 설치를 허용할 단말을 선택할 수 있는데 이 화면에서 선택한 단말들만 해당 프로비저닝으로 설치및 실행이 가능하다.

 

위 과정을 거치면 

1. 개발자의 공개키와 개인키

2. 애플이 인증한 인증서

3. 디바이스에 설치 가능한 프로비저닝

 

위 3가지로 빌드를 하면 .app파일이 생성되며 2가지로 구성된다.

1. 실제로 사용될 프로비저닝 프로파일 : 빌드시 사용된 프로비저닝이다.

2. _CodeSignature 폴더 : CodeResources 파일을 담고 있고 모든 파일의 암호화 해시정보를 갖고 있다.

 

AdHoc버전의 앱은 디바이스에 설치되어 실행될때 

 

1. .app에 포함된 프로비저닝 프로파일이 애플인증서로 서명되었는지 확인

2. CodeResources참조하여 모든 파일의 해시를 확인하여 무결성 체크

3. 디바이스에 프로비저닝 프로파일이 있는지 확인

 

위 과정을 거쳐서 실행된다.

 

엔터프라이즈배포의 경우는 애플은 그 회사를 신뢰하고 별도의 확인과정을 거치지 않고 바로 실행되게 해준다.

 

앱스토어배포의 경우는 그 어떤 디바이스에서도 실행될수 없다. 오로지 애플에 제출용으로만 사용이 가능하며 애플이 리뷰후 다시 사인하여 배포한다.

 

팁!)

새로운 팀원이나 다른 PC에 개발환경을 설정할 때 매번 애플인증서를 만들수는 없다.

이 때는 이미 등록된 인증서와 해당 인증서를 등록한 개발자의 키파일을 전달 받아서 설치해주어야 한다. 그러지 않으면 인증서의 출처를 확인하지 못하여 정상적으로 빌드가 안되는것 같다. 이 부분에 대해서는 정확히 아는 사람이 설명을 좀 해주었으면 ....

 



Posted by 삼스
iOS2018.08.04 13:17


애플의 인앱결재의 자동결재를 정리한다.


종류는 다음과 같다.


  • 소비형 : 한번 사면 바로 소모됨
  • 비소비형 : 한번사면 평생 유효
  • 자동갱신형 : 주기적으로 재구매(결재)가 자동으로 이루어짐
  • 비갱신형 : 기간 만료되면 다시 구매를 해야 함.

자동갱신

애플에서는 해당 구매의 만료일 10일전에 결재인프라를 먼저 확인한다. 이 때 카드정보등이 유효하지 않으면 메일등을 보내서 갱신을 유도한다.

하루전에는 실제로 결재를 시도한다. 이 때 결재가 실패할 수 있다. 

두가지가 있을 수 있다.


  • 결제정보의 일시적인 오류
  • 정기결제기능을 off

위 상황에서는 결재가 실패하게 되며 사용자가 결재정보를 유효하게 갱신하거나 정기결재기능을 다시 on하게 되면 애플에서는 구매를 수행하게 된다. 이 때 부득이 지연이 발생한다.


앱을 서비스 하는 입장에서는 이런 지연이 발생 한경우를 파악하여 적절히 사용자에게 안내를 해야 불온한 의도를 가진 사용자들의 공격을 막아낼 수 있을 것이다.


재결제내역 확인

앱과 서버가 모두 수행하는것이 좋으며 일반적으로 서버에서 하는것이 좀더 안전하다. 왜 더 안전한지에 대한 설명은 찾아볼 수 없으나 예상으로는 앱은 해킹이 가능하기 때문으로 추정해본다. 


앱 기동시에는 addTransactionObserver를 호출하면 된다. 이 때 재구매건이 있으면 paymentQueue에 결제건이 들어오게 된다. 이 결재건을 사용자가 직접 구매했을 때 와 동일하게 처리하면 된다.


서버에서는 만료일이 가까워진 결재건에 대해서 original 결재정보로 apple서버에 조회하여 마지막 영수증정보과 최종 영수증 정보가 다르면 리뉴얼 된것으로 파악하면 된다.


영수증정보의 갱신

영수증정보는 동일계정으로 로그인 된 다른 단말에서 재구매가 일어나도 앱 기동시마다 영수증정보를 최신으로 유지하기 때문에 동기화가 가능하다.


현재 구매상태인지 여부 확인

최초 결제의 영수증의 transactionId가 originalTransactionId가 되며 이 후 재결제가 일어나면 새로운 영수증이 발급되며 이 때 transactionId도 갱신이 된다. 하지만 originalTransactionId는 최초의 값이 유지된다.

따라서 영수증 목록에서 originalTransactionId로 필터링 후 expireDate가 아직 미래인 영수증이 있다면 아직 구매중인것으로 판단하면 된다.


구매취소 여부 확인

영수증에 Cancelation Date가 있다면 구독취소한것으로 판단하면 된다고 한다. Cancelation필드가 있으면 ExpireDate와 관계없이 취소된 구독이다.



결재내역 복원하기





Posted by 삼스
iOS2018.02.13 15:51


iOS7이전에는 자바스크립트와 무언가 작용을 하려면 UIWebView의 stringByEvaluatingJavaScriptFormString:를 사용해야 했다. 이는 웹뷰의 자바스크립트 런타임에서만 가능했다. 이는 싱글스레드인 환경의 제약이 있다.


JavaScriptCore는 Objective-C에서 자바스크립트의 풀런타임환경에 접근이 가능하게 한다. 문법확인, 스크립트실행과 변수 접근, 콜백수신  그리고 Objective-C 객체의 공유등으로 광범위한 상호작용이 가능하다.


JSVirtualMachine클래스로 불리는 가상머신에서 실행된다. 이는 여러개의 VM을 통해 멀티스레드 자바스크립팅이 가능하다는 것이다. JSVirtualMachine 각각은 여러개의 JSContext를 가질 수 있다. JSContext는 자바스크립트 런타입환경에 말하고 몇가지 기능을 제공한다. 이 중 두가지는 글로벌객체에 접근하는것과 스크립트를 실행할 수 있다는 것이다.


글로벌 영역에 정의된 변수에 대한 접근은 키로 바로 접근이 가능하다. 


    JSContext *context = [[JSContext alloc] initWithVirtualMachine:[[JSVirtualMachine alloc] init]];
    context[@"a"] = @5;
    JSValue *aValue = context[@"a"];
    double a = [aValue toDouble];
    NSLog(@"%.0f", a);

함수호출은 다음과 같다


[context evaluateScript:@”var square = function(x) {return x*x;}”]; 

JSValue *squareFunction = context[@”square”]; 

NSLog(@”%@”, squareFunction); 

JSValue *aSquared = [squareFunction callWithArguments:@[context[@”a”]]]; 

NSLog(@”a^2: %@”, aSquared); 

JSValue *nineSquared = [squareFunction callWithArguments:@[@9]]; 

NSLog(@”9^2: %@”, nineSquared);


evaluateScript로 스크립트 코드를 로드하고 callWithArguments로 스크립트내의 함수를 호출한다. 호출된 결과는 JSValue로 반환된다.

스크립트코드는 블럭코드형태로도 가능하다.



    context[@"factorial"] = ^(int x) {
        int factorial = 1;
        for (; x > 1; x--) {
            factorial *= x;
        }
        return factorial;
    };
    [context evaluateScript:@"var fiveFactorial = factorial(5);"];
    JSValue *fiveFactorial = context[@"fiveFactorial"];
    NSLog(@"5! = %@", fiveFactorial);
스크립트와 objective c간의 타입관계는 다음과 같다.

//   Objective-C type  |   JavaScript type
// --------------------+---------------------
//         nil         |     undefined
//        NSNull       |        null
//       NSString      |       string
//       NSNumber      |   number, boolean
//     NSDictionary    |   Object object
//       NSArray       |    Array object
//        NSDate       |     Date object
//       NSBlock       |   Function object
//          id         |   Wrapper object
//        Class        | Constructor object
스크립트NSNumber와 NSBlocks 타입은 mutable이 아니다 즉 한쪽에서 변경했다고 다른쪽에서 반영이 되지 않는다. id와 Class는 mutable이다. 
임의 오브젝트나 클래스가 자바스크립트에 브릿지될 수 있다. 
NSNull, NSString, NSNumber, NSDictionary, NSArray 또는 NSDate는 관련 클래스 계층을 JavaScript 실행 컨텍스트로 가져 와서 동등한 클래스 및 프로토 타입을 생성하는 JavaScriptCore를 생성하려고 한다.

JSExport protocol로 자바스크립트에 커스텀클래스의 일부를 노출할 수 있다. 래퍼객체는 다른곳에 생성될것이다. 그리하여 한개의 객체가 양쪽의 실행컨텍스트에 공유될 수 있다.

다음이 그 예이다.

    @protocol ThingJSExports <JSExport>
    @property (nonatomic, copy) NSString *name;
    @end

    @interface Thing : NSObject <ThingJSExports>
    @property (nonatomic, copy) NSString *name;
    @property (nonatomic) NSInteger number;
    @end

    @implementation Thing
    - (NSString *)description {
        return [NSString stringWithFormat:@"%@: %d", self.name, self.number];
    }
    @end

JSExport를 상속하여 ThingJSExports를 선언함으로써 자바스크립트에 노출할 수 있다. 이제 objective-c객체의 정보를 변경하면 자바스크립트에 그 값이 반영이 될것이다. 그 반대로 마찬가지.
다음은 id와 class를 브릿지한 예이다.


다음은 id와 class를 브릿지한 예이다.    Thing *thing = [[Thing alloc] init];
    thing.name = @"Alfred";
    thing.number = 3;
    context[@"thing"] = thing;
    JSValue *thingValue = context[@"thing"];

context[@"thing"] = [Thing class];

NSString *thingScript =

@"var t = new thing();"

"t.name = 'yslee';"

"t.number = 10;"

[context eveluateScript:thingScript];








Posted by 삼스
iOS2018.02.13 15:01


iOS에도 이런게 나왔을 줄이야..


안드로이드 하이브리드 개발자들은 알고 있겠지만 addJavascriptInterface를 통해서 자바스크립트에 java object를 바인딩이 가능하다.

이를 통해 하이브리드를 통해서 동기화 호출도 가능하다.

하지만 iOS는 불가했었다.

cordova도 NSURLProtocol을 통해서 하이브리드를 지원하는데 역시 동기화 호출을 불가하다.

하지만 불가능하지는 않다. 다른 방법으로 가능한 방법이 있으며 이를 통해서 실제 동기화 호출을 구현하기도 하였다.


그런데 iOS7부터 지원하는 JavaScriptCore프레임웍으로 가능한것 같다.


http://www.dbotha.com/2014/11/19/using-javascript-core-for-game-scripting-on-ios/ 를 참조하였다.


게임스크립팅 엔진을 javascriptcore로 변경하는것에 대한 글이다.


일반적인 게임튜터리얼의 스크립트는 아래와 같다.


/* tutorial1.js */
showText("Hello World!", /*x:*/ 160, /*y:*/ 100);
wait(5); // sleep 5 seconds
hideText()

showText("Tap the screen to continue", 160, 100);
waitForTap(); // pause execution until the user taps the UI
hideText();

showText("Match three coloured blocks to win!", 160, 100);
waitForLevelEnd(); // pause execution until a level end event occurs
hideText();

loadLevel("level2.map")

예제에서 보듯이 어떤 레벨에 도달할때까지 스크립트실행을 중지하는것이 좋다. 위에서 wait()함수에 대해 의문을 품게 될것이다. 싱글스레드의 자바스크립트 엔진에서는 의도한대로 작동을 기대하기 어렵다. 완전히 스레드가 멈추게 될것이므로..

JSVirtualMachine은 어떻게 실행을 중단할까?


스크립팅엔진자체에 대해 먼저 더 알아보자.


자바스크립트에 접근가능하도록 작성된 스위프트 프로토콜 메서드들을 보자


/* ScriptEngine.swift */
@objc protocol ScriptingEngineExports : JSExport {
    func wait(duration: Double)
    func waitForTap()
    func waitForLevelEnd()
    func loadLevel(mapName: String)
    func showText(text: String, _ x: Double, _ y: Double)
    func hideText()
}


금방 구현가능하고 앞서 기술한 튜터리얼 스크립트에 매우 가깝게 매칭된다.


이번엔 스크립팅 엔진을 살펴보자.


/* ScriptEngine.swift */
@objc class ScriptEngine : NSObject, ScriptEngineExports {
    var context: JSContext!
    let engineQueue = dispatch_queue_create(
            "script_engine", DISPATCH_QUEUE_SERIAL)
    
    override init() {
        super.init()
        
        dispatch_async(engineQueue) {
            self.context = JSContext()
            self.context.setObject(self, forKeyedSubscript: "$")
            self.context.evaluateScript(
                "function wait(duration) {$.wait(duration);}" + 
                "function waitForTap() {$.waitForTap();}" +
                "function waitForLevelEnd(){$.waitForLevelEnd();}" +
                "function print(text) {$.print(text);}" + 
                "function println(text) {$.print(text);}" + 
                "function loadLevel(name) {$.loadLevel(name);}")
        }
    }
    
    /* to be continued... */ 
}

engineQueue은 JSContext를 사용하기 위한 dispatch_queue이다. 이는 메인스레드와 분리하여 스크립트의 콜백을 스위프트가 받을 수 있도록 한다.

여기서 중요한것은 JSContext가 메인스레드에서 분리되어서 인스턴스화되었다는 것이다. 이는 메인스레드가 블럭되는것을 방지한다.


ScriptEngine 객체 인스턴스는 $변수를 통해서 접근이 가능하다.  evaluateScript가 호출되어 스크립트에 억세스 할 수 있는 ScriptEngineExports의 기능을 노출한다. 스위프트의 함수를 호출함으로 인해 ScriptEngine의 메서드가 호출된다.


실행중인 스크립트를 로드하는것은 간단하다. 



/* ScriptEngine.swift */
var currentScriptName: String?

func runScript(scriptName: String) {
    var ext = scriptName.pathExtension
    var fileName = scriptName.substringToIndex(
        advance(scriptName.startIndex, 
                scriptName.utf16Count - ext.utf16Count - 1))
    
    if fileExtension.utf16Count == 0 {
        fileName = scriptName
        ext = "js"
    }
    
    let url = NSBundle.mainBundle()
        .URLForResource(fileName, withExtension: ext)
    let scriptCode = String(contentsOfURL: url!, 
                            encoding: NSUTF8StringEncoding, 
                            error: nil)!

    self.currentScriptName = fileName + "." + fileExtension

    dispatch_async(engineQueue) {
        self.context.evaluateScript(scriptCode)
        return
    }
}

다음과 같이 실행이 가능하다.


let scriptEngine = ScriptEngine()
scriptEngine.runScript("tutorial1")

이제 어떻게 다양한 Wait()함수를 실행할 수 있는지 살펴보자


/* ScriptEngine.swift */
func wait(duration: Double) {
    NSThread.sleepForTimeInterval(duration)
}

이 wait함수는 engineQueue에 의해 관리되는 분리된 스레드에서 호출될것이 보장된다. 그래서 sleepForTimeInterval은 메인스레드가 아니라 이 스레드에서 동작할것이다. 자바스크립트는 실행이 잠시 중단될것이다.


다음은 좀 복잡한 대기로직들이다.


/* ScriptEngine.swift */
let tapCondition = NSCondition()
let levelEndCondition = NSCondition()
var seenTap = false
var seenLevelEnd = false

func waitForCondition(condition: NSCondition, 
        inout predicate: Bool) {
    condition.lock()
    while (!predicate) { // loop to protect against spurious wakes
        condition.wait()
    }
    predicate = false
    condition.unlock()
}

func notifyCondition(condition: NSCondition) {
    condition.lock()
    condition.signal()
    condition.unlock()
}

func waitForTap() {
    waitForCondition(tapCondition, &seenTap)
}

func notifyTap() {
    notifyCondition(tapCondition)
}

func waitForLevelEnd() {
    waitForCondition(levelEndCondition, &seenLevelEnd)
}

func notifyLevelEnd() {
    notifyCondition(levelEndCondition)
}

waitForTap()과 waitForLevelEnd()는 자바스크립에서 대응되는 함수가 호출되었을때 인스턴스 메서드로 노출된다. waitForCondition(condition:predicate:)는 해당 컨디션이 시그널될때까지 스레드를 블럭한다. notifyTap(), notifyLevelEnd()는 해당 컨티션발생시 시그널되고 engineQueue스레드를 깨워서 자바스크립트가 다시 살아나게 한다. 이 메서드들은 게임엔진에서 해당 이벤트가 발생하였을때 호출해야 한다.


이제 남은 노출된 함수는 구현하기에 따라 다르며 여기서는 다음과 같이 구현하였다.


/* ScriptEngine.swift */
func postNotification(type: GameNotification, 
        var userInfo: [NSObject : AnyObject]?) {
    
    if userInfo == nil {
        userInfo = [NSObject : AnyObject]()
    }
    
    userInfo![kGameNotificationUserInfoCurrentScriptName] 
        =  self.currentScriptName
    
    dispatch_async(dispatch_get_main_queue(), {
        NSNotificationCenter.defaultCenter()
            .postNotificationName(
                type.name(), object: self, userInfo: userInfo)
    })
}

func loadLevel(levelName: String) {
    postNotification(GameNotification.LoadLevel, 
        userInfo: [kGameNotificationUserInfoLevelName: levelName])
}

func showText(text: String, _ x: Double, _ y: Double) {
    postNotification(GameNotification.ShowText, 
        userInfo: [kGameNotificationUserInfoText: text, 
                   kGameNotificationUserInfoTextX: x, 
                   kGameNotificationUserInfoTextY: y])
}

func hideText() {
    postNotification(GameNotification.HideText, nil)
}


Posted by 삼스
iOS2018.01.16 11:19


CoreLocation framework에서 현재 위치의 위/경도 좌표를 얻을 수 있고 위/경도 좌표로 주소정보를 얻을 수 있다.



    _locationManager = [[CLLocationManager alloc] init];

// 사용중에만 유효하도록 

    if ([_locationManager respondsToSelector:@selector(requestWhenInUseAuthorization)]) {

        [_locationManager requestWhenInUseAuthorization];

    }

// 위치정보 와치 시작

    [_locationManager startUpdatingLocation];

    NSLog(@"%f/%f", _locationManager.location.coordinate.latitude, _locationManager.location.coordinate.longitude);

    

// 위/경도 정보로 주소 얻기

    CLLocation *location = [[CLLocation alloc] initWithLatitude:_locationManager.location.coordinate.latitude longitude:_locationManager.location.coordinate.longitude];

    NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@"ko-kr"];

    CLGeocoder *geocoder = [[CLGeocoder alloc] init];

    [geocoder reverseGeocodeLocation:location preferredLocale:locale completionHandler:^(NSArray<CLPlacemark *> * _Nullable placemarks, NSError * _Nullable error) {

        NSLog(@"%@", [[[placemarks objectAtIndex:0] addressDictionary] objectForKey:@"FormattedAddressLines"]);

    }];



Posted by 삼스
iOS2017.01.31 13:58


맥과 윈도우에서 모두 사용가능한 드라이브는 NTFS로 하는게 좋을것 같고.

이 경우 맥에서 쓰기가 안되기 때문에 이전에는 Paragon이나 NTFS3G같은걸 사용했는데

마운틴라이언부터는 맥이 기본적으로 기능을 제공한다.

다만 디폴트가 활성이 아니기 때문에 일부 수동으로 조정해주어야 한다.

치사하게스리


/etc/fstab에 라벨를 지정하는 방법이 그것인데 인식시키려고 하는 드라이브명이 'MYDRIVE'라면 아래와 같이 하면 된다


sudo nano /etc/fstab


LABEL=MYDRIVE none ntfs rw,auto,nobrowse


이렇게 한 후 드라이브를 다시 마운트시키면 쓰기가 가능해진다.


다만 Finder에 드라이브아이콘이 나타나지 않을 수 있는데 이 때는 /Volumes 폴더에 직접 접근하거나 터미널에서 아래와 같이 입력해주면 뜰것이다!


open /Volumes/MYDRIVE 


Posted by 삼스
iOS2016.12.12 10:57


Crash Log 콘솔에서 분석하기



크래시 발생 시 크래시데이터 저장위치(iTunes 동기화하면 저장됨)

Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>


Windows XP: C:\Documents and Settings\<USERNAME>\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>


Windows Vista or 7: C:\Users\<USERNAME>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>



아카이브파일은 Devices메뉴에서 Archives탭에서 해당 앱의 Show in Finder로 이동하면 찾을 수 있다.

아카이브에서 dSYM파일과 .app파일을 추출하여 크래시 로그와 동일한 폴더에 위치시킨다.


그러고 콘솔에서 아래와 같이 입력한다.

atos -arch armv6 -o 앱이름.app/앱이름 메모리주소


)

iyosam-ui-MacBook-Pro:Crash leeyosam$ atos -arch armv7 -o MobileApp-iPad.app/MobileApp-iPad 0x26000 [엔터키입력]

-[DSVCResultSearchViewController monthButtonTouchesUpInside:] (in MobileApp-iPad) (DSVCResultSearchViewController.m:241)

Posted by 삼스
iOS2015.08.31 14:53



호스트 연결전에 DNS Name resolving피하기


호스트에 접속하는 적절한 방법은 DNS 명을 받는 CFHost나 CFNetService같은 API가 있다. 앱에서 DNS name으로 리졸브된 ip주소로 접속을 한다고 해도 이 방법은 피해야 한다. DNS lookup은 보통 여러개의 IP주소를 반환하며 어떤 IP주소가 가장 좋은 연결을 제공하는지 알 수 없다.

최근의 대부분의 컴퓨터나 모바일디바이스들은 멀티홈을 가진다. 즉 WiFi + Ethernet이거나 3G + WiFi이거나 하는 환경이 많다. 하지만 모든 호스트가 모든 컨넥션에서 유효한것은 아니다. 예를 들어 iPhone으로 Apple TV를 제어하려고 하는 경우 App TV는 Wifi망에 있고 폰은 3G망에 있다면 이는 연결이 불가하다.

디바이스와 서버가 모두 멀티IP주소를 가지고 있다면 서버에 연결할 가장 좋은 IP주소는 어떤 네트웍에 연결되어 있느냐에 따라 결정된다. 예를 들어 가정의 멀티미디어 서버가 LAN과 WiFi IP주소를 모두 가지고 있다면 OS에서 더 빠른 네트웍을 감지할 수 있을것이며 프로그램이 이 주소를 통해 연결가능할것이다.

서버가 IPv4와 IPv6를 모두 지원하면 두 프로토콜을 사용함으로 인해 도달하지 못할 수 있다. host-name-basedAPI를 사용하여 OS는 동시에 시도를 할 수 있고 첫번째것으로 성공시킬수 있다. 앱이 먼저 찾아낸 IP주소가 어떤 주소냐에 따라서 연결이 안될 가능성 도 있다.

구형 서버로  IPv6를 지원하지 않는 경우에 AAAA형식의 IPv6주소로 접을을 요청하면 동기로 호출되는 DNS조회는 요청시간내내 블럭될것이다.(디폴트는 30초) . 만일 호스트명을 취하는 API를 사용하면 OS는 IPv4와 IPv6요청이 동시에 수행되는지 사용자가 알수 없게 할것이고 내부적으로 IPv4연결이 완성되면 IPv6연결시도는 취소할것이다.

Bonjours를 사용해서 서비스를 게시하는 경우(DHCP는 동작하지 않음) 앱이 해당서비스를 찾아서 IP주소를 얻어내었다면 해당 디바이스가 IP주소를 유지하는 동안에는 유효하다. 하지만 DHCP서비스가 다시 온라인이 되게 되면 IP주소는 변경되고 이전 IP주소는 더이상 유효하지 않게 된다. 만일 게시이름으로 연결을 시도하게 된다면 앱에서는 서버가 최종적으로 언어진 IP주소로 계속 연결을 할 수 있게 될것이다.

DNS Name 해결하기를 직접 피할수 없다면 먼저 CFHost API가 요구사항에 만족하는지 확인해보아야 한다. 이는 싱글주소 대신에 호스트에 주어진 모든 주소목록을 제공한다. CFHost가 만족시키지 못한다면 DNS Service Discovery API를 사용하라.



Posted by 삼스
iOS2015.08.31 13:38



아래는 애플뉴스스(https://developer.apple.com/news/?id=08282015a)의 전문이다.

Supporting IPv6 in iOS 9

August 28, 2015


At WWDC 2015 we announced that iOS 9 will support IPv6-only network services. All apps submitted to the App Store must support IPv6 starting in early 2016. To make sure your app is compatible, use the networking frameworks (e.g., “NSURLSession”), avoid use of IPv4-specific APIs, and avoid hard-coded IP addresses. Before submitting your app, test for compatibility.

To learn more, read Supporting IPv6 DNS64/NAT64 Networks and watch Your App and Next Generation Networks.


WWDC2015에서 이미 언급했다는데 iOS9부터 IPv6-only network service를 지원할거라나. 코드상에 웹서비스 주소를 도메인주소를 사용하고 있다면 문제가 안되겠지만 ip주소를 사용하고 있다면 문제가 될거란다. 내년(2016) 초부터 앱스토어가 지원을 시작할거라는데 이 얘기인즉슨 그런 앱들을 리젝을 놓겠다는건지 정확히 모르겠다. 무슨 지혼자 잘났다고 IPv6를 강제한단 말인가? 장비부터 해서 갑자기 강제하면 분명히 혼란과 혼돈이 있을것인제...

무튼 IPv4전용 API는 하드코딩된 IP주소를 모두 피해야 한다. 기존 앱들은 물론 다 바까야겠지.

자 그럼 불평만 할떄가 아니다 기존앱들은 그리고 새로운앱들은 또 어떻게 대응해야 할까를 연구해보자...

만일 앱이 high-level network api를 즉 NSURLSession이나 CFNetwork frameworkd의 API들을 사용하고 연결은 도메인명으로 하고 있다면 아무것도 할게 없다.

만일 도메인명으로 연결하고 있지 않다면 가이드(Avoid Resolving DNS Names Before Connectiing to Host)를 참고







Posted by 삼스