It seems that using Flutter Web on iOS device(Safari and Chrome tried so far) with this plugin, if the audio is not ready(still buffering) if you try to play it, will block the execution. Should be handle or should be something to update in the documentation?
Same case on Flutter Web but on desktop device does not cause the same issue.
I experienced the very same issue but on flutter web. In my case, it turned out to be a wrong path. It worked in Chrome and Firefox, but not Safari. Once I removed assets/ from the path (which was in the example I found), then it worked on all the browsers.
Related
I learned dart and I want to access flutter, but I was surprised by android studio because my computer is weak.so,can i create android and apple applications with flutter without android emulator , with just flutter pack and vs code and browser
If you only work with simple UI widgets yes you can use the embedded development tools within the browser to get the dimensions of the device you working on like so
But, most of the cases there are libraries work differently according to the platform so it might work with the web but not with android or iphone and you can not test it without the actual device.
And yes VS code is a very good with flutter and might be better than android studio but it won`t make the difference you expected, in my opinion what make it faster is to use an actual device for testing and not using the emulator, also don't use a lot of application along side with the IDE, like if you are using spotify, listening to youtube video or following a tutorial just use your phone because browsers as bad as emulator.
You can use a text editor and the command line tools to build flutter apps and test them on a real device.
I wouldn't recommend it though.
You could give VSCode a try as it is a more lightweight environment.
Your computer should handle testing on a real device, which requires only a USB cable. Accessing the application in the browser would probably eat a lot more memory. You can read about how to use the real device with flutter here.
I was testing using rive animation in Chrome and it works perfectly, but as the appliacation is for mobile, I connected to android and... failed.
I get an error:
Since web works and mobile version does not I expect it to be a kind of a bug? Is there someone who solved it?
I am trying to make my webpage mobile friendly. So, I am using Chrome DevTools to design a mobile version of my webpage. I have it the way I want it to look in DevTools. I uploaded it to my website & viewed it on a actual mobile phone & objects are not in the same places as they are in DevTools. I used the iPhone 6 mobile design in DevTools and also view it on an actual iPhone 6. They don't match. Anyone else have this problem? I have read articles about this, but don't know how to fix it. Any ideas? Should I use a different emulator?
This is Chrome DevTools version on iPhone 6:
This is how it really looks on an iPhone 6:
DevTools technical writer here. DevTools is just a simulation of mobile devices. It can't truly simulate an iPhone. So it's always a good idea to check how it actually looks on the devices that you care about (like you did). I don't think there's any bug or issue here. It's just an instance where the DevTools simulation doesn't reflect reality 100%.
Mac users can use Xcode's Simulator (that's the actual name of the simulator) to emulate any Apple mobile device and see exactly how their website will appear on it.
You can use it to open Safari and access your localhost. I used it to fix issues on my website, issues that I could not reproduce in DevTools' device simulator.
Clear the cache for on your browser to ensure that your phone is accessing the most recent updates to your code.
Safari's Web Inspector is absolutely awful, and it keeps crashing on me. One of my colleagues suggested using Chrome Devtools to inspect Safari pages via Remote Debugging. I haven't found anything on Google for how to do such a thing--is that possible?
Safari and Chrome use different debugging protocols (initially these were very similar, but over time they grew into separate things). Thankfully, there is a Google project that does the translation between these protocols - iOS WebKit Debug Proxy. It doesn't mention desktop Safari though.
I'm playing around with a simple web app locally, and can't quite figure out why it is not caching correctly on the iPhone. I am serving a .manifest file with the correct MIME-type, and the site works perfectly fine with my local server turned on or off on desktop Safari, Chrome and Firefox. It is only mobile Safari that is failing to cache the site. Any ideas why this might be?
It seems to be an iOS bug.
I found out that mobile safari will always run into an application caching error if you have at least one web view opened and the you clear the browser cache. I think that clearing the browser cache will destroy the cache database. All accesses to the cache database will then fail. It seems that the browser creates this database only on startup.
To get the application cache working again close all safari views and finally close the browser by returning to the home screen. Now applicaton caching should working. Some mobile devices also requires switching on and off.
If you know a methode to detect this situation let me know it, please.
I had a similar issue but Safari and iPhone were both NOT working whilst IE and Firefox were working. The reason was complex. One was a misspelling of the word "manifest" in the HTML tag. Silly mistake and very frustrating that IE and FF still worked offline. The other issue was that I was using default.asp as the main page of my app and not including this in the manifest.
My app was mydomain.com/myapp/ and thus the browser never saw the "default.asp". Also, according to the HTML5 spec, the main page need not be in the manifest but apparently Safari sees that a little differently...
I can confirm that the bug is also present on iPAD running iOS 4.3.
I spent quite some time to make the offline application cache work on iPad. I can confirm that the workaround mentioned in the previous post works.