Async cancellabel task - windows-phone-7

I want to implement a behaviour for my application that at the start checks a webservivce if any news are available. If there are news available, pop open a screen to show to the user. If there are no news available, or the user quits the application (or starts the game) i dont want to bother the user but instead cancel the task to retrieve the news item
I thought it would be a breeze doing this with the Task Library but unfortunatly it is not available in the default loadout on Windows Phone (or is it?).
I think the key here is the cancelable part. I certainly know how to start an async op, but what is the best practice for hte cancelable part?

The Task Parallel Library is available for Windows Phone, in this NuGet package: System.Threading.Tasks.
But I don't really get why you care to cancel the task. If the user quits the application, the task end, and if you do another action, nothing happens.

Related

Add a close button for a task module in ms teams

I am investigating if it's applicable to have a cancel/ close button on our html page inside taskmodule so it can actually close the task module?
Yes, it's entirely possible to do this. Basically, in order to close your task module in any way, you make a call from within the web page (in script), to:
microsoftTeams.tasks.submitTask
submitTask takes two parameters. The first is any object you want to return back to the caller (whatever opened your task module). For instance, if you have a Tab in your app, and the Tab opens the task module to app a new entry to a database, you could pass that new item back to the opening Tab by passing it as microsoftTeams.tasks.submitTask(newItem);
You can see more about this here.
If you have nothing at all to send back, you can simply call microsoftTeams.tasks.submitTask(null);. In this case, it will do nothing but close the task module, which sounds like what you're trying to do.

Adding alarm from BackgroundAgent (not working, looking for workarounds) - Windows Phone 8

I am developing an application which needs to notify the user at a pre-difined time with the help of background agent,
So I tried to add an Alarm, but according to MSDN's "Unsupported APIs for Background Agents for Windows Phone" all the methods regarding Microsoft.Phone.Scheduler (Add, Remove, Replace) are not supported (when ever i try to call Add method from background agent it gives error "BNS Error: The API can only be called from foreground app".). I tried to add the alarm when in foreground and then play with the "BeginTime" property and use the Replace method from the my scheduledTask (specifically, PeriodicTask which runs its code every 30 minutes) but to no avail, it did nothing.
What is important for me is to notify the user (with longer-enough sound) at the date and time that decided in the background-agent's Invoke method (My class derives from ScheduledTaskAgent and override the Invoke method), So I'm looking for workarounds. If there would be a toast that appears at a pre-defined time that would be ok somehow. Or maybe a toast that stays for a longer time on the top of the screen (from the moment the scheduled-task came up with an instance of DateTime until[and even after] the time that specifiend in this DateTime instance).
Please confirm, is it only the background agent that can calculate the correct time for the alarm to go off?
Assuming this is so, you can notify the user by sending a toast (which will also vibrate the phone, unless user has disabled that) and updating a tile pinned to the home page. These are both permitted APIs. So the toast message could tell the user to go look at the tile, which could have specific details about the alarm. The tile state will persist until you change it. If your foreground app would pin the tile for the user, that's a start. If you can then get the user to move the tile to the top of the screen, so it's always visible, you should be all set.
Considering that the alarm time might happen when the user is not actively using the phone, perhaps you want to do the toast plus a notification on the lock screen (as well as updating the tile)? That will provide another visual indication, though, again, it depends on the user configuring a lock screen.

How can a Mac app determine the method used to launch it?

