I was wondering if there is a way to display an alert dialog even when your application is minimized/not focused.
I'm creating a small alert system app for a small company. I'm using Xamarin. Don't really have to worry about old API Levels, every phone is 15+.
You can't show an alert but you can start an activity that is styled as a dialog (transparent background + your content in the middle). To do this start the activity as a new task. Example:
startActivity(new Intent(context, YourActivity.class).addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
This proved to work on all devices as long as it's not in standby with a secure lock - password for example.
Related
I want to create a notification or an alert for the user to restart the PC if it hasn't been done so for 5 days.I used windows toast to do this but found out that toasts can be dismissed and there is no way to perform an action upon dismissal, this is not good as the user can just dismiss the toast without restart the pc for n number of days. I need to implement something similar to the "Low/Ciritical battery" or the "Low Disk Space" Notification (see pictures attached).
I have tried some searching on how to implement this alert but almost all the sources use toast notifications to display the alert. Any help would be appreciated. Thanks.
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.
I have written an app that performs some lengthy operations, such as web requests, in a background thread. My problem is that after a while the automatic screen lock turns the screen off and my operations are aborted.
Is there a way to prevent the screen to be automatically turned off during these operations? Or is it in some way possible to keep running while screen is turned off?
I know there are ways to prevent the screen to turn off while debugging, but i need this behavior in the hands of the end user. Therefore I can not rely on some setting being set on the phone, but rather some programmatic solution.
The screen can be forced to stay on using the UserIdleDetectionMode property of the current PhoneApplicationService.
To disable automatic screen lock:
PhoneApplicationService.Current.UserIdleDetectionMode = IdleDetectionMode.Disabled;
To enable it again:
PhoneApplicationService.Current.UserIdleDetectionMode = IdleDetectionMode.Enabled;
More information can be found on MSDN
I know this question is about Windows Phone 8, but I had a hard time figuring out the way for Windows Phone 8.1 (Universal XAML Apps).
Use:
var displayRequest = new Windows.System.Display.DisplayRequest();
displayRequest.RequestActive();
Apps that show video or run for extended periods without user input can request that the display remain on by calling DisplayRequest::RequestActive. When a display request is activated, the device's display remains on while the app is visible. When the user moves the app out of the foreground, the system deactivates the app's display requests and reactivates them when the app returns to the foreground.
See: http://msdn.microsoft.com/en-us/library/windows/apps/br241816.aspx
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?
For practical purposes but also as a learning exercise, I am wanting to create notification application to remind me of friend's Birthdays. I would like the application to be running in the background so that it can check the current date against user configured reminders. If a reminder is due then the user is displayed a simple Window that will allow them to snooze or dismiss the notification. I want the application to have user specific notifications (i.e. User A's notifications are not seen when User B is logged in).
Option 1 - Application launched upon Windows startup:
I thought about keeping it simple by checking when to display notifications only when the application starts up. I would then put a shortcut in the Windows Startup folder. However, this probably wouldn't work if the PC is put to sleep and resumed each day.
Option 2 - Application constantly running in background:
I then thought about making the application so it minimises to an icon in the System Tray and thus would constantly be running in the background. It would then periodically check when to display notifications.
Option 3 - Using Windows Service with application:
I then thought about using a Windows Service to do the periodic checks as to when to display notifications. Obviously, a Windows Service cannot display UI notifications so it would need to use some other mechanism for notification (e.g. sending an email). An application could then be used to configure settings that the service uses.
Are there any other options that I have not considered which would work better. I'm currently inclined to go with option 2 for my first implementation but could look to move to a better solution afterwards.
TIA
Your option 2 is the optimal one since you are aimed to distinct users and their reminders - your application runs in the context of a particular user, you already know which remainders need to be shown. Of course, you could go for the third option but this way is really need more time to code and the code itself would be more complex. I would go for the second option. As your applications is WinForms, for the periodical checks I would recommend you to use System.Windows.Forms.Timer class.
By the way, showing an icon in the tray notification area does not make your application "run in the background", it is just a convenient way to show your application is up and running.