How to handle system-uri-response in the main.js process

bzee · May 17, 2018, 11:42am

Is there any particular reason you’re using Electron if you’re ditching the GUI?

happybeing · May 17, 2018, 11:43am

To make it as easy to build as possible. We have apps which do this using electron. If we had something else (which works) that I can modify easily I’d consider using that.

bzee · May 17, 2018, 11:47am

And by build you mean distributing to multiple platforms like Windows and OSX?

I’m starting to understand your challenge here. Do you have the code from your OP on a repository at the moment?

happybeing · May 17, 2018, 11:50am

I’ll settle for linux executable, but if it can target windows and mac that would be great.

I haven’t created a github repo yet but the code is essentially the nodejs tutorial, and then me trying to get the system-uri-response in the app rather than the window so I can strip the latter out. I also added a command (npm) so it handles parameters but don’t think that’s relevant. I’ll post the main.js to you by PM in case you want to see.

EDIT: I’m thinking maybe I should just hide the window for now and jump to a better CLI framework later. It just seems like this should be easily soluble by somebody who knows electron.

bochaco · May 17, 2018, 12:12pm

@happybeing, I assume you still have the following in your main.js:

github.com

maidsafe/safe_examples/blob/master/safe_app_electron_quick_start/main.js#L76


})


app.on('activate', function () {
  // On OS X it's common to re-create a window in the app when the
  // dock icon is clicked and there are no other windows open.
  if (mainWindow === null) {
    createWindow()
  }
})


app.on('open-url', (e, resAuthUri) => {
  mainWindow.webContents.send('system-uri-response', resAuthUri);
})


// In this file you can include the rest of your app's specific main process
// code. You can also put them in separate files and require them here.

If so, that’s the entry point of the response, and that code is trying to send the restAuthUri received to your renderer process/es, I presume you should replace the body of that function with your own logic.

Edit: and this other place is where you would also need to place your logic, this is for when you have your app running already so it doesn’t launch a new instance:

github.com

maidsafe/safe_examples/blob/master/safe_app_electron_quick_start/main.js#L37




// Emitted when the window is closed.
mainWindow.on('closed', function () {
  // Dereference the window object, usually you would store windows
  // in an array if your app supports multi windows, this is the time
  // when you should delete the corresponding element.
  mainWindow = null
})


const shouldQuit = app.makeSingleInstance(function(commandLine) {
  const resAuthUri = commandLine[2];
  if (resAuthUri) {
    mainWindow.webContents.send('system-uri-response', resAuthUri);
  }


  // Someone tried to run a second instance, we should focus our window
  if (mainWindow) {
    if (mainWindow.isMinimized()) mainWindow.restore();
    mainWindow.focus();
  }
});

happybeing · May 17, 2018, 12:16pm

Never assume anything with me.

I hadn’t realised the app was sending system-uri-response so I think you have hit the nail on the head. Thanks very much. Will have a go with that.

UPDATE: not sorted yet but I’m going to start again with hunter’s safe-app-base and try my best to keep the auth working. Thanks for the hints. This still might be what I needed to know.

bzee · May 17, 2018, 1:46pm

This topic gave me the idea to authorise without using Electron, as I initially thought it’s a distraction.

I’ll just leave this minimal viable example here, in case anyone might deem it useful:

const safeApp = require('@maidsafe/safe-node-app');

const info = {
    id: 'example', name: 'example', vendor: 'example',
    customExecPath: [process.execPath, __filename],
};

async function authorise() {
    const app = await safeApp.initializeApp(info);
    const uri = await app.auth.genAuthUri({});
    await app.auth.openUri(uri.uri);
}

(async () => {
    if (process.argv.length == 2) {
        await authorise();
        process.exit();
    }

    const app = await safeApp.fromAuthURI(info, process.argv[2]);

    // Authenticated and ready to rumble
})();

Was a useful learning experience; haven’t tested it thoroughly yet. I understand now why Electron comes in handy as it manages the process and instance for you.

happybeing · May 17, 2018, 2:14pm

I think I have this working now (with electron), but what’s still missing is the packaging to executable.

If there’s a way to package your stuff for linux, and ideally win/mac then this would be great.

bzee · May 17, 2018, 3:14pm

I’ve tried with https://github.com/zeit/pkg. It seems to be a little hard as the safe-node-app dynamically links to a library, which it expects to be at a certain path relative to the package scripts. When packaging everything into a single executable it won’t find the library.

It could be fixed by making it look for the libraries in the same directory as the executable.

