CoreBluetooth on Mac ( OS X Yosemite) : Huge data receving delay after first time connection - objective-c

I've got a strange problem using CoreBluetooth on Mac mini. By design, my code should receive a data update notification after discovering a characteristics service once it's connected. The problem is no data will be updated if a event is triggered by hardware within very first 20 seconds.
I've test the same code in the iOS,but it all works fine without any dealy. So the question is:
Does Apple delay the -[didUpdateValueForCharacteristic:] notification after first BLE connection?
In addition, I am using a custom profile ( A self defined UUID).
Thanks.

According to documentation:
This method is invoked when your app calls the
readValueForCharacteristic: method, or when the peripheral notifies
your app that the value of the characteristic for which notifications
and indications are enabled (via a successful call to
setNotifyValue:forCharacteristic:) has changed.
So no, it's not guaranteed that this method will be called after discovering a characteristic. You either have to call readValueForCharacteristic or subscribe to notifications and wait until peripheral sends a notification.
However, after discovering a characteristic, you can get its value in peripheral:didDiscoverCharacteristicsForService:error: method.

Related

Cumulocity - managedObject Event - detect device first connection

Looking to understand whether there is a a bulletproof event from the namagedObject side of c8y where we know the device has just connected.
I have a microservice that listens for events in real time and I want to trigger a process once we know a device has connected to send its payload.
We have used:
"c8y_Connection": {"status":"CONNECTED"}
We have had the microservice log to Slack all events from managedObjects where we saw for three days the "status":"CONNECTED" value in the payload of our demo devices at reporting times.
But after three days, we see no more this "CONNECTED" state (all payloads showing "DISCONNECTED").
What I am trying to achieve from the inventoryObject event is to understand when a device had connected and sent payload to know when data had arrived. I then go get the data and process it externally. This is post registration and as part of the daily data send cycle for my type of device.
What would be the best way to understand when a device has sent payload in a microservice? I want to notify an external application with either “data is arriving for id 35213” or even better, “data has arrived for device 35213, and here’s the $payload”.
Just as a general information ahead:
The c8y_Connection fragment showing connected shows an active MQTT connection or an active long polling connection and it is only evaluated once every minute.
So if the client is just sending data and immediately disconnecting afterwards this might not picked up.
If you want to see the device having send something to Cumulocity maybe the c8y_Availability fragment is a better as it holds the timestamp when the device last send something.
{ "lastMessage": "2022-10-11T14:49:50.201+09:00", "status": "UNAVAILABLE"}
Also here the evaluation (or better the update to database) only happens every minute.
Both c8y_Availability and c8y_Connection however are only generated if the availability monitoring has been activated for the device (by defining a required interval for the device).
So if you have activated the availability monitoring and you see a "lastMessage" you can reliably say that the device has already send something to Cumulocity.

Apple Wallet Passes : Update Calls trigger

There are numerous articles on "how to implement update service" is already present. However, I have serious question below:
when will pass get updated technically? what is the trigger for updating?
When will be passbook's update service be called?
when update push notification is clicked by user
when pass is opened by user
silently done in background
when automatic update is off and user opens a pass
Please help
Pass updates can be initated in one of two ways:
The users does a pull-to-refresh on the pass.
You send a push notification to the device.
In the case of number 2, the device responds to the push notification by reaching out to the service specified by the pass's WebServiceUrl.
It sends the device identifier and pass type identifier. The web service is responsible for determining the passes that need updating and it returns a set of serial numbers. It does this by looking at the update tag and applies whatever mechanism makes sense for the pass.
The device will then request an updated pass for each of these serial numbers.
The process is described in far more detail in Apple's Documentation:
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/PassKit_PG/Updating.html#//apple_ref/doc/uid/TP40012195-CH5-SW1

Sending Push notification from client - Worklight

I know that push notifications are being sent from a backend server. Is it possible to send notification from client itself? My application goes like this: It acquires its position using Location services API. once it enters a specific circle, the trigger calls a callback function. What i want to do is to use the callback function to push a notification to the device. Is there any way to do this?
Thank you very much in advance!
If you just want a notification when the app is active in the background, you can use local notifications: https://github.com/katzer/cordova-plugin-local-notifications. The plug-in Javascript has to be modified somewhat to work with a Worklight app, but with some simple modifications it works great, and allows your app running in the background to raise a notification without going through the server side round trip involved when using push.
That said, I implemented an app that did exactly what you are looking for (in my case, I needed some server side processing to figure out what the text of the push message should be) The geo-fence callback called an adapter, providing it with event details and the device ID. The adapter determined what message to send, and used unicast push to send it back to the device.
You can invoke a procedure in the client side. I tried to invoke in the client side with httpAdapter and its working.
If the notification doesn't need to come from the server, you can also create a service that will run in the background and show a dialogbox once it enters the geofence.

Can wifi / geo triggers be invoked even if the Worklight app is not running, including not in the background?

In Android, an app which is not currently running can be notified when certain event happens (like wifi scan results available, boot process completed) through Broadcast Receivers mechanism. Is this possible in anyway so that the wifi/geo triggers can be invoked even if the Worklight app is not running, including not running in the background?
Regarding wifi/connectivity changes notifying your app, that looks possible since it is a standard system event. It would likely take custom native code since you'd need to implement a broadcast receiver. And you'd need to register your receiver in your app's AndroidManifest.xml file. Take a look at http://developer.android.com/reference/android/net/ConnectivityManager.html and http://www.grokkingandroid.com/android-getting-notified-of-connectivity-changes/
Regarding geolocation triggers, it is unclear what sort of triggers you are looking for. This is all I see in the Android docs: http://developer.android.com/reference/android/location/GpsStatus.html and the standard broadcast actions at http://developer.android.com/reference/android/content/Intent.html#constants
If you are looking for something like geofencing, it would take application logic to determine when to fire events, so that means an app or service needs to be running. So although your broadcast receiver's onReceive() method can get called upon a geo event, who is going to fire that event?
Having the triggers activate when the application is not running at all (not even in background) isn't supported through the Worklight APIs.
You could try and use Worklight Android Native SDK together with cmarcelk's suggestions. Or you could use the Worklight Android triggers within a native service, together with the Broadcast Receivers mechanism so that it will run automatically on boot. You could then use an Intent to open the application from the trigger callback.

Push Notification service is not working, When device is switch off

I have implement Apple Push Notification in my application.
It's working fine when my iPhone is on.
Now, when I switch off my iPhone and fire notification from the server, it's successfully sent.
but, When I switch on my iPhone, I am not getting any notification.
So, what is the problem ?
Apple Push Notification service includes a default Quality of Service
(QoS) component that performs a store-and-forward function.
If APNs attempts to deliver a notification but the device is offline,
the notification is stored for a limited period of time, and delivered
to the device when it becomes available.
Only one recent notification for a particular application is stored.
If multiple notifications are sent while the device is offline, each
new notification causes the prior notification to be discarded. This
behavior of keeping only the newest notification is referred to as
coalescing notifications.
If the device remains offline for a long time, any notifications that
were being stored for it are discarded.