The iPhone is unquestionably the hot kid on the block, and stands to dominate the entire industry.
But unlike their entry and dominance of the mp3/mp4 player market, the other cell phone vendors plan on giving Apple a run for their money.

What we call a “smart phone” is more accurately a handheld computer with phone capabilities.  In the case of the iPhone, it runs a variant of Unix (similar to Apple’s OSX).   Dell has a similar phone that runs Windows, and there are no shortage of Linux and other vendors.  [Despite BeOS's recent change of ownership though, there are no BeOS smartphones yet.  Have faith.]

In order
In a post on Techgear, Scott Merrill refers to the “smartphone triumvirate” of the iPhone, Palm Pre, and Android.  He’s wrong.  While those two definitely require a closer look, the other players will outsell the iPhone alone.  Lets look at them all.

(In the bid for success, a phone needs users to buy the phones, and developers to make the applications that make the phone worthy of being bought.  A sign for how seriously Apple takes the competition is that it now allows for apps to be written in multiple programming languages.  At launch, they required Cocoa – the Apple scripting language.)

Palm has bet their company on the Pre, and it shows – it bests the iPhone on every front in all reviews I’ve read.  Palm still has a strong brand, and in its history has twice been the “must have” device for years on end (The original and the Treo).  They now have Apple designers on board as well [which has engendered a lawsuit from Apple], and are owned in large part by media outlets that will promote the brand. It runs a version of Linux dubbed WebOS, and allows app programming in the languages most used around the world (HTML/JS/PHP).

Android is not a phone – it is an operating system funded by Google and dozenss of partners.  It is VERY feature complete, and will be hawked by vendors from Sony to Motorola.  At least one of them [read: Samsung] is going to produce a device that will blow everyone away in style, price, battery, etc.  And being a branch of Linux, the developers for the apps already exist, and the barrier of entry are low.

Nokia makes up almost 50% of all cell phones sold worldwide.  They develop a operating system called Symbian, which is now open source and finding other uses besides cellphones.  While we haven’t seen any killer phones yet this year, they definitely have something up their sleeve.  And even older offerings like the E71 are prefered by people as  popular as Joel.

Blackberry is weak outside of the US, but to ignore manufacturer Research In Motion is plain dumb.  Verizon has sold over 1 million Blackberrys since November, and they claim over 50% of all phones sold in the US.  Their App store is larger and more accessible than Apple’s, and the furor the fuhror has made over keeping his has provided some very positive press.

Windows is still around, and they have indicated that they are not about to throw in the towel.  While we do not expect any real value from a Dell/Windows phone, Microsoft is not know for competing in the value department.  But compete it does, and very well at that.

And who knows what to expect from left field?!

All but the last two use the web browser by default – the Apple Safari.  [Actually, they use "Webkit", of which Safari is just one branch.  Other branches are the Nokia S61, Google Chrome, and Linux Konquerer.]  The new Opera browser is available for all phones except the iPhone which doesn’t support it.  But it requires a separate download that most users will not do.

S. Caron points out that it is important that mobile browsers speak the same css as desktop browsers.  More importantly, it cannot be underestimated the importance of minimizing variables with new technologies.  There is so much for us to stomache about the mobile web and about cloud computing, let us at least have one constant.

Even Microsoft’s monopoly was good for a time – had there not been one standard then, we never would have had the world of computing that now exists – I remember the days of the Commodore and Atari.

A few last points.

1. The concept of cloud computing will take some strain off of the devices that connect, and add others, we have to see how that will play out.

2. There is a chance all of these devices will paly into the hands of Adobe, Sun, and Google who create runtime environments that are meant to be platform agnostic (Air, Java, and Gears, respectively.  There are others, but not for this post.)

3. Every computer has a chip [called a CPU] to do its regular processing, and another [called a GPU] to do its graphic work.  The graphic chip is exponentially more powerful, but that power is generally not useful for everyday tasks.
A few weeks ago NVidia announced a milestone in its initiative to make an architecture for using the GPU for everyday use.  These changes are already being rolled out in “Snow Leopard”, the latest version of Apple’s OSX.  AMD claims to be not far behind on their own initative.
As this plays out, we will see incredibly powerful supercomputers (such as one by NVIDIA that is 100x faster than anything else its size), and we will see much more power in little devices.  The ones who will be affected are the netbooks, and the cellphones.  Expect the advances in cellphones to outpace Moore’s law.

So what does this mean for us?  It means that we will have to add support for mobile devices, but only for Safari for the time being.  If a CMS is able to automate this task, it is another reason to use on and not just build from scratch.

We rely very heavily on a WYSIWYG editor ["What you see is what you get"] to edit the actual webpages – the client needs to edit the page without understanding the code that is modified by his changes.

This WYSIWYG was written by us about two months ago, and modified heavily last month.  This week, we finally sat down to rewrite from scratch to handle all of the improvements we wanted to shove into it.  It is quite a bit shorter and more complete now, and we hope to have it out the door by the end of the week.

A note to explain why we decided to write our own, especially considering our policy of trying to use third party code whenever possible :

There are many hundreds of WYSIWYG editors out there on the web, ranging from open source to thousands of dollars.  By far, the two most popular are TinyMCE and one called FCKEditor (by Fred Knabben of course).  Both are open source, huge bulky beasts that will slow down any site that relies on them.  For all their weight, neither has essential features such as image upload.

A ways back, a fellow Mootooler named Cheeaun posted a really tiny editor (<10k) for Mootools that was designed from the ground up to be small, simple, and cross platform.  He called it MooEditable, and he did a really great job.
Except, he wanted it simple, and some important stuff was missing.
Except, he didn’t want code from others, and ignored corrections and design enhancements made by the other devs.
Except, he really doesn’t have the time to develop it himself.

This has created a fair amount of frustration, and I know of at least four forks to his project, and I haven’t gone looking.  [We started from the ground up, but have used his code for inspiration and to find gotchas].

Also, there is also one really, really annoying issue that has grated on me heavily, and I really thought it should be corrected.  Evry single one of the editors I have looked at (including MooEditable) loads the text to be edited into an iframe.  An iFrame is essentially a tiny browser window that sits within your web page, into which other pages can be loaded.

Since the early days of the internet, this has been necessary, since it was not possible for the browser to give you control over just one small section of the page, and the site managers didn’t want you editing the whole page, so iFrame it was.

The problem is that when you load one section into an iFrame, you lose all formatting for that section, and when you try to port it back into the page it doesn’t look like what you thought it would, so you don’t really get WYS.

It is no longer the early days of the internet.  Nowadays, not only is page manipulation possible without an iFrame on all modern browsers, it is even supported by Internet Explorer.  [OK, their implementation is very different, but it still mostly works.]  And while there are still bugs going around, it is far better than editing the page within a frame.

So, there was no choice but to build our own.  I am hoping we can get some of the other forks to look at our work and get them to help us develop it.  Because, as always, we welcome and encourage your help.

After Yahoo’s anouncement to use startup GitHub’s services to manage their code, (GitHub is powered by troubled startup EngineYard, but that’s another issue) I decided that they’ve reachjed maturity enough to move there.
JQuery and Moo both use GIT, let us git going ourselves.

Little did I know how hard it is to move to git.  And I must be missing something, as I don’t see even basic error reporting for non git users.  [Lighthouse?]

Unfortunately, Google code is not an option, as they don’t host projects that are licensed under the OSI (we have a modified OSI license).

I have no desire to tie myself to Sourceforge, and have not yet found a collaboration CMS to  our liking to host it locally.  So, we are still in need of good ideas, at least until I learn GITHub more thoroughly.

Anybody have ideas?

Thought I’d post a few useful links regarding SQLite as they are bound to be useful for others.

1) Software -
I mentioned in the last post the wonderful HeidiSQL, which is probably the best remote database tool I’ve used.  Our office purchased both EMS MySQL manager and Heidi (while it was still proprietary).  Since than, HeidiSQL got into a fight with the guys at MySQL that resulted in them open sourcing the project, and I daresay that it has surpassed the much more sophisticated EMS in a number of ways.  [Though even EMS's free version has many more options than Heidi, and is an excellent program.]

It turns out there are a number of initiatives to write software for SQLite, including the following open source tools:

• SQLiteAdmin – Windows tool, good reviews.
  
• SQLite manager – A Firefox Plugin.
• SQLiteDM – Web based, simple, works well.
• SQLiteManager – Web based. Looks solid, similar to phpMyAdmin, but hasn’t had updates in a few years.
• phpSQLiteAdmin – Young, but alive.  Haven’t looked much at it.

2) Tutorials:
SQLite can be accessed via bash over Telnet (using Putty, or even WinSCP), or using PHP.  Beware the permissions issue! Some of the better tutorials I’ve come across, for absolute beginners:

