-
Notifications
You must be signed in to change notification settings - Fork 15.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mobile Support #562
Comments
I think atom-shell was primarily build for atom text editor, so I would not expect it supporting mobile platforms. There are Phonegap and Cordova for HTML5 mobile apps. |
Yeah, but it is about sharing code from node.js modules and for accessing low level resources |
For mobile platform, nearly all of atom-shell's APIs don't apply, so I don't think we will ever support mobile platforms. |
Maybe you guys can at least play well with Cordova, etc, by (somehow) detecting the environment (at runtime, or specified during build) so that the Electron APIs simply call Cordova modules (or native code) without us knowing. That would be insanely awesome. |
+1 @trusktr |
@trusktr Sounds like a great 3rd-party module that would provide compatibility shims for Cordova |
I really hope this happens. I think the future of the web platform needs to move in this direction, so that we can write TRULY cross-platform apps. I'm really hoping this isn't ruled out. |
I can't believe it's already 2016 and there's still no such thing. |
@YuriSolovyov I'm not referring to Electron directly. There are actually no alternatives and that's what gets me frustrated. But yeah, you're right, that's actually not the right place to discuss that. |
Electron for mobile would be so awesome. I have a few Electron Apps developed and love the framework but every day I wish we would see it work on Mobile too. The only cross platform framework that shows end to end cross platform support (IOS, Android, Windows, OSX, Linux) is Xamarin but that requires to code in C#. I would not be surprised if Xamarin allows JS code soon as Microsoft now owns Xamarin and has also been making great strides in with porting node to their own JS engine. I really hope that some corporate sponsors can get on board to fund such a port / fork of electron for mobile that would eventually be baked into the same framework so we can have a full JS based cross platform application development framework. Thanks Electron team for your great work! |
Echoing the original question from @cjfromthesea, can someone explain the problems there are with Electron's APIs on mobile (perhaps @zcbenz)? With some general guidance, myself and others can potentially start thinking of ways around the problems by hacking and tinkering. I've dealt with jxcore-cordova a little, but some guidance would be nice. What are the roadblocks? |
@lastmjs a huge roadblock is that Electron uses V8 which is not supported on iOS. This means Chromium and Node.js will also not work on iOS and these three are the main components of Electron. |
A new chromium version for IOS was released in january, and node.app could maybe do the trick for node.js. And Android shouldn't be a problem given that V8 is supported. |
@noelmace Chrome for iOS does not use the Chromium engine since Apple doesn't allow that. It's just the WKWebView like Safari uses it, but with a different UI. |
@emin93 Does Apply allow using any custom interpretter like node.app? |
I had a few questions I'd love thoughts on from those in this thread—
|
I'm definitely looking for one app that can run everywhere. One codebase, one web platform, any environment. Examples of good mobile/desktop/web apps, where the screen size and device doesn't really matter, but you might want the same functionality:
Not all of the apps above necessarily have a desktop version run with a native executable, but they do have a desktop version in the browser. To me, of course it depends case by case, but generally I want my app to be my app no matter what device it is on. I strive for the same features across all devices as much as possible. Why not? I want Chrome to work the same on my desktop as it does on my Android, my iPhone, or my tablet, the same for Firefox, slack, Google Maps. I find it sad when sometimes Google Maps features are platform specific. Back to Chrome, I want to be able to view source and even use the debugger, even on my phone. I sometimes think we don't have the foresight to limit the functionality of our applications appropriately. What if someone does want a feature that works on the desktop version of the app on their phone? The apps should be responsive of course, but core functionality should remain the same as far as possible in my opinion. |
Thanks @lastmjs. I just edited my question because what I was thinking, but hadn't specified, was desktop apps that are also mobile apps but are not web apps. I think this is an important distinction.
Thinking out loud here: Electron creates an API for common native desktop application behaviors—it seems that if you also add in mobile that the common ground between all of these would shrink. An app based on the common ground between desktop and mobile might in the end work everywhere but be a sub par mobile experience and sub par desktop experience? |
Are the common native desktop application behaviors you are talking about mostly UI based? I can see how native menus and other behaviors might not translate well. The biggest benefit to me would be having one consolidated runtime, where I have access to Node.js and Chromium API's, and said runtime being deployable to all major platforms. Electron and Cordova are in a way doing the same thing for different platforms, minus UI functionality as you may have been talking about. With Cordova you have one codebase that can be deployed to a few major mobile operating systems, said mobile operating systems not being too different in functionality from the major desktop operating systems. An operating system manages processes and their resources, and grants access to hardware that the processes might need. There isn't much of a fundamental difference there between mobile and desktop operating systems. And with browsers beginning to have hardware APIs, the web platform is becoming more and more universal in its ability to deploy in all major environments. So as I see it, Cordova and Electron are accomplishing largely the same tasks but on different operating systems, said operating systems not being fundamentally different, and so why not combine them? 😃 |
I build for mobile and desktop and would like to add to the comments from @lastmrs and @noelmace Here are my thoughts for how it could work for everyone. The API that electron exposes has to vary based on if it mobile or desktop. So it is then the responsibility of the developer to do runtime environment detection ( which the electron layer provides) to call a different API depending the the environment context. As far as UI aspects, again it's down to the developer to do the right thing. I use polymer for all my desktop and mobile projects, and it's down to me to do it correctly. At build time, I package for desktop ( amd 64, etc, etc ) and mobile ( android or iOS) where I make a separate package for each OS and chip architecture. I do the same with electron. This allows me to do compile time differences as I need it because some code is hardware dependent. The great thing this provides is common tooling at design time and compile time. This is a huge productivity improvement for developers because you can install electron and run a bootstrap bash script to install the iOS and android bits and your writing hello world and packaging and deploying to desktop and mobile. I did not know that the Google team had updated chrome for iOS to be multii-process. I am super excited to see this. If I can help with any of this I would gladly do help. |
This would be such a massive improvement for a lot of my projects as well. One would already have to make changes to the UI based on whether it's mobile or not, might as well do any other detection/changes as well. |
I don't think having two separate APIs is a good idea (@joeblew99). For the end user, I think it'd be better if Electron made it's APIs work on top of Cordova or Node, so that the end user only needs to know one API (Electron API). Then if something isn't covered by the API, end users can dive into Node or Cordova as needed. Also, I think it would be important for Electron to define how to use an NPM workflow that works in either case (Cordova or directly on Node). I.e., Electron would have to define it's build system to be compatible with both, using NPM (and ES6 modules would benice too) so that end users wouldn't have to worry about how to build for each. The Node case is already handled, obviously, but there might need to be additional work so that NPM works fine in Cordova. Note that in Cordova Node.js APIs aren't available, so Electron would need to polyfill some of the native Node.js modules with alternatives that work in Cordova, similar to what Browserify does for the browser. This would help with making a unified API, because if there's something the Electron API doesn't cover, then at least the polyfilled libs means the user can fall-back to Node-based APIs that behind the scenes call Cordova APIs. |
The need to polyfill is exactly what I think it's smarter to start with the API route. It doesn't have to be a separate API, just some features are not available right away. If you go through and make it 100% compatible, then it's a much bigger beast to deal with when new features are added down the road. |
I would also just like to point out that Android and IOS aren't just mobile anymore. The project I'm working on would look awesome on an Android TV, plus I don't see why Github wouldn't want to make Atom run on TVs or Tablets. |
Great point, it isn't about screen size anymore, we're starting to deal with general purpose operating systems. |
I am confused as to the status regarding Electron on Android? Is it something which is actively being considered or merely something being talked about? |
This is definitely very doable. The application "Termux" from Google Play, for example, gives us a whole Debian-based terminal right in the app. We can Termux works without rooting our phones, it installs everything inside the app sandbox, and we can even symlink our external storage into our "home folder" within Termux and work in our external storage using all the command line tools that Termux gives us. We can open Node.js apps in our browser, on localhost, served right from in Termux. Its definitely possible to do something like this with Electron. |
I really hope this will happen, I have used ElectronJS for my previous project which was a stand-alone desktop-based computerized system. Electron was extremely great, now a company wants to hire me and they want to create mobile apps, they are thinking of using PhoneGap for it since they don't want to bear the trouble of having multiple teams for different platforms (iOS/Android), having a one-fits-all solution is extremely great, and I hope ElectronJS can have a version that supports mobile so I don't have to switch between different platforms and languages, it really tiring sometimes. |
react-native isn't a permanent fix for this problem |
@aprilmintacpineda have you looked into Progressive Web Apps already? https://developers.google.com/web/progressive-web-apps/ |
@Serkan-devel yes I have, I was not aware of progressive web apps when I saw this issue here. I decided to use react-native instead. |
@aprilmintacpineda you can still try out PWAs too, https://youtube.com/watch?v=vhg01Ml-8pI . It also helps on the desktop |
How does one integrate nodejs-mobile with Chromium? This seems like the closest solution to bring Node to mobile in a browser environment, similar to what Electron has done for desktop. (I'm aware of what PWAs can do today, and there are frameworks such as Cordova to wrap web apps into mobile apps, but PWAs can't access to OS-level file systems or embed HTTP servers, and Cordova is just an overkill for my current project, not to mention the setup and build processes for both Android & iOS.) A distributable bundle of Node-integrated browser for mobile would've made development as easy as developing desktop apps with Electron, which I believe is what made Electron so popular. A lot of code would also be reusable instead of writing completely different code for mobile. I'm a web developer and don't have the expertise in building system/native applications, let alone integrating a complex browser with Node, so any pointers would be greatly appreciated. If you have the expertise and want to help creating such project, you're more than welcome to contribute. |
While this is possible to be achieved, I think we should think twice if we should really do this. On the desktop app where I used electron, I experienced lags, especially with css animations. If there's a native option, I'd rather go for the native, native has a lot to offer. Or maybe try out PWA. It's awesome, but not a replacement YET for apps, but I think it has a great future. |
mark |
https://github.com/dna2github/dna2oslab the nodejs which can work well on android |
It's not exactly like Electron, but for anybody who wants to build Android apps with Node.js, this library seems to work well in my testing. |
It sounds like many people would like this mobile support including me. It would be much hassle to learn something new language again to able develop to phones too. I am thankful already for the electron team and all of the developers however superb would be mobile support too. I hope this dream will be available in the near future. Hope dies last 👍 |
Replying to myself on this, react-native is the perfect solution. |
We definitely need this for mobile!!! |
Nodejs has almost got official support for android now, and something as android-js can also work to some extent, hope electron could support android as well. Thanks!!!
|
Hi @ssight , are there any crons for android-js if using on production now? Thanks a lot. |
It'd be awesome if atom-shell supported iOS/Android. What is required to achieve this support? Related to #366
The text was updated successfully, but these errors were encountered: