Merge pull request #3460 from preco21/master

Small fixes, add translation
This commit is contained in:
Cheng Zhao 2015-11-17 11:42:57 +08:00
commit b4d3c8f248
6 changed files with 131 additions and 19 deletions

View file

@ -2,7 +2,7 @@
* [지원하는 플랫폼](tutorial/supported-platforms.md)
* [어플리케이션 배포](tutorial/application-distribution.md)
* [맥 앱스토어 제출 가이드 (0% 번역됨)](tutorial/mac-app-store-submission-guide.md)
* [Mac 앱스토어 어플리케이션 제출 가이드](tutorial/mac-app-store-submission-guide.md)
* [어플리케이션 패키징](tutorial/application-packaging.md)
* [네이티브 Node 모듈 사용하기](tutorial/using-native-node-modules.md)
* [메인 프로세스 디버깅하기](tutorial/debugging-main-process.md)

View file

@ -2,7 +2,7 @@
`app` 모듈은 어플리케이션의 생명주기 제어를 책임집니다.
밑의 예제는 마지막 윈도우창가 종료되었을 때, 어플리케이션을 종료시키는 예제입니다:
밑의 예제는 마지막 윈도우 창이 종료되었을 때, 어플리케이션을 종료시키는 예제입니다:
```javascript
const app = require('electron').app;
@ -30,14 +30,14 @@ Electron이 초기화를 끝냈을 때 발생하는 이벤트입니다.
### Event: 'window-all-closed'
모든 윈도우창이 종료되었을 때 발생하는 이벤트입니다.
모든 윈도우 창이 종료되었을 때 발생하는 이벤트입니다.
이 이벤트는 어플리케이션이 완전히 종료되지 않았을 때만 발생합니다.
만약 사용자가 `Cmd + Q`를 입력했거나 개발자가 `app.quit()`를 호출했다면,
Electron은 먼저 모든 윈도우창의 종료를 시도하고 `will-quit` 이벤트를 발생시킵니다.
Electron은 먼저 모든 윈도우 창의 종료를 시도하고 `will-quit` 이벤트를 발생시킵니다.
그리고 `will-quit` 이벤트가 발생했을 땐 `window-all-closed` 이벤트가 발생하지 않습니다.
**역주:** 이 이벤트는 말 그대로 현재 어플리케이션에서 윈도우창만 완전히 종료됬을 때 발생하는 이벤트 입니다.
**역주:** 이 이벤트는 말 그대로 현재 어플리케이션에서 윈도우 창만 완전히 종료됬을 때 발생하는 이벤트 입니다.
따라서 어플리케이션을 완전히 종료하려면 이 이벤트에서 `app.quit()`를 호출해 주어야 합니다.
### Event: 'before-quit'
@ -46,7 +46,7 @@ Returns:
* `event` Event
어플리케이션 윈도우창들이 닫히기 시작할 때 발생하는 이벤트입니다.
어플리케이션 윈도우 창들이 닫히기 시작할 때 발생하는 이벤트입니다.
`event.preventDefault()` 호출은 이벤트의 기본 동작을 방지하기 때문에
이를 통해 어플리케이션의 종료를 방지할 수 있습니다.
@ -56,7 +56,7 @@ Returns:
* `event` Event
모든 윈도우창들이 종료되고 어플리케이션이 종료되기 시작할 때 발생하는 이벤트 입니다.
모든 윈도우 창들이 종료되고 어플리케이션이 종료되기 시작할 때 발생하는 이벤트 입니다.
`event.preventDefault()` 호출을 통해 어플리케이션의 종료를 방지할 수 있습니다.
`will-quit``window-all-closed` 이벤트의 차이점을 확인하려면 `window-all-close` 이벤트의 설명을 참고하세요.
@ -200,11 +200,11 @@ GPU가 작동하던 중 크래시가 일어났을 때 발생하는 이벤트입
### `app.quit()`
모든 윈도우창 종료를 시도합니다. `before-quit` 이벤트가 먼저 발생합니다.
모든 윈도우창이 성공적으로 종료되면 `will-quit` 이벤트가 발생하고 기본 동작에 따라 어플리케이션이 종료됩니다.
모든 윈도우 창 종료를 시도합니다. `before-quit` 이벤트가 먼저 발생합니다.
모든 윈도우 창이 성공적으로 종료되면 `will-quit` 이벤트가 발생하고 기본 동작에 따라 어플리케이션이 종료됩니다.
이 함수는 모든 `beforeunload``unload` 이벤트 핸들러가 제대로 실행됨을 보장합니다.
`beforeunload` 이벤트 핸들러에서 `false`를 반환했을 때 윈도우창 종료가 취소 될 수 있습니다.
`beforeunload` 이벤트 핸들러에서 `false`를 반환했을 때 윈도우 창 종료가 취소 될 수 있습니다.
### `app.exit(exitCode)`
@ -212,7 +212,7 @@ GPU가 작동하던 중 크래시가 일어났을 때 발생하는 이벤트입
`exitCode`와 함께 어플리케이션을 즉시 종료합니다.
모든 윈도우창은 사용자의 동의 여부에 상관없이 즉시 종료되며 `before-quit` 이벤트와 `will-quit` 이벤트가 발생하지 않습니다.
모든 윈도우 창은 사용자의 동의 여부에 상관없이 즉시 종료되며 `before-quit` 이벤트와 `will-quit` 이벤트가 발생하지 않습니다.
### `app.getAppPath()`
@ -340,7 +340,7 @@ Windows에서 사용할 수 있는 JumpList의 [Tasks][tasks] 카테고리에 `t
`callback`은 주 인스턴스가 생성된 이후 또 다른 인스턴스가 생성됐을 때 `callback(argv, workingDirectory)` 형식으로 호출됩니다.
`argv`는 두 번째 인스턴스의 명령줄 인수이며 `workingDirectory`는 현재 작업중인 디렉터리입니다.
보통 대부분의 어플리케이션은 이러한 콜백이 호출될 때 주 윈도우창을 포커스하고 최소화되어있으면 창 복구를 실행합니다.
보통 대부분의 어플리케이션은 이러한 콜백이 호출될 때 주 윈도우 창을 포커스하고 최소화되어있으면 창 복구를 실행합니다.
`callback``app``ready` 이벤트가 발생한 후 실행됨을 보장합니다.
@ -352,7 +352,7 @@ OS X에선 사용자가 Finder에서 어플리케이션의 두 번째 인스턴
그러나 사용자가 어플리케이션을 CLI 터미널에서 실행하면 운영체제 시스템의 싱글 인스턴스 메커니즘이 무시되며 그대로 중복 실행됩니다.
따라서 OS X에서도 이 메서드를 통해 확실히 중복 실행을 방지하는 것이 좋습니다.
다음 예제는 두 번째 인스턴스가 생성되었을 때 중복된 인스턴스를 종료하고 주 어플리케이션 인스턴스의 윈도우창을 활성화 시키는 예제입니다:
다음 예제는 두 번째 인스턴스가 생성되었을 때 중복된 인스턴스를 종료하고 주 어플리케이션 인스턴스의 윈도우 창을 활성화 시키는 예제입니다:
```javascript
var myWindow = null;
@ -371,7 +371,7 @@ if (shouldQuit) {
return;
}
// 윈도우창을 생성하고 각종 리소스를 로드하고 작업합니다..
// 윈도우 창을 생성하고 각종 리소스를 로드하고 작업합니다..
app.on('ready', function() {
});
```

