Electron: 모바일 지원

나는 atom-shell이 ​​주로 atom 텍스트 편집기를 위해 빌드되었다고 생각하므로 모바일 플랫폼을 지원하지 않을 것입니다. HTML5 모바일 앱에는 Phonegap과 Cordova가 있습니다.

예, 하지만 node.js 모듈에서 코드를 공유하고 저수준 리소스에 액세스하기 위한 것입니다.

모바일 플랫폼의 경우 거의 모든 atom-shell의 API가 적용되지 않기 때문에 모바일 플랫폼은 지원하지 않을 것이라고 생각합니다.

아마도 여러분은 (어쨌든) 환경을 감지하여 (런타임 시 또는 빌드 중에 지정) Electron API가 우리 모르게 Cordova 모듈(또는 기본 코드)을 단순히 호출하도록 하여 최소한 Cordova 등을 잘 사용할 수 있습니다. 그것은 미친 듯이 굉장 할 것입니다.

+1 @trusktr

@trusktr Cordova에 대한 호환성 심을 제공하는 훌륭한 타사 모듈처럼 들립니다.

정말 이런 일이 일어나기를 바랍니다. 웹 플랫폼의 미래는 이러한 방향으로 움직여야 진정한 크로스 플랫폼 앱을 작성할 수 있다고 생각합니다. 나는 이것이 배제되지 않기를 정말로 바랍니다.

벌써 2016년이라는게 믿겨지지가 않고 아직도 그런게 없습니다.

@emin93 @zcbenz 가 이미 지적했듯이 이것은 건설적이지 않습니다. Electron API를 모바일로 이식하는 것은 거의 불가능합니다.
기능을 구현하는 방법에 대한 최소한의 제안 없이 기능을 요구할 수는 없습니다.

@YuriSolovyov 나는 Electron을 직접 언급하지 않습니다. 사실 대안이 없고 그것이 나를 좌절시키는 것입니다. 하지만 네 말이 맞아요. 사실 그런 얘기를 하기에 적절한 곳이 아닙니다.

모바일용 Electron은 정말 대단할 것입니다. 나는 몇 가지 Electron 앱을 개발했고 프레임워크를 사랑하지만 매일 모바일에서도 작동하는 것을 보고 싶습니다.

종단 간 플랫폼 지원(IOS, Android, Windows, OSX, Linux)을 보여주는 유일한 교차 플랫폼 프레임워크는 Xamarin 이지만 C#으로 코딩해야 합니다. Microsoft가 이제 Xamarin을 소유하고 노드를 자체 JS 엔진으로 이식하는 데 큰 진전을 이루고 있는 즉시 Xamarin이 JS 코드를 허용하면 놀라지 않을 것입니다.

일부 기업 후원자가 모바일용 전자 포트/포크에 자금을 지원하여 결국 동일한 프레임워크로 구워져 완전한 JS 기반 크로스 플랫폼 애플리케이션 개발 프레임워크를 가질 수 있기를 진심으로 바랍니다.

훌륭한 일을 해주신 Electron 팀에 감사드립니다!

@cjfromthesea 의 원래 질문을 반영하여 모바일(아마도 @zcbenz)에서 Electron의 API에 대한 문제를 설명할 수 있습니까? 몇 가지 일반적인 지침에 따라 나와 다른 사람들은 해킹과 수정을 통해 문제를 해결할 수 있는 방법을 잠재적으로 생각할 수 있습니다. 나는 jxcore-cordova를 조금 다루었지만 몇 가지 지침이 좋을 것입니다. 장애물은 무엇입니까?

@lastmjs 의 큰 장애물은 Electron이 iOS에서 지원하지 않는 V8을 사용한다는 것입니다. 즉, Chromium과 Node.js는 iOS에서도 작동하지 않으며 이 세 가지가 Electron의 주요 구성 요소입니다.

IOS용 새 크롬 버전 이 1월에 출시되었으며 node.app 이 아마도 node.js에 대한 트릭을 수행할 수 있을 것입니다. 그리고 Android는 V8이 지원된다는 점에서 문제가 되지 않습니다.
그동안 우리는 IOS용 전자와 함께 Cordova를 사용하는 방법에 대한 문서를 작성할 수 있었습니다(정말 필요하므로 기꺼이 도와드리겠습니다).

@noelmace iOS용 Chrome은 Apple에서 허용하지 않기 때문에 Chromium 엔진을 사용하지 않습니다. Safari에서 사용하는 WKWebView와 같지만 UI가 다릅니다.

@emin93 Apply는 node.app과 같은 사용자 정의 인터프리터를 사용할 수 있습니까?

이 스레드에 있는 사람들이 생각하고 싶은 몇 가지 질문이 있었습니다.

• 어디에서나 실행되는 _하나의 앱_을 구축하고 싶으십니까?
  
  
  
  • 후속 질문입니다. 모바일 앱이기도 한 데스크톱 앱(웹 앱이 아님)의 예가 있습니까?
  
  
• 아니면 모바일에서 _experience_를 구축하는 Electron 앱을 찾고 계십니까?
  
  
  
  • 후속 질문, Cordova/PhoneGap(또는 기타)과 어떻게 다릅니까?
  
  

어디에서나 실행할 수 있는 하나의 앱을 찾고 있습니다. 하나의 코드베이스, 하나의 웹 플랫폼, 모든 환경.

화면 크기와 장치는 중요하지 않지만 동일한 기능을 원할 수 있는 좋은 모바일/데스크톱/웹 앱의 예:

• 크롬
• 파이어폭스
• 느슨하게
• 지메일
• 구글 포토
• 구글지도

위의 모든 앱에 기본 실행 파일로 실행되는 데스크톱 버전이 반드시 있는 것은 아니지만 브라우저에 데스크톱 버전이 있습니다. 물론 저에게는 경우에 따라 다르지만 일반적으로 어떤 기기에 있든 제 앱이 제 앱이 되기를 바랍니다. 최대한 모든 기기에서 동일한 기능을 구현하기 위해 노력합니다. 왜 안 돼? Chrome이 Android, iPhone 또는 태블릿에서와 마찬가지로 데스크톱에서도 똑같이 작동하고 Firefox, slack, Google 지도에서도 동일하게 작동하기를 원합니다. 때때로 Google 지도 기능이 플랫폼에 따라 달라지는 것이 안타깝습니다. Chrome으로 돌아가서 휴대전화에서도 소스를 보고 디버거를 사용할 수 있기를 원합니다. 나는 때때로 우리가 우리 응용 프로그램의 기능을 적절하게 제한할 선견지명이 없다고 생각합니다. 누군가가 자신의 휴대전화에 있는 앱의 데스크톱 버전에서 작동하는 기능을 원하면 어떻게 될까요? 물론 앱은 반응해야 하지만 핵심 기능은 최대한 동일하게 유지되어야 한다고 생각합니다.

@lastmjs 감사합니다. 내가 생각했지만 지정하지 않은 것이 모바일 앱이기도 하지만 웹 앱이 아닌 데스크톱 앱이었기 때문에 방금 내 질문을 편집했습니다. 저는 이것이 중요한 구분이라고 생각합니다.

그러나 핵심 기능은 내 생각에 가능한 한 동일하게 유지되어야 합니다.

큰 소리로 생각하기: Electron은 일반적인 기본 데스크톱 애플리케이션 동작을 위한 API를 만듭니다. 모바일도 추가하면 이 모든 것 사이의 공통점이 줄어들 것 같습니다. 데스크톱과 모바일 간의 공통점을 기반으로 하는 앱이 결국 모든 곳에서 작동하지만 수준 이하의 모바일 경험과 수준 이하의 데스크톱 경험이 될 수 있을까요?

당신이 말하는 일반적인 네이티브 데스크톱 애플리케이션 동작은 대부분 UI 기반입니까? 기본 메뉴 및 기타 동작이 잘 번역되지 않을 수 있음을 알 수 있습니다. 나에게 가장 큰 이점은 Node.js 및 Chromium API에 액세스할 수 있는 하나의 통합 런타임이 있다는 것이며 런타임은 모든 주요 플랫폼에 배포할 수 있다는 것입니다. Electron과 Cordova는 UI 기능을 제외하고 다른 플랫폼에서 동일한 작업을 수행하고 있습니다. Cordova를 사용하면 몇 가지 주요 모바일 운영 체제에 배포할 수 있는 하나의 코드베이스를 갖게 되며 모바일 운영 체제는 주요 데스크톱 운영 체제와 기능면에서 크게 다르지 않습니다. 운영 체제는 프로세스와 해당 리소스를 관리하고 프로세스에 필요할 수 있는 하드웨어에 대한 액세스 권한을 부여합니다. 모바일 운영 체제와 데스크탑 운영 체제 사이에는 근본적인 차이가 없습니다. 그리고 브라우저가 하드웨어 API를 갖기 시작하면서 웹 플랫폼은 모든 주요 환경에 배포할 수 있다는 면에서 점점 더 보편화되고 있습니다. 내가 볼 때 Cordova와 Electron은 거의 동일한 작업을 수행하지만 다른 운영 체제에서 수행하고 있습니다. 운영 체제는 근본적으로 다르지 않으므로 결합하지 않는 이유는 무엇입니까? 😃

@jlord

모바일 및 데스크톱용으로 빌드하고 @lastmrs 및 @noelmace의 의견에 추가하고 싶습니다.

여기 모든 사람에게 효과가 있을 수 있는 방법에 대한 제 생각이 있습니다.

