I want to create desktop application compatible with other OS.For that I'm using electron with angular.Because both are frame work whether it will effect performance or loading time, and also whether deploying easy,can we use all the features of angular when we use with electron like routing..?
Electron uses Chromium and NodeJS which is the reason why it is compatible with other OSs. You can talk with the NodeJS process from your angular-app which opens up some possibilities. For example opening native file-dialogs to let the user choose files. Electron also already abstracts some platform specific operations like getting the user home to save some configuration files for example.
You can use routing just like in any Angular app and I think you can use most features like you would normally but dont take me for granted on this one.
I would not say it affects your loading time to combine those too. During development you have to build your angular app before electron can start up and use those files but in production Angular is already ready to be loaded so they dont hinder each other.
Related
Trying to find information on how to implement deferred deep linking in electron app but can't find it in the official electron documentation.
We have an electronic application. I need the following behavior: when a user tries to open a link of this type -> custom-protocol: // some-data in the browser, if the application is not installed, then automatically download the application and, after installation, pass the parameters contained in the link (some-data) to the application. Can anyone suggest how to implement this in electronic or a link to the documentation or show some abstract example of implementation
On Windows, custom protocols are stored in the registry. This is a chicken and egg problem because your application already has to be installed on the system for the registry entry to exist.
If you rewrite your application as a UWP app (lol) you might be able to check with getInstalledRelatedApps to see if the app is already installed.
If you want to streamline how your application is installed from the web, consider using ClickOnce.
So basically you just want a way to pass some query params to your application when installed from your website.
You can do this if you package your electron application as an MSIX. Check out the article below from Microsoft, that documents the process:
Passing query params to an MSIX packaged app
I'd like to scrape a javascript website using Scrapy + Splash in Google App Engine. The Splash plugin is a Docker image. Is there any way to use this within Google App Engine? App Engine itself uses a Docker image, but I'm not sure how to load and access a secondary image (which is how Splash is used). Here are the Splash install instructions
You can use Custom Runtimes in the App Engine Flexible Environment.
Custom runtimes let you build apps that run in an environment
defined by a Dockerfile. By using a Dockerfile, you can use languages
and packages that are not part of the Google Cloud Platform and use
the same resources and tooling that are used in the App Engine
flexible environment.
Explore more About Custom Runtimes. Please note when you use a custom runtime, you have to write your application code to deal with some flexible environment life-cycle and health checking requests. Check how to build a custom runtime for more information.
Deploying the Splash service separately is the proper way to accomplish this.
I went ahead and tested a few different setups and the only approach that allowed me to have Splash on App Engine was to deploy it as a custom domain, setting the forwarded_ports to able to connect directly to one of the service’s instances through its IP address.
This is clearly not an adequate solution, as it comes with many limitations and, in the end, it becomes basically using Google Compute Engine without all the control it provides.
My suggestion is that you only deploy the Scrapy service of your application to App Engine, and leave the Splash service somewhere else, like in a GCE instance.
Once you have that, all you will need to do is set a static IP address for the instance and connect to it from your App Engine app through that.
I just recently switched from using the outdated cfx to jpm for developing my Firefox add-ons. Every time I make a change to my code and want to test it again, I have to use the "jpm run" command it literally takes 3 to 5 minutes to launch the browser with the new code inside. This makes it pretty much impossible to develop my add-on because, every time I want to test a new line of code, I have to wait several minutes.
This kind of problem doesn't occur in Chrome so I'm not sure what the people at Mozilla are thinking. Do they want to make it nearly impossible to develop add-ons for their browser?
What are other Firefox add-on developers doing to test their code? Do they just spend hours launching and relaunching the browser very very slowly? Or is there a workaround?
You can use jpm watchpost together with the extension auto-installer instead to auto-reload the extension in a running firefox session.
But even without that it should not not take minutes, only seconds.
As the8472 has mentioned, you can test Add-on SDK extensions without the need to restart the browser using jpm by using jpm watchpost. Using this appears to take a bit of configuring. I have not used this, as I would find having the add-on automatically updated upon every write to a file a bit annoying. I often change multiple files, or make multiple writes to the same file between the times I run the add-on to test. Basically, I want to maintain more control as to when the add-on is reloaded than to have it automatically done each time a file is changed.
There is a way to load temporary add-ons which works for both unpacked add-ons and .xpi files. The problem is that prior to running jpm, your add-on is not actually a complete Firefox add-on. jpm adds wrappers around the contents of your add-on to make it a normal bootstrapped add-on. Without those wrappers, your add-on will not function. One possibility would be to run jpm xpi each time you want to test a new version: Once you have initially loaded the add-on as a temporary add-on, you would run jpm xpi, then click on the "Reload" button for your add-on in about:debugging.
[This method will have issues which you will need to work through]: Alternately, you could unpack the .xpi file and continue your development from the files contained in the resulting directories while using the temporary add-on method of installing your add-on (click on any file in the directory where you unpacked the files to install as a temporary add-on). However, this method may prevent you from using jpm at all with your add-on. In addition, jpm performs somewhat different actions when packaging your add-on into an .xpi file depending on the contents of your add-on. If so, things may start to break if you significantly change your add-on's functionality (e.g. changes in package.json won't propagate to install.rdf). With this method, you would, probably, need to use a "normal", non-jpm method of creating an .xpi file when you want to publish your add-on.
Is there a way to easily distribute an electron.atom.io app as a static site?
I don't need all the functionality, I just want to allow the client to view the latest updates.
-- edit --
Perhaps a better way to ask the question is; "How do I build a web app that can be hosted online and run on electron with minimum rewriting" - similar to the Slack app that works the same way on web or electron app.
As long as your main use of Electron is to create a 'native browser wrapper' for a web-app this is entirely possible.
You will have to implement a check if your application is running inside a browser or inside Electron and wrap your electron specific code in it:
if (window && window.process && process.versions['electron']) {
const {BrowserWindow} = require('electron').remote
}
You'll probably have to step through your application and disable Electron specific functionality at multiple places.
You have other options to do a long distance demo of an Electron app
Electron is basically a shell to run node.js apps on the desktop. This means if you want to move it to the web, you have to give up all the Electron APIs that access the local system and you're left with a basic node.js app, which is most likely not desirable.
To demo your desktop app to an off-site client, you can either make a presentation with screenshots detailing the current user flow, or compile a sandboxed demo version of your app and send it over to them.
Screen presentation
This is your quickest and easiest solution if your client just wants to be kept in the loop and see some eye candy. You can just record how the app works with some example data, add some written or audio explanation to it, and let them enjoy the smooth ride.
Build a demo
If your client wants to actually have a hands-on demo with the app, you need to have some form of basic code distribution. The cleanest way to do this would be to tie up all loose ends in your current app flows, block all unfinished roads in it and compile it for whatever platform your client requested the demo for.
Take a look at the electron-packager and electron-builder docs to get an idea how to build an .exe, .dmg or whatever file from your Electron app, then send that file to them with some basic instructions.
Is start (Dart server side framework) auto-refresh when one of our source code changed (just like PHP)?
Is bulls_eye, bloodless and express too?
or if they are not, is there any Dart server side framework that able to do that (edit code, then test on the browser, without needing to restart the dart/server program)?
Currently this is not yet possible in Dart. If you change the code you have to restart the app.
I wouldn't expect this to work anytime soon.
A main feature to make this possible is to manipulate the code at runtime. This is planned but as far as I know not yet started.
EDIT
The above mentioned feature is necessary when you want code to be updated without loosing the current state of the application but that is usually not so important on the server because it should be (mostly) stateless anyway.
In Dart there's no need to restart the server app when only the client part changes.
If you really just want to restart the entire server when the code changes you should be able to do that by yourself. Create a console app that loads the server app into an isolate (spawnUri) and watch the source directory for file changes. In the case of a file change shutdown the server-app-isolate and create a new one.