I'm new to electron and I want to make sure I understand the distinction between code that is appropriate for the main process vs the renderer process. The app is essentially a React app hosted inside a single electron page. So, as I understand it, I have one main process and one render process.
If I want to make REST calls as part of the React app (using axios for example), I assume I can do it inside the React code within the renderer process, right? No need to go to the main process for that is there?
I also have to create a socket connection to an outside server. This is not an HTTP REST interface, it's a raw TCP/IP socket. Can this also be done within the renderer process or do I need to go to the main for that?
I tried putting the socket calls using node's net library and it seems to work okay. The very first time I got some kind of connection error but subsequent tries seem to be working. That one error is making me wonder if using net inside the renderer is a good idea though.
Related
It may be because I'm not developing a traditional Swift app, instead I'm using the https://github.com/zserge/webview library to develop a cross platform app.
My app has 2 parts, divided into 2 different threads: one thread launches the window and displays a JS app. The second thread contains a background server bound to an ephemeral port and serves a json api, written in Rust. The Rust side is also the one talking with the File System and making all requests. On Linux I don't have any problem, but on Mac it works only when requesting resources from root and home directories but not from Documents/Desktop etc
The first problem I had when running it on Mac has been allowing access to the server from the window: I had to add a new entry to the info.plist file, according to this answer in stackoverflow: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection
This resolved the issue I had talking to the server bound to the ephemeral port. Truth be said I have to also say that now it requests me to allow access to external resources every time I launch the app.
But, when trying to execute a function which requires access from the Rust side to the Desktop (for example), it doesn't work and it does not show any popup and never did
Btw, if you want to have a look at the final product, maybe to help you understand better the app, have a look here: http://getdevspace.com/
Check the ch mode file system
Even had the same problem so i checked the ch mode so it worked
Thanks
I have recently created a custom framework that is planned to be re-used for multiple projects. The catch is, this is for a plugin, and knowing that we can't simply embed the framework within the plugin's bundle, due to symbol collisions and what-not, I'm thinking of simply embedding it with the plugin's XPC. On a side-note, this framework will be used to launch custom interfaces, such as a view controller, views, and use some delegates slapped inside it that the plugin will have to take ownership (which I am hoping). Which brings me to my question: is it possible for a different process to take ownership of objects instantiated in the XPC? I am quite new to using frameworks, so I've spent hours trying to jerry-rig stuff together in XCode based on tutorials I've found online, sadly to no avail.
A framework is a bundle of code and resources that can be used, and reused, by multiple applications. It can be embedded within your application, be part of the operating system (the entirety of Cocoa is actually a collection of frameworks), or dynamically located and programmatically loaded at runtime. Once loaded, the framework's code, classes, and resources appear to the application as if they had been compiled directly into the host app. The key is that the code executes directly, in your process's memory space.
XPC is an inter-process communications facility. It allows one process to send and receive messages with a different process. It cannot be used to communicate with itself.
You cannot "take ownership" of an object using XPC. All XPC messages serialize ("archive" in Cocoa-speak) any object and de-serialize that object on the receiving end. The second process now how a replica of the original object; it is not a reference to the original object and is constrained to the boundaries of its process.
If your second process needs to display something, you have (basically) three options:
(1) Make the second process its own application. The second process can be a full-fledged Cocoa app with windows and so forth. You can make it an "accessory" app, so it does not have a menubar or appear in the dock. See LSUIPresentationMode Info.plist property and/or NSApplication.activationPolicy.
(2) The advanced technique is to use an IOSurface. An IOSurface is, essentially, a method by which a second process (your XPC Service) can draw directly into a window of your application. Again, the drawing objects still exist—and are completely isolated in—the second process; but what they draw will appear in your application as if they were local view objects. (This is how Safari works; every browser page is rendered by an isolated background process drawing into a surface.)
(3) Use a poor-man's IOSurface: send your data to the second process, have it render the results into something (pixel array, TIFF, PNG, ...) that can be serialized and drawn by the host app, then use XPC to send that rendered image back to the host app for display.
Daemons and Services Programming Guide
IOSurface
I am in need to call an external *.exe compiled in C++
from ASP.NET WEB API 2 using Process (System.Diagnostics)
This executable does some image processing stuff and use lot of memory.
SO my question is if change my API calls to Async. or implement threads will it help, Or it doesn't matter?
Note: All i have is executable so i can not go for a CLI Wrapper.
You can separate the two. Your api is one thing, it needs to be fast, responsive to be able to serve the clients. Your image processing thing is different.
You could implement a queuing system. The api is responsible for adding a new item to this queue and nothing more. You could keep track of what tasks are being run in a separate sql table let's say. Imagine you have a sql table called Tasks. Your api chucks data in there and the status is "Not Running".
Some other app which lives on another machine entirely keeps an eye on this table and takes care of running that executable for each item. When it starts, it changes the status to Running, when it completes it's Done. You do whatever else you need. You could have an api endpoint which takes the ID of the task so your client can keep calling this endpoint to see what the status is. Or you could raise an event when it's done, depending on your application needs.
Bottom line, keep things separate, you gain nothing for blocking the api while a resources heavy task is running. Think what happens if you start that process 5 times, at the same time. You've just killed your api basically.
The app that does the heavy work, could even be located on a separate machine, so it doesn't affect the api at all.
I would like to notify my main application (if it is still running) when the ScheduledAgent has finished its background task.
Is it actually possible? I couldn't figure out how I could reference my App or MainPage
For simply protecting shared data access between main app and background agent using Mutexes have a look at this question. Maybe this already gives you a hint in the right direction.
But if you want to react to events like "the background agent just finished" (in main app) or "the main app starts up" (in background agent) then you might be out of luck. There is no simple direct communication available, let alone direct data access. You could use Sockets or Raw Notifications.
A method based on polling and Mutexes is discussed in this question.
I need to communicate with a Service using IPC from inside of a Browser Helper Object (registered with IE8). Unfortunately, all of this communication is done through an Assembly API that I have no control over. Whenever this API starts up I get the following error:
ExceptionSystem.Runtime.Remoting.RemotingException: Failed to connect to an IPC Port: The system cannot find the file specified.
I realize that it is difficult to discern what the issue is without source. However I am curious if anyone knows of anything sort of permissions or DLL issues that would prevent IPC from working in this case.
It looks like this issue can be caused by a number of things.
UAC, as always, can be an issue and should be disabled to make sure it isn't causing problems.
The other issue is that IE allocates a process for the main frame as well as individual tabs. This means that there is no guarantee that your BHO is in the main frame process. If you set the following registry key, IE will prevent the browser from allocating extra tab processes:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]"TabProcGrowth"=dword:00000000
In general, neither of these solutions are ideal though. I ended up backing away from this entire attempt as it seems very problematic from a number of angles.