I want to setup a deeplink functionality on my electron app and here's how I set it
app.removeAsDefaultProtocolClient('snetwork');
if (isDevelopment && process.platform === 'win32') {
// Set the path of electron.exe and your app.
// These two additional parameters are only available on windows.
// Setting this is required to get this working in dev mode.
app.setAsDefaultProtocolClient('snetwork', process.execPath, []);
} else {
app.setAsDefaultProtocolClient('snetwork');
}
But when running in dev mode on MacOS, the protocol is catched, but opens the default electron app and not my application.
And on windows I have this error message
As stated in the docs:
On macOS and Linux, this feature will only work when your app is packaged. It will not work when you're launching it in development from the command-line.
Related
I have created an Electron App(say MyApp). I have used electron-packager to pack the App. I installed the app in my local machine and I can see MyApp in the start menu. When I click on the Icon It launches the app but I am not able to debug it.
I can see the devtool
Electron version : "^5.0.7"
Electron Packager: "^12.2.0"
OS: Windows
Thanks in advance
I think the best way debug your main process would be to do so during development, i have found the information here on the Electron docs to be very useful https://electronjs.org/docs/tutorial/debugging-main-process
Also my Code Editor of choice is VSCode so i was able to use this link
https://electronjs.org/docs/tutorial/debugging-main-process-vscode
Its also good practice to have a Crash Reporter setup, Electron has the default one https://electronjs.org/docs/api/crash-reporter which also work great, but you can add other third party libraries like Bugsnag, Sentry or Backtrace.io.
Default Electron Crash Reporter
const { crashReporter } = require('electron')
crashReporter.start({
productName: 'YourName',
companyName: 'YourCompany',
submitURL: 'https://your-domain.com/url-to-submit',
uploadToServer: true
})
Using Sentry "You need an account for this option"
//You need to call init in your main and every renderer process you spawn.
import * as Sentry from '#sentry/electron';
Sentry.init({dsn:'https://<your-key-here>#sentry.io/15...5'});
Hello: I'm trying to get started with the ADAL plug-in for Cordova. Having used the native libraries a few times, I thought this would be pretty straightforward but I ran into a bit of an issue.
First of all my environment is VS2017, and the plugin is ADAL for Cordova 0.10.1.
I've created what I believe is the most simplistic example of a connection, using my own client application specifics and the ones provided in their sample online (which is) included below. My authentication looks like:
function authenticate(authCompletedCallback, errorCallback) {
var authority = "https://login.microsoftonline.com/common",
redirectUri = "http://localhost:4400",
resourceUri = "https://graph.windows.net",
clientId = "a5d92493-ae5a-4a9f-bcbf-9f1d354067d3";
var authContext = new Microsoft.ADAL.AuthenticationContext(authority);
authContext.acquireTokenAsync(resourceUri, clientId, redirectUri).then(authCompletedCallback, errorCallback);
This is then called in onDeviceReady();
acquireTokenAsync is called but doesn't appear to return either success or failure and a quick Fiddler trace doesn't appear to show the call which makes me wonder if it is not a configuration issue with Cordova to begin with.
I have commented out the Content-Security-Policy metatag with similar results.
Thank you in advance for any guidance!
Edit
Okay, perhaps this is helpful. I noticed that on the Cordova Plugin Simulation tab (I am trying to run this in the simulator in Chrome). I am seeing a dialog box with error:
There is no handler for the following exec call:
ADALProxy.acquireTokenAsync(...
Also, seems to work on a connected Android Device, just not in the local Simulator
The plug-in for Cordova doesn't support to run on the browser platform. When we developer an Cordova app and want to test on the browser platform, we have to ensure that the app depends on support the browser platform.
For the ADAL plug-in for Cordova support the platform:
Android (OS 4.0.3 and higher)
iOS Windows (Windows 8.0, Windows 8.1,
Windows 10 and Windows Phone 8.1)
And for other kinds of plug-in you can check it via you the Cordova plug-in.
I can't open devtools in the built version of my electron app. Therefore i want to find another solution to log any errors that only occur in the production version.
Is there any good way to get some console.logs from an electron application if its already built?
Obviously i can debug the “development” version (running npm run dev) of my electron app by opening the chrome dev tools. But i can’t find any way to enable them inside my production application.
I am using the newsest version of electron-vue
Thanks for any help in advance.
Here's what worked for me on Mac.
In terminal type lldb path/to/build.app
In the opened debugger type run --remote-debugging-port=8315. It should open a window of your app.
Open Chrome at http://localhost:8315/
Click on the name of the app. For example, Webpack App.
If you don't see anything in the opened tab, focus on the window of your app.
Launch your Electron application with the --remote-debugging-port=8315 flag set and navigate to chrome://inspect/#devices in Chrome 80+. Then click Configure... and add localhost:8315 as a discovery server.
Then, wait for your Electron instance to appear in the devices list and click inspect.
Enabling the Chrome devtools in production can be done in various ways:
A environment variable:
E.g. under Windows set ELECTRON_ENV=development&& myapp.exe
Pass a special parameter to your app
E.g. myapp.exe --debug
Debug mode via user settings (if you have persistent settings)
Menu entry to open the devtools
Can be combined with 1.-3. to only have that menu entry when in debug mode
You can just check if 1.-3. are set and if they are, you simply open the devtools via mainWindow.webContents.openDevTools()
Personally I use a combination of 1., 3. and 4. I simply unlock a developer menu that allows me to open the devtools or opens the userdata folder for me.
If you also want to log critical errors, then electron-log looks like a rather popular option for electron.
On Mac just run open /Applications/WhatsApp.app --args --remote-debugging-port=8315 and then open http://localhost:8315
https://github.com/bytedance/debugtron
Debugtron is an app to debug in-production Electron based app. It is also built with Electron.
The way to do this is using the --remote-debugging-port flag.
Using Signal as an example, take the following steps:
start the application from the CLI
signal-desktop --remote-debugging-port
Open the debugging URL in a Google Chrome browser (in this case http://localhost:39733/), this will open a page with the app name on it .
Click the to open a screen were you can click around to use the app and see output in the devtools
Alternatively, you can open chrome://inspect/#devices in the Google Chrome browser and click "inspect" (underneath the app name) to open the same window
In my case, I had a runtime error crashing Electron before the web view was even shown. Chrome dev tools were not useful for debugging this kind of error.
Even stranger, the app loaded fine using the lldb commands:
lldb ./dist/mac/electron-quick-start-typescript.app
run --remote-debugging-port=8315
I managed to solve by writing the Node.js console log/error to a file. So I could see the console output:
import fs from 'fs';
import util from 'util';
// use a fixed path, to ensure log shows outside Electron dist
const logPath = `/Users/username/Sites/electron-server/debug-${isDev ? 'dev' : 'prod'}.log`;
const logFile = fs.createWriteStream(logPath, { flags: 'w' });
const logStdout = process.stdout;
console.log = function(...args) {
logFile.write(util.format.apply(null, args) + '\n');
logStdout.write(util.format.apply(null, args) + '\n');
}
console.error = console.log;
I found the error was a relative path issue. When the app is started in production mode the relative path did not point to the correct location.
I solved by using an absolute path, with Electron getAppPath() method:
- './renderer'
+ app.getAppPath() + '/renderer'
In the main/index.js at the end of section app.on('ready') just add:
mainWindow.webContents.openDevTools();
Just for debugging, when electron opens an empty window, but the development version works fine, this way is very helpful for me.
The answers above don't help for me. ( those with -remote-debugging-port)
put this code into your main.js or similar file, it will automatically open the dev-tool when started.
mainWindow.webContents.openDevTools()
June 2022 UPDATE:
Devtools can be explicitly enabled through on the BrowserWindow object.
mainWindow = new BrowserWindows({
...,
webPreferences: {
...,
devTools: true,
}
}
And then you can manually open it on load.
mainWindow.on('ready-to-show', () => {
if (!mainWindow) {
throw new Error('mainWindow is not defined')
}
mainWindow.show()
mainWindow.webContents.openDevTools()
})
Worklight 6.1.0
iOS 7 on iPhone 5s
We have a hybrid application that relies on Worklight server to do the direct update. The problem occurs when the user minimizes and then re-opens the app, the user is able to see the update dialog, however the update would then fail due to the wrong WL-instance id.
Here is the init options:
var wlInitOptions = {
connectOnStartup: true,
onConnectionFailure: function() {
WL.Logger.error("Failed to connect: " + arguments);
}
WLJSX.bind(window, 'load', function() {
WL.Client.init(wlInitOptions);
}
Here are the steps I did:
1) Open the IOS application, it will bring me to the first index page of the application, say Page1
2) Press a button, which brings me to another page, say page2 using GluJs
glu.viewport('MyApp.page2');
3) Minimize the application.
4) Modify the WebResource and then deploy the modified Iphone app to Worklight server.
5) Re-open the minimized application, the user gets a prompt to direct update.
6) The update would then fail, and there is a log in Worklight console of the following:
[ERROR ] FWLSE0203E: Received bad instance Id from client. Server
instance Id:'3f9eveddc7br5mq3ll0nq89miu', client instance
Id:'ut5m5f01i3bkq5l78m54uq137o'. [project trunk]
The existence of GluJs nor step 1 at all is relevant to the process of Direct Update, which happens in 2 cases: on application startup, on return to foreground. Any "page movements" in the app are irrelevant.
You did not mention if this happens in your development environment (Worklight Studio in Eclipse with the built-in Worklight Development Server), or a production environment (clustered, not clustered, load balancer or not, etc...).
I've performed the following without any errors in Worklight Studio 6.1.0:
Created a new project and application
Added the iPhone environment
In initOptions.js, changed connectOnStartup from false to true
Run As > Xcode project
Tested the app in both iOS 7.0 Simulator and iOS 7.1 beta 4 device (iPhone 5s)
Launched the application
Moved the application to the background (clicking the Home button)
In Eclipse, altered the HTML file
Run As > Run on Worklight Development Server
Brought the app back to the foreground
Direct Update detected and processed, application re-inited and displayed the updated HTML file
We have a iOS and Android Hybrid App Environment in which we have App Authenticity successfully running (drop down available to control the feature) using:
<mobileSecurityTest name="app">
<testAppAuthenticity/>
<testUser realm="wl_anonymousUserRealm"/>
<testDeviceId provisioningType="none" />
</mobileSecurityTest>
We added a "iOS Native API" project to our Worklight project that we use for our native iOS client development in XCode 5. We are successfully able to connect to the WL server and call all our existing adapter procedures in our different adapters.
For this native API project, we now would like to enable App Authenticity as well. When we use the same MobileSecurityTest as in the hybrid app in the application descriptor of the native API project we can deploy it to our WL server and the App Authenticity feature is enabled (drop down available to control the feature) at the iOS Native API entry in the console.
On the native iOS app/project we set:
bundle ID is exactly the same as in the hybrid project and the same as in the Apple Developer portal
Key Chain is enabled in the project and also set to worklight.group (as in the hybrid XCode project)
we are not able to get a successful authentication running when we want to connect to WL server. We see that the DeviceAuthManager tries to get the UUID from the device, but then the server returns an error response:
2013-09-24 08:58:35.530 App[32535:c07] DeviceAuthManager:getWorklightUniqueDeviceId --> returning UUID from the keychain
2013-09-24 08:58:35.564 App[32535:c07]
isCustomResponse
2013-09-24 08:58:35.564 App[32535:c07] this is it: Status: 403
InvocationResult: (null)
InvocationContext: {
delegate = "<MyConnectionListener: 0x7d73ec0>";
}
Response text: /*-secure-
{"WL-Authentication-Failure":{"wl_authenticityRealm":{"reason":"com.ibm.json.java.JSONObject cannot be cast to java.lang.String"}}}*/
2013-09-24 08:58:35.564 App[32535:c07] [ERROR] Worklight: -[WLRequest requestFailed:]:309::Status code='403' error='(null)'
2013-09-24 08:58:35.565 App[32535:c07] [ERROR] Worklight: -[WLClient onInitRequestFailure:userInfo:]:410::
We did try this with and without a registered ChallengeHandler that just prints the response. The same results, just that we can see the error response printed in the isCustomResponse method if we have the ChallengeHandler.
Also, a Worklight dialog is shown automatically that says "Error: An error was encountered while processing the request from the application (CLOSE)".
We can see that in 6.0 there is the worklight.plist value:
<key>wlUid</key>
<string>wY/mbnwKTDDYQUvuQCdSgg==</string>
is that also necessary in 5.0.6? Our plist file there does not have that.
When we change the environment value in the worklight.plist file from iOSnative to our app name (or something else) we get a response Response text:
{"errorCode":"UNEXPECTED_ERROR","errorMsg":null}
so I assume this value iOSnative is a fixed value that has to be there?
Sept 30th: WL 6.0.0.1 Update
In WL 6.0.0.1 it seems to not show the same bug when we used it with a Studio 6.0.0 generated iOSApi Environment deployed to a Consumer Server on Tomcat.
Now we are getting an:
Invocation Failure: Status: 403
InvocationResult: {
"WL-Authentication-Failure" = {
"wl_authenticityRealm" = {
reason = "forbidden state";
};
};
}
when we have Enabled, blocking and we can connect and call Adapters when we change to Enabled, servicing. (which was not possible with the 5.0.6 bug before)
Now we assume we need to somehow setup our iOS Certificates or Signatures that we use to sign the app for the iOS Simulator and for the iOS Devices (Developer and Distribution Certificates) on the Wl server, so that the WL Server allows a connection?
Could someone help us with the steps that we need to take to setup an iOS native App Authenticity in our XCode 5 project to successfully connect to the server and after that call our adapters with Enabled, blocking.
We did add worklight.group to the turned-on Keychain Sharing capability of the iOS app.
We copied all Wl iOSAPI files including the plist file with the wlUid into the iOS app xCode5 project?
As mentioned above, it works with Enabled-Servicing and with Disabled AppAuthenticity fine.
For App Authenticity to function in a native iOS application using the Worklight Native API for iOS, the steps are the same as in a Hybrid application on the Eclipse side:
Setup the securityTest in authenticationConfig.xml
Add the securityTest to the iPhone environment application-descriptor.xml
Add your bundleId to the iPhone environment in application-descriptor.xml
There is, however, 1 extra step to do - in Xcode.
Once you open the generated Xcode project:
Under Build Settings > Linking > Other Linker Flags
Add the flag -ObjC
Now you can Clean and/or Run the project on the iOS Simulator/device. Should work.