전자가 노출하는 API는 모바일인지 데스크톱인지에 따라 달라져야 합니다. 따라서 환경 컨텍스트에 따라 다른 API를 호출하기 위해 런타임 환경 감지(전자 계층에서 제공)를 수행하는 것은 개발자의 책임입니다.
다시 한 번 명확히 하자면, 올바른 일을 하는 것은 개발자에게 달려 있습니다.

UI 측면에서 올바른 일을 하는 것은 개발자에게 달려 있습니다. 저는 모든 데스크탑 및 모바일 프로젝트에 폴리머를 사용하며 올바르게 수행하는 것은 저에게 달려 있습니다.
또한 데스크탑과 모바일에서 하드웨어에 액세스하는 데 필요한 컴파일된 항목을 작성하는 데 golang을 사용합니다.

빌드 시 데스크탑(amd 64 등)과 모바일(안드로이드 또는 iOS)용으로 패키징하여 OS 및 칩 아키텍처별로 별도의 패키지를 만듭니다. 전자도 마찬가지입니다. 이를 통해 일부 코드는 하드웨어에 종속되기 때문에 필요할 때 컴파일 시간 차이를 수행할 수 있습니다.
여전히 모든 빌드에 동일한 코드를 포함하고 런타임 스니핑을 수행할 수 있으며, 여기서 전자가 환경 컨텍스트를 제공합니다.

이것이 제공하는 가장 좋은 점은 디자인 타임과 컴파일 타임에 공통 도구가 있다는 것입니다. 이것은 전자를 설치하고 부트스트랩 bash 스크립트를 실행하여 iOS 및 Android 비트와 작성 Hello World를 설치하고 데스크탑 및 모바일에 패키징 및 배포할 수 있기 때문에 개발자에게 엄청난 생산성 향상입니다.

Google 팀이 iOS용 크롬을 다중 프로세스로 업데이트했는지 몰랐습니다. 나는 이것을 보게되어 매우 기쁩니다.

이 중 하나라도 도울 수 있다면 기꺼이 도와드리겠습니다.

이것은 내 많은 프로젝트에서도 엄청난 개선이 될 것입니다. 모바일인지 여부에 따라 UI를 이미 변경해야 하며 다른 감지/변경도 수행할 수 있습니다.

두 개의 개별 API를 갖는 것은 좋은 생각이 아니라고 생각합니다(@joeblew99). 최종 사용자의 경우에는 Electron이 Cordova 또는 Node 위에서 자체 API를 작동하게 하여 최종 사용자가 하나의 API(Electron API)만 알면 되는 것이 더 낫다고 생각합니다. 그런 다음 API에서 다루지 않는 것이 있는 경우 최종 사용자는 필요에 따라 Node 또는 Cordova에 뛰어들 수 있습니다.

또한 Electron이 두 경우 모두(Cordova 또는 Node에서 직접) 작동하는 NPM 워크플로를 사용하는 방법을 정의하는 것이 중요하다고 생각합니다. 즉, Electron은 NPM(그리고 ES6 모듈도 유용할 것입니다)을 사용하여 둘 다 호환되도록 빌드 시스템을 정의해야 최종 사용자가 각각을 빌드하는 방법에 대해 걱정할 필요가 없습니다. 노드 사례는 분명히 이미 처리되었지만 NPM이 Cordova에서 제대로 작동하도록 추가 작업이 필요할 수 있습니다.

Cordova에서는 Node.js API를 사용할 수 없으므로 Electron은 Browserify가 브라우저에서 수행하는 것과 유사하게 Cordova에서 작동하는 대안으로 일부 기본 Node.js 모듈을 폴리필해야 합니다. 이것은 통합 API를 만드는 데 도움이 될 것입니다. Electron API가 다루지 않는 것이 있다면 최소한 폴리필 라이브러리는 사용자가 백그라운드에서 Cordova API를 호출하는 노드 기반 API로 대체할 수 있다는 것을 의미하기 때문입니다.

polyfill의 필요성은 API 경로로 시작하는 것이 더 똑똑하다고 생각하는 것과 정확히 같습니다. 별도의 API일 필요는 없으며 일부 기능을 바로 사용할 수 없습니다. 100% 호환되도록 하면 새로운 기능이 추가될 때 처리해야 할 훨씬 더 큰 문제입니다.

또한 Android와 IOS는 더 이상 모바일이 아니라는 점을 지적하고 싶습니다. 내가 작업하고 있는 프로젝트는 Android TV에서 멋지게 보일 것입니다. 게다가 Github이 Atom을 TV나 태블릿에서 실행하는 것을 원하지 않는 이유도 모르겠습니다.

좋은 점은 더 이상 화면 크기가 아니라 범용 운영 체제를 다루기 시작했다는 것입니다.

Android의 Electron에 대한 상태가 혼란스럽습니까?

적극적으로 고려되고 있는 것입니까, 아니면 단순히 이야기되고 있는 것입니까?

Electron 앱을 PhoneGap 또는 Cordova 앱의 유효한 대상으로 만드는 것이 약 1000배 더 쉽습니다!
즉. cordova platform add electron-osx electron-win electron-linux

@purplecabbage는 확실하지만 전체 브라우저 스택을 제어하는 ​​추가 이점을 모두 잃게 됩니다.

RE: Node.js 폴리필.

이것이 작동하려면 필요한 _native_ 폴리필 목록을 시작해야 합니다. Browserify에는 이미 Node.js Core의 _lot_ 순수 웹 버전이 있습니다. 우리가 필요하다고 생각할 수있는 유일한 것은 다음과 같습니다.

• dns
• net
• fs

다른 건 없나요?

전역 개체:

• __디렉토리 이름
• __파일 이름
• 프로세스

@purplecabbage 는 그 3개에 브라우저화 구현이 있는 것처럼 보입니다. https://github.com/substack/browserify-handbook#__dirname. 장치에 따라 다른 값을 부여해야 합니까?

예, __dirname 및 __filename은 중요하지 않습니다.
프로세스는 Browserify의 베어본입니다. 이벤트를 지원하고 싶지 않습니까?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Electron.js와 코드를 공유하는 네이티브 모바일 앱의 경우 Electron.js와 NativeScript를 결합하여 경로를 탐색하는 것이 가장 좋은 방법이라고 생각합니다( http://github.com/NativeScript/NativeScript).

우리(NativeScript 팀)는 샘플 데모 앱을 만들 계획입니다. 관심이 있으시면 이 문제에 대해 의견을 말씀해 주십시오. - https://github.com/NativeScript/NativeScript/issues/2695

실제로 이를 가능하게 하는 Angular 2 고급 시드가 이미 있습니다( https://github.com/NathanWalker/angular2-seed-advanced). 그러나 Angular 2는 이러한 종류의 솔루션을 구현하기 위한 요구 사항이 결코 아닙니다.

이게 말이 되는 일입니까?

핵심은 당신의 팀이 네이티브 API를 추가하기 위한 레그 작업을 완료했다는 것입니다. 나는 당신의 아이디어를 위해 모두입니다.

@valentinstoychev 기본적으로 모든 전자 앱이 전체 UI를 다시 실행해야 함을 의미하지만 정말 흥미로운 아이디어입니다. 맞나요? 어떻게든 libchromiumcontent 를 포함하여 $ electron #$ 와 유사한 webview $ 을 만들 수 있다면 정말 흥미로울 것입니다. 그러면 하나의 앱에서 둘 다 사용하는 것이 더 쉬울 것입니다.

Android WebView 위젯과 iOS의 이에 상응하는 위젯은 어떻습니까? 사실 안드로이드는 이미 크롬입니다. :)

@hadees 예, 모바일 UI는 NativeScript를 사용하여 iOS 및 Android용으로 한 번 구현하고 전자를 사용하여 데스크톱용으로 한 번 구현하는 것입니다. 다른 모든 것 - 데이터, 모델, 비즈니스 로직, 서비스, 데이터 액세스는 동일해야 합니다.

여기서 주의할 점이 두 가지 있습니다.

첫째, electron.js 및 NativeScript 로 빌드할 때 거의 동일한 기술 세트(한 팀이 데스크탑, 웹 및 모바일용으로 만들 수 있음)를 사용하게 됩니다. 모두 JavaScript/TypeScript/CSS입니다. 원하는 경우 Angular 2를 사용할 수 있습니다. 스타일 지정을 위해 NativeScript와 전자 모두에 CSS를 사용합니다. _일반적으로 다른 유일한 것은 UI 마크업_입니다. 다음 달에 FlexBox 레이아웃을 출시하므로 레이아웃도 익숙할 것입니다. 다른 모든 것은 재사용 가능한 코드와 가장 중요한 재사용 가능한 기술입니다. 도구 부분은 또한 Chrome Devtools를 사용하는 NativeScript에서와 같이 친숙해야 합니다.

여기서 주목해야 할 두 번째 사항은 실제로 모바일과 데스크톱에 대해 다른 UI를 갖고 싶어한다는 것입니다. 따라서 대부분의 경우 UI 부분은 어쨌든 재사용되지 않으며 달라야 합니다.

나는 이것이 꽤 설득력 있는 이야기라고 믿고 우리는 그것을 탐구하고 곧 실제 사례를 보여줄 것입니다. 실제 코드와 실제 앱을 보고 탐색할 가치가 있는지 없는지 확인하는 데 조금 도움이 되기를 바랍니다.

어쨌든 최종 앱(또는 앱)은 어디에서나 기본 UI와 함께 제공됩니다. 그리고 이것이 이 솔루션을 독특하고 탐구할 가치가 있는 이유라고 생각합니다. 전자.js와 NativeScript 모두에서 변경할 필요가 없기 때문에 해킹하는 것도 저렴합니다. 이 첫 번째 솔루션에서 시작하여 보다 긴밀한 협업이 가능한 영역을 찾을 수 있습니다.

Cordova와 함께 데스크탑 및 모바일 GUI용 폴리머를 사용했습니다. 코르도바
데스크탑과 모바일을 지원합니다.

저에게 핵심은 grpc를 바인딩 기술로 사용하는 것이었습니다. 이것은 많이 만들었습니다.
클라이언트와 서버가 상호 운용할 수 있기 때문에 더 쉽습니다.

모두 중개인 역할을 하는 grpc 프록시 플러그인이 필요했습니다.

2016년 9월 10일 토요일 08:17 Valentin Stoychev, 알림 @github.com
썼다:

@hadees https://github.com/hadees 예, 아이디어는 구현하는 것입니다.
NativeScript를 사용하는 iOS 및 Android용으로 한 번, 데스크탑용으로 한 번 모바일 UI
전자를 사용하여. 기타 모든 것 - 데이터, 모델, 비즈니스 로직, 서비스,
데이터 액세스는 동일해야 합니다.

여기서 주의할 점이 두 가지 있습니다.

첫째, 거의 동일한 _skillset_을 사용하게 됩니다(한 팀이
데스크탑, 웹 및 모바일용으로 만들기) electron.js로 빌드할 때 및
NativeScript - 모두 JavaScript/TypeScript/CSS입니다. Angular 2를 사용할 수 있습니다.
당신이 좋아한다면. 스타일 지정을 위해 NativeScript와
전자. _일반적으로 다른 유일한 것은 UI입니다.
마크업_. FlexBox를 출시할 때 레이아웃도 익숙해야 합니다.
다음달 레이아웃. 다른 모든 것은 재사용 가능한 코드이며 가장 중요한 것은
재사용 가능한 스킬셋

여기서 주목해야 할 두 번째 사항은 실제로 다른
모바일 및 데스크탑용 UI, 오른쪽. 따라서 대부분의 경우 UI는
부품은 어쨌든 재사용되지 않으며 달라야 합니다.

나는 이것이 꽤 설득력 있는 이야기라고 믿으며 우리는 그것을 탐구하고
곧 실제 사례를 보여주십시오. 실제 코드를 보고
실제 앱은 탐색할 가치가 있는지 여부를 확인하는 데 약간 도움이 될 것입니다.

어쨌든 최종 앱(또는 앱)은 어디에서나 기본 UI와 함께 제공됩니다.
그리고 이것이 이 솔루션을 독특하고 탐구할 가치가 있는 이유라고 생각합니다. 그것
또한 변경할 필요가 없기 때문에 해킹하기에 저렴합니다.
전자.js와 NativeScript 모두. 이 첫 번째 솔루션을 시작으로 우리는
보다 긴밀한 협력이 존재할 수 있는 영역을 찾을 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/electron/electron/issues/562#issuecomment -246093147,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript는 실제로 Electron의 모바일 지원을 위한 옵션이 아닙니다.
웹 기술에서 JavaScript로 패러다임을 완전히 전환합니다.
네이티브 위젯에 대한 바인딩. 본질적으로 우리가 갖게 될 것은 더 이상
"Electron", 핵심에 있는 Electron은 다음을 노출하는 브라우저 스택이기 때문에
브라우저 컨텍스트의 Node.js _inside_, 이것이 Electron을 만드는 것입니다.
전자.

NativeScript + Node.js 바인딩은 완전히 다른 것으로 간주될 수 있습니다.
프로젝트.

첫째, electron.js 및 NativeScript로 빌드할 때 거의 동일한 기술 세트(한 팀이 데스크탑, 웹 및 모바일용으로 만들 수 있음)를 사용하게 됩니다. 모두 JavaScript/TypeScript/CSS입니다.

NativeScript를 사용하면 일부
기본 위젯이 작동하는 방식에 대한 이해
당신은 JavaScript로 코딩하고 있습니다. 즉, 지식 없이는
위젯 및 해당 위젯 바인딩을 수정하는 방법에 대한 지식 없이
네이티브 코드를 사용하면 사용자 지정 작업을 수행하는 것이 매우 어려워집니다.
웹 스택의 순수 JS/HTML/CSS의 경우는 그렇지 않습니다.
내부를 수정한다는 것은 이미 있는 동일한 환경에서 동일한 유형의 코드를 수정하는 것을 의미하며 외국어에 대해 걱정할 필요가 없습니다.

여기서 주목해야 할 두 번째 사항은 실제로 모바일과 데스크톱에 대해 다른 UI를 갖고 싶어한다는 것입니다. 따라서 대부분의 경우 UI 부분은 어쨌든 재사용되지 않으며 달라야 합니다.

Electron(웹 기반 프론트 엔드 포함)을 사용할 때의 이점 중 하나는 다음과 같습니다.
하나의 코드를 작성하면 거의 _정확히 동일하게_ 작동합니다.
어디에나. NativeScript의 경우 항상 그런 것은 아닙니다.
완전히 다른 기술 집합을 하나의 언어로 연결하려고 합니다.

나는 개인적으로 어디에서나 web-ui를 사용한다는 아이디어를 훨씬 더 좋아합니다.
어디에서나 다른 기본 UI와 비교합니다. 어떤 사람들은 네이티브 UI가
웹 UI보다 훨씬 낫습니다. 어느 정도 맞는 말이기도 하고 그렇습니다
웹의 전체 기반을 모르는 개발자와 함께. 하지만 함께
웹 API를 적절히 사용하면 실제로 멋진 UI를 만들 수 있습니다. 웹은 거대한
진전. WebGL은 매우 크로스 플랫폼입니다...

__/#!/_조피

2016년 9월 9일 금요일 오후 11:17 Valentin Stoychev < 알림 @github.com

썼다:

@hadees https://github.com/hadees 예, 아이디어는 구현하는 것입니다.
NativeScript를 사용하는 iOS 및 Android용으로 한 번, 데스크탑용으로 한 번 모바일 UI
전자를 사용하여. 기타 모든 것 - 데이터, 모델, 비즈니스 로직, 서비스,
데이터 액세스는 동일해야 합니다.

여기서 주의할 점이 두 가지 있습니다.

첫째, 거의 동일한 _skillset_을 사용하게 됩니다(한 팀이
데스크탑, 웹 및 모바일용으로 만들기) electron.js로 빌드할 때 및
NativeScript - 모두 JavaScript/TypeScript/CSS입니다. Angular 2를 사용할 수 있습니다.
당신이 좋아한다면. 스타일 지정을 위해 NativeScript와
전자. _일반적으로 다른 유일한 것은 UI입니다.
마크업_. FlexBox를 출시할 때 레이아웃도 익숙해야 합니다.
다음달 레이아웃. 다른 모든 것은 재사용 가능한 코드이며 가장 중요한 것은
재사용 가능한 스킬셋

여기서 주목해야 할 두 번째 사항은 실제로 다른
모바일 및 데스크탑용 UI, 오른쪽. 따라서 대부분의 경우 UI는
부품은 어쨌든 재사용되지 않으며 달라야 합니다.

나는 이것이 꽤 설득력 있는 이야기라고 믿으며 우리는 그것을 탐구하고
곧 실제 사례를 보여주십시오. 실제 코드를 보고
실제 앱은 탐색할 가치가 있는지 여부를 확인하는 데 약간 도움이 될 것입니다.

어쨌든 최종 앱(또는 앱)은 어디에서나 기본 UI와 함께 제공됩니다.
그리고 이것이 이 솔루션을 독특하고 탐구할 가치가 있는 이유라고 생각합니다. 그것
또한 변경할 필요가 없기 때문에 해킹하기에 저렴합니다.
전자.js와 NativeScript 모두. 이 첫 번째 솔루션을 시작으로 우리는
보다 긴밀한 협력이 존재할 수 있는 영역을 찾을 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/electron/electron/issues/562#issuecomment -246093147,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr 전적으로 동의합니다. 개발자들이 네이티브처럼 보이게 하는 데 너무 많은 재고가 있다고 생각합니다. 네이티브는 일관된 이상조차도 아닙니다. 지난 10년 동안 모바일 인터페이스는 수십 번 바뀌었고 안드로이드 폰마다 일관성조차 없었습니다.

사용자가 액세스할 수 있는 모든 플랫폼에서 앱이 일관되게 보이도록 하는 것이 훨씬 더 나은 표준입니다. iPhone과 Windows 작업 시스템 모두에서 앱을 작동하기 위해 두 가지 UI 기호 및 신호 세트를 배우게 하는 것은 끔찍합니다.

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

역사적으로 iOS용 Chrome 코드는 플랫폼에 필요한 추가 복잡성으로 인해 나머지 Chromium 프로젝트와 별도로 유지되었습니다. 수년간의 신중한 리팩토링 끝에 이 모든 코드는 Chromium에 다시 합류하여 오픈 소스 저장소로 이동됩니다.

iOS 플랫폼의 제약으로 인해 모든 브라우저는 WebKit 렌더링 엔진 위에 구축되어야 합니다. Chromium의 경우 이는 WebKit과 다른 플랫폼용 Chrome의 렌더링 엔진인 Blink를 모두 지원함을 의미합니다. 이로 인해 Chromium 코드 기반에 배치하지 않으려는 몇 가지 추가 복잡성이 발생했습니다.

오픈 소스 코드에 대한 Chrome의 약속을 감안할 때 우리는 지난 몇 년 동안 iOS용 Chrome용 코드를 Chromium으로 업스트림하는 데 필요한 변경 작업에 많은 시간을 할애했습니다. 현재 해당 업스트림이 완료되었으며 개발자는 다른 버전의 Chromium에서와 마찬가지로 iOS 버전의 Chromium을 컴파일할 수 있습니다. iOS용 Chrome에 대한 모든 테스트를 Chromium 커뮤니티 전체에서 사용할 수 있고 해당 코드가 체크인될 때마다 자동으로 실행되므로 개발 속도도 빨라졌습니다.

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

첫 번째 큰 단계? :]

