I want to push a notification to the user every X minutes.
However if there already exist an unread notification,
I want to delete it and replace it with a new one. How can I delete?
How can I check how many unread notification my app has already pushed?
To replace an existing notification with a new one you should simply post a notification with the same id, this behavior is mentioned in the documentation of NotificationManager's notify() method. If you want to just remove a notification, call cancel() providing the id you used to start it.
Regarding counting the number of notifications your app has sent, I think the best solution would be to just store a counter and increment it once a notification has been sent.
Related
I have added to my phone authentication to my sign up process, in a send code activity - which sends the sms code to confirm the phone authentication process. Then, I have also added a "go-back"/"return" button which moves the user back to the main activity.
If I make the following request which sends the user a sms code to his phone:
PhoneAuthProvider.verifyPhoneNumber(options);
I won't be able to make another request before the defined timeout duration ends. Therefore, I thought about the easy and not messy approach, that would be to cancel the ongoing request, but unfortunately couldn't find how to do so, if even possible nowadays. I have also saw the unanswered post here: Android Firebase OTP auth: Is there a way to cancel OTP code request programatically before the actual timeout?
Couldn't work with this, even though it's what I am looking for, but it has no related answers.
Note: I am programming my project with Java and not Kotlin.
I have also thought about the second approach, which is to save current activity's phone number and then extract it with onRestoreInstanceState and onSaveInstanceState, then resend a code sms again. But of course, it's much more complicated and messier.
It is possible to cancel an ongoing verification request by calling the verifyPhoneNumber method again with the same phone number, but with the forceResendingToken parameter set to null. This will cancel the previous request and allow to start a new one.
It is also possible to use the PhoneAuthProvider.getInstance() method to get a reference to the PhoneAuthProvider instance, and then call the verifyPhoneNumber method on that instance instead of calling it directly. This allows to call the verifyPhoneNumber method multiple times without canceling the previous request.
Timeout duration for verification requests is typically around 5 minutes, so if you want to allow the user to request a new code before the timeout expires, provide a way for them to do so, such as by adding a "Resend code" button to the app.
Overall, it's best to design apps in a way that minimizes the need for canceling ongoing verification requests, as this can lead to a confusing user experience. Instead, focus on providing clear instructions and options for the user, and consider using the getInstance method to avoid having to cancel requests altogether.
I am building a chat app, and like Whatsapp, I need to provide users the facility to save their messages as undelivered when internet connectivity is OFF, and as soon as the internet is back then that data should be retried to be sent to the receiver.
But, in case I scheduled a write operation using Firebase .setValue(), then how could I cancel that process in case the user changes his mind and doesn't want that message to be sent, or in technical terms does not want to setValue(), how could I stop that ongoing write.
As I understand from your scenario, the problem arises when the device is offline and you want to let the user the possibility to delete the message, so it cannot be displayed once it regains connectivity. Because the setValue() method returns a Task<Void> object and because I don't see any cancel method in this class, the only thing to do it to simply remove the message. In this case, when the user is back online, no other users will see the deleted message.
On the other side, it's true that there is a chance in which the user sends the message and right after that he loses connectivity. Even if there was a cancel method, you would have nothing to cancel, as the message is already set on the server. Again, the single option that you have is to delete the message. The delete operation will remain in queue until the device regains connectivity and right after the synchronization the message will be deleted.
Besides that, remember to set the persistence enabled, because it's not enabled by default:
setPersistenceEnabled(true);
I want to implement push notification in java so please help me out
1-Each time a new record(Message) pushed into data base(due to event created by some other user), a push notification should be sent to specific Logged in user automatically.
2-Content of the push notification should be the message present in the db.
3-If there are multiple messages, then the user should receive them one by one in a queue fashion.
4-Most important thing is the logged in user need not have to trigger any event to get notification, user should receive it automatically throughout the session.
You could use Server Sent Events. Java provides SseEmitter to send timely notifications.
You can use EventSource API in JavaScript to trigger the SSE event stream and in the server-side, loop the database query code which is wrapped by an ExecutorService - which can spin of separate thread based on the initialization.
Put SSE timeout to -1 for listening for an infinite amount of time.
Please note this answer is only a hint. Use these to explore more from the internet.
This issue I have may be only present on devices running Oreo or later as I have only a OnePlus 3T with me for development.
I have a foreground Service that is started using ContextCompat#startForegroundService() and in the service's startCommand method I make sure to create / enable my notification channel so that I can call startForeground with the associated on-going notification.
So I believe, in terms of requirements I get everything right here.
What does my Foreground Service do:
It acts as a Bluetooth Server using the Bluetooth Class RFCOMM BSPP to listen for client to connect ;
When a client connects, it listens for incoming requests ;
It performs the requests and send data accordingly.
My problem lies with the last point. When I connect and ask to send data, two things happen on the phone :
The relevant data is being loaded from the phone and
Once fully loaded, the data is sent to the client.
Each of these operations have their own notifications to display progress to the end-user.
While the first operation is not delayed, the second one may take many minutes (up to 6 in one of my tests).
After further tests, the cause is the notifications because I cancel the first operation notification then I call the second operation, which in turns will display and update its own notification.
So in the end, because I call NotificationManagerCompat.cancel on the first operation notification right before calling the second operation, that call can be delayed for a lot of time. If I don't cancel the notification first, then the second operation is immediately started.
As a solution, I believed that the Doze mode is responsible for that behavior, so I manually white-listed my app the battery optimisation settings of my phone. That did not change a single thing.
Finally, if, at any point, I unlock my phone / turn the screen on, the blocking / delaying notifications get's unlocked immediately and the second process starts right on the bat. So, of course, this behavior does not occur when my phone is plugged into my computer even with screen off.
Is this a bug ? Is this related to doze mode ? I do not know.
[Edit 1]
For better clarity, here is a code snippet that represents the sequence of operations:
loadData() {
... // defer heavy work on a worker thread and updates notification of progress from time to time (every 10%)
notifyDataLoadingStarted(); // on main thread. Displays its notification with progress bar
}
// once the data is fully loaded
onDataLoaded() { // called on the main thread
cancelDataLoadNotification(); // asks the notification manager compat to cancel notification
initiateDataSendingOperation(); // will also defer heavy work on a worker thread and update its notification accordingly
}
What happens is that onDataLoaded is called once the first operation is over. But the problem is that cancelDataLoadNotification is blocking. I am on the main thread and this methods returns very very lately. Hence, this is the reason why initiateDataSendingOperation is greatly delayed.
When I unlock my phone, I could see that the notification of the loading operation is stuck in the middle, as though the loading operation is halted, around 50%. However, this only lasts a fraction of a second because before I know it, the first notification pops out while the the second notification pops in. All in the blink of an eye. Which clearly means that yes, the first operation was indeed over since a long time ago, but its notification was definitely obsolete. And since the second operation would only be initiated when the first notification is cancelled, they you can clearly understand that the second operation is greatly delayed.
That's why my first workaround works if I first start the second operation before canceling the first operation notification.
Nevertheless, in any case, the notifications are still out of date while screen is off.
I want to notify the user of my app when he receives special news (from my app).
How can i display some kind of a messeage to the user, even if my app is running in the background (or not running at all if possible).
I want him to be notified by text, and sound.
Thanks.
You need to write a service for doing this. Then in your service code use Notification class to show text and sound alerts.
Use Broadcast Receiver, to notify abt some action. Like updates, sms, or abt indicate when booting of a phone completes,etc... BroadCast Receiver works on the principle of Publisher and Subscriber pattern.
If your app is not running and you want to do something you'll need some kind of broadcast receiver to receive a trigger.
Probably what you'll end up doing is starting up at device boot, to schedule some stuff. This answer here should get you into the right direction
After that, the best way to notify the user is with notifications (or Toast messages if you're a great fan;))
Have a look at
Status Bar Notifications