I have made a osx application contains a normal app, a login item which stored in 'Contents/Library/LoginItems' directory and a XPC Service stored in 'XPC Services' directory.
My main application can communicated with XPC Service like below.
let connection = NSXPCConnection(serviceName: "me.wanyi.xxx-XPCService")
It works fine.
But the login agent application can't work. It reported it can't communicate with the helper application. I thought it couldn't locate the XPC service.
I found it did work after I embed the XPC Service binary into the agent's bundle. But there will be two xpc binary bundles in the same bundle. I think maybe this is not an elegant solution.
Is there another way to solve this problem?
Related
I have been working on a NativeScript project that uses an API. The API project is on my MacBook and haven't deployed to anywhere yet. It's based on Laravel and I use Laravel Valet as development environment.
I can't test the mobile app on iPhone because the app can't connect to local API URL. I know Valet has "share" command, but because the API consumes another API -which has IP restrictions-, it doesn't work for me. Sharing a local domain via Valet's share command is something like a proxy as I understand, so the consumed API doesn't work on that proxy.
I also checked articles about how to share Macbook's network with iPhone, but it only shares the same network. I can't access the local API still.
Is there any other way that can resolve my issue? Maybe a Docker based solution? I am not that good at Docker, but I can give a try if it is possible with it.
https://ngrok.com/ will happily expose your local Laravel Valet server.
Looks like there's a bit of a walk through on that here too https://mannyisles.com/using-laravel-valet-and-ngrok/ which may help?
I come from the desktop application world (WPF, WinForms), where the convention is to deploy your exe to \Program Files[ (x86)]\CompanyName\AppName\ directory, and store all the data in \Program Data\CompanyName\AppName\ directory.
What's the corresponding convention for deploying Asp.NET Core web services on a desktop (not a server) PC? Program Files directory doesn't seem like a good idea, because it requires admin credentials for writing, a problem you hit the moment you try to publish the app. On the other hand, while Program Data doesn't have the permission problem, it just doesn't feel right, given there is no corresponding Program Files location.
I've also seen C:\intepub\wwwroot\web-service-name used, when IIS was involved. Is that the way to go? I'm guessing it makes sense when running Asp.Net Core app in Kestrel behind IIS as reverse proxy, but what if I were to host my app inside a Windows Service instead?
There is a lot of enduser as well as enterprise apps deployed as windows services with embedded web applications (using Apache, tomcat..etc) Under Program Files, Ex: HPE server admin/config tools.
So for Kestrel APP, I would deploy bin in Program Files and write logs,DB,etc under Program Data. it will works without permission issues since dotnet binary has the needed perms.
I have a module layer (embeds a framework) within my application to serve as a generic logging service to several services like Fabric, Mixpanel etc.
This module has a target dependency with the main app target.
I am initializing Fabric in the main app target's AppDelegate and later making calls to the Module layer for sending custom logs of this sort:
`CLSLogv("%#", getVaList("Some Log"))`
This however does not work unless I explicitly initialize Fabric in the Module layer
`Fabric.with([Crashlytics.self()])`
(The same way I've done it in the AppDelegate.)
I have NOT added a run script phase for Fabric in the Module target.
My question is, is this needed really since the module is a target dependency to the main app target and it already initializes Fabric in its app delegate?
If it is needed, is this going to cause any issues?
Is it possible for me to write my own server and use that on pythonanywhere? I saw in the wsgi file that it just imports app as application from my source. Can I just supply an object called app that will behave in ways it expects? Where would I find all the info I need to make my own socket server work on pythonanywhere?
Yes and no. PythonAnywhere only supports WSGI applications, so you wouldn't be able to build your own socket server. But you could build an application that implements the WSGI protocol, without using any third party framework...
Here's an example of that last...
I have a J2EE application that runs fine and is accessible to the internet. Some of our prospective customers would like to use it, but are unwilling to send their data over the internet.
As a workaround I've thought of providing them with the war file and letting them run it themselves.
The problem is: how do I make it trivial for them to update the application when I make a new version available? The more difficult it is, the less likely they are to buy in.
What's involved in writing an updater that fetches the latest war file from online and updates the web application? Is this even possible?
In the least they would need to redeploy the war file. Most application servers have an interface through which you can upload a new war file. I am in favor of doing this process manually i.e. you send them a war file and they can use the app server's admin page to deploy the new war. This way they explicitly know when they are updating the app. Also they control when they want to deploy a new version of the app and easily roll back to an older version.
I would recommend using Jetty as an embedded solution. I have used a few apps that that use the embeded functionality. It allows you to create a packaged distribution of your application that runs a servlet container out of the box.