What I need is to provide an exit confirmation dialog for my mobile app.
The dialog is to appear when users taps the Back button on their phones. I know two options i.e.
"Press back again if you really wish to exit" type of message.
"Do you really wish to exit + Yes/No" dialog.
I am exploring the second variant.
The problem I see primarily concerns the windows store apps.
If I show it and give user time to decide than I have already cancelled the default behavior.
For windows store app it is Windows.Phone.UI.Input.HardwareButtons.BackPressed i.e. I've set the Windows.Phone.UI.Input.BackPressedEventArgs.Handled to true.
What do I do if user clicks Yes i.e. confirms his intent to exit the app?
I've read the Metro App can no longer be programmatically killed and do understand that programmatically closing the windows store app is considered "unacceptable". Does it mean that such an exit confirmation dialog is banned for windows platform?
What about Android? Is it ok there to exit the app programmatically?
Formally Windows Store Policy does not allow such behavior:
Where applicable, pressing the back button should take the user to a previous page/dialog. If the user presses the back button on the first page of the app, then the app terminates (unless it is allowed to run in the background).
So you might be lucky to pass certification, but it is definitely not recommended behavior.
For "testing purposes" there are two methods exposed in API to programmatically exit application:
High-level Application.Current.Exit()
Low-level CoreApplication.Exit()
Technically you can use one of these methods to force application to close after user confirmed to exit. But there is no guarantee that you will pass certification.
For Android there are also guidelines. In particular the Core App Quality guide says that
App does not crash, force close, freeze, or otherwise function abnormally on any targeted device.
There are various discussion on Stack Overflow on how to correctly close Android app (example).
From my experience such apps do path certification, but Play team may choose to not promote them as they don't follow official design guidelines.
You could by using the onBackPressed callback method and showing a dialog, but as Jason said, it is a bad practice on Android too.
Let me explain why.
The OS has a PackageManager which manages every apps on the device. Apps have a priority level. That's why the phone app opens when it receives a call and yours get paused (in background). If the active app with the highest priority level needs memory or if your device encounter any problems, it can destroy your activities and then close your app automatically.
Related
I have developed an app for the Microsoft store. The problem is, that I can not upload this app to the store, because I've used the confirmAppClose capability, to detect when my app gets closed.
Does anybody know another way to detect when my app gets closed?
Does anybody know another way to detect when my app gets closed?
I am afraid there is no way to detect or prevent the app from exiting without using the confirmAppClose restricted capability. That's why it was introduced in the first place.
When it comes to store submission, you'll need to provide additional information on the Submission options page in order to receive approval for an app that uses a restricted capability.
We are creating an application(must be UWP for Microsoft app store). The application will remain running and we want to “hide” the UI from the desktop after they log in (not in taskbar). We want to put it somewhere where they can see the status of the application and/or logout (like a VPN or Anti-virus app shows status).
We have investigated using systray (non existent in uwp), quick actions tray (seems to be for system applications), notifications (show status there, but user can remove it—looking for something like the Action Center buttons for Wifi). Our goal is to have an application running, but out of the way, with access to the status and logout functionality. What is the Microsoft approved way? If there is no such approved way, how have you solved this?
At this point, that's not supported in UWP.
You can however publish WPF applications to the Microsoft Store using Desktop Bridge. I haven't touch it, but I've seen a few apps in the store running more elevated access than UWP and you may have the ability to control the visibility of the application's icon (ie taskbar/systemtray).
Give it a try and let us know if it works.
You're right, but there are some workarounds that can be used:
1. USING THE DISMISSED EVENT to show the notification again if user dismissed it.
2. UWP APP WITH SYSTRAY EXTENSION
As explained in this blogpost, you can add a component that will create the tray icon.
I'm writing a .NET 4.0 application that simply accepts input into a TextBox, processes it and then sends it off to a database. This app is intended to work with USB barcode scanners.
I have a requirement to ensure that the input from these barcode scans is processed by this app. I have been asked to ensure that this app stays activated and focused at all times as the laptop it will reside on has no other requirements other than to power and accept input from a USB barcode scanner.
I managed to achieve this myself by using a System.Windows.Forms.Timer that calls this.Activate() on a set interval, or better yet;
protected override void OnDeactivate(EventArgs e)
{
BeginInvoke((Action)this.Activate);
base.OnDeactivate(e);
}
Whilst these methods work fine on my Windows 8.1 Development machine, I can't get this same code to work on a Windows 7 OS (I've tried numerous boxes as well as VMs). For the Win7 machines I can see that this code is executed fine, but I just cannot get my app to Activate again.
Could anyone please advise as to why I'm seeing this behaviour?
Many thanks!
Windows only permits the application that owns the foreground window to bring another window into the foreground (either one of its own or belonging to another application). A background application can't bring itself into the foreground. This is a deliberate design choice (introduced circa Windows 98, as I recall) to prevent background applications from interrupting what the user is doing - particularly to ensure that keyboard input goes to the right place and doesn't accidentally fire actions that the user hadn't intended.
This constraint is documented in the SetForegroundWindow documentation:
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
• The process is the foreground process.
• The process was started by the foreground process.
• The process received the last input event.
• There is no foreground process.
• The process is being debugged.
• The foreground process is not a Modern Application or the Start Screen.
• The foreground is not locked (see LockSetForegroundWindow).
• The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
• No menus are active.
Source: SetForegroundWindow function (Windows)
If you need to be sure that input from a barcode scanner goes into a particular application, you should look into keyboard hooks, if the scanner is configured for keyboard emulation, or whether the scanner supports another API to allow direct control.
For example, the scanner may support the National Retail Federation's UnifiedPOS standard. Microsoft have provided a library, POS for .NET, which allows UnifiedPOS devices to be controlled from .NET.
That's an illegal action. You're stealing control from the user, which is forbidden in the desktop ecosystem. The user should always be the one in control. Windows Vista+ started paying a lot more attention to things like this.
The proper thing the OS is supposed to do is notify the user you want his attention (e.g. flashing the window in the taskbar), it must not actually activate your window. Every time the OS allows you to steal control from the user, it's considered to be a bug, and usually must be fixed.
Maybe you want to replace the default Windows shell instead? That will allow you to simply have just one application running anyway, and when it's closed, it will restart the machine...
Barcode scanners typically transfer their data as if some user would have typed it by using keyboard. This lead to a false assumption that you need to have focus and active window all the time.
However, you could use technique from stone age called keylogging (usually with the word trojan in front). This is achieved by setting keyboard hooks in windows based system. Then your application can have all the input.
It's done by using SetWindowsHookEx. I still have windows XP software which uses hooks and it seems to work under Window 8.
The problem to determine when it's a barcode scanner and when user is typing password into login form of another application I leave at your disposal =P.
I am trying to build a window service which will run in background for card reader, I will take card's data on a textbox . My question is :
When someone swipes a card on a card reader that window service WINFORM should take card;s data on a textbox. How can I achieve this.
or,
IF any one can tell me just that how to execute a WINFORM when card swipes, that would work also
Thanks
Windows services aren't supposed to show any kind of UI to the user, they run as completely background task that take no input from the user and show no output or status to them. If you require a service to "talk" with the user, the normal practice is to split the project in 2 different programs, one being the service itself, which is a UI-less thing that does the background processing, and a normal user app, maybe ran at login, that shows notifications and communicates with the service. Consider also that services survive logoff and logon, and there may be many users logged at a given time, so it doesn't make sense to show a dialog to anyone.
My suggestion would be to turn the service into a normal program, that the installer configures to run at startup, and it does the monitoring of the card reader and displaying of the popups asking details for the user. Since there will be no background work, other than monitoring, and if the form is absolute required, it doesn't makes sense to monitor without a user logged in, I don't think a service is the best choice.
I have seen two type of card readers:
1 - plugs into your keyboard port and acts as a keyboard (can also plug into a USB port, but still simulates a keyboard). When a card is swiped the info is written to whatever application and text field currently has focus.
2 - Has some kind of hardware driver (most likely a USB driver, possibly Serial or other).
If you aren't sure which you have then open notepad, make sure it has focus, and swipe the card. If the details show in notepad then you have #1. If they don't, then you probably have #2
If your reader is #1 then you can put some code into the Textbox's TextChanged event to do what you need (I presume you can add code to the application as you said you are building it).
If your reader is #2 then it really depends on the driver it uses. Some will likely provide an API you can integrate with, but you will need to find documentation.
Do you have a model number and manufacturer for your card reader?
I'm creating a WP7 app that needs to continue running when the user is not using the phone - ideally the user sets it going, locks the phone and carries on with their life.
Is this possible?
I know it is possible to disable the lock screen, so if the user were to just leave the phone on a table it would be fine and carry on running. The problem is when they put it in their pocket - buttons will get pressed such at the windows/home button, and if this happens then the app is tombstoned straight away.
Any ideas if this is possible? Either somehow locking the phone without tombstoning the app, or implementing a sort of custom lock screen and handling the events for all the hardware buttons including the windows/home button?
Any suggestions will be appreciated.
Just as you figured out:
PhoneApplicationService.Current.ApplicationIdleMode = IdleDetectionMode.Disabled
No need to ask user for permission anymore (since the original 6.3.1 "Configurable Functionality" was dropped). However, there are other Marketplace certification requirements to consider, see section 6.3: http://go.microsoft.com/fwlink/?LinkID=183220
I think I've done it again - asking questions too soon.
I believe the following setting:
PhoneApplicationService.Current.ApplicationIdleMode = IdleDetectionMode.Disabled
will enable the application to run under a lock screen.