G2 and beyond

phonegap In-App Purchase on iOS, plugin problem

gitagy — Thu, 12 Sep 2013 14:39:04 +0900

phonegap iOS IAP 플러그인은 https://github.com/j3k0/PhoneGap-InAppPurchase-iOS 에 있다.

phonegap 플러그인 관리 시스템인 plugman 을 통해서 설치를 진행 하면 되겠다.

아니면 수동 설치 라도 관계 없다.

xcode 에는 Storekit.framework 와 plugins 아래에 소스가 설치될 것이고,

config.xml 에 <plugin> 이나 <feature> 로 플러그인 정보가 등록되면 된다.

문제는 웹 쪽 처리 방식이다.

phonegap 은 플러그인과 관련하여 cordova_plugins.json 과 cordova_plugins.js 를 자동으로 불러 오도록 디자인 되어 있다. json 이 있다면 사용하고 에러가 발생 (404 not found 등) 하면 js 를 불러오도록 말이다.

이 json 과 js 는 기존에 플러그인을 사용중이라면 하나의 방식은 반드시 사용하고 있을 것인데, plugman 을 통한 설치는 js 방식으로 인스톨 되도록 되어 있다.

json 방식을 사용코자 한다면 js 에 등록된 내용 일부를 json 로 옮기면 된다.

[
{
"file": "InAppPurchase.js",
"id": "com.phonegap.plugins.inapppurchase.InAppPurchase",
"clobbers": [
"storekit"
]
}
]

그리고 github 에서 제공하는 InAppPurchase.js 를 그대로 쓰면 문제가 있는데, 반드시 cordova.define 으로 감싸여야 한다. (plugman 을 통해 설치 하면 자동 처리 된다.)

cordova.define("com.phonegap.plugins.inapppurchase.InAppPurchase", function(require, exports, module) {

/*
기존 소스 파일 전체
*/

});

마지막으로 HTML 파일에서는 cordova.js 에 의해서 적절한 타이밍에 plugin json 이나 js 가 불러져 플러그인이 로딩 되도록 해야 한다. (cordova.js 만 불러 들이면 된다는 말이다)

When reinstalling the iOS OTA deployment, GUID is changed.

gitagy — Thu, 12 Sep 2013 14:24:41 +0900

Any app updates or patches for storage and storing data through, if OTA distribution methods during the reinstallation of its contents can not be maintained.

This is because changing the GUID of the app.

This is thought to reinstall after deletion, strangely information stored in localStorage is maintained.

Remove and reinstall the whole seems not.

But do not worry. Not happened before in the App Store.

phonegap LocalFileSystem.PERSISTENT and TEMPORARY path

gitagy — Tue, 10 Sep 2013 16:20:46 +0900

iOS PERSISTENT

/var/mobile/Applications/C6498276-BD1B-403C-971B-389B3E8B38E8/Documents

iOS TEMPORARY

/var/mobile/Applications/C6498276-BD1B-403C-971B-389B3E8B38E8/tmp

Android 4.x PERSISTENT (if mounted)

file:///storage/sdcard0

Android 4.x TEMPORARY

file:///storage/sdcard0/Android/data/com.xxxx/cache

으흠.

can make a asset patcher using phonegap?

gitagy — Tue, 09 Jul 2013 16:57:59 +0900

The conclusion is possible.

Look at the sample code below.

var success = function(_fs)
{
qbw_patcher.fs = _fs;
qbw_patcher.getLocalPath();
}

window.requestFileSystem(LocalFileSystem.TEMPORARY, 0, success, failure);

runThread: function()
{
if (qbw_patcher.exit == true)
return;

var target = this.getQueue();

if (!target)
{
this.threadRun--;
this.s.thread_run.text(this.threadRun);

if (this.threadRun == 0)
{
qbw_patcher.setLocalPlist();
this.s.mesg.text('다운로드 완료');

setTimeout(function ()
{
qbw_patcher.download_complete();
}, 500);
}

return;
}

var remoteUrl = encodeURI(this.remoteUrl + target[0]);
var localPath = this.localPath + target[0];

this.download(remoteUrl, localPath, target);
},

download:function(_remoteUrl, _localPath, _target)
{
var fileTransfer = new FileTransfer();

var success = function(_entry)
{
qbw_patcher.queue_complete_recent = _entry.name;
qbw_patcher.queue_complete_count++;
qbw_patcher.queue_complete_size += _target[1];

qbw_patcher.jsn.list[_target[0]] = [_target[1], _target[2]];
qbw_patcher.setLocalPlist();

qbw_patcher.runThread();
}

var failure = function(_err)
{
console.log("download error source " + _err.source);
console.log("download error target " + _err.target);
console.log("download error code " + _err.code);

qbw_patcher.error++;
qbw_patcher.s.error.text(qbw_patcher.error);

qbw_patcher.runThread();
}

fileTransfer.download(_remoteUrl, _localPath, success, failure);
},

