All posts by onlyconnect

Apple iPhone needs Google Gears

At its developer conference Apple announced that the forthcoming iPhone will support Web 2.0 applications. In this context, “Web 2.0” means at a minimum an embedded web browser (Safari) that runs JavaScript, but that’s no big deal; we expected nothing less. It’s at least a little more than that though:

Developers can create Web 2.0 applications which look and behave just like the applications built into iPhone, and which can seamlessly access iPhone’s services, including making a phone call, sending an email and displaying a location in Google Maps.

The emphasis is mine. This implies some sort of hole in the sandbox, but web apps on the iPhone needs more than just the ability to make phone calls if they are going to be useful. They need to work offline. In fact, a mobile phone (ironically) is one environment where offline web apps will be particularly useful. Nobody is always-on when travelling; it varies from mostly on (urban travel) to mostly off (trains, planes). As a regular train traveller, I find attempting to run web apps on a mobile utterly frustrating.

Fortunately Google has come up with an answer to this with its Gears initiative. Here’s how you write a good Gears app:

  1. Write your app to work offline.
  2. Add synchronization with the server that happens transparently when connected.

This is perfect for a mobile app. Running web apps rather than local apps also bypasses one of the main obstacles to mobile development: the need to get your binaries approved by a telecom provider before they can be installed.

Now, I have no idea whether Apple plans to include Google Gears, or an equivalent, in the iPhone (I’m not at WWDC). But I do think it is a great idea, for this or any mobile device. Combine it with Flash or Silverlight and we will wonder why we ever wanted more.

Lennon and McCartney, Yin and Yang

There’s a discussion over at the Hoffman forums on the value of the post-Beatles solo efforts.

There is a touch of magic in the Beatles’ work though I am not really a diehard fan. Generally I find the solo albums less satisfactory with a couple of exceptions. The reason I think is to do with yin and yang, a Chinese philosophy of complementary opposites. Exactly how Lennon and McCartney differ is going to be hard to put into words, but it is to to with light and dark, where McCartney is content mainly to stay in the light, and Lennon is driven to explore the dark. In the solo work, McCartney is always in danger of descending to nursery rhyme, while Lennon is always in danger of descending to primal scream. They are better together.
Personally I tend toward introspection so my preference is for Lennon, and in particular Plastic Ono Band I regard as a work of genius, dark though it is. As for McCartney, I love Band on the Run though it is lightweight, and Flowers in the Dirt where Elvis Costello seemed to play Lennon’s role to some extent, giving the music an edge that McCartney’s work often lacks.

PCs that shut themselves down

I was asked to look at a misbehaving laptop recently (a hazard of this profession). “It seems to works fine, then shuts itself down without any warning,” I was told.

Yesterday the same happened to me. I was typing away when bam! the PC turned itself off.

The reason in both cases was the same. Dust. When I took the back off the PC I saw that the fins on the heat sink were completely clogged and it was no longer cooling the CPU effectively. When the CPU overheats its thermal protection kicks in and turns it off.

The laptop was a variation of the same problem. Some of the vents in the case were filled with dust and dirt, impeding the flow of air. Apparently this is a common problem with some Acer models.

Part of the problem lies with Intel for making CPUs that run so hot. Cooling is critical.

Fortunately the fix is easy, though you normally need to take the back off. I used one of those aerosols that squirts out compressed air. Clean out the dust and it all runs sweetly again. If only all system failures had such simple solutions.

Technorati tags: , , ,

Google’s new model of app development

I was fascinated by this slide shown at the recent global developer day, which I’m reproducing with Google’s permission:

Four blocks captions Ads, Standards, Mashups, Open Source

The image doesn’t make sense without the caption, which I’ve used as the title of this post: The New Model of App Development. You can see the slide in context in this Register piece. Two things in particular interest me. One is the appearance of ads as an integral part of the development model. This makes sense for Google’s own development, but does it make sense for others? Given that much of the software industry is slogging away at internal business applications, that seems a stretch. It may be true for consumer apps. Ad-funded applications have not been a big success on the desktop, but we have somehow become tolerant of ads flashing round the screen when working on the Web.

Another issue is one we tried to capture in the caption for this image at the Reg. The main goal of developer day was to get developers to integrate Google services into their applications, by using Google Maps and the other APIs on show at Google code. The company is even keen to host your gadgets on its own servers. Google wants to be an indispensable building block in app development, even though it left itself out of the illustration.

How about open source? Google uses and sponsors open source software, and has posted the code for Gears, but where’s the code for Docs & Spreadsheets? Closed source is an important part of Google’s own app development model, as it is for most others.

Adobe Live in London – quick report

