Coinciding with Google's latest release during Google I/O the other day, I'm finding Google Assistant intermittently hangs with the 3 dots typing animation forever, even after it receives what appears to be an error-free, fast response from my bot.
Usually, when I repeat the utterance, GA gets out of its funk and responds, but not always. It happens both in the simulator and from my Android phone, but more often from outside the simulator.
This never happened before a day ago. Has anyone else noticed this? Is this a known problem? My bot hasn't changed significantly to warrant this kind of erratic behavior at a GA-level. Normally, GA should timeout, not hang showing animation dots.
I have been using Actions SDK V1 on Node, not sure yet if that has something to do with this problem, and should probably migrate to the new SDK.
I went ahead and migrated my Action to the new Action SDK V2 for Node today and so far I've seen no hang behavior yet after a few hours of testing. It appears as though Google's backward compatibility may not be all there.
I plan to make a progressive web app to display the time remaining in a meeting. I need this to keep the display always on. Is there any way for a progressive web app to avoid screen to go to sleep and blank ?
Update July 2020:
Chrome 84 now ships with the Wake Lock API https://www.chromestatus.com/feature/4636879949398016 which can be used to prevent the screen from turning off.
You could use the Standby API however support is still limited.
Then there are hacks such as playing a video infinitely or the nosleep script, however from my experience they don't work consistently either.
Here's the documentation for the Wake Lock option in Chrome:
https://developer.chrome.com/articles/wake-lock/
Note that it's only available on HTTPS. (Normally not an issue, although some non-public internal applications can be standard HTTP.)
I have an iPhone application I'm testing - I've just noted when testing it on a device that sometimes when I resume it (i.e. launch it again in the "multitasking" sense when I expect it to appear and continue on) the startup image appears. As if it totally restarted.
Would this be an indication of memory issue with the app?
Good question. I've noticed this as well and wondered also. It might not be this app that has an issue though, but other apps have required extra memory which caused the system to take memory from this app. Im not sure exactly because (if I recall correctly) the resumed app restarts on the screens it was on, so it didnt lose state. I wonder if in this case, iOS has unloaded some of the backgrounded task's code and its taking a bit of time to read the code back in, so it puts that screen up. However, if this was the case, then the app would really need to be idle and not active in the background.
I've noticed that since iOS 4.0, the apps I developed started to not "exit" when the home button is pressed, but rather they stay in the "system tray" thing which pops out when you double click the system.
At around the same time, I noticed that the battery in my phone starts draining a lot faster. Then again, theoretically all the app should be using right now is only memory, because it is not currently active.
Which begs the question, has there ever been any benchmark on what causes the iPhone to drain the most batteries? Perhaps opengl calls, which use the graphics card would consume quite a bit? Or maybe just having the apps active mean there's less memory, and this causes faster battery loss (say, because the memory allocator must do more work etc)?
I am keen to know what other developers have tried to do to optimise battery usage.
its not opengl or allocations that cause the battery drain in fact the variables are saved on the hard disk when the application quit. They don't stay in memory cause this wouldn't be possible with running all apps at the same time. (see comments)
special thanks to Stephen Furlani for this guide in documentation
I think the only ones that can cause the faster drain are background processes that still accepted to be run in background like the voice over IP feature from Skype. (the features where big announced at the iOS 4 SDK preview back then). Background audio/video, network transfers like pandora etc. (I can't name all) but not every app!
And by the way, I also noticed that my battery sometimes not hold as long as possible on other days. But I can't locate which App cause that :(
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!