ying qu
Building Blockchain Apps: https://www.buildingblockchainapps.com/
Rust and WebAssembly on the server-side: https://www.secondstate.io/ssvm/
SCJP 1.4<br /><a href="http://www.cise.ufl.edu/~sih" target="_blank" rel="nofollow">www.cise.ufl.edu/~sih</a>
Originally posted by Rishi Tyagi:
Michael Yuan,
I agree with you that in general we don't need this.
But if we want to download some fix amount of data and want to tell the user that how much time it will take to download data and also wnat to show the progress on the screen in this case we may need the same.
Building Blockchain Apps: https://www.buildingblockchainapps.com/
Rust and WebAssembly on the server-side: https://www.secondstate.io/ssvm/
Originally posted by Michael Yuan:
I guess I have to ask, why do you want to know this? The wireless toolkit uses your host PC's internet connection. The network performance on real devices could be very different. I do not see how that information can be useful.
Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
Originally posted by Mark Herschberg:
My experience has suggested that bandwidth is often the most constrained resource on wireless devices. Memory and speed, while limited, are fixed. Bandwidth is limited, and occasionally even more so, and sometimes altogether gone.
Building Blockchain Apps: https://www.buildingblockchainapps.com/
Rust and WebAssembly on the server-side: https://www.secondstate.io/ssvm/
Originally posted by Michael Yuan:
If bandwidth is so unstable and can be "altogether gone", it makes even less sense to predict download time based on historical data. Right?
Stefan Haustein <br />Co-Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/0672320959/ref=ase_electricporkchop" target="_blank" rel="nofollow">Java 2 Micro Edition Application Development</a>"
Consider Paul's rocket mass heater. |