phonegap universal devices 대응하기

gitagy — Tue, 09 Jul 2013 16:33:58 +0900

몇가지만 설정해 주면 된다.

1. iOS Application Target 에서 Devices를 Universal 로 설정

2. phonegap config.xml 에서 Preferences for iOS 에 EnableViewportScale true 설정

3. 웹페이지에 device-width 를 384px 로 scale 을 2.0 으로 설정

asset 에 main page 를 scale 별로 만들어 두고, startPage 에서 device.model 으로 구분하여 로딩하면 된다.

device.model 로 대응이 어려운 상황이 생기면 scale 1.0 에서 startPage 를 로딩하여 window.innerWidth 를 뽑아서 적절하게 custom 분배 하는 방법도 있을 듯 하다. (이건 나중에 해볼 예정)

웹엔지니어 광고가 이정도는 되야지.

gitagy — Thu, 20 Jun 2013 11:25:38 +0900

jQ.Mobi 의 $.ajax options.complete 미실행 버그 대처

gitagy — Fri, 10 May 2013 18:19:45 +0900

jQuery 도 마찬가지 이지만 jQ.Mobi 에는 $.ajax 가 있고 success, error, complete 의 3가지 callback 을 지원한다.

success 와 error 는 통신 에러와 성공을 처리 할 것이고 complete 는 success 든 error 든 반드시 함께 수행되는 callback 에 해당 된다.

complete 의 수행 순서는 success 나 error 수행 후 인데 통신 전/후 처리가 필요할때 후 처리로 사용하기 적합한 callback 인 셈이다.

그런데 complete 의 수행 순서가 후 순위 이다 보니 전 처리에서 스크립트 오류가 발생하면 실행되지 않는 문제가 있었다.

어떻게 해야 하나 하다가 의외로 간단히 적용 되었다.

소스는 아래와 같고 볼드 된 부분이 추가된 것이다. 간단히 try catch 만 추가 되었다.

qbw_e.cfg.fgXhr = $.ajax(
{
type:'POST',
url: _url,
data: _data,
dataType:'json',
timeout: 30000,
success: function(_data, _status)
{
if (_data.qbw_cmd_return)
{
if (_successFunc)
{
try
{
_successFunc.call(window, _data, _status);
} catch (e)
{
//
}
}
} else {
// common message show
qbw_dlg.setDataOpen('message', { text:'error s1 : ' + _data});
}
},
error: _errorFunc,
complete: function(_xhr, _status)
{
qbw_e.cfg.fgCmdUse = false;
qbw_e.cfg.fgCmdLastest = qbw_timer.now();
qbw_e.cfg.fgCmdCount++;
qbw_cmd_inprogress(false);
}
});

VirtualBox Windows 7(Host) CentOS 6.3(Guest OS) 간 공유폴더 (share folder, vboxsf) 캐싱버그 (caching bug)

gitagy — Fri, 26 Apr 2013 17:09:00 +0900

개발 환경을 Windows 7 에 VirtualBox VM 으로 CentOS 6.3 을 올리고 Host, Guest OS간 vboxsf (virtualbox 의 공유폴더 디바이스) 로 Windows 의 폴더를 공유하여 CentOS lighttpd 에서 해당 공유폴더를 web service root 로 해서 사용 중 입니다.

이러면 윈도우 7에 이클립스를 설치하여 개발하고 브라우저를 띄워 lighttpd 에 접속하여 확인을 하며 개발을 진행 할 수 있습니다.

왜 굳이 윈도우에서 개발을 하느냐는 지금은 많이 좋아 졌는지 모르겠지만 리눅스에서 멀티모니터 (3~4개 사용) 사용하려면 골치도 아프고 퍼포먼스도 상당히 떨어 집니다. 그래서 고생하기 싫어서 윈도우를 사용 합니다.

VirtualBox 를 사용하기 전에는 서버 환경 (lighttpd, php-fpm(여기다가 각종 PECL), python 서버, node 서버 등) 과 개발 환경 (apache, mod_php, python, node 등언 개발서버꺼 공용 사용) 이 같지 않았었습니다. 물론 시간과 노력을 들이면 거진 비슷하게 할 수 있겠지만 그 시간과 노력이 좀 많이 들어가야 합니다. 버전이 바뀜에 따라 한번 더 작업 해 줘야 할 수도 있구요.

이런 상황에서 위와 같이 개발을 진행하면 윈도우에서 개발을 할 수 있다와, 쉽게 production 환경과 100% 동일한 독립 개발 환경을 가질 수 있는 크나큰 이점이 있습니다.