I attended Adobe Live yesterday. This was in two parts, an exhibition with a schedule of presentations/tutorials, and a developer day focused on Rich Internet Applications – Apollo and Flex – as well as ColdFusion 8.

I’m told that around 1800 attended, though most of these were for the main exhibition, whereas I spent almost the whole day in the developer sessions.

It was a worthwhile though low-key event and I picked up some insights into Apollo and Flex 3 as well as getting an update on ColdFusion. I’ll be reporting in more detail shortly. A couple of quick comments though.

First, this struck me as primarily a designer crowd, Flash folk interested in applications, rather than developers new to Adobe. These are just impressions so I could be wrong, but it strikes me as in interesting issue. Equally, when I went along to Microsoft’s Mix07 earlier this year my perception was that many delegates were primarily Visual Studio folk interested in web design, rather than vice versa. If I’m right, Adobe and Microsoft have inverse cultural and marketing problems here. Still, at least Adobe put on a proper developer schedule this year; it didn’t exist at last year’s London event.

Second, I found the Apollo stuff though-provoking in the light of Google’s Gears announcement as well as what Microsoft is offering with WPF. I knew that Apollo was sandboxed, but hadn’t appreciated the extent of the sandboxing. As I understand it, Apollo apps can do file i/o on the local machine, but in other respects it is locked down in a similar way to web apps running in the browser. There is no access to external libraries, OS scripting, or custom native code extensions.

That’s good from a security perspective, but it limits the extent of OS integration. So the key question: if you can’t integrate with the OS, beyond a few trivia like Start menu or Dock shortcuts, then why bother with a desktop app? Especially now that Gears has a solution to the offline problem. Maybe it is worth it just to get out of the browser window, but some at least will not see the point.

Third, I asked what if anything Adobe intends to do with Google’s open-source Gears code, but apparently I may not have the full story yet – more when I get the information.

Technorati tags: , , , , ,

FireFox team not sure about Google Gears adoption

During Google Developer Day I had the impression that Mozilla was right on board with Google Gears, the plug-in which which enables offline applications. Here’s Aaron Boodman and Erik Arvidsson from the Gears team:

We are releasing Gears as an open source project and we are working with Adobe, Mozilla and Opera and other industry partners to make sure that Gears is the right solution for everyone.

It seems that things are not as clear-cut as Boodman and Arvidsson imply. LinuxWorld.com quotes Mozilla’s Mike Shaver:

We’re talking to Google engineers and looking at how these two models — ours and theirs — compare. This is in the open now, and going forward we’ll see what we can learn from each other,” Shaver said. “But there’s a lot of work that’s been done already [on Firefox 3.0], and we’re not planning to throw that work away.

According to the article, Shaver is particularly doubtful about using SQLite for persisting web application data locally, and is inclined to stick with the more limited DOM Storage API already planned for FireFox 3.0.

A related point is that Adobe’s commitment to Gears is not absolute. Here’s Adobe’s Michele Turner says, quoted by David Berlind:

…For example, they’re using SQLite and we were already incorporating SQLite into Apollo. So, now we’re aligning our efforts with Google on things like the synchronous and asynchronous calls that must be made to the SQLite database in order to enable the offline capability. 

My impression is that Adobe is aiming for a measure of API compatibility, but will ship its own build of SQLite rather than using one installed by Gears, with inevitable version and customization differences.

There is a world of difference between using a similar API on the one hand, and sharing common components and/or common source code on the other. It looks to me as if Apollo, FireFox and Google are going to provide three independent and isolated mechanisms for handling local storage.

Of course Gears installs into FireFox anyway, and there is nothing to stop Flash developers from using Gears.

I will quiz Adobe on this subject at tomorrow’s Adobe Live event.

Google: Don’t let your kids use Gears

More Google Gears Terms and Conditions madness. Gears is licensed under New BSD terms; yet before you can install the runtime you have to agree to onerous terms and conditions. Here’s clause 2:

2. Accepting the Terms

2.1 In order to use Google Gears, you must first agree to the Terms. You may not use Google Gears if you do not accept the Terms.

2.2 You can accept the Terms by:

(A) clicking to accept or agree to the Terms, where this option is made available to you by Google in the user interface for any Services; or

(B) by actually using Google Gears. In this case, you understand and agree that Google will treat your use of Google Gears as acceptance of the Terms from that point onwards.

2.3 You may not use Google Gears and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, or (b) you are a person barred from receiving the Services under the laws of the United States or other countries including the country in which you are resident or from which you use the Services.

I’m puzzled. If Gears is BSD licensed, how can Google insist that the mere act of using it binds me to these terms (which I dislike for other reasons too)? And 2.3 is bewildering: you may not use Google Gears apps if you are not an adult?