• http://www.switchonthecode.com/tutorials/php-tutorial-creating-and-modifying-sqlite-databases
• http://devzone.zend.com/node/view/id/644
• http://www.litewebsite.com/?c=49

And the official docs, at sqlite.org and PHP:

• http://www.sqlite.org/docs.html
• http://www.php.net/manual/en/book.sqlite3.php

3)
For the record, it is not at all clear how SQLite stacks up to MySQL.  Many good comparisons such as this would have you believe that no serious site would be SQLite.  Others would say that SQLIte is better in one way or another, but less efficient [eg. more expensive if you are on NFS which charges according to use],  The official SQLite site claims that it trounces MySQL in every way including speed, and only gives the full databases the advantage of arcane query support.
I doubt that either is correct.  On most hosts, even VPSs, the databses are stored on separate servers which can be more or less responsive that using the local db files generated by SQLite.  Dreamhost suffers from a terrible reputation when it comes to database response time [though overalll they sound fine], whereas NFS has a blazing fast cluster  [they should, considering that most of their clients pay 3x as much for the database as they do for the hosting].

3) Flat files
In case any of you has a need to use flat files, the best beginners tutorials I have seen are here and here.  This article at AlbinoBlackSheep is also good, spending more time on the presentation than the code.  It is curious to me that only this About.com article refers to the feof() and other basic functions.  Good luck.

