In a project I'm currently working on, we send some small info across the wire to WP7 device when we send a raw notification.
When the application is in a tombstone state and the user receives the toast message, we can't add the extra baggage in the toast. So we figured we need a way to resend the notification once the user entered the application again.
Anybody has any experience or possible solution for this problem. We are currently looking at a sort of handshaking between client and server. But it all seems a bit drastic for me.
Kind regards,
Tom
I would suggest to stop using rawNotifications and use only toast.
To handle the case when the app has been started using a toast notification, query the server at app startup to check if there's pending data.
For notifications sent while the app is running, you can detect them using the ShellToastNotificationReceived event of your channel. When the event is triggered, query the server to retrieve the payload.
Related
I've integrated Huawei's Pushkit, push notification service into my Xamarin application, I've tested the notifications while the application is running in the foreground and it works as expected.
However, while the application is closed the application and attempt to send a notification, the OnMessageReceived method in my messaging service is not triggered.
According to the documentation that can be found here :
Regardless of whether your app is running in the foreground or
background, if you override the onMessageReceived method in the
DemoHmsMessageService class, your app can obtain the data message
content as long as you send a data message.
According to me, that means the OnMessageReceived method should be triggered, so long as you're sending a Data Message.
Am I missing something, or did I perhaps misinterpret the above-quoted passage?
Thanks In Advance! 😀
Push kit supports two types of messages - notification messages and data messages.
OnMessageReceived will be triggered for data message to receive message.
For data message, if app is closed, user might not receive message. As per doc :
https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/funtion-description-0000001050148080
The delivery of data messages depends on the resident status of your
app. Push Kit cannot guarantee a high data message delivery rate,
because it may be affected by Android system restrictions and whether
the app is running in the background.
It might be because of battery optimization.
For Notification message, notification can be delivered regardless of app resident status, even if app is not launched.
I'm building an application where I need to manage the drop-off screen, ie, the screen from where the user killed the application.
One way to solving this problem is to ask the JS client to send an event to the server. The event will be the last successfully executed screen. For eg:- if my application has 10 different screens, then the last screen which was successfully completed by the user, the client will send the server the screen_name.
Now when the client wants to know the screen from where the user dropped-off, it can make a GET call and fetch the same.
The cons I see with this solution is:-
1) Dependency on the client for sending an event. If while sending the event, the connection drops-off or the user killed the application(website), then the client has no way to send the event again. In this way, the user will come back again to the same screen which was successfully completed
2) Increased number of network calls.
Is there any way in which server can itself handle the drop-off state? I have RESTful APIs.
I'm sure this must have been answered but i cant find it.
What are the techniques used to test a server side application that generates apple push notifications?
We have a host based service that waits on an event, and then generates an APN, and our IOS application will receives this notification.
So, I'd like to write a test that simulates the event being received and sends the APN and then determine if it was delivered. From what i understand, apple will does not support this?
Only think i can think of is to write an IOS application, that simulates the event has occurred and tells our host to send back a Push notification to the testing device. Then the IOS application could detect that it was received or not. We could put it on an IPOD touch that is always running in our server rack. I dont really like that approach but dont know what else to do.
If we used Urban Airship would that make it easier?
You can send push notification using below url :
http://pushwatch.com/apns/
You'll just need three thing as below :
1)Pem file
2)Device token(s)
3)Message
My app needs to keep receiving data from BLE devices when the user hits the side button and "kill" the app or it simply run in sleep mode. How can I save the state of my app and his listeners so I can keep receiving the data?
I've read some approaches but I want to know what is the one more indicate.
Launch a service as the center of my app?
Launch pendingIntent so the user can re-enter the app after sleep mode? In this case how can I keep my listeners for receiving data?(service?)
Your app can implement a WearableListenerService; framework will instantiate it when you have a message/data and calls its appropriate callbacks with the message or data that has arrived.
The solution I've implemented was the first one!
I've completely detached the center of my app from the UI activity and implemented a service as the "brain". The service and the activity are in constant communication through a broadcast channel. When the smartwatch is in sleep mode I launch a pendindIntent (card) so the system can recover to the main activity.
That's how I've done it, hope it helps someone else!
I'm trying to understand whether the HTML5 Web Notifications API can help me out, but I'm falling short in understanding how it works.
I'd like user_a to be able to send user_b a message within my webapp.
I'd like user_b to receive a notification of this.
Can the web notifications API help here? Does it let me specifically target a user (rather than notify everyone the site has been updated_? I can't see how I would create an alert for one person.
Can anyone help me understand a little more?
The notifications API is client side, so it needs to get events from another client-side technology. Here, read THIS: http://nodejs.org/api/. Just kidding. Node.js+socket.io is probably the best way to go here, you can emit events to one or all clients (broadcast). That's a push scenario. Or each user could be pulling their notifications from the server.
HTML5 Web Notifications API gives you ability to display desktop notifications that your application has generated.
What you are trying to achieve is a different thing and web notification is just a part of your scenario.
Depending upon how you are managing your application, for chat and messaging purpose as humbolight mentioned, you should look into node.js. it will provide you the necessary back-end to manage sending and receiving messages between users.
To notify a user that (s)he has received a message, you can opt for ajax polling on client side.
Simply create a javascript that pings the server every x seconds and checks if there is any notification or new message available for this user.
If response is successful, then you can use HTML5 notification API to show a message to user that (s)he has a new message.
The main problem with long polling is server load, and bandwidth usage even when there are no messages, and if number of users are in thousands then you can expect your server always busy responding to poll calls.
An alternate is to use Server Sent Events API, where you send a request to server and then server PUSHES the notifications/messages to the client as soon as they are available.
This reduces the unnecessary client->server polling and seems much better option in your case.
To get started you can check a good tutorial at
HTML5Rocks
What you're looking for is WebSocket. It's the technology that allows a client (browser) to open a persistent connection to the server and receive data from it at the server's whim, rather than having to "poll" the server to see if there's anything new.
Other answers here have already mentioned node.js, but Node is simply one (though arguably the best) option for implementing websockets on your server. You might also be comfortable with Ratchet, which is a websocket server library for PHP, or Tornado which is in Python.
How you handle your real-time communication is up to you. Websockets are merely the underlying technology that you can use to pass data back and forth. The client side of this will be fairly easy, but on the server side, you'll need a mechanism for websocket handlers to get information from each other. Look at tools like ZeroMQ for handling queues, and Memcached or Redis to handle large swaths of data which don't need to be stored permanently.