그러나 크롬은 애플 스토어에 올릴 수 없기 때문에 아무 의미가 없습니다.

그러나 안드로이드에서는 지금 매우 필요합니다.

Cordova 및 기본 webview로 개발하는 것은 지옥이며 인텔은 Android에 대한 기본 webview로 chromium webview의 인텔 포트인 Crosswalk를 폐기했습니다.
https://crosswalk-project.org/blog/crosswalk-final-release.html

문제:

• 기본 webview는 서로 다른 작업을 수행하는 다른 공급업체 덕분에 신뢰할 수 없습니다. Android 6.0까지는 안정적이지 않습니다. 이는 휴대전화의 20%만 사용합니다.
• 모든 사람이 안드로이드 펌웨어나 패키지 업데이트를 하고 있는 것은 아닙니다. 특히 값비싼 3G를 사용하는 대역폭이 제한된 지역에서는 더욱 그렇습니다.

우리가 할 수 있는 일:

• Electron API는 크롬으로 이식하는 것이 불가능합니다( @zcbenz 가 2014년에 말한 대로).
• 안드로이드용 크롬 및 안드로이드용 크롬 웹뷰는 이제 완전히 오픈소스화되었습니다: https://www.chromium.org/developers/how-tos/android-build-instructions
• 우리는 횡단 보도를 포크하고 계속할 수 있습니다(기본적으로 더 적은 제한이 있는 안드로이드로 크롬 포트) https://github.com/crosswalk-project , 이미 상당히 안정적입니다.
• 우리의 경험에 따르면 좋은 JS 프레임워크가 있는 횡단 보도와 코르도바는 네이티브에 가까운 성능을 제공합니다( Emberjs / React / Angular /Vue ).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

