I have one service manager app which all other apps on the current mule node use. I want this app to start up first before other apps.
Saw the documentation, http://www.mulesoft.org/documentation/display/MULE3USER/Application+Deployment
which mentions the order will be preserved for apps mentioned in the command line, but in my case, I want to only specify Service Manager app, any other app in the apps folder should be picked up. Since the list of other apps is dynamic, I dont want to specify that.
Is there any way (hack), I can use for my case?
The best option here would be to create a bash/bat script that generate the list of the other apps it got from an ls/dir command and then leverage the -app argumented you pointed out
Related
I Want to create a application which display list of installed application with help of android service.
Which android service to use in this scenario?
It depends on what you want, you can use WorkManager , it runs synchronously in the background, and it is very flexible, espcially if you want to schedule your work. You can also use Foreground Service if you want to show a notification while your app is running. You can use Bound Service if you want to exchange data between an activty and the service.
Before android Oreo, you could useIntent Service, but starting from Oreo, it started to cause an exception. You can also still use AsyncTask but it has serveral drawbacks and AsyncTask may be deprecated in the future.
This is an overview, you haven't mentioned specific details about your app, hope this overview will help choose which way you go.
I wish to distribute my enterprise Worklight application to many different clients.
Basically what I want to do is give my customer the .ipa and .apk files of the Worklight app so that they may upload them onto their own Application Center. The problem is that each application needs to be slightly different in that there are different URLs they must refer to as well as some other properties such as text.
I was wondering if there's a way to have my ipa/apk read from a properties that my client could change on their own without having to rebuild the ipa/apk?
EDIT for clarification:
The application I'm referring to is NOT the Application Center app, it is an application I've built using Worklight that I would like to distribute using the Application Center. I will be selling my application to entire companies rather than single users. Once the company has the application, their employees will need to download it somehow (using the Application Center I'm hoping).
Right now I'm trying to figure out exactly how I will distribute my application to my clients. My application calls services of another application hosted on another server (aka the "URL" I was referring to before, it is NOT the Worklight URL). The problem is this URL will be different per client and as far as I know right now in order to change this URL per client, I must recompile the ipa/apk for each client. This is what I'd like to avoid. If possible I would like to distribute the same ipa/apk to each client and have them change some sort of parameter somewhere to set the correct URL for their environment. It's also important to note this URL does not go through an adapter, and lives directly in the client.
IMO what you are asking for is not possible, be it with a regular native app or a Worklight hybrid app (that is really a web app but enclosed in a native "shell").
Once you produce the .ipa or .apk file, it is closed and cannot (unless cracked) be opened to make changes (that would be a security breach). Using a "properties file" next to the app is obviously not possible either.
You will need to create a custom .ipa/.apk for each customer.
I'm trying to get information about license info of my app and MSDN docs (http://msdn.microsoft.com/en-us/library/windows/apps/hh694065.aspx) advice to use Windows.ApplicationModel.Store.CurrentAppSimulator class for that purposes during development/testing and when submitting app to store replace that class with Windows.ApplicationModel.Store.CurrentApp.
I wonder if there is any way to check in code (javascript in my case) if app is already installed from store so my code should use proper class and I won't have to remember every time I submit update of app to store to replacing those classes properly.
As far as I know, I could not find such thing. In fact, LicenseInfo is what provides information about the store listing.
I use a config.js file to keep settings at place which change between development and production. For example - if your app talks to a service, service URL also will likely change between development and production; the service might be running at localhost for development and for production in azure environment. I keep a bool in here and change by hand.
I have not automated it fully. but it is likely possible. need to dig through the msbuild logs for the build created for the store. if there is configuration setting found, then project can have two config.dev.js and config.release.js and msbuild need to conditionally pick the right file. I haven't looked into this yet.
I think I found at solution as described here WinJS are there #DEBUG or #RELEASE directives? . Not ideal, but works for me.
I have created an application that exposes a OSX service for certain file by adding an NSService entry into my applications info.plist (as in http://www.macosxautomation.com/services/learn/), but I find that upon installing my application on a new machine the service doesn't show up quickly in the finder right click context menu.
I know that this is because pasteboard services hasn't re-indexed the /Applications folder and "discovered" the newly installed service.
I also know that I can force a re-index and discovery by manually running /System/Library/CoreServices/pbs.
The question here is what is the best way to ensure that my service shows up as quickly as possible for users who are installing my application for the first time.
I could execute a system call to "/System/Library/CoreServices/pbs" when my application starts up --If the user immediately starts my application--, but that only partly solves the problem (in addition I wonder if there is a better Cocoa API based way of doing this).
If my application is generally only accessed via the context menu, a user will never think to go out and start the application in the first place. They will only think it is broken when the context menu isn't there.
I am not distributing my application with an installer. I am simply providing a bundle that can be dragged and dropped into /Applications (as I believe Apple usually suggests).
Is there a way to expedite the process of service discovery when doing an installation in this fashion, so that there isn't any period of time where the user is without the newly installed service?
As a side note, it appears that the problem may not exist in 10.8 (or at least be as pronounced). Apple may have made this indexing happen more quickly in their most recent release.
I've actually ended up using
system("killall pbs;/System/Library/CoreServices/pbs -flush");
in one of my apps, just as you describe, though it's a long time ago, when 10.5 was in question as well.
You might want to try this function, however:
void NSUpdateDynamicServices(void)
which according to the documentation acts just like flushing pbs, but is a cleaner solution.
Also, if (according to your description), the app is nothing but a service, consider making it a really just a service - see (Installing the Service)
To build a standalone service, use the extension .service and store it in Library/Services.
We have an Adobe AIR application which could be possibly downloaded from multiple domains. And when it's run, it should connect back to the site it was downloaded from to get data to show to the user.
So far we have a separate application build for each domain with a site URL hardcoded into it. And I wonder is there a way for AIR application to find out at runtime the URL (or at least domain) from which it was downloaded?
What we would like to have is a single downloadable binary served from all different domains, which still can know it's origin URL.
There's no function to retrieve such information, it would just make no sense if you think about it.
The most stable way is to include an external configuration file into the package.
Note that you can use ANT to automate this process for this final deployment.
There's no direct way to do it.
Here are some options which come in mind:
Build different versions for each site (this could be automated)
Let user choose the site at first launch
Try to guess it using using whatever resources you have (timezone, language, etc)
How should this work? The only solution i see (independent from AIR) is that you deliver an extra (properties) file with the application, containing the URL downloaded from. So you dont need to build a separate app for each domain, but only package a different domain-file with it. The app then reads this file and executes some context sensitive stuff.
I am trying to address the exact same issue right now.
It looks like you can modify the install badge to pass parameters to the air app.
From what I gather the values are only passed down on install or launch-from-badge.
Something I plan on researching is that one of the parameters in "AIRBadge.as" is _appURL which is the URL of the page the badge is on. I don't yet know if that value makes it down to the installed AIR app in some way; but it could be a useful property. I'm ultimately hoping that the AIR install process injects that into the application descriptor xml, but I'm not holding my breath.
Check this page out: http://archive.davidtucker.net/2008/01/10/air-tip-5-passing-arguments-to-an-application-on-install/#
When the user downloads, you could store their IP address in your central DB. Then when the app is installed and runs the first time, the app could hit your central DB to match up their IP address with the server they downloaded from.
A cookie with a specific name being stored on a download page, and the AIR app looking for that? Though that might not work for direct downloads. It might also be hard to pull off since knowing the specific browser used to download it would be an issue.