I would like to call the event/alert API but filter the results by Device Type or Device Group, or as a last resort with multiple sources. Is there a way to make a sigle call to the API to achieve this result? At the moment I use /inventory/managedObjects with a device type first to get a list of devices, and then loop through the results and make a call to events/alarms for every device but this doesn't seem like a good way to do it.
Currently there is no way to query event and alarm APIs for a collection of source IDs. You can only query by a single ID.
If you are completly unhappy with calling for every device in the group there are two workarouns that come to my mind:
You query all and filter on the client (the more groups you have the worse this method will be).
You can create an event processing rule that adds an additional fragment to every created alarm and event based on the device group (incoming alarm -> check source -> check parents of the source (there is a function findAllManagedObjectParent). E.g. you add:
"myDeviceGroupName": {}
to all alarms and events.
Afterwards you can query the APIs not by source but by fragmentType.
Related
Could you explain what is the usage of Modules with select query?
For example if I write (as shown on this page https://cumulocity.com/guides/users-guide/administration/):
select * from MeasurementCreated
Is it useful to get real time notifications by subscribing of the related channel? Is the module reachable by an angularJs Module? Can this module be used in other CEL statements?
Just selecting data without putting it into another stream can make sense in the case you want to make this data available via a real-time channel to some external application (this could be of course AngularJs).
Take a look at this section in the docs: http://cumulocity.com/guides/reference/real-time-statements/#notifications
This very one example though does not make a lot of sense because raw measurement data is already provided on a real-time channel
http://www.cumulocity.com/guides/reference/measurements/#notifications
As for the second part of the question:
Yes it is possible to communicate with other modules within your tenant.
e.g. You can declare some stream in module a and it will be available in module b.
I am studying interface design.
Here is what I curious about.
Some of open API support 2 different interfaces to implement toggling. i.e. instagram like interface. It separates like interface(like, cancel like)
What is the advantage of separate those two.(separating into two interfaces makes end-user more complicated in my view)
I question this, since it could be implemented with toggle.
i.e. user send item_id and user_id. server check database(this item is already liked or not), and update.
Thanks for answer!
The real benefit to having two interfaces for toggling is that it doesn't require the user to know the current state of the thing they are attempting to change (i.e. it doesn't require me to first query for the state).
If I am a consumer of an API, typically I will want to perform actions such as like-ing something. Very rarely can I think of a case where I would want to perform the action of do the opposite of what I did previously (unless I'm feeling like flip-flopping). If you didn't have two endpoints for like and unlike then you'd first have to poll the API to get the current status, and then perform the toggle that you're talking about if needed.
This situation introduces more logic into your code, requires that you make 1-2 calls to the API, and assumes that the state didn't change between calls; whereas having two endpoints reduces the logic, limits your API calls to 1 per action, and you don't have to worry about the state changing unexpectedly.
In the case where you try to like something that the user has already liked, then the API would simply return a successful result and not alter the underlying data.
One reason to prefer an interface where you specify the desired state explicitly is that it will be idempotent. That is, the resulting state is the same even if the request is made multiple times.
This is a pretty contrived example, but if two different people sharing the same account tried to like the same thing within a small enough window, you could end up with it being un-liked instead.
I'm wondering how push notifications can be sent in batches. Let's look at the problem from the following 3 major patterns:
one API call -> one message -> delivered to a specified user
one API call -> one messages -> delivered to many different users (specified by id)
one API call -> many different messages -> delivered to many different users (specified by id)
The first one can be done easily.
The question is, what would you recommend to use for the second and the third ones?
I'm thinking of something similar to Facebook's Batch Requests when you have the ability to pass instructions for several operations in a single HTTP request. Is it possible at all with Parse?
for second pattern there is a way.
where parameter should be like this: where={"id":{"$in":[1,3,5,7,9]}}
more where parameters:
another example if you need to execute query for fining IDs:
still no workaround for third pattern
I'm trying out iBeacons now.
I have 2 devices that I'm using as beacons and 1 device to do the ranging.
When I implemented this method call locationManager:didRangeBeacons:inRegion:, in the documentation it says that "didRangeBeacons" takes an array of beacons in the proximity.
However, what I'm noticing is that locationManager:didRangeBeacons:inRegion: is getting called twice by each individual beacons. Is it supposed to behave that way?
Thanks,
Tee
You are supposed to get one call per second to locationManager:didRangeBeacons:inRegion for each CLBeaconRegion that you are ranging, and this callback includes an array of the CLBeacon objects that are seen inside that region.
So if you have set up two CLBeaconRegion objects and are ranging on both of them, you should two callbacks per second, each with a single beacon in its array.
If you have set up a single CLBeaconRegion for ranging that matches both beacons, then you should only get one callback per second and it should contain two beacons in its array.
You're right that locationManager:didRangeBeacons:inRegion gets called multiple times - when the proximity of beacons changes. I thought I read that this was usually once per second (and my testing would seem to align with this) but I can't find a reference for it at the moment.
You can of course decide what action you want to take whenever the method gets called (or even to take no action at all). You could also call stopRangingBeaconsInRegion: if you only want to be notified once.
Can I extend the server-side Java Code in Worklight?
For example, there is a class called JavaScriptIntegrationLibraryImplementation under com.worklight.integration.js. Inside this class, there is a method broadcastNotification and I would like to override this method. Is it possible to do so?
EDIT
The reason is that:
When I make the subscription in client side with option field (e.g. add customType: A), I would like to retrieve a list of devices which have been subscribed to this event source. Base on the option field in deviceSubscrpition, I would like to have some business logic to determine who to send the notification message. For example, I will only submit the message to the user which 'customType=A'.
However, there is no API in Worklight which can retrieve a list of devices which make me to retrieve the list first. Then do the logic in JavaScript and called WL.Server.notifyDevice..
Therefore, I would like to check whether there is any method to retrieve a list of devices (through API / Adapter which connects to DB) which have subscribed to an event source.
Thanks.
This part of Worklight is not extendable. You can try and override this method as you say, but do note this is not supported and we cannot help in this case.
Edit
Now that it is clear what you're trying to achieve... what you are looking for currently not available. I will open a feature request for it and it will get evaluated at some point (if you are a customer of IBM, I suggest to get in touch with your contact...).
My suggestion (somewhat hackish in form): you could perhaps use multiple Event Sources, where each event source represents an iOS version. On the client-side, upon app initialization, you can retrieve the iOS version and use it to register to the correct event source (this would be very generic code to allow re-use). In case a new iOS version is released (you will likely know of this in advance), you simply add this event source to the adapter code and re-deploy the adapter. Users of the new iOS version could still register for notification, because you get the iOS version upon init, and use this information to register to the correct event source...
To reiterate:
The adapter contains: ES_iOS5 ES_iOS6
The client:
fetches iOS version, stores it in some variable.
registers to event source, where event source name is ES_${iOSVersion}
if a new iOS version is released, simply create a new event source and re-deploy
the adapter; the client is already equipped to handle this.
#Red23jordon,
i had similar case, i created a custom table where at the time of subscription, I was saving
user ID and event type in custom table. and when user unsubscribe then i also remove details from custom table.
For sending push to users subscribed to a particular "even type" i look into custom table to get list of user IDs subscribed to particular event type, and then i went into Notification user/device tables and fetching corresponding devices and sending Push.
Hope it may help you.
thanks