우리는 횡단 보도에 기여자와 유지 관리자가 필요합니다. 바로 당신이 찾고 있는 사람일 것입니다.

좋은 소식

관련 뉴스, @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/ 의 iOS에 대한 Node.js의 새로운 포트

따라서 수행해야 할 유일한 노력은 @mikeal 이 게시한 링크를 통해 에뮬레이트되는 경우 모바일 브라우저가 전자를 지원하는지 확인하는 것입니다.

요즘 iOS에서 다른 JS VM을 제공하는 것이 합법입니까? 아니면 Apple에서 여전히 사용을 요구합니까?

실행 코드를 생성하지 않는 @trusktr 배송 VM은 앱 스토어 지침을 위반하지 않습니다. 이러한 앱은 이전에 앱 스토어에서 승인을 받았습니다(ChakraCore가 아닌 SpiderMonkey를 사용하지만).

전자가 향후 모바일 프레임워크를 지원할 것인지에 대한 논의를 계속하기 위해 이 문제를 다시 열 수 있습니까?

나는 이것을 두 번째. 무엇을해야합니까? 나는 약간의 방향으로 이것에 대한 테스트 또는 해킹을 시작하게 되어 기쁩니다.

@OtterCode 전자 모바일이라는 저장소를 만들고 거기에서 해킹을 시작하는 것이 합리적입니까? 수행해야 할 작업을 파악하기 위해 예제 애플리케이션을 계획하고 준비하는 데 필요한 단계를 볼 수 있었습니다. 시작하기 위해 에뮬레이트할 수 있는 더 높은 수준의 전자용 API 라이브러리가 있습니까? (Api 문서, 빌드 대상 등)

