Having built a series of five mobile device emulators (of which the Microsoft Phone was the hardest) which are used by various online services on the Internet, I decided to make them available here as well with some technical background as the operations.
The emulators, because that is what they are...they virtually emulate the real different devices, it's not like I have the physical device, load a webside and show a photograph of it. The base is a 'chomeless' browser engine that prefers HTML5 but will degrade to any version of readable HTML. The remaining two rules are simple.
The devices were chosen to give a reasonable spread of different technology and types in use in the twenty first centuary and consist of: iPhone, Samsung, Nokia and BlackBerry.
If you're interested in how it works without compromising security, after all anyone could use it to test new all-singing-all-dancing viruses and other malware to take out systems, see the section on remoting.
Mobile website emulator service is currently offline.
The images above shows how this website responds to the different mobile operating systems. The goal was(is) to keep it navigatable, identifiable and usable at all times. is it a success? Is your website a success on small screen devices? If not, you now know where to find me, and I'm always willing to lend a hand.
Designing emulation and simulators for public use that need to respond to (unknown) remote references and accurately reflect the end result needs careful consideration and engineering. Besides the ability to accurately undertake what an actual devices will do and display the results, the security aspect is the most important to deal with first.
Rules of engagement - Expect anything and everything and deal with it appropriately.
You may assume this very noble, but running a system that needs to adhere to these rules in an environment that supports many other (mission critical) services is just not an option at all, ever. If this happens, you may as well put up an open proxy to the world and sit back and watch as the lights go out.
Exposing public interfaces that can call on other public services for source data to act on is a magor security risk and should be avoided.
Solution - 'Keep them separated'