The first list of items I want to cover actually could be applied to any web browser on any platform. Yup! I think that the following would be of immense use running under windows or Linux, using IE, FireFox, Opera or Safari! Ok, so this is more than what I said in the first paragraph!
The second list of items is a wish list of iPhone specific things I would like to see added to the iPhone Safari browser's functionality. These items have to do with interacting with the iPhone's user interface.
List 1: Enhanced Programming Functionality for All Browsers (Especially iPhone Safari):
- A "webapp" meta tag. If the web browser sees this, it will know to save the file in a special area for the domain it came from.
- When the browser sees that the page is flagged "webapp", it will call the server via the domain that allegedly sent the page to the browser. To will expect a response from the server. The purpose of this functionality will be to prevent a web app that has it's domain spoofed from being able to run. This challenge response would only be done once during the web app's installation.
- Users would always be prompted before installing a new web app.
- The web browser will have its own web app page that can be accessed either from the menu or the main toolbar.
- The user can bring up this page and click on a link/button to start the web app.
- The web app will run locally (unless a URL on an image or link points to an external domain).
- Users would be able to delete web apps from their web app page.
- Users could set up the maximum storage space allowed for all web apps on the client computer.
- Users could set up the maximum storage space for a domain or sub-domain that the web app is coming from.
- Users could set up domains which they wish to automatically block any web apps from installing on their PC.
- The storage for web apps would hold the following items: HTML files, Javascript files, image files, mp3 files, own cookie area, it's own private database instance.
- All data for a web app would be stored encrypted.
- Each web app would have it's own private database instance. This instance could have one or more schemas. One could use pretty generic SQL to work with a schema.
- For a web app running on an iPhone (at least), another meta tag could specify an image file to be used as a button (for the web apps page).
- All scripting would be done in Javascript.
- All the new functionality would be exposed via the new webapp object.
- webapp.databases would expose any database schemas as well as methods to work with them.
- Cookies would work like normal from a programmer's perspective but would be saved in the web app's own storage area.
- webapp.getInstallDate() would return a date object with the date/time the web app was installed.
- webapp.getDomain() would return the domain/sub-domain that the web app came from.
- webapp.databases.createSchema(schemaName) could be used to create and return a new schema object.
- webapp.databases.getSchema(schemaName) would return an existing schema object.
- webapp.databases.deleteSchema(schemaName) would delete a schema name. If successful, it would return a value of True.
- webapp.databases.getSchemaList() This method would return a javascript text array of all the schemas that the databases object contains.
- schemaObject.addTable(tableName) Would create a new table. Could Use DDL too.
- schemaObject.delTable(tableName) Would delete a table. Could use DDL too.
- schemaObject.executeSQL(sql) Would execute SQL. If running a SELECT statement, it would return a recordsetObject.
- schemaObject.beginTransaction()
- schemaObject.commitTransaction()
- schemaObject.rollbackTransaction()
- recordsetObject.getRecordCount()
- recordsetObject.moveFirst()
- recordsetObject.moveLast()
- recordsetObject.moveNext()
- recordsetObject.movePrevious()
- recordsetObject.getFieldValue(fieldName)
- An "ontouch" event. The event object would return an array. Each array element would contain an object holding the coordinate of a pixel that was being "touched" at the time, as well as a timestamp when the event occurred. Using this info, one could even write a finger painting type app which captured all the subtleties of the user's finger gestures.
Example:
var touched = event.touched;
alert("pixels touched="+touched.length;
var dot = touched[0];
alert("coords:"+dot.x+","+dot.y);
alert("timestamp: "+dot.date); - An "onrelease" event. Would work the same way as the ontouch event but the array of objects it would return would be of all the pixels that were being pressed but now are not being pressed! Sort of like mouseup but more robust.
- An "onresize" event for the body tag that works properly!
- window.makeAsyncSound(sSoundFileName) This would return a asyncSound object.
- asyncSound.onplay used to trigger code to run when sound starts to play.
- asyncSound.onplaydone used to trigger code to run when sound is done playing.
- asyncSound.play() plays sound.
- asyncSound.getStatus() returns the status: 0=not playing 1=playing 2=error
- asyncSound.stopPlay() stops playing sound (if it is currently playing)
I think this is a good start. What do you think? What are some possible security issues in the web app architecture that I've set forth? I'm planning on adding and tweeking this page as you give feedback and as I get more ideas. Perhaps it will inspire some Safari browser developers?
