I got the following message from apple.
"The HTTP / 2-based Apple Push Notification Service Provider (APN) API lets you take advantage of great features like authentication with a JSON web token, improved error messages, and per-notification feedback. If you are still sending push notifications with the legacy binary protocol, make sure to update to the APN provider's API as soon as possible. APNs will no longer support the legacy binary protocol after March 31, 2021."
I have to investigate if it is going to impact the project.
Currently notifications are handled by a plugin called: phonegap-push-notification, with a forked havesoruce.
But I can't find or don't see where in the plugin it uses what apple wants to modify. I don't know if the changes will impact, I don't know if when updating the plugin, the apple changes will be made in the system.
How do I know if my app uses legacy binary protocol, where do I see that?
APP:use ionic 3, AngularJs.
Related
Google is deprecating Cloud Iot, so not an option.
https://cloud.google.com/iot/docs/release-notes
Cloud IoT Core will be retired on August 16, 2023. After August 15, 2023, the >documentation for IoT Core will no longer be available.
I would like to use Firebase - Firestore for my backend. It takes all the hassles out of keeping a server up and running, scalability etc.
I managed to send data after login and authentication from an ESP32S3 using ESP-IDF in C, (note not Arduino, and not C++), and would like to know if I can rather use a websocket for the communication, once the Authentication done, and if so, can you give me a code example or pointers.
With a websocket, I can send data to my own server hosted in Europe, in less than 400ms.
With Firestore, there is a large HTTP header, that includes the API key, and also the Auth Token, a large amount of data, quite a lot of handshaking going on over HTTPS, and eventually the data is sent. This takes more than 1400ms.
We are weighing items in a farming scenario, and need to weigh very frequently, and the 1400ms with fast internet is not acceptable.
So if I could still go with Firebase Authentication, and Firestore for data, I probably would be able to speed it up to even faster than 400ms if I could use a WebSocket client connection with the Firestore document store. I can use the Refresh Token if needed to refresh the Auth Token, and thus keep the socket connection up, every 3600s as required by Firebase, (that also takes quite long) but less of a hassle, as only once every say 55 minutes.
Any pointers, advice will be appreciated.
Firestore supports multiple SDKs and wire protocols, but none of them work over web sockets. The closest you can get with Firestore would be its REST API, which is documented here. It's not the easiest protocol to work with though, so I recommend using the API explorer that is built into the documentation to create examples for yourself.
I am kind of new to React, so this might be just lack of experience, but I don't seem to find any answer to my question:
I have a react app, where I need to subscribe to a push notification channel. Messages are delivered through PubNub, and in order to connect I need to supply a subscribe and a publish key to the message server. Now, I know it is not a good practice to store secrets in a react app, and they should be handled through backend services, but do I really need to create a service just to subscribe to the channel and forward the messages to my frontend app? Is this not an overkill?
The messages I am receiving are just time ticks (I need a trusted source of time), but I still don't want my API keys to leak out...
Is there any reasonably ok way for me to avoid standing up an intermediate service?
It is perfectly normal to have your PubNub publish and subscribe keys in client side code. If it is necessary to restrict who has the power to publish and subscribe (read/write) using those keys, the developer can enable PubNub Access Manager (PAM) in the admin panel. There are PAM guides to get you started on controlling access.
Another point to consider is that your JavaScript PubNub connection can also be used as a trusted source of time. The JS SDK time call will get a 17 place precision unix timestamp from a PubNub node:
const pubnub = new PubNub({
publishKey: 'your_free_pubnub_publish_key',
subscribeKey: 'your_free_pubnub_subscribe_key'
});
let pojoDateObject;
pubnub.time().then((timetokenObject) => {
pojoDateObject = new Date(+String(timetokenObject.timetoken).substring(0,13));
});
Scope:
I have an app that i am starting to build that has the "subscriber/publisher" situation on it's core.
For those who don't know, the idea behind this schema is that:
1) Someone creates a "Topic"
2) Endpoints subscribe to a "Topic"
3) Any message published to a certain "Topic" is pushed to the subscribers of said "Topic"
Considerations:
I am going to use Xamarin.IOS and Xamarin.Android as the framework to build this mobile app (so that it can be crossplatform from the begining).
RabbitMQ:
The RabbitMQ service is built on top of the AMQP pattern which solves my entire problem of modeling the "Topic/Subscriber/Publisher" problem.
The Problem:
Now that I have the problem modeled via the RabbitMQ framework, I need those "Messages" that are "pushed" to each endpoint (mobile device) to actually be a "Push Notification" instead of the standard message that will arrive to that device.
How can I model my solution to accomplish that ?
Thanks in advance.
RabbitMQ can't send out the push notification itself.
For each message consumed from the a RabbitMQ queue, the "Consumer" service needs to invoke whatever push notification backend/API you are using (e.g. Firebase, AWS, etc.) using their SDK.
How does automatic updates work in passbook available in backfield of the pass, how to use webserviceURL key to get update from the server.
in webserviceURL key i have provided remote path from where updated pass can be downloaded, but even after content changed in server, it does not reflects in pass.
This question has been asked so many times, in so many ways, in so many forums; mostly by people that are too lazy to read the manual, or are too inexperienced / incompetent to understand it.
The first paragraph of the Passbook Web Service Reference explains why simply adding a link to an updated pass will not work.
A REST-style web service protocol is used to communicate with your server about changes to passes, and to fetch the latest version of a pass when it has changed. The endpoints always begin with the web service URL, as specified in the pass, followed by the protocol version number. For example, a request for the latest version of the pass of type com.apple.pass.example and serial number ABC123 might look like the following:
The Passbook web service is an integral part of the Passbook eco system. Anyone wishing to issue passes that change their content (either in response to a push message or in response to a user requesting fresh content by pulling down on the back of the pass), needs to implement their own Passbook web service.
This entails building a server capable of responding to the following to authenticated requests from each device that has installed your pass.
There are 5 methods that your web service should respond to:
1. Registering a Device to Receive Push Notifications for a Pass
POST request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
2. Getting the Serial Numbers for Passes Associated with a Device
GET request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier?passesUpdatedSince=tag
3. Getting the Latest Version of a Pass
GET request to https://webServiceURL/v1/passes/passTypeIdentifier/serialNumber
4. Unregistering a Device
DELETE request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
5. Logging Errors
POST request to https://webServiceURL/v1/log
In order to have a pass respond to a manual refresh or push request you need to implement at least the first 3 methods. This is because the device will not issue any further requests until it has received a valid response to the registration request.
Furthermore, the web service must be available over https. An unsecured http service can be used for development, but production devices will only recognise a webServiceURL key that begins with https.
I've been following the HTML5rocks webRTC guide and I have the Javascript set up as described, however the guide is not clear on how to receive a channelToken, roomKey, and User ID. The guide says,
"Note that values used in the JavaScript, such as the room variable and
the token used by openChannel(), are provided by the Google App Engine
app itself: take a look at the index.html template in the repository
to see what values are added."
Unfortunately the link provided is no good and I'm left with very little information regarding the most essential step in this process. The guide isn't clear about whether or not the Google App Engine is a necessary component and I don't see why it should be. I have searched the web in an attempt to find a more useful source, but I was unsuccessful. I also took a look at the webRTC Demo(https://apprtc.appspot[dot]com), that too was no help seeing that the channel information is generated server side. I feel like I should just be able to make a simple http request to some Google server and then run from there. Any information regarding my problem would be much appreciated.
Apologies: the code for this example has been moved to here.
(Been meaning to update the article, but haven't had a chance...)
The apprtc.appspot example uses the Channel API on App Engine for signaling, but there are lots of other ways to do this. Signaling mechanisms are not defined by the WebRTC spec. (Note that signaling, which is accomplished via a signaling service, is the exchange of network and media metadata in order to set up a WebRTC 'call': the actual data is communicated directly between peers.)
We ran a codelab at Google I/O, which describes from start to finish how to build a video chat application that uses Socket.io on Node.js for signaling (it's very simple!) You might want to try that instead.