03.03.09
Posted in AJAX, Uncategorized at 5:09 pm by Twm
Hurrah. Gmail at last support uploading more than one file at a time (and a upload progress bar to boot).
The lack of support for multiple file upload has really affected the usability of many web based applications. Applications such as Wordpress have solved the problem by introducing a “Flash” upload page which support a file browser with multi select. Others such as Facebook chose a more heavyweight Java implementation (which seems to freeze my computer for a few seconds on launch).
One of the peculiarities of AJAX is how unfit for purpose the original web standards were to application development. Flash has stepped in more than once as a fall back for thing were simply not possible in HTML/Javascript. So now we have a Gmail page which is rendered in HTML but has just a couple of/hidden or discrete embedded flash SWF. One gives you a better uploader, and the other one plays notification sounds.
Using Flash like this It is a bit like using an X-Box as a paper weight. But then again, as a user it really doesn’t matter. It’s quite nice to log in to a service and then spot small incremental changes that make the product better. Gmail has been very consistent and restrained in evolving small features over time and provides a good example of how a live application can changed in situ (ignoring the recent outage)
Of course, there are other less visible things that are updated behind the scenes including better performance, security, bug fixes and interoperability – all this ready for when you log on next.
Although I don’t like being forced into an upgrade (especially when I’m happy with the stability of a product), the web app experience is vastly better to the situation on my PC where on booting my machine, I’m faced with chain reaction of “checking for updates” dialogs etc. Some of which cause me to install a Yahoo! tool bar if I’m not paying attention.
I suppose this interplay between the slow moving democratised web standards, and the new opportunities raised by proprietary extensions makes the web a better place. The thing I like about the Flash way is that it doesn’t involve inventing new HTML markup tags (as opposed to e.g the Canvas tag), and so there is a clear demarcation of standards and proprietary.
Permalink
02.23.09
Posted in AJAX, Development, Mobile, javascript at 2:46 pm by Twm
Last year, I wrote an article for the Reg about Google’s need for a mobile web platform which has Gears like functionality. There are a couple of ways of achieving this on S60, one is the Gears plug-in (a non starter on S60), develop your own browser (Firefox are doing this, and Chrome may or may not appear on mobile), or wait for the built in browser to implement the relevant HTML5 standards which allow interfacing with client side databases.
As I mentioned previously, the support for “canvas” tag in the HTML5 spec fills the need to draw arbitrary shapes, and Google demoed the potential of dropping Gears in favour of standard HTML5.0 primitives at MWC:
http://www.mobilecrunch.com/2009/02/18/video-offline-gmail-web-app-for-webkit-browser-phones-demoed/
So all this standards love in is all coming together nicely, with the palm Pre getting in on the action. But I found it hard to find information about S60’s web browser and HTML5 support, anyone know?
Permalink
02.19.08
Posted in AJAX at 10:47 pm by Twm
I used to read the dailywtf.com often, a website which originally just posted anonymised coding horrors sent in by the readers.
The site has expanded its scope to include disastrous project management techniques and stories from the front line of sysadmin. But unfortunately the horror stories seem have come to represent the norm rather than the exception in the software development and so I lost interest somewhat. I do however, occasionally visit to be cheered up by a moronic dialog box or some hoplessly desperate code fragment which takes a twenty lines to concatinate a string rather than use the built in function.
After spending so many years establishing the fundamentals as a C++ engineer, trying to master thread safety, secuirity, atomic transactions and small footprint code. It can feel a little off putting to have the mobile platform open to any developer who can throw together some javascript and XML.
It’s not that I think these technologies are bad or inappropriate even, it’s that I worry about anything that grossly underestimates the development effort.
Read the rest of this entry »
Permalink
12.02.07
Posted in AJAX at 11:57 am by Twm
I had an interesting thought the other day while contemplating the mash up culture.
Every service is out there pushing their APIs and championing efforts from the community on innovative use of APIs.
APIs
Most APIs have some sort of limit associated with their usage. For instance a maximum number of requests per day, or a bounded dataset (e.g only return the last 100 comments).
The limit exists in order to oil the tracks for casual developers to innovate by using the APIs without having to sign contracts and service level agreements. If a developer came up with something which was popular which required much more bandwidth, then usually there is a fee/royalty to pay.
Using APIs for data migration
Consider a service which was once innovate but now is more of a commodity (like a gas supplier, or electricity). Let’s consider photo storage.
I’m currently with Flickr, but wizzy service fadphotoservice3.0 might come along and offer more or less the same service, but for free.
What’s stopping me from switching? Well, all my photos, my tags and my comments on Flickr. It’s far less hassle for me to continue paying Flickr.
But if you look at what’s happening in the UK, energy suppliers and banks go out of their way to make it easy for you to switch accounts. They know that the Griffin Saver account which you set up as a kid is probably the one you will have for life unless they find a economic for tempting you- usually an incredible rate.
If a service which offered everything that Flickr does for free, and offered to migrate my data (including preservation of comments by others) by having me authorise its use of the API, then it would remove most of larger obstacles for switching.
DRM on the desktop means that migrating music and videos is hard. But for the web, it looks like they are making it easier which is good for users.
If embracing the mash up culture means removing the API limits and spending lots of infrastructure, are incumbent services opening themselves up to the competition?
Permalink
11.26.07
Posted in AJAX, Python, javascript at 5:00 am by Twm
Due to popular demand, I’m publishing my iTunes remote source code here
Read the rest of this entry »
Permalink
07.20.07
Posted in AJAX, Mobile, javascript at 10:51 pm by Twm
We had a presentation at work today by some enthusiastic folk from the wireless industry which took me back to 1999.
As part of the talk, the words “widgesphere” and “widgetization” were exchanged without a trace of irony. This of course relates to the hype wagon which surrounds the widget engine which Nokia announced recently.
It will be nice to have another application programming environment for ‘creative types’ but I tried to convince my manager to just replace the word widget with app and see if the proposition was still as revolutionary. For me the word widgets just means something you spent an hour configuring and chosing when you get a new PC and then disable after a couple of weeks when you realised that you can see what the weather is like by sticking your head out the window.
I’d much prefer to write web services using AJAX than C++ and thousands of _LIT() statements, but as an app development environment it’s going to need access to native APIs and a persistence model (something like google gears) to float my boat. Once you start adding lots of native calls, it starts to look like a clunkly version of flash without debugging tools.
Permalink
09.26.06
Posted in AJAX, Python, javascript at 8:52 pm by Twm
My first AJAX app
I’m now officially Twm2.0 and i feel great.
What is iTunes Remote?
Lets say you have a nice PC hooked up to your swish HI-FI. It’s very inelegant and not very modern to have to go over to the PC every time you want to change the music or mute.Wouldn’t it be great if you could use your mobile phone to view playlists, skip tracks and mute all from the comfort of your armchair or bed.
Enter iTunes remote. It turns any device with a web browser into an iTunes remote control. This could be a slim laptop, or a modern wifi enabled cell phone.
(click image for full screen shot)
What are the main features of iTunes remote?
- Log into iTunes running on a remote PC in the house with any web enabled device
- Click on the arrow next to a playlist to play it
- Browse playlists and select an individual song. One click will cause the host PC to start playing.
- Free text s earch for song,artist. One click on the results causes song to play
- Stop/mute whatever is currently playing on iTunes
- Display of album art for the current song retrieved from iTunes store.
- Valuation of music – it displays how much money you have spent in ITunes store (assuming 79p per track)
- Wake up timer – register a wakeup time and a playlist to gently ease you out of bed in the morining
The Web UI can be served in two flavours:
- Desktop grade which uses advanced browser technologies to emulate the iTunes UI.
- Simple device grade which uses simpler technology to deliver a multi page interface for devices with less power.
What use is it?
It was developed while I had broken my ankle and femur and getting up onto crutches to change the tune was a bit of a pain. So the driving use case is for immobile people to make use of their mobile in a local context.
But, what is great for the immobile is fantastic for the rest of us.
Technical notes
The aim of the design was to provide an excellent remote control on a device without having the user install anything. The chief advantages of this approach is.
- No client install. User just fires up a bookmark in the mobile web browser
- Target mutiple devices – even ones which haven’t been invented yet
- Almost Zero upgrade cost for user. e.g a new cell phone just needs a new bookmark in the web browser
Implementation details
The iTunes remote solution is authored in two parts following the “AJAX” model.
- Seperation of content and display – DHTML + CSS takes care of the layout client side, python produces XML data.
- Currently uses Apache web server to handle mutiple requests
- Apache serves a single AJAX front page for the UI, there are no page reloads.
- The python scripts use the COM interface exposed by iTunes to control the application
Challenges
A key challange in creating a consumer grade remote control is to ensure trouble free install. Bluetooth is a one approach. BT is clearly designed for local area connection of two devices and has concepts such as one time pairing for exactly this sort of use case. BT however requires an application to be written for the target device which contradicts the design goal.
Superficially, the web server based approach seems simple enough in a wifi household. The user installs a service on the PC and then points the mobile web browser to the URL of the server. The problem is that the host PC may be hidden behind a router, and complex configurations of router ports and firewalls.
I’d like to know what the best way of doing this is and will be looking to UPnP for the future. I only want a clean easy way of exposing a web server to another device on the same network (of course without running any code on the device).
Nokia 9500 iTunes Remote photos
The search query page:
The result of selecting a song from the search results:
Permalink