I have a Mac OS X application that is also a protocol handler (just as, for example, Safari is a protocol handler for the HTTP and HTTPS protocols). So when a user clicks a link of the form myscheme://some-kind-of-info in any application at all, my application launches to handle the link.
Now I need to be able to determine if the application was launched by such a link click, or if it was launched by any other method. In other words, it was launched by any method besides a link click. (In those cases, I want the app to stay open, but if it was launched by a link it should quit and ignore the link. This way it only operates when already running.)
Is there some way within the app at startup to introspect and find out that it was launched by a standard method rather than by an AppleScript GetURL event? I'd like to find out through a documented method, rather than - for example - just have my app only open these links after it's been running for a half a second.
You can register a handler for each of the possible Apple Events you'll get on launch, and make note of which one you receive first.
If the application is launched without documents, you'll get kAEOpenApplication.
If it's launched with documents, you'll get kAEOpenDocuments (or
kAEPrintDocuments).
If it's launched with a URL, then (obviously) you'll get kAEGetURL.
There's also kAEOpenContents, but I wasn't able to trigger it easily in my test app; it's probably worth supporting no matter what.
How Cocoa Applications Handle Apple Events documents all of this stuff.
There is one error in there, though; it says that AppleScript's "launch" will send kAEOpenApplication. It won't, it'll send ascr/noop (kASAppleScriptSuite/kASLaunchEvent, defined in ASRegistry.h). I couldn't get the usual Cocoa event handler mechanism to trap this event, so you may need to do some more digging there.
One way you can check if the event is sent at launch is to register the event handlers in your application delegate's applicationWillFinishLaunching: method; they should deliver by the time applicationDidFinishLaunching: is invoked. With that method, you could potentially only check for kAEGetURL.

netServiceBrowserDidStopSearch not called

I'm now writing a Bonjour service listener class, according to the document here:
Currently, it seems working, I can receive "netServiceBrowserWillSearch:" and "didFindService:moreComing:" correctly. However, after a long wait, I cannot receive " netServiceBrowserDidStopSearch:" or "netServiceBrowser:didNotSearch:". Therefore I don't know that is the proper time for my delegate class to stop showing some UI.
Could anyone have an idea for this? Thanks.
NSNetServiceBrowser doesn't stop browsing (and call the -netServiceBrowserDidStopSearch: delegate method) until you explicitly tell it to by calling -stop. After it's found the initial services, it continues informing you as new matching services are added or old ones disappear.
How you handle this depends on how you want your app to behave. If you have a window that continuously shows the available services (e.g. like the Bonjour window in iChat), then it's best to let it continue, and contiuously update the list in response to delegate messages. If you've got more like a dialog that gets populated and then goes away once the user makes a selection (e.g like the system Add Printer... dialog), then you want to keep the browser running while it's displayed, then call -stop once the user dismisses it. If you're waiting to find just one specific service, then you can call -stop once you've found and resolved it.

Session 0 Isolation

Vista puts out a new security preventing Session 0 from accessing hardware like the video card, and the user no longer logs into session 0. I know this means that I cannot show the user a GUI, however, does that also mean I can't show one at all? The way my code is set up right now, it would be more work to make it command line only, however if I can use my existing code and just programmatically manage the GUI it would take a lot less code.
Is this possible?
The article from MSDN says this:
• A service attempts to create a user interface (UI), such as a dialog box, in Session 0. Because the user is not running in Session 0, he or she never sees the UI and therefore cannot provide the input that the service is looking for. The service appears to stop functioning because it is waiting for a user response that does not occur.
Which makes me think it is possible to have an automated UI, but someone told me that you couldn't use SendKeys with a service because it was disabled in Session 0.
EDIT: I don't actually need to show the user the GUI
You can show one; it just doesn't show up.
There is a little notification in the taskbar about there being a GUI window and a way to switch to it.
Anyway, there actually is a TerminalServices API command to switch active session that you could call if you really needed it to show up.
You can write a separate process which provides the UI for your service process. The communication between your UI and service process can be done in various ways (search the web for "inter process communication" or "IPC").
Your service can have a GUI. It's simply that no human will ever see it. As the MSDN quote suggests, a service can display a dialog box. The call to MessageBox won't fail; it just won't ever return — there won't be anyone to press its buttons.
I'm not sure what you mean by wanting to "manage the GUI." Do you actually mean pretending to send input to the controls, as with SendInput? I see no reason that it wouldn't be possible; you'd be injecting input into your own program's queue, after all, and SendInput's Vista-specific warnings don't say anything about that. But I think you'd be making things much more complicated than they need to be. Revisit the idea to alter your program to have no UI at all. (That's not the same as having a console program. Consoles are UI.)
Instead of simulating the mouse messages necessary to click a button, for instance, eliminate the middle-man and simply call directly the function that the button-click event would have called.

Resources