As previously stated, the article written by Pavel states “Blynk app can “ask” your hardware for the data when the app is open. When Blynk app is closed or is running in background, data is not requested.”.My assumption was the iPhone would act the same as the Android. I would like to cut down on cellular data traffic as it costs $.
As for your question on Terminal or Serial Monitor, the Serial.println(“sending data”); would be to the Serial Monitor inside IDE. Its a way to see if the phone application is still requesting data after being put into the background.
BLYNK_READ(Virtual_chan) “ONLY” gets fired on Hardware side when the “TIME” set for refresh has expired. If the phone app. is “OPEN”, this process will continue at that rate. Once the phone app. is closed or sent to background (hit home button on iPhone), its suppose to stop making those refresh requests. Works as advertised on Android, not so much for iPhone.
Does this need to be filed as a bug? Is there another setting I’m not aware of that determines how long the fetches occur as being sent to background.
“Blynk app can “ask” your hardware for the data when the app is open. When Blynk app is closed or is running in background, data is not requested.” because Android and iPhone seem to be handling it differently.
At the moment, Blynk_read is not triggered by server if there is no open network connection with the app.
When transferring app from active to background, iOS app holdes its network connection for some “special” short time to finish queued requests and to be ready if user gets back shortly. The exact time is defined by iOS system and depends on available resources, battery, whether “low power mode” is on, etc., etc.
BTW, there are cases when network connection is not closed even the app is in background (both on iOS and Android). E.g. if you have a GPS widget set to work in background.
Please consider to not depend on Blynk_read not being called when there are no open applications. The initial goal of such limitation was to save processing resources on our servers - AFAIK this limitation may be removed in the future.
Maybe we need to introduce a new command which app should send on transitioning to background, but I believe this is a low priority, @Dmitriy ?
Just a thought on possible implementation. Can the phone app. pass along a call to a function just like it does for BLYNK_READ(). Example: when the phone app. is sent to the background, call a new function like BLYNK_PHONESTAT(param=phone status)…Note: could be used to pass other phone status as well.
One could then capture the param if desired or ignore it entirely by not including the function in their sketch. So, if the status param was BACKGROUND, the hardware can set a flag to STOP updating virtual channels to cut down on traffic. It saves cell costs and decreases server loads. This also would not break any ones hardware since it is passive in nature.
if your app. is running as shared OR out of actual account
Too many permutations to list. For example:
If application was previously left in RUNNING state:
-Fires BLYNK_APP_CONNECTED & BLYNK_APP_DISCONNECTED when brought to foreground then background…Good
-Fires BLYNK_APP_CONNECTED when brought to foreground BUT if you stop app. then switch to background, the BLYNK_APP_DISCONNECTED is never called. On the harware side, I would be stuck sending updates forever.
If app. was not left running and then app. brought to foreground and RUN button pressed, you never get BLYNK_APP_CONNECTED. On the harware side, I would never start sending updates.
The iPhone is similar but has its own unique anomalies.
As you can see from above, the hardware would definitely get confused and break. This is pretty simple to duplicate on your end to see what I’m talking about (using your example code).
That is why I was thinking about a different function to simply update Foreground/Background status. Per Eugene’s comment, I’m wondering if the existing functions are tied to network connection status. This would also explain differences between phone platforms. The other issues with Shared Access ?