1 message in com.googlegroups.android-internalsEvent/Intent routing - Handling only ...| From | Sent On | Attachments |
|---|---|---|
| Erich | 03 Feb 2008 04:55 |
| Subject: | Event/Intent routing - Handling only certain calls/messages![]() |
|---|---|
| From: | Erich (eric...@gmail.com) |
| Date: | 02/03/2008 04:55:25 AM |
| List: | com.googlegroups.android-internals |
Hi folks,
First let me note that I havn't even read through all the documentation available for Android yet. But I was at the "Android Developer Session" held by Google Germany in Munich. In the Android Internals session, I asked this question, and it was suggested I post it to the list or file a bug, so it can be considered for future API changes. Apparently, this point has come up before, but has so far just been considered a rarely needed feature. My use-case is rather simple but useful, so it might help on deciding how to implement this the best way.
In the sessions, it was explained that users should be able to choose which application to install for handling certain tasks, e.g. for taking a call. My question was whether users can give a priority for multiple applications, and whether one application can "pass" and let the next application handle the event instead. Think of exception throwing.
The use case I have is simple: a door bell application. I took this idea from some TV report I saw years ago, where a wheelchair user had set up a similar system, so he could e.g. have the postman deliver a package to his flat door even when he was not at home.
The idea is simple: many telephone systems allow attaching the doorbell to it. When someone rings at the door, it would call my mobile phone. When such a call comes in, I want my mobile phone to connect to my webcam, and offer me an "open the door" button INSTEAD of giving me the regular phone application.
To be able to implement this, I'd need a way to have the "door bell" application only handle certain calls (based on the Caller ID), while pass on any other calls to the regular 'phone' application. A similar use would be SMS notification of network issues. Many people have setup a monitoring system for their servers that will send a SMS alert when something goes down. In such a case, I'd like my phone to automatically pop up a status page giving me more detailed (and more up-to-date) information than the actual message.
Another use case for 'passing' on an event (not sure if these are 'intents', so I'm using the term event): Let's assume I have two applications for a task, e.g. "picking a photo". One is network-enabled, let's say a Picasa photo picker. The other one is only using the phones internal memory. When there is no network connectivity, I'd like the Picasa photo picker to pass on the event, and let the other photo picker handle it (granted, maybe the Picasa photo picker should just have an offline mode, but you're welcome to come up with a better use case). This can be useful in pretty much any situation where an application can detect early whether or not it will be able to handle the event. E.g. if the application is not yet configured, lacking some data files, etc. pp., it might just pass and the system could automatically fall back to a secondary application.
Random other stuff:
One more question that came up at the Android developer session, somewhen informally when waiting for lunch: Security policy. Users might want to prevent some applications from e.g. doing a call or accessing GPS information. Especially relevant for cost control and privacy. I've seen that there are some permissions in the Manifest file, but that doesn't include e.g. GPS information. I figure this can be done via the permissions system, and just isn't in place for some things yet. Just reporting what people talked about at the event. Someone also asked about multi-touch support.
I also wondered if there is a way to do "single sign on". Many apps will need a web service for certain tasks; but probably won't want every user to have to sign up separately. Last I checked, the Google Accounts API for example couldn't do SSO.
Is there a 'rich editor' component that can be reused by applications? Let's say I'd like to do a "mobile wiki" app; it probably should just reuse a rich editor widget (which probably should then use WebKit? or based on TextView/EditText?). I don't think doing everything in webkit yourself (using things such as FCK-Editor) is appropriate, since graphics, buttons and usability in general of the rich editor should maybe be optimized for the mobile phone itself.
Are there any plans of using Android e.g. on MP3 players (think of Apple using the iPhone software also on iPod Touch; see Rockbox, which works great on my iAudio X5, and one of the things I really love is the sudoku app), traditional PDAs (probably a dead market by now), sub- notebooks (like the Asus EEE-PC, OLPC) etc. pp. I'm aware that many people thing MP3 players, mobile phones and PDAs will completely converge into one device, but for example I'm used to my MP3 player running out of battery sometime, but I couldn't tolerate that on my phone, so I like keeping them separate devices.
In general, Android could make an interesting embedded-linux platform even for displayless devices. I've been developing embedded Linux on the Intersil ISL3893, a wireless system-on-a-chip. The biggest issue was that their SDK was a years-old fork of ucLinux with even bugs in the memory allocator Intersil developed (which happened to break all SSL libraries by making realloc() malfunction in certain situations that frequently occurred there). I'm aware that much of the Android platform currently is quite a lot about user interface and user- installed applications, but even just the Dalvik runtime and it's resource management. So even if it's mostly useless for an AccessPoint, there are just tons of devices with embedded Linux around. I might for example want to use an AccessPoint with a USB port, attach a USB audio device to it, and use it as network media player. The UI will probably be a web UI I'm accessing via my mobile phone. Then it might be cool to have Android on both my media player and my mobile phone controlling it. Or a TV set. Why not use Android on a TV set and allow users to e.g. write an XMPP (Jabber, Google Talk) client to run on their TV set.
Regards,