Our decision was based on our own experiences with shared hosting.  Most hosts have ridiculous or inconsistent database implementations, and even once the database is setup, the user can’t access the data through managers without the painful phpMyAdmin or variations (the buggy FlashMyAdmin?).  Hosts with a robust MySQL that allow connections from the likes of Heidi are just to few and far between.  [Even our current host, NearlyFreeSpeech.net requires the DB to be setup and paid for separately - not good for most of our clientelle.]  We try hard not to alienate the non techies from our framework.

So, we had plans to use flat files, accessing the data through classes such as the one at http://lukeplant.me.uk/resources/flatfile.  These have the advantages of definitely being available everywhere php is, and the data can be stored and edited easily.   Huge advantages!

However, it would mean that any third party class that relies on mySQL would not work.  Since the bulk of 3rd party classes rely on mySQL, and one of our ideologies is to use third party classes, we had a problem.  Contacting each class vendor to ask them to modify their class, or writing a sql wrapper, sounds awful.

The final decision is to use SQLite.  SQLite is a php5 module that allows the creation and querying of flat files with SQL.  It is available on every host we’ve checked out, and doesn’t require any special permissions or passwords.  True, Heidi may not be able to speak to it (though perhaps such a client could and should be created), and we won’t have the ubiquity of pure php.  And we may yet have to write a wrapper for it.  But it still seems safer than any other solution.

For the end user.  This means nothing.  For the big thousand page site, you should switch to mysql in the admin page anyways.  For developers, know what to expect.

And now, back to coding.