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.
Related
Worklight 6.2.0
Native Worklight App on Samsung Galaxy S4, Android 4.4.2
WLAnalytics.enable();
WLAnalytics.log("some text", new org.json.JSONOBject() );
WLAnalytics.send();
// and also go on to successfully call an adapter
Analytics Dasboard shows the app version and adapter activity. Log Search does not show any application log messages and the dropdown for selecting applications shows "All Applications" only, no sign of my app.
Have I missed some initialisation step? Any other ideas?
** edited to add **
It has been suggested that we should use the method:
WLAnalytics.log("some text");
In our 6.2.0.00 CLI environment there is no such Java method.
The answer is that there a further initialisation requirement that seems to be necessary when working with a pure Native application, these are typically build using the Worklight CLI tooling.
This is the initialisation, note the call to Logger.setContext()
WLAnalytics.enable();
Logger.setContext(this);
Then this works
WLAnalytics.log("My test message2", new org.json.JSONObject());
It's worth noting that the call to WLAnalytics.send() is not necessary in normal running as typically the analytic data is buffered and sent as a piggy-back on adapter calls. However while testing a call to send() does help.
Further, if running in an environment where the Analytics WAR is on a separate machine from the Worklight Server WAR there are additional latencies. Hence testing all of this needs care.
For now, I suggest that you just use the WLAnalytics.log(String) method. There are some clear inconsistencies that need to be dealt with whether it be through documentation or code fixes.
The WL.Logger APIs were originally created to send log data to a custom adapter, which is why they take a dictionary/object for extra metadata. The data sent to the custom adapter could be read as a valid JSON object to run operations on the adapter.
The WL.Analytics APIs mimicked the WL.Logger APIs for the same purpose: parsing the JSON on a worklight adapter. The Operational analytics server came as a convenience to intercept and display some of these logs, but not all of them are being captured as you have learned.
Your questions are all valid though, as none of this is described in the documentation. In future releases, we may make use of the extra JSON object passed into the API in the Operational analytics console, but for right now they only serve their original purpose of sending the analytics to a custom adapter.
I am working on a Finder Sync Extension for OS X and want to use a background XPC service.
I can start in the main app and have it launch the XPC and run correctly but nothing happens when I attempt to access it from the Finder Sync. both the finder sync and the XPC are their own bundles so that may be the reason why. What I am wanting is for the finder sync to talk to the XPC about the status of the files and the main app to talk to both the finder sync and XPC about the list of folders to watch.
Has anyone had any luck with this? Is there a better way for a on demand background service? Is it possible to talk between two XPC services?
Working with some Apple Engineers they realized this was a problem and suggested using a LoginItem until a better solution is in place.
So, it is sort of an XPC service, just one that constantly runs. XPC communication is available to both extension and host app.
It works, although it is not the most ideal solution. I recommend the apple sample project that deals with XPC login items for an example of how to get this working.
I implemented MainApp <-> FinderSyncExtension communication via CFMessagePorts. See my question and answer for some details:
How should Finder Sync Extension and Main App communicate?
You can't communicate directly between the container application and the extension, but you can do it indirectly using shared resources. I did exactly what you have done which is completely incorrect. I hope you store the file status in the database, if not store it and then share the database between the container application and the extension. I know, why do you want to use XPCService as it is in the Apple's FinderSync Doc. (Actually for the performance reason, Create a NSXPCService to the extension and from the XPCService, access the shared database)
For more information about sharing database:
http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios-8
Hope this helps you,
I had stubbornly ignored utahwithak's answer and tried to get it to work anyway. I eventually had to ask a similar question on Apple Developer Forums and finally received a definitive answer on why connecting the Finder Sync Extension to an embedded XPC service is not a viable system design.
Essentially:
Finder Sync Extension essentially behaves like a third party app in that it does not have the same scope as the host app to be able to establish an XPC connection with the embedded XPC service.
utahwithak's answer is correct in that in order to allow the Finder Sync Extension to communicate with the XPC service, it needs to be an XPC login item. However there are some caveats to this:
This seems to be an accidental feature. Not sure if it's something that might eventually be fixed/removed
The XPC will have to be always running even if it doesn't need to, by virtue of being an login item
If it's a login item, the user will need to explicitly opt in for this feature and be able to opt out.
Source:
Establishing an NSXPCConnection from a Finder Sync Extension to an XPC Service
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
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.
I have a dynamic library, I intent to inject in running application & newly launched applications.
I can inject it in running applications with the help of a process running with root user permissions.
Now I am trying that library should get loaded as soon as application is launched. I know one such library capable of doing this called, application enhancer. I am looking for similar behavior.
Does anyone has an Idea how can this be achieved?
Look at SIMBL agent code. It adds a observer to application launch notification and then injects. You can follow the same approach.