잡설이 길었는데 이 vboxsf 에는 큰 버그가 있는데 일반적인 text 파일에서는 겪지 않았지만 이미지의 경우 윈도우에서 변경해도 리눅스 서비스 파일은 캐싱되어 변하지 않는다 입니다. 이미지를 조금씩 수정하여 개발을 진행 할때는 아주 미춰 버립니다.

파일명을 바꾸거나, vboxsf 의 mount 를 새로 하거나, 여간 귀찮은게 아니죠.

OS 레벨에서 disk 캐쉬 or 버퍼를 날릴 방법이 없을까 hdparm 등으로 찾아 보았지만 vboxsf 에서는 애매 하네요.

그래서 아래와 같은 명령을 찾았고 아주 잘 동작 합니다.

sync; echo 3 > /proc/sys/vm/drop_caches

PHP (php-fpm) 5.4.12 의 Uncaught exception Fatal error bug (버그)

gitagy — Fri, 05 Apr 2013 16:25:31 +0900

이 버그 때문에 시간으로 치자면 하루 정도는 고민을 한듯!

아래 스크립트 실행시

<?php
try
{
throw new Exception('error');
} catch (Exception $e)
{
echo "error";
exit;
}
?>

PHP 5.4.12 하에서 CLI 로 실행시 제대로 되고 php-fpm 으로 실행시 아래 에러 메시지 발생

[05-Apr-2013 16:11:43 Asia/Seoul] PHP Fatal error: Uncaught exception 'Exception' with message 'error' in /-------------/t.php:4
Stack trace:

예전 서비스 들은 5.3.x 를 사용하는 지라 중간 버전 업데이트에 따른 대대적인 변경이 있나 싶어서 한참 찾아봄. 그래도 못 찾겠어서, 설마 하는 심정으로 5.4.13 으로 업데이트

문제 해결!

끝

리눅스 load average 와 컨텍스트 스위칭

gitagy — Wed, 09 Jan 2013 17:35:55 +0900

작년 연말 서비스 중인 게임의 통합 작업을 진행했는데 가장 큰 통합은 웹 서버 였다.

KT ucloud 에서 사용중인 2 core 4g memory VM 18대를 4 core (HT) 16G 물리서버 2대로 통합 하는 작업.

서비스 아키텍쳐는 그대로 유지해야 하기 때문에 동일 프로그램을 여러 프로세스로 다른 포트를 사용 하도록 처리하면서 프로세스 갯수라든지 쓰레드 조정 작업을 진행 하였다. (웹서버 이긴 하나 다른 어플리케이션도 동작)

BMT 나 여러 수치상으로는 문제가 없었으나 이관 완료 후 몇 일간 지속적인 모니터링을 해본바 CPU idle 에 비해서 load average 가 너무 높게 나오는 것이였다.

보통 10대를 유지하고 피크때 20을 가볍게 넘기고 30까지 가는 상황, 물론 이때도 CPU idle 은 괜찮은 편.

원래 알고 있던 load average 는 20이 넘어가면 서버가 다운 되는 걸로 알고 있었는데. 참 신기한 현상 이였다.

이를 분석하기 위해서 vmstat 를 사용하였고 procs 의 r, system cs 가 엄청나게 높게 나오는 상황 이였다.

procs r 은 The number of processes waiting for run time.

system cs 는 The number of context switches per second.

얼마나 높게 나왔냐면 procs r 은 30-50대, cs 는 십만 단위.

딱 2년전 iowait 때문에 고생한거 생각하면 wait 는 정말 보고 싶지 않은 단어인데, run time waiting 이라니...

하여튼 cs 와 procs r 은 밀접한 관계가 있다고 판단하고 서비스 아키텍처 중 리얼타임 웹을 위해서 롱폴링 서버가 별도로 존재하는데, 얘가 multi process 에 multi thread 라 이녀석의 문제로 단정하고 thread를 4개에서 3개로 process를 반으로 줄이는 작업을 진행했고.

결과는 run time waiting 이 거의 사라지고 cs 도 5만 이하로 떨어 졌다는 것.

내부 아키텍쳐가 좋은 편이 아니라 cs 를 많이 유발하더라도 독립된 상태에서는 문제가 없었는데, 통합이 후 9개로 분산하는걸 축소를 감안하더라도 5개쯤을 한곳으로 통합한 거라 꽤 문제가 되리라는 걸 짐작하지 못했다. (2년 전 일이므로?)

멀티태스킹 환경에서 너무나 중요한 CS 사용에 대한 것과 이게 run time waiting 으로 갈 수도 있다는걸 알게된 좋은 경험.