Is it possible to write rules for sending alerts when an app node or an app space starts or stops.If yes, which method from the list can be used for the same?
It's should be simple, use below method of the appnode
AppNodeRuntimeStateInfo
of the Appnode check it's status , if it is running send an alert.
Related
I'm developing an application with SWIFT, which sends the location of cars through a REST call. When the application goes to background after 7 minutes, the loop that is sending the location stops being sent.
Does anyone know of any way to keep the loop running?
In the documentation it informs that this is a normal behavior .. but it needs to continue making this call of REST.
You may need to enable "iOS background data transfer". Check here an article on this topic: https://topologyeyewear.github.io/engineering-blog/2017/11/20/background_transfer/
Good luck!
I need to notify user when a certain condition is met but that condition might or might not meet in months. I need to run condition check in background (even when app terminates) so that I could detect condition is met (even if it happens after 3 months). If condition is met then I need to send notification only to a single user (not all users).
I am not sure what is the best way of doing it. Local Notification or Push Notification? I can not schedule a local notification in advance because I don’t know when it will meet the condition. I think Push notification is not needed because I am sending only one notification to only one user in several days/months.
I also need to constantly run this check in background. I know it can be run infinitely in background by using location update (significant monitoring or background navigation). But my condition checking code doesn’t actually require location updates. As far as I understand, Apple allows only location update or network related task in background (for few minutes). That's why I am thinking of putting my code in background location update code.
In my opinion , I should use local notification and put my code in background location update code so that I could check constantly if certain condition is met. This background check will schedule local notification and show it to the user who is using that device. I don’t think it is possible to schedule a push notification by code running in background.
In summary, I have following 3 questions
Should I put my code in background location update? If not, what is the right approach of running my code infinitely in background without location update?
Will Apple reject application if I put my code in background location update while location update code doesn’t actually send/receive current location?
What kind of notification should I use in this kind of situation where I send notification to a single user after months? Would you use Local Notification? or Push Notification.
Please reply. Any help is truly appreciated.
Thanks in advance.
This is a bit of a tricky problem unfortunately.
Apple won't allow you to create long-running operations in the background. As you mentioned, you can add code in the background with location updates or audio, but neither of those are very good solutions since (1) Apple will likely reject you from the app store and (2) the user will probably close the app if they notice a big locations banner at the top of their phone (or a weird background audio signal), and closing the app will kill your operation. For any truly long-running tasks it's probably best to set up a server and run a cron job or equivalent long-running operation. It's the only way you can know that the task will continue running.
Sorry, I was just answering one at a time, but as I mentioned above, yes, they'll probably reject your code for that. As a rule of thumb: if you think the Apple-created code you're using wasn't meant for what you're using it for, Apple will probably reject your app.
It sounds like you should use a remote notification. If you do use a remote notification, you'll probably want some sort of backend anyway. You could use a local notification to notify a user after a few months, but you would need to know the exact time to send it up front, which it doesn't sound like you would.
In summary: Try to build a simple BE. Maybe use Firebase Functions or something, and also build an APNS system to send pushes. In the app, tell the server to start processing the information and send the push back when it's done. The situation sounds like a perfect use case for server-side logic.
Hope that helps!
I'm trying to connect to our push server via MQTT-Client-Framework.
There is no complication for connecting to server and with a few line of code i can connect to server and subscribe to topic.
but I have a few question that I could not find any direct answer for them.
1) How can I keep my client running at background?
2) What happen after device restart? how can I automatically connect to server after device restart?
3)Suppose I got an error during connecting to server. Will this library trying to connect in a loop? how many times it try? or I need to manage this myself?
4) The same 3 scenario for subscribing to topic?
Based on my experience on MQTT-client framework following are the answers to your questions/queries. I hope it clarifies your concerns and helps you to move ahead.
1) How can I keep my client running at background?
You can not keep your MQTT client running in background, as Apple doesn't allow any application to keep running for long time in background. Though if you override its not guaranteed your application will keep running in background. You can read more about background execution support in apple documentation.
Also refer issue posted on github for given framework.
2) What happen after device restart? how can I automatically connect to server after device restart?
Each time your app begin execution you need to connect to your server using MQTT client framework there is no auto connect mechanism available in MQTT-client framework. I suggest to write init your connection in specific controller which executes immediately after your app launch except same as AppDelegate
3) Suppose I got an error during connecting to server. Will this library trying to connect in a loop? how many times it try? or I need to manage this myself?
If your MQTT-client fails to connect your server, you need to handle it yourself, library doesn't try to auto connect as mentioned in previous answer. I have written sample code as below. Use NSTimer for auto connect to server.
[self.mqttSession connectToHost:MQTT_HOST port:MQTT_PORT usingSSL:NO connectHandler:^(NSError *error)
{
if(error)
{
// Application fail to connect to server, write your code to auto connect here
}
}];
4) The same 3 scenario for subscribing to topic?
If your broker server has configuration to track your existing subscription for individual users/client then you don't need to subscribe each time.
Otherwise each time you need to subscribe to same topic on successful connection. Use following MQTTSessionDelegate method to subscribe.
- (void)connected:(MQTTSession *)session
Happy coding :)
1)Project->Capabilities->Background Modes. There has some options for allowing your app to run at background.
2)Generally speaking, MQTT will not be disconnected to the server if your app is allowed to run at background, but i think you would better check up the connection and maybe re-connect MQTT to your server when the app become active again.
AppDelegate-> - (void)applicationDidBecomeActive:(UIApplication *)application;
3)Unfortunately, yes, it will. And you have to manage yourself.
4)I can't help.
For your first question:
Details on how to run in the background on iOS can be found here. This link also lists the actions that Apple allows to run in the background, if your app does not meet those criteria then it is likely to get thrown out of the app store by Apple.
The list also shows which UIBackgroundModes to place in your Info.plist to flag that your app needs background access.
The other 3 I can't help with
We all know that Apple doesn't allow app service to run in the background, so MQTT will be disconnected in the background mode.
Now do one thing use better frameworks for MQTT like this in this framework you will get auto-reconnect and callbacks and many things.
So When you receive a call back that the MQTT is connected, immediately subscribe to all the topics that you have.
And if you want to get all missed messages then you need to change the MQTT configuration to like 'clean = false'.
I have signed with RIM for BlackBerry Push Service Evaluation Credentials so that i can test my push notifications implementation.
I used the low level sample as my server to send the push and i build the client side.
Everything worked well till now. Suddenly my application stopped showing the received push messages. Instead every time i send a push i can see in the right up corner an arrow loading (like something is being processed) but no push notification is shown.
Is really strange , cause i didnt do any change on my code.. Any ideas?
EDIT
Actually i found out that when i deploy the app in the device , the push doesnt work as i described. When i restart the phone though , the push works fine. I think maybe is because , i call the background process for listening for push , when the phone gets restarted. Have a look on my code: http://codepad.org/ddJvyOox
When i launch the app , i register to BIS for push but i think i dont listen for them. I do that every time the phone restarts.. Do you think this might be the problem?
Curious are you behind a firewall by any chance?
To consider adding firewall exceptions to have access for the eval/prod PPG then need to add the IP addresses below:
Eval:
68.171.224.57
68.171.224.59
Production:
74.82.67.65
74.82.67.66
74.82.67.70
74.82.71.70
Another high level check before diving deeper; are you able to login into the EVAL CP Portal URL Your credentials might have been reset/expired, if so contacting blackberrypushservices#rim.com to help with access to the portal.
On the application level, the app needs to connect to the InvokeManager signal at the beginning.
onInvoked() function would first check to see the bb::network::PushService instance exists and the appID is stored.
connect(m_invokeManager, SIGNAL(invoked(const bb::system::InvokeRequest&)),
SLOT(onInvoked(const bb::system::InvokeRequest&)));
The application will extract the push message from the invoke request by passing the invoke request into the PushPayload constructor if the action property of InvokeRequest matches the string constant BB_PUSH_INVOCATION_ACTION from the onInvoked() function.
Do any of these suggestions work? Otherwise please explain more in depth which client/server code you have implemented and the bar-descriptor file's properties.
Curious to know where are you located as there might be the likelihood of Push Service outage if Push Notifications suddenly stopped working.
Using GPS, how can I notify a cab operator in the area if I wanted to be fetched? I've seen a lot of apps regarding finding a taxi and fetch you wherever you are, example http://www.taxifinder.com/ .
I'm wondering what's the idea behind it?
Does the cab operator need to have a server where I can access it and tell them I need a taxi?
I really don't know how to do it, can someone enlighten me. Steps / list on how it should be done.
I don't know the scalability of it but here is a try:
A webserver that can process the request from the frontend and processes it. A simple case scenario would be that it receives the requestor's information including GPS coordinates. It would then check for drivers in the vicinity that are registered to the webserver and dispatch the push notifications to them.
A push notification system to push the notification to the cab driver/s. Check out Google Cloud Messaging although I believe there are no options for filtering the users in this case.
A web/native application that communicated with the server.
ps. The Taxi driver/s will have to have their devices registered for the push notification. On a second thought, the Taxi driver[s]' location access would be required as well so as to filter the drivers that would receive the dispatch request. Then maybe add a functionality where if one driver 'accepts' the dispatch, the user is notified and the other drivers cannot accept it any more.