I was wondering if there was a way that I could get notifications of when a system process from /usr/sbin starts and finishes. Is it possible to attach NSTask to the running process without launching a new one? Preferably without polling please :!
For UI process you can use NSRunningApplication. You can observe the "terminated" property to know when it finishes. You can listen to NSWorkspaceWillLaunchApplicationNotification to know when an application will be launched.
Since you're not running a UI application the above probably won't work. You'll have to use more low level BSD calls. Here's an example of how you can know when an process terminates:
https://developer.apple.com/library/content/technotes/tn2050/_index.html#//apple_ref/doc/uid/DTS10003081-CH1-SUBSECTION10
Good luck!
Related
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
Coming from Android/WP7 and having been involved in Symbian projects by the past, i would like now to exactly understand the Symbian App life cycle. I want to understand how the Apps are killed.. if they are..
I found this:
"The Symbian platform is a modern preemptive multitasking operating system. Applications are created in their own process, running in a single main thread. The kernel preemptively schedules all threads in the system, based on their priority. While it is possible to create secondary threads, Symbian strongly encourages applications to co-operatively multi-task using active objects. ". Ref-link
"(..) applications may be up and running at the same time and the user may switch between active applications. When a asynchronous event occurred, running application is moved to the background but it remains active". Ref-link
It seems to me that the Apps are never killed, even when they are in background..
My question is: If the system does not kill them, how the system deals with the RAM issue? What about the possible battery drain? Does it mean that Symbian allows starting each single App, till there is not enough memory? Is there a specific meaning about the use of the Cancel/Back key that might destroy the App in certain conditions?
In UIQ framework i remember a lowMemory() call-back, but one never used that..
Thanks, for your help..
Symbian Apps are indeed never killed. That allows you to have several apps running in parallel without problems. Every app should of course provide the Exit command that closes the app. Back/Hide command just leaves the app runnning and takes user back to the menu. Also every well-written app should also manage his background tasks and allow to stop them when needed.
FYI, in Symbian there might be several background tasks running that are automatically started when phone is powered on. You can get the list of them when asking for a list of processes. You can also kill any process or app if your app has enough capabilities.
I want to use NSWorkspace to check if application is launched or closed.
But the process is Launch Daemon and Apple documentation says its not thread safe.
However, the part of code that makes use of Workspace will not be executed at start up or login time. It will be executed after some commands received from other application via BSD communication and process is background process without UI?
Is it safe to use Appkit framework in this situation? Only NSWorkspace API and no other? Alternate solution is Polling? What is your suggestion?
Generally you can use any code that isn't thread safe, as long as you are only doing one operation of whatever the unthreadafe operation is at any given time. I would go ahead and try it, and just be aware that whatever you are doing you can't do concurrently, if you absolutely need to do something concurrently you can try throwing a couple of #synchronized blocks around the code, either in callbacks of a long running background process, or delegate calls.
I am developping an objective c application and I would like to detect non responsives windows even if they are not own by my application.
Is there a way to be notified when a such case occurs?
Thanks in advance for your help,
Regards,
I think the only way to detect whether an window is hanging is to detect when its application is hanging. And I think the only way to - reliably - do this is to talk to it. Send it some inter-process message and await an action. I think that's exactly how the system detects it: there is some delay before the beach ball appears. And this is because the system sent a message and received no answer in x seconds.
What kind of message that might be is hard to say. Must be something that goes through the main event loop but can be sent by every application. I'm sure Google will be of some help finding it. I'm no pro in inter-process communications and would have to search as well.
You can use the Instruments application with a "Spin Monitor" instrument track. If you set it to monitor "All Processes", it will capture stack traces whenever an application hangs (doesn't process the main event loop for a long time).
I have a windows mobile application
I have noticed that it properly terminate on exiting, they simply minimize and take up memory. I need to cehck whether any instance of the same application is running in the taskmanager.If exists, i need to kill the process.
I need to write small app that would loop through all open application processes and terminate the required one.
Does such an application exist? If not, which onecould I use to write my own app for it?
Typically this is not how you solve this problem.
You should hold a 'mutex' in your application, and when it launches a second time, you first check this mutex, and if it's taken, you know your app is already running.
Find an appropriate global mutex to hold, and then check for it (I'm not sure what sort you can use on whatever version of Windows Mobile you are targetting, but a trivial search should help you find the answer).
If your app shows an [X] in the corner that's a Minimize button. Change the MinimizeButton property of the form and it will become an [ok] button which will close it.
The CF under Windows Mobile already enforces application singleton behavior. If the app is already running, the CF will look for it, find it, and bring it to the fore for you. No extra work needed.
If you really want to find the process and terminate it, that's done with the toolhelp API set. You can P/Invoke it or use the classes in the Smart Device Framework.