I have a process that runs as root in the background. When a certain even occurs, I have it pop up an NSAlert with an NSTextField on it so the user can provide some info. However, the user is unable to click on the TextField or type anything into it. I can drag the Alert box around and click on the buttons on the Alert just fine.
I'm guessing this is because my process is running as root and not the end user account that is logged into the machine. Is there a way to easily get around this without spawning a separate process as the user and piping back the info via Distributed Objects or the like?
The best thing to do is to have your UI stuff running as the current user, not only because of problems like this, but also because running a GUI app as root poses a large number of security risks, and in fact there have been a number of security vulnerabilities in the past which were caused by some AppKit-enabled process running as root.
With that said, XPC is the mechanism you want to use to communicate between the root tool and the GUI app, not Distributed Objects, which is quite antiquated and has a number of issues of its own.
Related
When we deactivate a WP app, it can be tombstoned and terminated later by the OS. I need to save some unsaved app data to a persistent storage when the process is terminated, but not before this. Obviously, the Deactivated event cannot be used for this purpose as it is raised immediately when an app is moved to the background; the Close event is also not the event we need as it si not raised when the app process is terminated by the OS. Is there a special Windows Phone app event for that, something like Application_Terminated?
The problem is that the operating system only tombstones your app when it is under severe resource pressure. At the time it is not practical to wake up the app and run app code because it might risk whatever is currently in the foreground. This limitation exists on all modern mobile operating systems (Android, IOS included). This is just the cost of operating in a battery/resource friendly environment.
Having said that, it sounds like your backing store does not disambiguate between data the user "saved" and data that is just being cached until the user can finish the transaction. It would be useful to build the idea in. Think of it the way some of the smarter web sites on the internet now work. You can navigate away while you were in the middle of entering data and when you come back the site presents you with the partially filled form. The site understands that you weren't "done" but it respects the fact that you had provided some of the information you'd need to get "done".
What I'm saying here is that the problem is easily fixed by understanding and accommodating the way your users are likely to use the app. Thinking of your app like a web site (at least in this context) helps out things into perspective. Sorry about the longish answer. I hope it helps :)
There is no such event. You should save your state on Deactivated so that if the application is removed from memory (tombstoned) you can set yourself up again upon reactivation. If your problem is figuring out whether or not you need to restore state on Activated, check out the ActivatedEventArgs.IsApplicationInstancePreserved flag (http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.shell.activatedeventargs.isapplicationinstancepreserved(v=vs.105).aspx). This flag tells you whether your app was tombstoned. If it wasn't, you can throw away the old state or overwrite it the next time you are deactivated.
I'm writing a small Mac application (in Obj-C) which runs the following command:
system("killall Finder");
I wanted to see what would happen if I sandbox the app (as sandboxing will be required on June 01), and the app wouldn't work. I got the following response:
killall: warning: kill -TERM 6524: Operation not permitted
Is there any way to get around that? As in a specific entitlement to add or another way to run the command?
Thanks in advance.
Your app completely goes against the spirit of the sandbox, so there's almost no chance that the MAS reviewers will accept it. Also, you may be surprised at what "defaults write com.apple.finder" does from inside your sandbox—basically, nothing useful. You'll have to use a temporary exception entitlement to home-relative /Library/Preferences/com.apple.finder.plist, use some non-sandbox-affected API to get the path to home (e.g., getpwent()->pw_dir), and load and save the plist directly. And then you'll discover that there is no way to call on a non-child process from a sandboxed app, period, no way around it—and if you try to system killall, it ends up running inside the same sandbox as you, and therefore has the same limitations.
However, you asked a specific question as to whether there's a way around that system killall failing, and there are at least three (not counting holes in the sandbox which have either been plugged by 10.7.4 or will surely be plugged soon):
You can create a helper app that isn't sandboxed, that does the killall for you. The only two App Store-approved ways to do this are XPC and SMLoginItemSetEnabled. And you're not allowed to enable the helper without the user explicitly telling you to do so.
You can send Finder an Apple Event asking it to quit, instead of signaling it. The easiest way to do this is to execute the Applescript 'tell app "Finder" to quit'. At least for 10.7.3 and earlier, you'll need a temporary exception entitlement to send Apple Events to com.apple.finder. (There may be different mechanisms for future OS versions, but nobody can discuss them outside the NDA forums.)
You can send an Apple Event to some other process—like System Events—to kill Finder on your behalf.
And so on.
If you have a good reason you can still kill applications like this:
How can I terminate my app in a helper app with sanboxing enabled?
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
Good morning. I have an application that queries a REST source. It needs to run continuously, capturing data which is refreshed every five minutes, without fail. My solution is Task Scheduler, where the app is set to launch on server boot. Once launched, it uses a timer to re-query periodically. The TS task is set to repeat every five minutes, with the check box "if app is already running, do not start another instance," so if the app crashes it should restart automatically within five minutes.
This works fine, but TS launches the app invisibly. I'd feel warmer and fuzzier inside if I could see the app, just as if I'd launched it myself. Also, if I need to close it (e.g., to post a new exe), I have to kill it via Task Manager; ouch. I've gone over the TS options a dozen times for some kind of "launch in foreground" option, but none exists. Can anyone tell me what I'm missing?
Notes:
From my web searches, it's clear that an app is only allowed to interact with the desktop if it's running under the same user account... but it is, I'm using my AD account, not SYSTEM or another local account.
It's acceptable for the app to only be visible to me, though even better would be if other users could also see and interact with it. I suppose the only way that would work would be if each user had their own monitor app which just reflected results exposed from a single invisible app which actually did the work.
I get the same behavior if I start the TS task manually or if it launches on boot automatically.
"Run only when the user is logged on" won't do, as I need it to resume even if the server restarts in the middle of the night.
I had been launching the app with a little PS script, so I could send a notification if the app failed to launch at all, but there's no change if I have TS launch it directly.
I suppose the proper solution would be to write this as a service. I put some time into that, but I haven't done that before and couldn't get it running. If the consensus is that that would be a better approach, I'll give it another try.
Any ideas? Thanks!
If you set the task to "run only when user is logged in" then it will be visible for you if you uncheck the "hidden" box.
If you have the "Run whetever user is logged on or not" choice checked, then it will be hidden even if you uncheck the "hidden" box. The implementation of Task Scheduler doesn't allow you to run programs in the foreground if you aren't logged in.
To solve this you can create a user that does AutoAdminLogon and start the application with the Startup script. By doing it this way, you will make the server log in with this user on boot and start the program you want.
If you then want to check how it's going or so, you can login as that user or switch to that session.
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.