@OtterCode 및 관심 있는 사람은 내가 만들었습니다. https://github.com/gabrielcsapo/electron-mobile , 관심 있는 사람이 있으면 귀하를 소유자로 추가할 수 있으며 iOS 및 Android 빌드를 위한 앞으로의 작업을 시작할 수 있습니다. 전자의 표적.

Samsung Dex와 같은 제품, http://www.samsung.com/global/galaxy/apps/samsung-dex/
이것을 실행 가능한 요청 IMO로 만드십시오(적어도 Android의 경우).

이것은 확실히 매우 가능합니다. 예를 들어 Google Play의 "Termux" 애플리케이션은 앱에서 바로 전체 Debian 기반 터미널을 제공합니다. 우리는 우리가 설치하는 것이 장치의 CPU 아키텍처를 지원하는 한 필요한 모든 것을 apt-get install 할 수 있습니다(Node, Vim, Git 등). Termux와 유사한 자체 앱 샌드박스 환경에서 Electron을 실행하는 것은 완전히 가능합니다.

Termux는 휴대폰을 루팅하지 않고도 작동하고 앱 샌드박스 내부에 모든 것을 설치하며 Termux 내의 "홈 폴더"에 외부 저장소를 심볼릭 링크하고 Termux가 제공하는 모든 명령줄 도구를 사용하여 외부 저장소에서 작업할 수도 있습니다.

