Push mail; traditionally enterprise handheld, the Pearl’s being a consumer non-QWERTY model
Still no switch towards touchsreen models with 9000
Official, current OS: 4.2 / 4.3; new: 4.5
(Unofficial) betas already available: A2DP, new fonts(!), multimedia streaming, new Web browser, HTML e-mail (BES/BIS-side support needed), HE-AACv2, somewhat better Web browser (in-page search, save page, zoom); ref: 2589
The biggest advantage on all mobile platforms: No need for PDA/handset-only pages; you can access full pages – see the fate and scarcity of WAP. Possible problems:
>500k HTMLs (for example Snitz Forums 2000 or even YouTube), particularly under PPC2k2 (max. 100-120k HTML without crashing)
Rule of thumb: under PIE / IEM, memory usage is about an order of magnitude more than the original size of HTML. With alternate browsers (particularly with Opera Mini and, to a lesser degree, Opera Mobile) this isn’t an issue
desktop ActiveX : not supported, not even on WM (not an x86 architecture)
Java applets (login, authentication): custom third-party JVMs only and on WM only (no applet support at all on Symbian / BB); restricted, max. JDK1.4; no official support from Sun.
Flash incompatibility and problems
Less important HTTP/HTML problems, bugs and restrictions
$30; built-in Flash (weaker than that of Adobe / Macromedia; has CPU usage problems), SVG (Japan!) and Java VM; multitab (max. 5 – as opposed to IEM plug-ins or the Opera s); minimap; iPhone-like acceleration & dragging
Advantage: uses its own fontset, which makes rendering possible even on 320-wide screens. HOWEVER: it only supports Western characters; meaning no support for Eastern European languages. The latter can be somewhat fixed by converting the special, Unicode-only characters used by them to 8859-1 on the server side; ref: 1327
PIE can use similar fonts to look pretty much the same condensed (Ref: http://forum.xda-developers.com/showthread.php?t=250789 )
No support for hi-res ((W)VGA) screens; no saving at all (ref: 1302), not even copy from pages. Doesn‘t use client-side caching at all; it is only able to download to built-in storage; no upload etc.
Pretty much discontinued; BitStream now is concentrating on a MIDlet-based new version (OEM-only ATM); ref: 2485
They greatly extend PIE‘s capabilities (multitab, resource saving, User-Agent GUI-based setting, hardware buttons used for navigation / program usage, GPS-based, location-dependent services, address bar macros, altering the way the document is scrolled by D-pad etc.)
PIEPlus : probably the best and most featureful (saving, tabs, buttons etc.; unique feature: Pocket View one-column view for pre-WM2003SE browsers – n.b. “ One Column ” was only introduced in WM2003SE)
MultiIE : used to be better than PIEPlus; however, this doesn’t seem to be the case any more
ftxPBrowser (Ref: 551): free; in pre-WM5 times, used to be highly recommended.
Mostly incompatible with WM5+!
Webby (Ref: 1334, 1828): .NET Compact Framework-based and is, therefore, a bit on the slow side. However, it’s become better and better over time and offers for example extensions like Mozilla for for example ad filtering. No One Column mode. Brand-new Touch Browser (ref: 2593) is pretty similar in its functionality (or, currently, the lack thereof).
Spb Pocket Plus 4 (Ref: 2250): while in pre-4 times it was definitely worse (it didn’t even offer on-screen, easily clickable tabs) than PIEPlus or MultiIE, this is no longer the case: version 4.0 has fixed this, along with other goodies like accelerated screen dragging.
Operating system-level, runtime problems not fixable on the code level, unlike, say, pre-WM5 PIE CSS crashes
Driver memory usage: NetFront and Opera Mobile used to be problematic, particularly under WM2003SE (Ref: 882)
Optimizing for PDA / phone 1: small-screen rendering / PIE - 1
Low screen resolution results in having to scroll horizontally: “ One column ” for the rescue. Supported by all browsers except Thunderhawk
PIE received One column in WM2003SE; previously, only the weaker “ Fit to screen ” was accessible (this remained as “ Default ”), in addition to “ Desktop view ”. Example ( Desktop / Fit to Screen (Default) / One Column ):
Optimizing for PDA / phone 1: small-screen rendering / PIE - 2
Therefore: in WM2003SE PIE’s (where there’s no One Column and “ Fit to Screen ” ( Default ) often isn’t sufficient,
PIEPlus (explicit Pocket View mode)
Use an alternate browser like Opera Mobile (WM2003) or Thunderhawk (compatible with even PPC2k / 2k2)
Optimizing for PDA / phone 1: small-screen rendering / Opera Mobile
Three modes – as with IEM. N.b. One Column is buggy: the horizontal size is 240 pixels; that is, it’s only really usable on QVGA devices used in Portrait – preferably not in Landscape and definitely not on a (W)VGA hi-res model.
NetFront : Three similar modes: Normal, Just-Fit (about the same as “ Fit to Screen” / “Default” in IEM), Smart-Fit. The latter is the best: it’s like One Column , but still tries to render contents horizontally where applicable, unlike IEM
Reducing data usage - 1 (Content-Encoding: gzip)
Problem: data connections can be expensive unless you have a flat rate. Pre-3G connections (GPRS, EDGE stb) are slow, too.
All WM browsers (starting with PPC2k PIE too) support gzip / deflate HTTP response body compression ( Accept-Encoding header!)
Several forum engines (e.g., vBulletin ) support GZIP’ing if it identifies the client as a mobile device. See header list: Ref: 796
You still need to find out whether a mobile user is accessing?
Several users use User-Agent spoofing: check for UA IEM headers to find out whether it’s a real desktop browser or IEM with spoofed User-Agent. Ref: 1125
Reducing data usage - 2: client-side optimizing
If the server doesn’t return compressed content, you can still reduce data usage:
Toonel (Ref: 1002): runs on Pocket PC; free; also supports SMTP/POP3
OnSpeed (Ref: 494):
MultiIE, PIEPlus and Webby automatically supports the online services; the first two ( Toonel / OnSpeed ) can be used with all Windows Mobile Web browsers allowing for proxy usage (that is, everything except Opera Mini and TH – not a problem though as they’re content-stripped / compressed already)
Compatibility – 3: W3C’s “Web Compatibility Test for Mobile Browsers” – 5 – Desktop browsers
Bottom: Firefox 3 beta5; Internet Explorer 8 beta; IE7; top: Opera 9.5
Avoiding future problems with Windows Mobile browsers 1: the problem of (Inline) Frames - 1
PIE : the number of (standard, not i-) frames is restricted (10/12 at most for pre-WM6/WM6+, respectively). One of the most widely known example of the affected pages is freemail.hu (pics: PIE, Opera Mobile )
Avoiding future problems with Windows Mobile browsers 1: the problem of (Inline) Frames - 2
Inline Frames (IFrame) are in no way supported by pre-WM6 PIE and TH.
Therefore, no Gmail / Yahoo Mail dynamic address completion is possible (which works in Opera Mobile and Minimo )
WM6 Iframe and standard frame demo (see “ Iframe support ” row in 1828 Chart) 04/29/10
Avoiding future problems with Windows Mobile browsers 2: Cookie-related problems
NetFront : a known problem for years: doesn’t take DST into account: if DST is not used (it’s not summertime) and the NF client is given a cookie expiring in less than an hour, it’ll be discarded at once
Used to be a huge problem with the index.hu forum (not any more)
TH temporary cookie bug requiring the manual copying of cookies; see the 2005 version of Browser Bible for a client-side, manual fix.
Avoiding future problems with Windows Mobile browsers 3: Language & encoding problems (Ref: 1327), internationalization
Content-Type charset attribute: HTTP header vs. meta tag
NetFront is entirely different from the rest – and is buggy when 8859-1 is used along with special 8859-1 punctuation.
Opera Mobile is pretty problematic at POSTing special contents (special 8859-1 punctuation and everything different from 8859-1).
Never ever return special punctuation chars from the server
for example, convert them back to the basic, non-formatted chars: upon recognizing these two browsers, dynamically convert the chars on the server for NF and (for editing; see below) Opera Mobile
If an Opera Mobile client edits a non-8859-1 document (like an article or a forum post), convert all special Unicode characters (like ő and ű) to HTML char entity codes (ő and ű with ő and ű, respectively). These entity codes are correctly POSTed back by the browser
Avoiding future problems with Windows Mobile browsers 3: Language & encoding problems - 2
Thunderhawk : 8859-1 should always be used whenever possible – that is, when the source language can easily be mapped to 8859-1 ( User-Agent check )
Accept-Language request header: user-preferred language
Can only be set in PIE and Minimo; all the other, non-proxy-based solutions (everything except TH, Opera Mini ) need a header-altering proxy server
Avoiding future problems with Windows Mobile browsers 4: File download (ref: 1302, 2590)
Content-Type: text/plain response problems with binary content: IEM & NF don’t try to decide whether the body is binary and blindly render it – as opposed to IE on the desktop. No such problems with other Windows Mobile browsers. That is, make sure Content-Type: is correctly set on the server to allow for binary downloading to IEM & NF!
NF & Opera Mobile : They send out download requests twice (vs. desktop) – this is why for example RapidShare doesn’t work
never reject double download requests!
Referer -related problems: before WM5, PIE (and Thunderhawk even now) don’t pass the Referer header
don’t trust the Referer header always being sent in order to deny out-site download requests
Acceleration: multithreaded download (see FlashGet on desktop); two multithreaded apps:
Just-released Adisasta WinMobile Download Accelerator 2.0 (do NOT use older versions because they’re slow!)