I can see the usecase for this. Especially abroad (expensive data) and in areas with poor data (Edge connection or even GPRS) this would be a life-saver.
>in areas with poor data (Edge connection or even GPRS) this would be a life-saver.
I have had Opera Mini installed on my iPhone since it was released for exactly this reason—it performs noticeably better than Safari when at the very fringes of data service coverage. It's not really a situation I'm in terribly often, but it has saved the day a handful of times.
I've been a massive fan of Opera Mini for years now, and this is really impressive! I wonder how it's implemented? Years ago, on Windows Mobile (not Windows Phone) it struggled with Javascript. Is that still the case? Is it merely UIWebView + a proxy to do the compression?
This release has a secondary new mode that we hope will replace the older OBML-without-javascript mode over time, as devices get faster. It's basically Opera Turbo v2, attempting to get optimally efficient network benefits of the old Opera Mini to work with full web rendering using webkit. (On iOS Apple have been thoughtful enough to make it possible to make it possible to replace the network layer of the built-in webkit component.)
Cool, so OBML remains on Presto until it is phased out completely?
Can you point to any papers/specs/sources concerning OBML or the likes?
I was always fascinated by it (and have been trying to do something similar for my own amusement, most recently with webkit), but while getting a serialised render tree to display is trivial, making something half as usable as Opera Mini has always been seems impossible.
I believe there is still a huge market for smaller devices (probably smaller than feature phones) on which this style of web access is much thought after.
I believe it does server side compression and JavaScript parsing, then sends it to the device in a compressed format. So technically it's not really even a web browser.
Kind of. Current version has 3 modes.
Regular browser, Mini mode (which sends pre-rendered web pages back to the phone) and Turbo mode which compresses images and videos.
Using Turbo mode for now, best of both worlds - data savings and compatability with all websites.
Since Apple only allow browsers use built-in webkit engine in iOS. The turbo mode is use Opera's proxy to compress data, and render them by webkit. Therefore the user agent says they are AppleWebKit:
Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) OPiOS/8.0.0.78865 Mobile/11D201 Safari/9537.53
But for "Opera Mini" mode, it will render the page at their server, then send to iOS device. so they can bypass the limit from Apple and save many bandwidth. Therefore the user agent is complete different:
Opera/9.80 (iPhone; Opera Mini/8.0.0/35.3088; U; zh) Presto/2.8.119 Version/11.10
Wow. I'm surprised that Mini is still that far behind Desktop (2.12.388), but I guess updating Presto isn't exactly a high priority compared with moving to Blink.
As a side note if you haven't checked out Opera's Other Browser "Coast". I would really recommend playing around with it. It feels closer to the Web as OS concept than anything else I've seen.
I like almost everything except I quite detest the fact that it must reload every time I navigate back and forth. That previous versions DIDN'T do that was a huge draw for me.
Perhaps the devs could make it so it only reloads if you tap the back/forward buttons, and doesn't if you use the back/forward swipe gestures. I think that would be ideal both functionally and aesthetically.
The reason for not reloading is two-fold:
1) Much snappier browsing experience.
2) Reduced data usage.
I really like the built-in QR code scanner. I noticed that my private certificate authorities I've installed don't seem to work -- is this an iOS limitation?
The "Opera Mini" mode renders webpages into a specialised format (OBML), so they function more like interactive images; I'd bet they finally implemented a OBML rendering/UX layer for iOS. "Opera Turbo" would be a standard iOS UIWebView except it routes your requests through a caching and optimisation server for smaller payload and quicker downloads.
Chrome on iOS renders in a UIWebView, too, and enables a similar "bandwidth saving proxy" technique by default which achieves similar results.
Sadly, I seem to only be able to install the previous version of the app which is a vastly different experience to the screenshots in the App Store. It might not have caught up to Australia's cache servers yet.