View file

@ -1,6 +1,6 @@
# Frameless Window
Frameless Window는 [테두리](https://developer.mozilla.org/en-US/docs/Glossary/Chrome)가 없는 창입니다.
Frameless Window는 [테두리](https://developer.mozilla.org/en-US/docs/Glossary/Chrome)가 없는 윈도우를 말합니다.
이 기능은 윈도우 창의 일부분인 툴바와 같이 웹 페이지의 일부분이 아닌 부분을 보이지 않도록 합니다.
[`BrowserWindow`](browser-window.md) 클래스의 옵션에서 설정할 수 있습니다.
@ -25,7 +25,7 @@ var win = new BrowserWindow({ 'title-bar-style': 'hidden' });
## 투명한 창 만들기
Frameless Window 창의 배경을 투명하게 만들고 싶다면 `transparent` 옵션을 `true`로 바꿔주기만 하면됩니다:
Frameless Window 창의 배경을 투명하게 만들고 싶다면 `transparent` 옵션을 `true`로 바꿔주기만 하면됩니다:
```javascript
var win = new BrowserWindow({ transparent: true, frame: false });

View file

@ -1,6 +1,6 @@
# Electron이 NW.js(node-webkit)와 기술적으로 다른점
__주의: Electron은 Atom Shell의 새로운 이름입니다.__
__참고: Electron은 Atom Shell의 새로운 이름입니다.__
NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합 환경을 제공함으로써
웹 페이지에서 저 수준 시스템에 접근할 수 있도록 하여 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 하는 프레임워크 입니다.
@ -26,7 +26,7 @@ Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유
__3. Node 통합__
NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
[`node_bindings`](../../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
__4. 다중 컨텍스트__

View file

@ -12,7 +12,7 @@ Electron은 HTML5 Notification API](https://notifications.spec.whatwg.org/)를
편리하게 데스크톱 알림을 사용할 수 있는 기능을 제공합니다. 데스크톱 알림은 운영체제의 네이티브 알림 API를 사용하여 표시합니다.
```javascript
var myNotificiation = new Notification('Title', {
var myNotification = new Notification('Title', {
body: 'Lorem Ipsum Dolor Sit Amet'
});

View file

@ -0,0 +1,112 @@
# Mac 앱 스토어 어플리케이션 제출 가이드
Electron은 v0.34.0 버전부터 앱 패키지를 Mac App Store(MAS)에 제출할 수 있게 되었습니다.
이 가이드는 어플리케이션을 앱 스토어에 등록하는 방법과 빌드의 한계에 대한 설명을 제공합니다.
## 앱 스토어에 어플리케이션을 등록하는 방법
다음 몇 가지 간단한 절차에 따라 앱 스토어에 어플리케이션을 등록하는 방법을 알아봅니다.
한가지, 이 절차는 제출한 앱이 Apple로부터 승인된다는 것을 확신하지 않습니다.
따라서 여전히 Apple의 [Submitting Your App][submitting-your-app] 가이드를 숙지하고 있어야 하며
앱 스토어 제출 요구 사항을 확실히 인지하고 있어야합니다.
### 인증서 취득
앱 스토어에 어플리케이션을 제출하려면, 먼저 Apple로부터 인증서를 취득해야 합니다.
취득 방법은 웹에서 찾아볼 수 있는 [가이드][nwjs-guide]를 참고하면 됩니다.
### 앱에 서명하기
Apple로부터 인증서를 취득했다면, [어플리케이션 배포](application-distribution.md) 문서에 따라 어플리케이션을 패키징한 후 어플리케이션에 서명 합니다.
이 절차는 기본적으로 다른 프로그램과 같습니다. 하지만 키는 Electron 종속성 파일에 각각 따로 서명 해야 합니다.
첫번째, 다음 두 자격(plist) 파일을 준비합니다.
`child.plist`:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.inherit</key>
<true/>
</dict>
</plist>
```
`parent.plist`:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
</dict>
</plist>
```
그리고 다음 스크립트에 따라 어플리케이션에 서명합니다:
```bash
#!/bin/bash
# 어플리케이션의 이름
APP="YourApp"
# 서명할 어플리케이션의 경로
APP_PATH="/path/to/YouApp.app"
# 서명된 패키지의 출력 경로
RESULT_PATH="~/Desktop/$APP.pkg"
# 요청한 인증서의 이름
APP_KEY="3rd Party Mac Developer Application: Company Name (APPIDENTITY)"
INSTALLER_KEY="3rd Party Mac Developer Installer: Company Name (APPIDENTITY)"
FRAMEWORKS_PATH="$APP_PATH/Contents/Frameworks"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/Electron Framework.framework/Libraries/libnode.dylib"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/Electron Framework.framework/Electron Framework"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/Electron Framework.framework/"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/$APP Helper.app/"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/$APP Helper EH.app/"
codesign --deep -fs "$APP_KEY" --entitlements child.plist "$FRAMEWORKS_PATH/$APP Helper NP.app/"
codesign -fs "$APP_KEY" --entitlements parent.plist "$APP_PATH"
productbuild --component "$APP_PATH" /Applications --sign "$INSTALLER_KEY" "$RESULT_PATH"
```
만약 OS X의 샌드박스 개념에 대해 처음 접한다면 Apple의 [Enabling App Sandbox][enable-app-sandbox] 문서를
참고하여 기본적인 개념을 이해해야 합니다. 그리고 자격(plist) 파일에 어플리케이션에서 요구하는 권한의 키를 추가합니다.
### 어플리케이션을 업로드하고 심사용 앱으로 제출
어플리케이션 서명을 완료한 후 iTunes Connect에 업로드하기 위해 Application Loader를 사용할 수 있습니다.
참고로 업로드하기 전에 [레코드][create-record]를 만들었는지 확인해야 합니다.
그리고 [심사를 위해 앱을 제출][submit-for-review]할 수 있습니다.
## MAS 빌드의 한계
모든 어플리케이션 샌드박스에 대한 요구 사항을 충족시키기 위해, 다음 모듈들은 MAS 빌드에서 비활성화됩니다:
* `crash-reporter`
* `auto-updater`
그리고 다음 동작으로 대체됩니다:
* 비디오 캡쳐 기능은 몇몇 장치에서 작동하지 않을 수 있습니다.
* 특정 접근성 기능이 작동하지 않을 수 있습니다.
* 어플리케이션이 DNS의 변경을 감지하지 못할 수 있습니다.
또한 어플리케이션 샌드박스 개념으로 인해 어플리케이션에서 접근할 수 있는 리소스는 엄격하게 제한되어 있습니다.
자세한 내용은 [App Sandboxing][app-sandboxing] 문서를 참고하세요.
**역주:** [Mac 앱 배포 가이드 공식 문서](https://developer.apple.com/osx/distribution/kr/)
[submitting-your-app]: https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html
[nwjs-guide]: https://github.com/nwjs/nw.js/wiki/Mac-App-Store-%28MAS%29-Submission-Guideline#first-steps
[enable-app-sandbox]: https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html
[create-record]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/CreatingiTunesConnectRecord.html
[submit-for-review]: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/SubmittingTheApp.html
[app-sandboxing]: https://developer.apple.com/app-sandboxing/