Termux에서 바로 제공되는 localhost의 브라우저에서 Node.js 앱을 열 수 있습니다.

Electron으로 이와 같은 작업을 수행하는 것은 확실히 가능합니다.

나는 이것이 일어나기를 정말로 희망합니다. 독립 실행형 데스크탑 기반 컴퓨터 시스템이었던 이전 프로젝트에 ElectronJS를 사용했습니다. Electron은 매우 훌륭했습니다. 이제 회사에서 저를 고용하고 싶어하고 모바일 앱을 만들고 싶어합니다. 그들은 다른 플랫폼(iOS/Android)에 대해 여러 팀을 갖는 수고를 감당하고 싶지 않기 때문에 PhoneGap을 사용하는 것을 고려하고 있습니다. , 만능 솔루션을 갖는 것은 매우 훌륭합니다. 그리고 ElectronJS가 모바일을 지원하는 버전을 가질 수 있기를 바랍니다. 그래서 다른 플랫폼과 언어 사이를 전환할 필요가 없습니다.

react-native는 이 문제에 대한 영구적인 수정이 아닙니다.

@aprilmintacpineda 이미 Progressive Web Apps를 살펴보았습니까? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel 예, 저는 여기에서 이 문제를 보았을 때 프로그레시브 웹 앱을 인식하지 못했습니다. 대신 react-native를 사용하기로 결정했습니다.

@aprilmintacpineda 여전히 PWA를 사용해 볼 수 있습니다. https://youtube.com/watch?v=vhg01Ml-8pI . 데스크탑에서도 도움이 됩니다

nodejs-mobile 을 Chromium 과 어떻게 통합합니까? 이것은 Electron이 데스크탑용으로 한 것과 유사한 브라우저 환경에서 Node를 모바일로 가져오는 가장 가까운 솔루션인 것 같습니다.

(나는 PWA가 오늘날 무엇을 할 수 있는지 알고 있으며 웹 앱을 모바일 앱으로 래핑하는 Cordova와 같은 프레임워크가 있지만 PWA는 OS 수준 파일 시스템에 액세스하거나 HTTP 서버를 포함할 수 없으며 Cordova는 과잉입니다. 내 현재 프로젝트의 경우 Android 및 iOS의 설정 및 빌드 프로세스는 말할 것도 없습니다.)

배포 가능한 모바일용 Node 통합 브라우저 번들은 Electron을 사용하여 데스크톱 앱을 개발하는 것만큼 쉽게 개발을 할 수 있게 해주었을 것입니다. 모바일용으로 완전히 다른 코드를 작성하는 대신 많은 코드를 재사용할 수도 있습니다.

저는 웹 개발자이고 Node와 복잡한 브라우저를 통합하는 것은 고사하고 시스템/네이티브 애플리케이션 구축에 대한 전문 지식이 없으므로 어떤 포인터라도 대단히 감사하겠습니다. 전문 지식이 있고 그러한 프로젝트를 만드는 데 도움을 주고 싶다면 기꺼이 기여할 수 있습니다.

이것이 가능한 일이지만, 우리가 정말로 이것을 해야 한다면 한 번 더 생각해야 한다고 생각합니다. 전자를 사용한 데스크톱 앱에서 특히 CSS 애니메이션에서 지연이 발생했습니다. 네이티브 옵션이 있다면 네이티브를 선택하고 싶습니다. 네이티브는 많은 것을 제공합니다. 아니면 PWA를 사용해보십시오. 훌륭하지만 아직 앱을 대체할 수는 없지만 큰 미래가 있다고 생각합니다.

표시

https://github.com/dna2github/dna2oslab

안드로이드에서 잘 작동하는 nodejs

Electron과 완전히 같지는 않지만 Node.js로 Android 앱을 빌드하려는 사람에게는 이 라이브러리 가 내 테스트에서 잘 작동하는 것 같습니다.