Is it possible to run multiple instances of same application on Windows Phone 7.5 ? When I deactivate current instance and try to run a new instance via Start menu, the backround app disappears, and the new one starts in foreground with initial screen.
Is Application State preserved between such "restart" ?
No, it’s not possible to run multiple instances of an application in WP. When you start the application as you describe it counts as a restart of the application and no state is saved. Have a look at http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92).aspx for detailed information.
When you start an instance of your app and then deactivate it (by using the Start button), you have the chance to save the app state (there are Deactivated events you can you for this)
So, when a new instance is launched from the menu, the previous instance of the app gets killed and you can at this point just reload the previous saved state (if any!)
Each app can only have one instance as far as I know (from my experience so far).
Related
I try to run an windows 10 application inside a windows servercore container.
The app can run without user input via COM-Interface (and without visible GUI), but it seems that it needs to load a hidden window in the background. When I start it on docker, the application log file indicates that it's stuck on starting this window.
Is there a way to make the app assume it successfully loaded the window?
All information I found so far was about users who want to see the GUI or about Linux/Windows combinations. None of that helped me.
I'm having some architectural doubts about a project (Mac OS X app) I'm working on. It basically consists of two elements: a daemon that runs in the background gathering some data and a viewer used to represent the gathered data.
The daemon should be visible in the status bar (no dock icon) and includes a small menu accessible via the status bar. It saves data in a core data store. One of the menu items is a link which opens the viewer. When this viewer is opened, a normal GUI application should start including a dock icon and menubar. The viewer is also opened when opening the application itself (by double-clicking on the icon).
After some experimenting, I figured out the best way to achieve this functionality is by creating two applications, the main application representing the viewer and a helper utility representing the daemon. One of the reasons I did it this way is that it isn't possible to switch between LSUIElement values instantly to force the daemon/viewer state.
Now I have some questions about this architecture:
Both the daemon and viewer application uses the same core data store to save and retrieve data. When having a multi-threaded application I know multiple NSManagedObjectContext objects are needed to correctly synchronize data. What about having multiple applications using the same core data store simultaneously? Is this even possible without having the risk of conflicts, locks, etc.? How do I guarantee consistency?
The daemon should always start when the viewer starts. I achieved this by simply looping through all open processes and checking if the bundle identifier of the daemon is listed. If not, the daemon is started using NSWorkspace's launchApplication. This works fine. Now when the user quits the daemon, the viewer should also stop. What is the best way for the viewer to be notified of the daemon stopping? I can periodically check active processes and quit the viewer if the daemon is gone but that sounds a bit odd. I would rather choose some kind of notification that I'll send when the viewer is about to close. But since this notification should be sent and captured between apps I don't know which simple notification service is available. Any thoughts?
The application is sandboxed as it will be distributed on the Mac App Store. Starting apps with NSWorkspace's launchApplication causes the target app to run in the same sandboxed environment as the source which I think is not a problem at all because running both applications in the same sandbox feels better and probably is. But imagine this scenario: the daemon is started automatically at login (using SMLoginItemSetEnabled) and the user double-clicks Viewer.app. As the daemon is already running (again, this is checked by looping through active processes) it won't be started. Now we have the daemon and the viewer running in different sandboxes right? Will this cause any problems regarding preferences, core data store, etc.?
I would like to use NSUserDefaults for basic configuration, can I somehow interchange this data between the daemon and the viewer? Again, both applications will have different bundle identifiers.
Thanks in advance for your help, appreciated!
There isn't one right answer to this problem, but here's how I'd approach it:
Both the daemon and viewer application uses the same core data store to save and retrieve data.
Because sharing a Core Data store between processes isn't supported (as far as I know), I'd have the daemon expose an XPC Service. Instead of opening the Core Data store itself, the viewer would use an NSXPCConnection to access the data via the daemon.
Assuming the viewer never runs without the daemon, it can use SMLoginItemSetEnabled, like you mentioned in the question, to register a mach service for the daemon, and then connect to that service.
There's sample code that goes over the details of setting that up here on Apple's website (summary: the daemon needs to be at App.app/Contents/Library/LoginItems/daemon.bundle.id.app), and you might also want to read this blog post that discusses some extra requirements imposed by sandboxing (summary: make extra sure that your Team ID is in the daemon's bundle identifier).
The daemon should always start when the viewer starts.
All set: once you register the daemon with SMLoginItemSetEnabled, launchd will start it (if necessary) when the viewer connects to its XPC Service.
Now when the user quits the daemon, the viewer should also stop.
The viewer can use the NSXPCConnection to find out when the daemon quits. The daemon can also use SMLoginItemSetEnabled to un-register itself before it quits, so that it doesn't get relaunched.
I would like to use NSUserDefaults for basic configuration, can I somehow interchange this data between the daemon and the viewer? Again, both applications will have different bundle identifiers.
Use a suite for this:
// To read or write:
NSUserDefaults* suiteDefaults = [[NSUserDefaults alloc] initWithSuiteName:#"com.example.app.shared"];
[suiteDefaults setObject:[NSDate date] forKey:#"launchTime"];
// Add the suite to -standardUserDefaults to make reading easier:
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
[defaults addSuiteNamed:#"com.example.app.shared"];
To work with sandboxing, the viewer and the daemon must share an App Group. You can even use KVO to observe changes to shared keys.
I'm developing a windows phone app, suppose my app is running, user click start key, my app will bring to background, then next user long press back key, the task manager will be shown. My question is here: How can update the screenshots of my app when it was brought to background? I don't want expose anything of my app outside even in the task manager, could I do it? Thanks.
How can update the screenshots of my app when it was brought to background?
You cannot. And it's not a task manager, but a "fast app switch", allowing the user to easy swap between applications. The screenshot you see, will be the last screen of your application when it was in the foreground.
And your application will not be running in the background.
No - you cannot change the image shown in the app switching UI. This is built in OS functionality.
I am trying to understand the application life cycle.
Scenario: I am launching a blank application; after that I am intentionally coming out of that app and opening a separate app. After some time I look at the Task Manager. The blank app appears to be suspended. Then I launch the blank app again (which was in a suspended state). At that moment, it has to hit the resuming event, right?
1) Why is the resuming event not firing? (Resuming event should be fired because the app is coming from the suspended state into the running state.)
2) Why is the OnLaunched event fired?
3) Is the OnLaunched event fired only when the application starts for first time, or also when being activated after termination?
Thanks in advance.
I don't have much experience with Metro apps yet, but I'll try to answer:
Ad 1) If your application went from the Suspended to Running state (as in diagram in this MSDN article on Metro Application Lifecycle), resuming event should actually fire. I made a few tests in similar scenario and it did. And btw, here's the best description of this event I found:
When an app is resumed from the Suspended state, it enters the Running state and continues from where it was when it was suspended. No application data is lost, as it was stored in memory. Therefore, most apps don't need to do anything when they are resumed. However, the app could have been suspended for hours or even days. So if your app has content or network connections that may have gone stale, these should be refreshed when the app resumes.
Ad 3) Launch for what I understand is just a special kind of Activation (one of the possible entry points to application), which corresponds to transition from Not running->Running. Some quotes:
When an app is activated, for any reason, the system sends the
Activated event.
and
When the user switches to your terminated app, the system sends the
Activated event, with Kind set to Launch and PreviousExecutionState
set to Terminated or ClosedByUser. The app should load its saved
application data and refresh its displayed content.
Ad 2) If OnLaunched was executed and Resuming event wasn't fired, my guess is your app was in 'Not Running state', e.g. it was terminated by the system (Suspended->Not Running) before you re-launched it. I don't know why task manager might have not refreshed this information.
I can answer this one:
1) but why the resuming event is not firing ? (resuming event needs to fired because the app is coming from suspended state to running state )
There is a debug button available for you to force your app into suspended state. In the quick-search of visual studio search for "debug location". This is a debug toolbar that you tap on the "suspend" button when you are debugging. Once you go back into your app (give it acouple seconds before you go back in) then you should get the resuming event fired.
ResumeEvent is not firing because you opened the app from the start screen or from its pinned tile. In that scenario, the app is treated as having been launched again. That's why the OnLaunched event was executed and not ResumeEvent.
To make sure ResumeEvent is fired, wait for 10 seconds after switching to other app, and then go to the top-left corner and bring the app back to the foreground. Make sure to wait the 10 seconds, before then Windows treats the app as running.
Is it possible to create an app the runs in the background? If so is there any samples out there for this?
In Windows Phone OS 7.1 you can actually use Background Agents now to perform tasks in the background.
from MSDN:
Scheduled Tasks and background agents allow an application to execute
code in the background, even when the application is not running in
the foreground. The different types of Scheduled Tasks are designed
for different types of background processing scenarios and therefore
have different behaviors and constraints.
You can use a PeriodicTask or ResourceIntensiveTasks. Read more about it in the MSDN article above.
And here's some sample code for you to integrate background agents into your existing app.
Sample Code: Background Agents in Mango
An application in the foreground can continue to run when the phone screen is locked(not background but...) by setting the PhoneApplicationService.ApplicationIdleDetectionMode property. By setting up your application to run when the phone screen is locked, a user is able to access the application quickly upon unlock. However, when your application runs under a locked screen, it could consume power outside of the user's control. For this reason, your application must minimize power usage when running under a locked screen
At the moment there is no way to create application that runs in background.
True multitasking for 3rd party Windows Phone 7 apps will come as an OS upgrade later this year. However, unless the app has to absolutely run in the background (like Pandora etc.), we as developers share some responsibility in making our apps feel at home with the rest of the OS.
Windows Phone OS offers app developers chances to save state of their applications to give the end users the feeling that it never stopped running; this is essentially the same as in other mobile platforms. As your app is being deactivated/closed, you have the option to "Tombstone" your state so that your users can come back to just where they left with BackStack navigation or future launches. Channel 9 had a nice set of demos & labs around tombstoning, found here.
Hope this helps!