Repository navigation
Why use string-based Ipc as opposed to controller webrequest? #47
Description
I get that traditional electron apps need ipc to communicate between renderer and main, but the string-based Ipc message passing between processes feels unnecessary now that we have a full ASP.NET MVC site available with strongly-typed access to the underlying native desktop services.
Is there a reason why you wouldn't just make sync or async web requests to a controller method and have the controller method perform the relevant native task like opening a file save dialog or etc? Using controllers seems like a much more standard/robust/testable/etc way to perform the same communication tasks that old-school electron would do via string-based ipc message passing, or am I missing something fundamental here?
Activity
GregorBiswanger commentedon Nov 9, 2017
Hey @yoDon
there are some reasons why we use the IPC, but you can use regular controller action calls too.
One is a refresh effect after we call a controller. That is not like a desktop app. Okay, it is possible with an ajax call, but the implementation is not sexy too.
The next is, the push communication from the backend (Main process) to the view (Renderer process). In desktop apps you often use async background processes. This feature supports no controller. You need SignalR as example. And the integrated IPC is easier, stable, secure and fast.
I show a little example in my youtube getting started video:
https://www.youtube.com/watch?v=nuM6AojRFHk
I hope my answer helps you.
yoDon commentedon Nov 9, 2017
oooh wow, yes SignalR is what I really want (I just hadn't thought that far ahead).
Is there anything tricky to adding nuget packages to the ASP.NET side or do I just add them to the .csproj and then npm electronize start? I can try to work up a SignalR sample if there isn't something you can point me towards as a hint (or even if there is)
GregorBiswanger commentedon Nov 9, 2017
Do you like a hybrid- or desktop-app? Which information should be pushed to the view?
If you want a desktop app only, you should use the IPC communication instead of SignalR... but its not mandatory..
You can use SignalR equal to the normal ASP.NET MVC project..
See the How-To´s from the project site:
https://github.com/aspnet/SignalR
robertmuehsig commentedon Nov 9, 2017
Just to make sure we are all on the same level (maybe @GregorBiswanger needs to correct me, because he created it ;) ) :
After the Electron part is started a Socket is created on a available free port, lets say port 8000.
In the next step we try to boot up the ASP.NET Core app, that is embedded inside the Electron app and we try to find the next available free port, lets say 8001. When we start the ASP.NET Core app, we start it with the parameter from the Electron Socket (8000)
Now we our ASP.NET Core App running under Port 8001 and the socket inside the electron app is running on Port 8000 and the ASP.NET Core app knows the port to communicate to the electron part.
This is more or less what is happening in the main.js.
The Socket on Port 8000 is our IPC bridge to the Electron world. The Electron.NET API package is more or less a adapter for the IPC stuff.
When you are accessing the Clipboard API, we trigger the clipboard.js API inside the Electron part via this IPC bridge.
To access the real Electron APIs within the ASP.NET code we need our IPC bridge - at least currently. In theory the thing that we call IPC could be done via SignalR, but AFAIK Gregor had some issues that the SignalR stuff was unable to communicate with the socket.io stuff inside the Electron part.
The Electron part is just a big browser for us and we need to talk to it to invoke Electron APIs - it's like the Visual Studio Browser-Link Feature
Does this clear things up? If you have a better solution we are open for ideas :)
yoDon commentedon Nov 9, 2017
@robertmuehsig yes - I was thinking use HTML<-SignalR->ASPNET<-IPC->ELECTRON, and trying to avoid the HTML->IPC->ELECTRON->IPC->ASPNET->IPC->ELECTRON->HTML paths I was seeing in the demo (eg. avoiding using IPC stuff in HTML/JS and using SignalR there instead.
robertmuehsig commentedon Nov 9, 2017
Where did you see the HTML-IPC path? As far as I know the HTML/JS part in the ASP.NET Core app doesn't know anything about electron at all.
yoDon commentedon Nov 9, 2017
@robertmuehsig I was looking at things like the DesktopCapturer in the demo, which seemed to be doing a lot of the work in JS, I believe on the client
robertmuehsig commentedon Nov 9, 2017
Ah - this one here? https://github.com/ElectronNET/Electron.NET/blob/master/ElectronNET.WebApp/Views/DesktopCapturer/Index.cshtml#L75-L123
Mhh... indeed... @GregorBiswanger - is this even working?
yoDon commentedon Nov 9, 2017
The screenshot code definitely does work in the demo app
robertmuehsig commentedon Nov 9, 2017
Uh... I had no idea and still don't know why this is working, maybe @GregorBiswanger knows why ;)
yoDon commentedon Nov 9, 2017
I'm trying to fold https://github.com/dsuryd/dotnetify-react-demo-vs2017 into the Electron.NET demo. The two together look to be almost exactly what I want. Static React SPA UI communicating via SignalR with C# implementation logic running under ASPNET. That, to me, sounds like heaven in that it lets me run what I consider best practices in my UI layer, my implementation layer, and my communication layer, all wrapped up in Electron.NET
robertmuehsig commentedon Nov 10, 2017
Regarding the DesktopCapturer: The JS Code in it is not talking to our Electron.NET API / IPC Stuff, instead it is using the possibilities of the Electron renderer itself. As far as I understand it now: When you are rendering the page via Electrons browser instance you can always just do such stuff.
Hope this helps and if you succeed please let us know - seems like a good idea :)
Could we close this one? Maybe I will add some more details to our wiki page.