What if someone else installs Gears on your machine, and you then use a Gears-enabled app? How can terms like this possibly apply in such cases? Note that the agreement does not refer only to installing Gears, but specifically to using Gears.

By the way, you can download the source for Gears, and compile it if you can figure out how, without assenting to any such agreement.

I think Google is letting its legal team get out of hand.

Technorati tags: , ,

New Live Writer is out

Beta, of course. But since this is my favourite offline blog authoring tool, I’m taking a break from Google posts to mention it here. You can download it here – I’m using it to write this post. The official blog has a list of new features.

Do they amount to much? Inline spell checking (wiggly underlines) is great, except that it still seems to be hard-wired to US English. I like Paste Special, particularly as I’ve had problems pasting from Word in the past, with Writer inserting annoying font tags (something to do with using the embedded IE editor, no doubt). That said, I’ve just tried a paste from Word and it worked fine, so perhaps this is fixed too. Synch between local and online edits is neat – when you retrieve a post from Live Writer’s local cache, it updates it from the online version, so that it is now safe to edit in either location. Writer also exposes a richer set of properties, including Excerpt. There are a bunch of other changes that don’t matter much to me, such as Sharepoint support. Table editing? I don’t generally use tables in blog posts, but it could be useful.

On the minus side, Writer has sprouted an odd extra toolbar so that you now have three rows above the working area: menu, toolbar, and editing toolbar. That looks cluttered and unnecessary. There’s the spelling problem mentioned above. And as for this, words fail me:

 

Overall, a useful but low-key upgrade.

Update: Graham Chastney has a hack to fix the US spelling.

Why Google Gears? Thoughts from Google Developer Day

Google Gears is a browser plug-in to support running web applications offline. It has several components:

A local server – not a complete web server, but a cache for web pages. One of its benefits is to solve versioning issues. For example, what if you had an application that retreived one page from the cache, complete with Javascript, and another from the Web, including some updated Javascript? The app would likely break. The Gears local server lets you define a set of pages as an application, so you can ensure that either all or none of the pages are delivered from the cache.

A local database. SQLite of course. I can think of many uses for this – whether or not your application needs to work offline. Searching and displaying data from a local database will be quicker than retrieving it remotely. In the current beta, there is no limit to the size of the database you can download or create on the user’s machine.

A WorkerPool for running Javascript in a background thread. Again, there are many possible applications, but a key reason for its inclusion is so you can do long-running synchronization tasks in the background.

A Javscript library to enable access to all these goodies.

Synchronization

Synchronization is integral to the Gears concept. The idea is that your web application works the same online and offline; and then when you reconnect, any changes you made offline are transparently synched back to the server. Google’s demo app for Gears is Reader, a blog reader app, but you can see how this would work nicely with Documents and Spreadsheets, removing one of the disincentives for its use. I’m reminded of comments from James Governor and others about the Synchronized Web – cloud storage, but with full offline capability.

Gears vs Apollo

How does Gears impact Adobe, which is promoting offline web applications in the guise of Apollo, desktop applications running on Flash? You can argue this either way. On the one hand, you could say that Gears removes the need for Apollo. Now any web application can work offline. On the other hand, you could say that Gears is not targetting the same space. Apollo is for desktop apps; Gears is for web applications that happen to work offline.

My take is that Google is making its pitch for ubiquitous web apps which break the offline barrier. The attraction of Gears is that it is seamless, at least for the user. Look at the reader example: it’s the same app, but now it works offline. As I see it, Google is saying that you don’t need Apollo (or WPF, or Java) for compelling apps that work connected and disconnected. That said, it’s not against Flash; there are even handy Google Javascript APIs for simplifying SWF hosting.

Another twist is that Adobe says it is supporting the Gears API in Apollo. That presumably means Apollo now has a fast embedded SQL database engine, which must be a good thing.

 

SQLite will be everywhere

One of the core components in Google’s new Gears API is SQLite, an open source database engine. I’ve been an enthusiast for SQLite for a while now – I first blogged about it in 2003. I’ve also worked a little on SQLIte wrappers for Java and Delphi.

It’s a superb embedded database engine and I’m pleased but not surprised to see it now picked up by Google. It’s part of PHP 5.x, and also used by Apple for Core Data and Spotlight search in OS X. Now it is part of Gears and I imagine will be widely deployed. Google is also apparently contributing to the project – Full Text Search has been mentioned here at Developer Day – though I’ve not yet looked at this in detail. Congratulations to the primary author D. Richard Hipp, truly a star of the open source world, and thanks to him for making SQLite “completely free and unencumbered by copyright“.