I made a little program to synchronize our internal time reporting system with Trello (SCRUM addon) and everything works fine. It basically takes the estimated hours per card from Trello, synchronizes the cards name with our internal system and then updates Trello with the actual hours used per card.
The problem is that each update of the card names triggers a Trello notification. Is there any way to suppress this behaviour? Ideally I'd want our system to update the Trello board right away when someone reports some spent time but as it is there are too many unnecessary notification emails being sent.
I was thinking that it could either first remove all notifications, make the subject changes and then readd notifications or is there some way to globally tell Trello to ignore making notifications for changes done with the Trello API?
Kind regards
Mats Forsén
There's no way to do that through the API, but a recent change to when notifications are generated means that this should no longer be a problem.
Related
With the new API, it is great that we are able to push orders to the POS app - now I just need a way to notify customers that the pick-up is ready. I have my own system seperately right now, but is there any way to do this inside of Square. Or even better, is there any way to hook into a square event?
I see webhooks, but only things like payment, refund, dispute events. Is there any way to catch an order status change?
Currently there are webhooks for different order update events:
You could then create some webservice of lambda to process such webhook payload, and submit an email using some 3rd party email sending solution.
There is a challenge that since you will need to query the square api for the rest of order details, you will need to create a square app, implement oauth etc.
Unfortunately, there's currently no Order webhooks at this time. Webhooks are definitely an area Square's APIs have been focusing and improving lately, so I suspect this to be an area we continue to improve. With that said, there is no ETA on if/when this is coming, sadly we do not share public timelines.
I need a bit of guidance, so for my application i'm looking at using local notifications to send a notification every morning at 7 o'clock.
The issue i'm having is how can i make the content for the local notification dynamic mainly the body and the attached image? As it will vary for the user on a daily basis.
What would be the best way to go about this since you can't edit future notifications.
Here's a little lesson about notifications. First, what is a notification? It's basically an alert presented on your behalf by the system. Second, there are two kinds of notification: local and remote.
Let's imagine, then, an app that aims to present a notification to the user every morning at 7 AM saying what the current temperature is outside. (Assume for purposes of the example that we have a way of learning this information.)
A moment's thought will reveal that this cannot be done with local notifications. We cannot know the current temperature at 7 AM until 7 AM (or close to it) and we cannot schedule the notification unless the app is running. Therefore we would need the great good luck to have the app running at 6:59 AM in order for this app to work. But an app only runs when the user summons it, so that is extremely unlikely.
Therefore a task of this kind is possible only with remote notifications. A remote server is always running; therefore it can get the temperature and "ping" the user's device at 7 AM, and the system will present the notification on your behalf. You would therefore need to possess such a server in order to write the imagined app.
(An alternative using local notifications would be this: You schedule, say, a week's worth of local notification in advance. Then if you have the great good luck to find the app running before a notification is presented, you tear down all the scheduled notifications and do it again with a more up-to-date forecast. But of course this cannot possibly work as well as using remote notifications, and it will stop working entirely after a week if the user doesn't launch the app. That, to put it bluntly, sounds pretty lame.)
Is-it possible to get the user's current playing track with Deezer API?
I've tried to use history but it seems to get 1 or 2 minutes before adding the last track... No way to get it real time?
I'm working on iOS app.
There are no real time updates for now in the Deezer API. Using the listening history is the right way to proceed.
If you absolutely need real time, you may use Facebook as an intermediary since they have real time updates for the Deezer users who publish their music activity on Facebook.
I have a button follow on my website, you can toggle it on or off as much as you want.
Each time it sends a notification mail to the followed people. I don't want him to be spammed.
So I want Play Framework not to send this mail twice (twice in a day, for example)
Is there any built-in mechanism or any library of play framework to do it?
Thanks !
EDIT :
Preferably an external service, like Mailjet or mailchimp.
Just save notification to DB instead of sending it immediately - so user can decide how often he want's to get it.
Next use Akka scheduler for sending many notifications in single emails from time to time.
I have a live tile working which updates how many users are online and how many lobbies are open within the app. This begins updating when my app loses its visibility (no point it updating the live tile whilst the app is running), but I want it to update when I first turn the computer on.
I have had a look around and mentions of making the app a lock screen app have popped up but that is all, no explanation how to do it.
Does anyone know how to do this and provide a nice little explanation or link of how to do so?
Many thanks,
Kevin
You should use push notifications for this kind of behaviour. This msdn link has more info:-
Using tile notifications
Choosing the right notification method to update your tile
There are several mechanisms which can be used to update a live tile:
Local API calls
One-time scheduled notifications, using local content
Push notifications, sent from a cloud server
Periodic notifications, which pull information from a cloud server at a fixed time interval
The choice of which mechanism to use largely depends on the content you want to show and how frequently that content should be updated. The majority of apps will probably use a local API call to update the tile when the app is launched or the state changes within the app. This makes sure that the tile is up-to-date when it launches and exits. The choice of using local, push, scheduled, or polling notifications, alone or in some combination, completely depends upon the app. For example, a game can use local API calls to update the tile when a new high score is reached by the player. At the same time, that same game app could use push notifications to send that same user new high scores achieved by their friends.
You're right with the assumption that you require a lock screen capability to be able to run background tasks without your app being started once. The main process would be to extract the part of your application that gets the data into a background task that is probably triggered by a timer and write some code to be on the lock screen.
When I first encountered that restriction I was kind of surprised, but in terms of battery performance this design decision makes sense: Only consume battery power if the data is absolutely worth it. If it's worth, it is also of interest having it on the lock screen.
On MSDN is a good overview about lock screen along with further reading links. It's much better than what I could type in here. Come back with problems related the implementation (which actually even better fits the purpose of SO). This blog might be useful, too.