i am working on an application for windows mobile 6.5, which need to know whenever any application is launched.
Is there any way to get notified when any application is launched?
Can we do something like this?
ManagementEventWatcher
I don't think there is a way to get an event when a new process is created. However, you can get a list of processes using the ToolHelp API, so it should be possible to get the necessary information, but you need to continuously poll in order to detect when a process is started.
Access to the ToolHelp API is not provided in compact framework but you can use the native API instead. An example can be found here: http://msdn.microsoft.com/en-us/library/aa446560.aspx
I think you're going to have to poll for the available processes using Allan's suggestion. I've worked on custom Windows CE shells, and they use the RegisterTaskBar(HWND) to receive notification when windows are created, raised, and destroyed. But that doesn't means every process has a window.
Related
I am trying to make a chat app using XMPP protocol. The app is working fine except it doesn't show message notification when the app is in background. In Android I have used a Service for this purpose, however in Windows Phone I couldn't find anything similar to this.
I am trying Background Tasks for this, but as far as I have understood, they're made to run on prespecified trigger and I cannot add any custom trigger to it. In Android I have put my socket connection and parsing message calls in the service itself so that they can run on background too and the socket doesn't get closed even when the app is stopped.
So my question is, is there any similar way to do it in Windows Phone 8.1 (WinRT, not silverlight) or if Background Task is the only option, can you suggest a way to implement the notification functionality. I don't need the exact code, I just need a push to the right direction.
First: You cannot run a network connection in background.
Suggested way is using PushNotifications:
Either directly with a Toast Notification
Or with a PushTrigger to handle a Raw Notification, work out what to do
with it (who was it from, prepare data, etc.) and then create a ShellToast from it. Adds flexibility and improves user experience, but is quite complex.
Known downside: You have to use a server.
Only workarounds: Background-Tasks that checks for new messages about every 30 Minutes.
In Android, an app which is not currently running can be notified when certain event happens (like wifi scan results available, boot process completed) through Broadcast Receivers mechanism. Is this possible in anyway so that the wifi/geo triggers can be invoked even if the Worklight app is not running, including not running in the background?
Regarding wifi/connectivity changes notifying your app, that looks possible since it is a standard system event. It would likely take custom native code since you'd need to implement a broadcast receiver. And you'd need to register your receiver in your app's AndroidManifest.xml file. Take a look at http://developer.android.com/reference/android/net/ConnectivityManager.html and http://www.grokkingandroid.com/android-getting-notified-of-connectivity-changes/
Regarding geolocation triggers, it is unclear what sort of triggers you are looking for. This is all I see in the Android docs: http://developer.android.com/reference/android/location/GpsStatus.html and the standard broadcast actions at http://developer.android.com/reference/android/content/Intent.html#constants
If you are looking for something like geofencing, it would take application logic to determine when to fire events, so that means an app or service needs to be running. So although your broadcast receiver's onReceive() method can get called upon a geo event, who is going to fire that event?
Having the triggers activate when the application is not running at all (not even in background) isn't supported through the Worklight APIs.
You could try and use Worklight Android Native SDK together with cmarcelk's suggestions. Or you could use the Worklight Android triggers within a native service, together with the Broadcast Receivers mechanism so that it will run automatically on boot. You could then use an Intent to open the application from the trigger callback.
I have to design and implement a way to deal with long running processes in a client/server application. A typical long running process would/could take 2-3 minutes. I also need to report progress to the UI in the meantime and keep the UI responsive.
Having these in my mind I though of a few solutions:
One async request to start the process which starts the server-side process and returns an assigned LRPID (Long Running Process ID) then poll periodically from the client using that LRPID. (Pro: simple to deploy, no firewall messing around Con: Unelegant, resource consuming etc.)
Use a duplex binding (such as NetTcpBinding) and initiate callbacks from the server as progress is being made (Pro: Elegant, efficient, Con: Deployment nightmare)
[Your suggestion???]
What would be your take on this?
Here is a post by Dan Wahlin about how to create a WCF Progress Indicator for a Silverlight Application. This should be of some help.
If you do not want to have to worry about the client's firewall, etc... I would probably go with your first solution and use a BackGroundWorker to make the call in order to keep from blocking the UI thread. I did this recently for an app where a request to generate a report is put on a queue and is retrieved once it is done. It seems to work well.
Another way (without having to change the WCF binding) is to use a WebBrowser control in the WPF client, and SignalR to post progress messages from the server to that control.
Note that to avoid javascript errors that happen with the WebBrowser control (because by default it seems to use Internet Explorer version 7 which doesn't seem to be compatible with jQuery.js), you will need to add keys to the registry on the client machine to change the default for the client app to use IE10 or later - see http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version).
This could be a deployment nuisance (because admin rights seem to be needed - eg on a 64 bit Windows 8.1 pc - to add the registry keys).
Also, it still seems necessary to call the long running WCF method in a separate thread, otherwise the WebBrowser control doesn't seem to update its display to show the SignalR messages it is receiving. (This makes sense because the UI thread would otherwise have to wait until the WCF call had finished).
But I mention it as an alternative approach using a newer tool (SignalR) :)
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.
I have an application that needs to "poll" a webservice to see if the user has any new messages waiting. I have no control over the webservice so I cannot switch to a "push" mechanism, I'm stuck making a request every X number of seconds to see what's available.
I am using a System.Threading.Timer to make the request every so often, but am encountering a few problems. The biggest is that it stops running when the phone is sent into "standby" mode (screen off, but still able to get calls and email/txt notifications).
I'd really like it to behave like other background applications. What can I do to make it work without being too big of a drain on the battery?
Hate to answer my own question, but I was pointed to this, which was able to perform even when the device is asleep. Looks like it's working perfectly.
There's nothing you can do, AFAIK. Standby mode is meant to suspend the processor to save power, and there's no way your code can execute if the processor isn't running. There are things your application can do to prevent the device from going into standby mode, but this really isn't advisable at all.
Yep. Similar to how MusiGenesis has answered, you won't be able to do much without keeping the device up and running. Similar to how some phones will notify that "Game/App Running" and thus your battery is being slapped around.
What about writing an interface from your phone to leverage text messaging (which still works) and get it to send a text message to the web service? Would that be possible? I'm guessing that sort of method might also stop running, but I figure it's a thought?
I'm not sure about compact framework, but in Win32 there is WaitableTimer that can wake up computer from standby. It takes some native calls though as there's no wrapper in .Net.
Although you can't modify the webservice, you might be able to add a second "shadow" webservice in between your clients and the original webservice. The shadow webservice could poll the original webservice and then "push" anything it finds out to the PDAs.
I think you might still have the same problem, though. I've never done "push" from a webservice, but I think it's basically implemented by having the client make an initial call to a webservice method that takes a delegate to a method in the client, which the webservice then hangs onto. When the webservice needs to push something, it calls that delegate. If the client has gone into standby mode in the meantime, the attempt to call the delegate from the server will fail.