So, your best bet would still be Electron! Using hunterlester/safe-app-base shouldn’t it be as simple as npm run package?

happybeing · May 17, 2018, 3:16pm

I hit this too (for /**/safe-clip/node_modules/@maidsafe/safe-node-app/src/native/mock/libsafe_app.so) and I think I also get it with Hunter’s thing but I’ll need to go back to that to check.

I am trying to get it included by pkg by specifying it as an asset, but a few people seem to have failed to get that to work with other missing resources, so I’m not sure it works. I haven’t got it working yet.

bzee · May 17, 2018, 3:31pm

The problem lies with the fact pkg changes the path the script thinks it’s executing at. (In Windows) It thinks it’s in C:\snapshot\project, so will look for the DLL there.

hunterlester · May 17, 2018, 3:38pm

I need to update the readme.
It’s setup so that you don’t have to package it for development.
You can run yarn start and it’ll receive the URI response back from the browser, once authorisation is approved.

npm run package will do though.

hunterlester · May 17, 2018, 4:05pm

Testing just now, I was getting the same error as you about not being able to find module @maidsafe/safe-node-app.
yarn was pruning my resources.
I updated the repo just now to run use npm and it’s fine.

~~Were you able to solve the issue and still use yarn?~~

[EDIT]: I’ll require const safeApp2 = require('@maidsafe/safe-node-app') in the main process to see if I can get it to error just now.

southside · May 17, 2018, 4:09pm

fascinating to watch you guys working through this

happybeing · May 17, 2018, 4:18pm

This is working now. Sorry @hunterlester I must have got confused somewhere so I shall carry on. See:

Thanks for your help!

If you have any ideas for how to solve the problem with pkg that would be good, so we can build CLI apps without electron. It looks like its almost there.

hunterlester · May 17, 2018, 4:24pm

I’ll take some time to see how pkg works.

In my repo I’m simply using electron-packager

happybeing · May 17, 2018, 4:26pm

I started by following this and it works fine until I add const safeApp = require('@maidsafe/safe-node-app') and other stuff from your safe-app-base

bzee · May 17, 2018, 5:22pm

Using my previous simple example, packaging with pkg:

$ pkg --targets host index.js
> pkg@4.3.1

Gives the following result upon execution:

$ index.exe
ERROR:  Error: Dynamic Linking Error: Win32 error 126
    at new DynamicLibrary (C:\snapshot\test\node_modules\ffi\lib\dynamic_library.js:74:11)
    at Object.DynamicLibrary (C:\snapshot\test\node_modules\ffi\lib\dynamic_library.js:33:12)
    at Object.ffi.init (C:\snapshot\test\node_modules\@maidsafe\safe-node-app\src\native\lib.js:20:15)
    at new SAFEApp (C:\snapshot\test\node_modules\@maidsafe\safe-node-app\src\app.js:36:9)
    at Object.initializeApp (C:\snapshot\test\node_modules\@maidsafe\safe-node-app\src\index.js:61:25)
    at authorise (C:\snapshot\test\index.js:0:0)
    at __dirname (C:\snapshot\test\index.js:0:0)
    at Object.<anonymous> (C:\snapshot\test\index.js:0:0)
    at Module._compile (pkg/prelude/bootstrap.js:1243:22)
    at Object.Module._extensions..js (module.js:644:10)
(node:15456) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Failed to load native libraries: Error: Dynamic Linking Error: Win32 error 126
(node:15456) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero
exit code.

Error 126 means the library is not found.

I figured out that we can give an option to initializeApp and fromAuthURI to specify the path to append to the library searching: libPath. So, the following worked out well:

const path = require('path');

// ...

const app = await safeApp.initializeApp(info, null, {
    libPath: path.join(path.dirname(process.execPath), './node_modules/@maidsafe/safe-node-app/src/native')
});

This will be put together with the name of the library (src/native/lib.js#L33) and it will be found. (Assuming relative to the executable the node_modules directory is located containing the built @maidsafe/safe-app-node package with its libraries.)

I think I’ll be refining this to make some kind of repository that will use any of this to make a packagable test app.

happybeing · May 18, 2018, 10:20am

Bravo @bzee. I just tested this and it seems to work! I have a command which just invoked SAFE Browser! Woohooo.

The packaged executable is 44MB just to do that, but it damn well works.

I’ve only tested Linux BTW, but pkg also works for Windows and Mac so easy to check this out too.

happybeing · July 15, 2018, 5:56pm

This topic was automatically closed after 60 days. New replies are no longer allowed.