Monthly Archive for July, 2008

Take screenshots on your iPhone

If you’ve ever wanted to get a perfect screenshot of a program on your iPhone, there’s a simple command that Apple has built into the iPhone and iPod Touch 2.0 firmware that lets you save a screenshot of the current app.

Hold the home button down and tap the power/sleep button. That’s it!

Can the iPhone really deliver the full web experience?

Visiteurs de MacPlus: Salut, merci d’avoir visitĂ©!

The iPhone browser appears to be king of the hill right now when it comes to browsing on mobile devices but just how close is it to being the full web experience? I decided to test its rendering capabilities when compared to some of the major desktop browsers. Read on, the results might surprise you!

Acid 2 Test

For some time now, the Acid 2 test has been used as the benchmark for CSS standards support. Several major browsers achieved support with Safari being the first in October 2005, followed closely by Konqueror and then Opera in the following year. Let’s see how the current versions of the browsers stack up:

As you can see, the iPhone, while not perfect, produces a decent rendering with just a few small defects. When you take into account that IE7 is the most widely used browser on the web, Mobile Safari suddenly seems very capable in comparison. After all, if IE7 is “good enough” to render most sites correctly, the iPhone ought to handle most pages just as well, if not better. The only browser here to score a perfect rendering was Firefox 3, though Apple’s desktop version of Safari (not pictured) also passes.

Strangely, Opera 9.51 has actually regressed on the Acid 2 result since 9.50 renders it correctly. Initially I thought it was a problem with my machine but clearing the cache and reinstalling gives the same result. Quite why this would be, I’m not sure. It’s unlikely that Opera would remove support for part of a web standard so perhaps this is a bug resulting from a recent change.

Acid 3 Test

Next up is Acid 3, the most demanding test of a browser’s capabilities. Whereas Acid 2 focused on CSS support, this new test is centered around ECMAScript and DOM handling and it tests several components vital to “Web 2.0″ functionality.

Incredible! Mobile Safari actually scores better on Acid 3 than the latest Firefox release by the narrowest of margins. Opera 9.51 is the most capable browser here with IE7 trailing behind with 12. IE8, due out late this year promises great improvements in standards support.

The Web. Mobile.

Apple and the Webkit team have worked very hard to really bring the full web onto the iPhone and for the most part, they’ve succeeded. Mobile Safari on iPhone 2.0 is a very capable platform for developers and it reduces the hassle developers face when targeting mobile devices. There’s still work to be done, however, particularly with rich media such as Flash and Quicktime support, and I look forward to seeing progress there in future.

Has Mobile Safari worked well for you? Are there websites that fail to behave? Post a comment and let us know!

Tying it all together

All applications fit neatly into one of two categories - those that repackage easily and those that are close to impossible. For the past 2 months I’ve been dealing with one of the latter, ArcGIS by Esri, a geographical information system. Basically, it’s a suite of apps for working with mapping data that’s split into many components.

The problems with packaging aren’t the fault of Esri at all. In fact, unlike a lot of companies, an MSI is provided on the disk which would normally make life easier. On an RM network however, the procedure is a little different from a vanilla deployment. Instead of using active directory to deploy the MSI directly, you have two options:

  1. Set up a “package build” workstation  - essentially a computer with a minimal number of packages. You then use the RM Application Wizard to perform a “before scan” of the station, install your software and then run an “after scan”, capturing the changes and creating an MSI file. On the plus side, this lets you change program settings before deployment which is a nice touch. One of the problems I often run into is that occasionally changes are missed, which makes some software think the install is corrupt. The other common problem is that user settings are often pulled into the MSI and during deployment these are sometimes unable to be set and the install will fail.
  2. The Application Wizard is also able to accept MSIs directly, repackaging them on the fly and generating shortcuts and other required files in the RM package format.

Unfortunately, both of these methods failed for ArcGIS. I suspect the software is just too big and complex for a simple repackage job - a basic install is over 1.4GB, with files and registry keys all over. That’s 1.4GB of software - no maps, no data! The MSI deployment would always fail with an MSIInstaller error 11606, complaining that it was unable to find “WindowsVolume%\”.

I decided the best way forward would be to somehow install the original MSI unedited. The RM system does support this by way of its package.ini files. Using these, you can set EXEs to run and MSIs to install. What I couldn’t do was pass the /qb switch to the MSI in order to do a typical, silent install. It was time for some scripting…

The workaround was to tell the package manager to execute my custom batch file, which itself called MSIInstaller /I setup.msi /qb after verifying the sizes of certain installer files. Frustratingly, when the batch file finishes, it seems to return a code that the RM package manager interprets as a failed install! Luckily, though there’s a switch in the package.ini file to ignore return codes and this seemed to do the trick. Big thanks to whoever at RM implemented that feature!

I also had to write an uninstaller batch file, again calling MSIInstaller with the correct product code, since the RM system now has no record of the particular MSI that has been installed.

In an ideal world, that would be it but I also had to install a service pack that was supplied as an MSP file. I couldn’t use method 1 above to package it because I couldn’t do the original install that way and method 2 doesn’t support MSP files. Neither, it seems, do the RM package.ini files, as you can only specify an MSI to run, not an MSP. Batch file time again, this time executing the MSP in the same method as above. Finally, a working installer that brings together the two worlds of vanilla MSIs and the RM system.

It took a little longer than our usual 2 day turnaround on software packaging but I’m pleased with the result, from now on it’s quite simple to install generic MSI files with just a little batch editing. Don’t get me wrong, the RM system has its advantages but this method is sometimes much easier than trying to work around strange repackaging errors.