But what is the point of all that? If you have an iphone or ipad you can do everything except watch the live games, but even then you can still use the scoreboard function and the live scores update automatically. And if you really want to know what's happening you can still use the play by play function from your iphone or ipad.
Two reasons:
1. Presentation. The site might look OK on an iPad, but on an iPhone its tiny. You spend a lot of time pinching and zooming around on an iphone. Granted, functionality of the full site is still accessible from a mobile device, but its not as well presented as it could be. If presentation didn't matter, why would anyone bother making mobile sites at all?
2. Performance. The actual connection to the buzzerbeater website is done by the web server hosting the mobile site, not the mobile device itself. The way I designed it - the mobile connects to the web server, the web server then establishes a connection with buzzerbeater, retrieves (or sends) the appropriate info, parses it and packages it into a mobile response, and sends it back to the mobile device. Using this method, I reduce the amount of network traffic the mobile device uses by 90%, hence increasing the speed of the site. This was the original reason why I developed a mobile site - using buzzerbeater on the go (while on the train going to/from work, etc) was far too slow on my 3g carrier connection, hence I needed to design something a bit more efficient.
As I said in my previous post, this was a pretty complicated way in solving a problem - that is...developing a mobile site for buzzerbeater. If the BBAPI was to be expanded and included a few more web service calls to write information, that would be fantastic and make writing a mobile site a hell of a lot easier (and less fiddly and prone to error).