Vodafone NZ set 10am Tuesday 8 July (today) as the time they would release the official iPhone pricing and plans – and their website was then inaccessible between 10am and 10:45am.
I wonder how many NZ's are interested in the iPhone? Especially now that the pricing has been released.
To view the Vodafone pricing details click here.
Today Apple officially released the iPhone 3G – the next generation of the iPhone. Adding 3G speeds, support for 3rd party software, Assisted GPS, combined with a major drop in the pricing takes the iPhone to the next level – and it was already a pretty convincing package to begin with.
Vodafone New Zealand will be selling the iPhone in-store on July 11th. There will be two devices available: the iPhone 3G 8Gb for USD$199 and the 16Gb model for USD$299. This pricing is for an iPhone on a 24 month contract. It sounds like you can still purchase an iPhone without a contract (i.e. for prepay use) for somewhere between NZD$800-$1,000. There is no news from Vodafone NZ on the plans being offered.
So – July 11th it begins.
Why all the hype? Has Apple's marketing got to me? Well, yes it has. But it is not just hype, it is based on some pretty convincing facts. The iPhone package has already redefined the mobile phone – it is now redefining our expectations of mobile computing full-stop. Let me explain…
The Hardware
The iPhone hardware gives the average person unprecedented power in their pocket, and now for a pretty impressive price
:
All of these hardware features are packed into the slickest phone design ever. As the Senior Vice President of Walt Disney stated: "It really has the ability to pack the power of a laptop into the size of a smartphone." The hardware features combined with the OS X operating system means that Apple potentially fill more than the mobile phone space, but also move into the ultra-mobile computing space. With rumored 7 inch devices running the same multi-touch interface it will be interesting to see what comes next from Apple in this area.
The Software
It is not just about hardware with Apple – their software is consistently beautiful and simple. It is intuitive and appealing. The software on the iPhone covers off the needs of 80% of the market:
PIM software to manage Contacts, Calendar, Email and NotesAnd that just scratches the surface. These tools are not new in themselves – but as usual Apple takes them to the next level. It is a pretty convincing toolkit in your pocket, covering off most of the features the average user will ever need in a mobile device. And that is before 3rd party apps enter the picture.
It is pretty clear that the Apple is now aggressively going after market share. Within the first 8 months of its launch the iPhone had already claimed over 28% of the smartphone market in the US, second only to RIM (Blackberry). At that point it was not available in other countries. As of today the iPhone is available in 6 countries, on July the 11th it will be launched in another 14 countries, and within a few months it will available in 70 countries worldwide. Combined with the significant price drops and locked ceiling for pricing worldwide we can see the picture.
Will Apple really start to dominate the mobile phone market? Yes I believe it will. The rapid adoption of the initial iPhone already paints the picture. More than that however, we can see that the iPhone lives up to the hype, receiving rave reviews from satisfied owners and critics alike. I have never seen a single device get so much attention from the media or the average person down the street – not even from Apple, who seem to be at the forefront of marketing the launch of such devices (eg the iMac and iPod).
Let's have a look at some of the target audiences Apple is obviously going after…
Children/Students
Let's be honest – Apple already had most kids with the iPod, and the iPhone is an even more compelling music experience. Now add the coolest phone with SMS and email. Now add the slick games powered by the accelerometer. What about the inbuilt YouTube support and the best mobile browsing experience? Now add the 3rd party software that has been launched – student learning tools, social networking software, sound mixers and much more. Do I need to say any more?
SME/Enterprise
Sharp pricing. "Push" email, contacts and calendar. Microsoft Exchange support. 3G data transfer speeds. Multiple secure networking options and Cisco VPN support. Remote device wipe. Support for Microsoft Office documents. MobileMe for remote sync, backups and anywhere/anytime access to data using the slickest browser-based toolset. Apple has ticked off the list of most business and corporate requirements. The overall packaged software combined with the slick hardware and pricing model is sure to be appealing to business users.
Developers
It is obvious that developers are a key target with this launch of the iPhone. The SDK (Software Development Kit) has been well publicized and marketed
. The Apple WWDC was sold out for the first time ever and Apple has made no secret of this. The App Store joins the gap between the developers and the end users. And Apple is definitely showing off the 3rd party apps that have been developed, and emphasizing over and over again the short amount of time developers had to work on their application and how easy they found it. We can see that Apple are trying to get a singular message across to developers – developing for the iPhone is quick and it is easy. Whether that is true or not, developers are definitely listening and are more interested in Apple now than ever before. But again, this is based on more than just Apple's marketing hype.
The iPhone offers a pretty compelling picture to developers. The hardware is very powerful for a mobile device, and gives developers the ability to tap into features they have not had access to before – such as multi-touch, the accelerometer, and location awareness. Apple is making it easy for developers to work with this type of hardware – and as a result we are seeing some impressive and innovative software coming to the iPhone that we have never seen on any other platform. Apple helped by getting the hardware form-factor right in many respects as well – for example the screen resolution is large enough to create compelling and usable software that can be navigated with a finger, while still small enough to fit into a pocketable device. It is also powerful enough in terms of processing and graphics to remove limitations that developers were previously hindered by in the mobile space.
Apple has also cleverly architectured the iPhone operating system. It is not just a cut-down and limited version of their desktop OS – the core layers are exactly the same. It will be easy for developers to migrate from the iPhone to full OS X desktop development – a very clever strategy from Apple that they will move on more in the future I am sure. Apple is also clearly documenting and communicating their API, their conventions, and placing and enormous emphasis on best practice which will standardise the development efforts and the resulting software. I like the way that Apple brings their simplicity and clarity to the development community – it is a much clearer picture to navigate than trying to learn to develop for other mobile platforms from scratch.
Combine the above facts with the potential market share that the iPhone will pick up over the coming months. For a developer choosing a target platform for their software the choice is becoming pretty obvious. While the iPhone may not be their only target platform it will likely need to be at the top of their list.
During Bill Gate's final publicly scheduled speech as a full-time Microsoft employee, he acknowledged that Microsoft's success is 'due to our relationship with developers.' Apple may well be saying the same thing in a few years time.
——-
Apple has been consistently wowing us for the past few years – OS X, then the iMac, the iPod, and now the iPhone.
It has been clear for a while that mobility is the future of computing. And the iPhone is emerging as the King of mobility. This device is indeed a game changer. It is more than a mobile phone – it is a new platform.
The iPhone takeover begins.
You may have noticed that printing in Internet Explorer 7 has a new feature – "Shrink to Fit". In some situations, such as when pages are in an iFrame, "Shrink to Fit" is always applied by default. For general web pages this feature may be appreciated, but in a web application where developers want to control the layout of the page, and perhaps generate reports, we do not appreciate IE7's changing the print layout at all.
If you have not been challenged by this behaviour yet, don't worry – you will! And when you do, here is the solution.
Instead of the typical "print()" command in JavaScript, use:
document.execCommand('print', false, null);
Or if you are wanting to print a document inside an iFrame you can use something like:
window.frames(0).focus();
window.frames(0).document.execCommand('print', false, null);
Note: This solution is for Internet Explorer 7 only – I leave it up to you to do the browser detection.
As a heavy Pocket PC user I have been evaluating UMPC's as my next portable device. Why? Here is a list of the main reasons:
Decent screen size (physical dimensions)
What will I lose by moving away from my Pocket PC? My built-in phone and some portability as UMPC's are obviously larger. Is this a big deal? Not as much as it used to be – read on…
I am using my PDA more and more and the small screen of my device is bugging me a lot – and hurting my eyes. Pocket PC's only seem to be getting smaller and smaller screens however, and any of the newer devices with larger screens have major drawbacks – the HTC Advantage with it's lack of phone support and it's stupid magnet (why have a portable device that cannot sit next to a wallet or another device with a HDD? duh), and the HP IPAQ 200 with it's nice 4inch screen but no phone. If a Pocket PC has no phone and a small screen then I am looking elsewhere – and the only elsewhere is towards the new generation of Ultra-Mobile PC's.
The concept of carrying around a full computer running the same applications as my everyday PC is very appealing. No more syncing of data, no more shelling over cash for Pocket PC software that is a cut-down imitation of the real thing. As I am a IT Manager/Developer it also means I will have access to tools that are required for my job at hand 24/7 – there will be no requirement for me to lug my laptop around when on the go. Sure I will have to carry a small phone plus a UMPC as opposed to a single device, but there are some advantages in that as well such as each device being optimised for its purpose.
To move away from a Pocket PC however there are a few requirements that a UMPC must meet to cover my everyday usage. It must be able to support at least 4 hours battery life. It must still be very portable in terms of overall dimensions. I also want to be able to use it in situations where it must be quiet and discreet. For example I use it a lot in places like my church to take notes and have study/reference material at hand – I don't want the device to be too obvious and distracting to others. 
For a UMPC to run desktop software it must also be reasonably fast and have decent storage capacity. A keyboard is not a huge requirement for me – I am very capable with a touchscreen combined with a Fitaly onscreen keyboard for data entry, but if a keyboard present and it does not add too much real-estate to the device then that is fine.
So that gives a bit of background on my usage and feature requirements.
There are two UMPC devices that interest me the most at this point. The RAON Digital Everun and the OQO 02. Until a few days ago the HTC Shift was also on the list, but definitely not now – the limited battery life and limited Windows Mobile took care of that.
To decide between the two devices I asked for feedback from the community. The feedback I received was mainly sweeping comments that the OQO was the better device in nearly all areas except battery life and was by far the more "productive" office machine. I kept feeling like there was more to the Everun than that – so I made the following chart to compare the two devices feature for feature. The end result? It's a tough call but I think in terms of value for money and overall usage the Everun is going to be hard to beat… especially when thinking in terms of moving away from a Pocket PC rather than as a desktop replacement.
| Key:: |
|
| Spec. | Everun | OQO | Thoughts |
| CPU | 600MHz AMD Geode LX 900 | 1.6 Ghz VIA C7M ULV | - |
| RAM | 512Mb | 1Gb | If using Vista on OQO not sure 1Gb offers any real advantage |
| Operating System | XP Home or Pro | XP Pro or Vista Business/Ultimate | Either XP or Vista is fine for my requirements. Both have advantages/disadvantages – XP is perhaps more stable and in theory will run faster on lower spec hardware than Vista. |
| Standard Battery Life | 7 hours | 3 hours | - |
| Extended Battery Life | 12 hours | 6 hours | - |
| Dimensions | 83×170x25mm | 83×142x25.4mm | The OQO is shorter but slightly thicker. |
| Weight | 460g (with SSD) / 490g (with HDD) | 454g with standard battery | - |
| Design | Practical/Nerdy | Sleek/Professional | Shouldn't affect my decision, but worthy of note! |
| Screen | 4.8 inches | 5 inches | The OQO will be slightly more readable due to larger pixel size |
| Screen Type | Touch Screen | Active Digitizer | After using a Pocket PC for years either type offers advantages that balance each other out |
| Native Resolution | 800 x 480 | 800 x 480 | The OQO has interpolated zoom up to 1000 x 600 still readable |
| External Resolution | Up to 1920 x 1200 | Up to 1920 x 1200 | The OQO offers DVI support as well. |
| Zoom | Up to 1680 x 1050 | Up to 1200 x 720 | - |
| Docking Station | Coming | Yes | The OQO docking station is very slick – let's see what RAON bring to the table |
| Camera | Coming | No | The Everun will have the option of a 2.0 Megapixel camera |
| HDD/SSD | 30/60Gb HDD and/or 6Gb SSD | 60/80/120Gb HDD or 32Gb SSD | In my opinion the Everun wins because of the fact is allows both SSD and HDD or CF in the same device – so you can have a 6Gb SSD and a 60 Gb HDD or SSD and CF in the same device. CF cards now go up to 64Gb and can be swapped. Due to my emphasis on ruggedness and the device running queitly the extra Flash options are a bonus. |
| Compact Flash | Yes, hybrid with SSD only | No | |
| Noise | Silent | Noisy | Users are reporting that the Everun can only just be heard when holding it up to the ear. |
| Heat | Cool | Hot | Speaks for itself. |
| WWAN | HSDPA | None | I live in New Zealand, so the OQO's EVDO support is no good to me. The Everun however has the option of HSDPA which can optionally support voice. |
| Microphone | Yes | Yes | - |
| Wifi | b/g | a/b/g | - |
| Bluetooth | Yes | Yes | - |
| USB HDD | Yes | No | This indicates if the device can be used as an external USB HDD or not. |
| Auto-Rotation | Yes | No | There is a 3rd party solution to enable this on the OQO |
| Auto-Brightness | Yes | Yes | - |
| Keyboard | Yes | Yes | Both have keyboards but it is obvious that the OQO's is very usable over the unusual thumbboard of the Everun. However for me this is a moot point – I will use the Fitaly onscreen keyboard anyway. |
| Integrated Pen | Yes | No | The OQO pen cannot be stored in the device |
| Base Model Price | USD 799 | USD 1,299 | The cheapest entry point – pricing from Dynamism. |
| Preferred Model Price | USD 899 (SSD, CF adapter) | USD 2,349 (Vista Business, SSD) | If I was purchasing this device, the model I would select |
I have been using Zend Studio for quite a while now as my primary PHP IDE. To get the powerful remote debugging and profiling that comes with the tool you used to have to install Zend Studio Server as well. With the release of version 5.5 however, Zend stopped shipping Studio Server and forced developers to install the Zend Platform instead. This is a commercial tool (free to developers) available from Zend that offers PHP acceleration, caching and other features … that I don't want! I just want my debugging back, without having to bloat my local server with software I will not use elsewhere – especially when the Zend Platform does not support APC, which we run on our servers, and it also broke my web application.
It turns out that we do not need the Zend Platform at all. As part of the PDT Eclipse project Zend has made available a standalone version of their debugger. This can be downloaded from here: http://downloads.zend.com/pdt/server-debugger/
Then you just need to put the .so or .dll file in the correct location and add a few lines to your PHP.INI file and you are away. Here are the lines I had to add to my PHP.INI, which is running inside a Debian VMWare image. Note the commas separating the IP numbers – this took me a few goes to work out as the examples showed spaces or forward-slashes which didn't work for me.
zend_extension=/etc/Zend/ZendDebugger.so
zend_debugger.allow_hosts=192.168.1.3,192.168.220.1,192.168.150.1,127.0.0.1,192.168.220.10
zend_debugger.expose_remotely=always
Why did Zend make this so hard to work out? Reading on different blogs and through the Zend forums highlights that this issue has been a source of frustration for many developers. Grrrr…
Google Gears is an open source browser extension, less than 1Mb in size, that lets developers create web applications that can run offline. There are two main ways the extension can be used – by embedding the API or runtime software in an application you distribute to end users, or by writing a web application which makes use of installations of Gears on end-users' computers.
Web developers write software for … the web. For applications that run via a browser that is connected to the Internet. Google Gears will take web applications to the desktop – enabling Web applications to work offline. A user will not be required to be connected to the Internet to use the application.
First of all web applications will need to detect whether or not Google Gears is installed on a user's machine. If Gears is installed, then the application will be able to access the Google Gears APIs from JavaScript code. If Gears isn't installed, the user can be directed to a customized installation page.
The APIs can then be used to access Google Gears three core features:
The final release will run on the following browsers:
To find out more about this project you can visit the Google Gears website. From there you can download Gears and then install some of the sample applications available.
Some developers are already playing with Google Gears and sharing their experience and their plans. For example you can listen to a podcast about Dojo Offline being ported to Google Gears, or take a look at RSS Bling moving to Google Gears.
This is definitely a project to watch. With Google obviously coordinating with the efforts of popular projects such as Dojo, as well as supporting all the major browsers, there are some interesting possibilities opening up for web applications.
Linus Upson, the engineering director at Google, stated that the goal of Google Gears is to "create a single, standardized way to add offline capabilities to Web applications." Google is certainly on the right track … I'm off to have a play!
I found a very useful tool today – the Data Generator. It generates large volumes of random, custom data for use in testing software. The tool is a free download, and can generate data in the following formats:
- HTML
- Excel
- XML
- CSV
- SQL
There is an online demo available that is limited to 200 results. Click here to find out more…
Introducing a new technique to allow efficient reuse of JavaScript and CSS – effectively allowing you to download the code once and then inject it into Iframes. This solution is targeted at Web Applications which commonly use Iframes for complex layouts and to control memory usage in larger apps without moving to the complexity of a Single Page Interface (SPI). Along the way we summarise and explain other methods available to developers for minimising their code and speeding up the loading time of their application.
With the next generation of Web Applications upon us the challenges faced by the average web developer have broadened. Understanding and confronting issues like memory leaks, bandwidth, load times and JavaScript processing time is becoming more of an everyday focus for web developers than ever before.
Fortunately we now have the tools available to help. On the developers machine the Web Developer Toolbar and Firebug for example are essential. And within the applications themselves we find increased usage of JavaScript libraries such as Dojo, jQuery, Prototype, YUI and widget frameworks like Ext, which provide a layer of abstraction and freedom for developers from some of these issues.
The increased usage of JavaScript however brings other challenges. Particularly in the world of Web Applications where the use of Widgets (tabs, grids, menus etc) is more likely, it is not uncommon for the volume of JavaScript and CSS to quickly accumulate from tens to a few hundred kb of code. This is a far cry from ideal, but is also to a certain extent unavoidable if that is the type of application you are supporting.
What can a developer do to minimise this issue? There are several very effective methods that can be explored:
Compacting Your Code
This is acheived by stripping out comments and unneccesary white-space which can drastically reduce the size of your files – sometimes cutting them in half. Recommended tools: Dean Edwards Packer or Douglas Crockford's JSMin. You could apply the same theory to your CSS as well.File Compression
Using GZIP or Deflate can drastically reduce the downloaded file size (but should be used wisely). You can read more on this here.Combining Multiple Files
In general browsers download only two or four files in parallel per hostname, depending on the HTTP version of the response and the user’s browser. On top of that it seems that JavaScript files are loaded synchronously and sequentially as they appear in your code. This means that only one JavaScript file can be downloaded at a time – and each file must be completely downloaded and then interpreted before the next download can begin. Reducing the number of HTTP requests by combining your JavaScript and CSS files into single files will definitely help improve your applications response times. Using CSS Sprites to combine your images into a single file and re-use with CSS is also an extension of this principle and is a very effective technique.Caching
Server-side caching can help speed the up the delivery of page content. Also understanding browser caching and how to control this using file headers can make a difference – but again should be used wisely.
These techniques have been around for quite a while now. But this leads me to the real point of this post!
When it comes to the world of Web Applications (as opposed to a "website") where the use of Iframes is more likely, there is another technique that can be explored – "Code Injection".
I became aware of this technique while trying to interpret some very lengthy posts from Choleriker on the Ext forums. I thank Choleriker for taking the time to explain the concepts. I thought I would share my interpretation of this technique, as well as provide some examples to see it in action as requested by other developers in the forums.
First of all – what is this "code injection" that I am referring to?
Explained
In breif, the technique basically involves loading your JavaScript and CSS only once and then re-using it inside any iframes without downloading it again. This is acheived by loading your code "inline" inside the top level page of the application. The top page then makes the JavaScript and CSS available as two variables that can be called from the iframes directly. So the code is passed or "injected" from the top level page into any iframes using JavaScript.
Benefits?
There are several benefits to this technique – the most obvious being that you only download your JavaScript and CSS once, no additional downloads required. If you normally compress your JavaScript files using GZIP you likely know that there is a performance hit in the client browser to decompress the code before it can be used. This is no longer an issue for the reused code. And there is no longer any concerns with browser caching issues. Another big plus is that the CSS and JavaScript is being loaded as part of your actual page – i.e. there are no other additional files to download, which will improve the response times as described above.
Downsides?
I guess that the technique requires iframes. In time I guess/hope the principles of the technique may be able to be used in other perhaps more elegant ways that I haven't thought of yet. Another downside is the need to load your JavaScript and CSS inline. This was initially repugnant to me, mainly due to my background in website development. But in an Application is it really a big deal? I have decided it does not outweight the benefits.
Another perceived downside is that you have to get all of your JavaScript and CSS into a format that is loaded inline – but of course you still want to work with your separate "clean" files as you are used to. This should be viewed as an opportunity! It is likely time to implement a number of techniques as discussed above. My recommended technique is to have a server-side script that does the following:
- Combines the required JavaScript and CSS files
- Compacts the code by stripped white-space, comments etc
- Caches the output code to a file on the server
- Include the code inline using PHP or some other scripting language
I may provide some code for doing this in PHP in the future. In the meantime you might want to look at the "Combine" script from Niels Leenheer to get started.
Sample Application
So – how about an example? Click on the image below to see this technique in action. The example is built using Ext 1.0 Beta 2. It is a top level page which generates an Ext Layout with panels. The right-hand panel contains an iframe which receives the JavaScript and CSS from the top level page – it has not downloaded any files except the required images.
The secret to this working is the following code in the Top Page:
<textarea id="StyleProxy" style="display:none;visibility:hidden;">
// CSS loaded inline here
</textarea>
<script type="text/javascript">
document.write(['<style type="text/css">',document.getElementById('StyleProxy').innerHTML,'</style>'].join('r'));
</script>
<script type="text/javascript" id="ScriptProxy">
// JavaScript loaded inline here
</script>
<script type="text/javascript">
// define the variables for storing the JavaScript and CSS
var _SCRIPTS = null;
var _STYLES = null;
// use jQuery to run the JS once HTML is loaded
$(document).ready( function()
{
// place the JavaScript and CSS into the variables for reuse
top.window._SCRIPTS = Ext.get("ScriptProxy").dom.innerHTML.toString();
top.window._STYLES = Ext.get("StyleProxy").dom.innerHTML.toString();
// create an iframe and add to the DOM
// this should be always be done after the variables
// for the JS and CSS are filled
$main_container = Ext.get("iframe_main_container");
var $iframe_nav = Ext.DomHelper.append (
$main_container, {
tag: "iframe",
id: "iframeMain",
name: "iframeMain",
width: "100%",
height: "100%",
frameborder: "no",
scrolling: "no",
src: "ext_demo_iframe1.htm"
}
);
})
</script>
A look at the files downloaded reveals the benefits – the iframe had nothing to download but the basic page itself. The JavaScript and CSS were downloaded only once as part of the top page. This top page was a reasonable size – but Ext is not small, and we can see the GZIP compression kicking in:
Conclusion
So – should you use this technique? That depends on your application and your preference. The objective of this post was to simply introduce a concept that was new to me, and I am sure is new to many others. It is simply another technique to add to a developers toolbox.
PS: I am very interested what other developers think of this technique and what they perceive as the advantages and disadvantages. I also have a question – does this technique expose any security holes I should be aware of?
In an initiative to improve the sucurity of PHP, experts from the Hardened PHP Project have launched the "Month of PHP Bugs".
Stefan Esser’s, widely regarded as an authority on PHP security issues, plans to make daily disclosures on buffer overflows, double free vulnerabilities and trivial bypass bugs in PHP’s protection features as part of a wider goal “to make people and especially the PHP developers aware that bugs in PHP exist.â€
Some of these bugs have already been addressed in PHP 5.2.1. Others are fixed by the Suhosin patches and extensions from Stefan Esser, which are freely downloadable here. Others hopefully will be addressed in the very near future by the PHP development team.
To find out more about this initiative visit the PHP Security website.
PHP 5.2.1 was officially released yesterday, and it is possibly the time for PHP 4 die-hards or PHP 5/5.1 users to upgrade. Why? Consider the following:
New Features in PHP 5.2.1
Performance Enchantments
Improved Security
Improved Stability
If you are interested in migrating from earlier versions of PHP please see the guide provided by Ilia Alshanetsky.
This work is licensed under a Creative Commons
Attribution-NonCommercial-NoDerivs 2.5 License.
Hello.World is proudly powered by WordPress and hosted by SiteHost.
Entries (RSS)and Comments (RSS).