I have a requirement to create an ATL COM service which does some operation in background always. I want to know, can we create a service in Windows-8 Metro style mode ?
if so, how to create the service ? if not, what is the alternative solution for this ?
Please share your taught on this.
I think you can't have a always-on service running in the background in Metro-style apps. The WinRT framework discourages the use of apps that are always running - to conserve battery and provide a good user-experience for the user. Only one (or two if you include snapped-mode) app can be active - the one in the foreground - all other apps which are in the background are suspended and don't get any CPU time.
You can, however, use BackgroundTasks to do something periodically or when a system event occurs.
Related
I am developing two apps. Main app is a regular cocoa application to show data in core data. The other is a LSUIElement agent which in charge of updating the data using by main app stored in core data. These two apps should be in the same bundle.
Now I have no idea how to notify the main app to refresh its view from core data, after the agent app updated data source. They share the same NSPersistentStoreCoordinator.
I want to use NSDistributedNotificationCenter at first. But it seems no to be efficient and elegant.
Is there any best practice for communicating between processes or applications on mac os?
Thanks for any helps or suggestions.
You can use Distributed Objects.
The Objective-C runtime supports an interprocess messaging solution
called “distributed objects.” This mechanism enables a Cocoa
application to call an object in a different Cocoa application (or a
different thread in the same application). The applications can even
be running on different computers on a network.
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.
So I've read that in iOS, all timers will pause when your app is running in the background. I've also read that you can run tasks in the bg using beginBackgroundTaskWithExpirationHandler (like so).
What I am trying to achieve is to call a method once every 3 minutes, and another method a fixed-amount of time before the first one. I have managed to do this within one NSTimer which repeats in a way that lets me do this. It works fine but is obviously disabled (or paused) when the app is in the background - I can only assume because of the reason described above.
Does anyone know if there's a way to run a timer or at least call something after a specific amount of time so I can do this?
Basically if you want to continue running active in the background you have to meet one of the following requirements. From the Apple docs:
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must
request specific permissions to run them in the background without
their being suspended. In iOS, only specific app types are allowed to
run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Apps that implement these services must declare the services they
support and use system frameworks to implement the relevant aspects of
those services. Declaring the services lets the system know which
services you use, but in some cases it is the system frameworks that
actually prevent your application from being suspended.
http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24
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 may have gone crazy... but I am hoping there is a way to do this.
I have a base class that has event handling in it. My console application is running my workflow. Part of that workflow is to raise events at specific intervals in a separate thread to broadcast the workers' current state (a heartbeat I have heard many call it).
I also have another program in the same solution that is a windows form that I want it to be able to listen to what is going on in the console application so that it can display the worker states. I have tried running both at the same time and verified the events are triggering, but the monitor is not finding any of the raised events.
I am fearing that there is no way to do this, and I will need to go to a database logging method or something else... but in the off chance someone knew how to communicate between applications with event (or event-style) logic, I would appreciate it.
Currently the applications are running from the same location. The goal is that the monitor application will eventually be attached with a broadcaster for our network so that our workstations can monitor for certain worker states without being logged into the machine and the main monitor will show us the full status of all the workers.
Please let me know if I need to expand/clarify this, have a 2-year old watching Star Wars while I type this so I may have missed something.
There are several ways: using remoting, custom windows messages and named pipes. One way is How to use named pipes for interprocess communication in Visual Basic .NET or in Visual Basic 2005
Here's a remoting example: Simple Inter-Process Communication In VB.Net
Here an example of custom windows messages: VB.NET, VB6 and C# Interprocess communication via Window Messaging
Perhaps the most 'up-to-date' way is to use WCF Callback Channels: Using Callback Contracts in WCF for Asynchronous Publish/Subscribe Event-Style Communication