The flow data that can be loaded via the REST API (https://api.flowground.net/docs/v2/#retrieve-a-flow-by-id) contains the properties data.attributes.status and data.attributes.current_status. In my case both have the value "active". What is the difference between these two properties?
data.attributes.status this can be active and inactive. This is basically how we want a flow to be.
data.attributes.current_status shows the status as is.
For example:
You have an active flow. It has both data.attributes.status & data.attributes.current_status as active.
Then you stop the flow and for some period of time (while the pods still running and then shuts down), it will show data.attributes.status as inactive and data.attributes.current_status - active.
After Admiral does it's job, the status changes to inactive on both data.attributes.status & data.attributes.current_status.
Related
I am reading through the documentation for the Apple HealthKit and am stuck on understanding the difference between a query being registered for background deliveries vs. running on the background. This excerpt from the explanation of anchored object queries seems to differentiate between the two:
Anchored object query. In addition to returning the current snapshot of modified data, an anchored object query can act as a long-running query. If enabled, it continues to run in the background, providing updates as matching samples are added to or removed from the store. Unlike the observer query, these updates include a list of items that have been added or removed; however, anchored object queries cannot be registered for background delivery.
Source: https://developer.apple.com/documentation/healthkit/reading_data_from_healthkit
I am confused about the difference between the two types of "backgrounds." Does the statement "continues to run in the background" really mean "when the app is in the foreground, this query will continue to run without needing to be re-called?"
Background Delivery works like background app refresh, or GPS significant location change events. It wakes up your app to allow you to act on some event. In this case whenever a health sample you are listening for, is added to the store, your app is woken up (once within a given interval) in order to be able to process the event.
Think of a running/cycling app, where a user is trying to tracking their progress on a long workout. The app won't remain open the whole time, but you can ask for the number of steps every X interval so that you can keep your UI updated, or in sync with a server.
More info on background delivery: https://developer.apple.com/documentation/healthkit/hkhealthstore/1614175-enablebackgrounddelivery
The other reference to background, means that it continues to run in another thread, while the app is open. So if you query for heart rate, you can be notified every time a reading comes in, as opposed to just receiving 1 result and having to check every X seconds for a new one
I've got an iPhone app where you create an account, and while you're logged in, you can be either active or inactive. To be clear, even when you're inactive, you're still logged in. I want to make it so that if a user is active but hasn't checked the app or used it for 45 minutes, they are automatically made inactive. Is that possible? If so, how would I go about it? I'm not trying to force a log out, but rather change their state from active to inactive. so in firebase, for each user, it has a variable for isActive. I'm trying to make it so that turns from 1 to 0 after a certain amount of idle time.
Thank you!
This can be done by leveraging a Cron Job.
There are two things that will need to happen.
You'll need determine what mechanics indicate a user is active or not. For example, every time the users taps a Search button, that timestamp is written to Firebase. As long as the difference between that time and the current time is less than 45 minutes, take no action.
A cron job to trigger code* that compares a current time stamp to the written time stamp and if greater than 45 minutes, set's the user to inactive. (actually just querying for all users where current time - posted time > 45 minutes, and set them all to inactive)
*code could be integrated with Firebase Cloud Functions, or your app could be observing a node that's set as well.
The app could also trigger this sequence but if it goes offline the active/inactive node would not be set or cleared. However, there is an onDisconnect Firebase function you may want to look into as well
We have a little app we've used to automatically log an employee out of an account if they go afk, and this design pattern works well.
Make a timer variable and make it work. Attach a mousemove event to reset the timer not stopping the timer. If the time elapsed is greater than your desired limit call the signOut method in firebase.
why mousemove?
To notice the inactivity.
Actually I am a web developer most of the time dealing with javascript. I don't know which programming language you are using so use similar method as setTimeOut in javascript.
I am developing a web application which shows the status of the all available smart devices in my hub. and I can also control the devices from this application.
For example, if I want to turn on the switch I send "on" commands with appropriate contexts to smartthings API.
In order the send commands, the devices should be active (it should respond to commands).
And I got the state of the device through API call (device.status) but this state found with the device object is not accurate.
For example, the Econet valve is actually responding to my commands.but it states shows INACTIVE.
So I can't trust on the values get from "device.status" parameter. is there any other approach?
Update: In order to know the current value of devices and take actions according to the current value, we need to know whether the device is responding or not. Currently, we cannot rely on the device status like ACTIVE, ONLINE because even after disconnecting the devices from networks the states doesn't change.
I've got an iOS application that requires the user to log in before using its features. It uses Bluetooth and location services in the background after logging in. The typical use of the application is:
User logs in -> transition to 'lobby' page
Selects 'begin logging data' -> transition to 'logging' page
Bluetooth and Location services run in the background
User locks screen and app runs in the background (this needs to last for 8-10 hours)
The way the app handles logins is via a session token which times out after 12 hours.
If I leave the application running overnight, however, upon resuming the application it starts up the log in view controller (a.k.a. the root view controller). I need the application to resume on the page it was closed on and can't seem to find any reference online as to how to do this.
I did find something about saving and resuming state but could get a definitive answer. Any help?
UIStateRestoration is the mechanism that Apple provides for your application to be archived when it is backgrounded. Even if the app is eventually terminated by the operating system, UIStateRestoration provides APIs to restore the state of your application to where the user left.
Resources:
State Preservation Programming Guide
If you didn't define a background task, the app will be killed once it stays over 20 minutes in background
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
I'm working on an Cordova mobile app, currently targets iOS platform. I would like to know how to handle errors when the user quit the app abruptly on middle by pressing the Home button. Let'say the user has clicked a button that navigates the file-system, read a file, encrypts the content and save into a different location. In the middle of the process the user has clicked the Home button and so the app has moved to background. Can I expect all the operations will complete even-though the app has moved to background or do I need to handle these cases?
I would say there are two things you need to know:
1) iOS will not perform background operations unless you explicitly tell it to do so, so in the case you described, iOS would just cancel the actions that are currently active in your app. However, you have the chance to perform some operation between the point in time where the user pressed the home button and the point in time where the app actually changed its status from active to not being active. This can be done in the AppDelegate, since this is the component that controls the lifecycle of your app. The method you use here is - (void)applicationWillResignActive:(UIApplication *)application, this gets called before your app enters the background, from the Apple docs:
This method is called to let your app know that it is about to move
from the active to inactive state. This can occur for certain types of
temporary interruptions (such as an incoming phone call or SMS
message) or when the user quits the app and it begins the transition
to the background state. An app in the inactive state continues to run
but does not dispatch incoming events to responders.
So, this would be the place to either cancel the current action or save the current state so that it can be restored later.
2) iOS allows for multi tasking, but its quite tricky and only allowed in certain cases. This means you can not perform random operations while your app is in the background.
Some of these cases are:
Core Location Update: If you are using Core Location in your app, your app can receive updates on when the GPS position of the device changes and gets the chance to perform some operations in the background based on the new GPS data
Voice Over IP: The app provides Voice-over-IP services. Apps with this key are automatically launched after system boot so that the app can reestablish VoIP services. Apps with this key are also allowed to play background audio. (from the Apple Programming Guide on Background Execution)
Background fetches: With background fetches you can perform network requests on a regular basis, however you are still not able to perform the operations at points in time that you can precisely specify, you can rather tell iOS that you want to perform network requests in regular intervals and iOS will schedule the requests for you. Here is an excellent read on background fetches.
Hope it helps!