I'm certainly not suggesting that making intents visible would be a
complete solution to the swampy problem.
But, it would bring some useful clarity into the world, and reduce the
confusion and randomness that comes out of the methods developers are
using right now. At the very least, it would ma
Ok, then we had similar suggestions :-)
Somehow extend the default information about intent filters with
additional information provided by the developer (either in the
Manifest, or through separate intents).
Whether any of these is more effective than writing good documentation
remains to be se
It does not exist, it is meant to be an example of how it could be
done.
On Feb 2, 9:11 am, Peli wrote:
> > In Android, to make it easier to let developers communicate how to use
> > intents you could add a url to document how to use the Intent to the
> > intent-filter.
> > http://mydomain
> In Android, to make it easier to let developers communicate how to use
> intents you could add a url to document how to use the Intent to the
> intent-filter.
> http://mydomain.com/android-api/appname/
Is this something that exists, or did you just make this up as an
example, how it *co
Hi,
> The effect is that there is is no good distinction between 'private'
> and 'public' interfaces, since all intents are equally visible [...]
> Just being able to see the intent filters of other apps
> would be a huge help.
I doubt that this would be the solution you look for. If your
appli
The "swamp" you are describing is very similar to what has happened
with Microsoft's COM architecture. Once a COM interface is out there,
other developers start using it, whether you want them to or not.
In Android, to make it easier to let developers communicate how to use
intents you could add
I see where you are coming from, but I think what may really happen is
that the usage of intents between apps will turn into a terrible
swamp.
You can see it happening already, with developers using logcat output
and guessing and finding snippets in other deveelopers blogs and
reading source (whe
And btw, a significant number of things you can do with the applications are
documented in the Intent class as generic protocols (such as VIEW or
GET_CONTENT) along with the various MIME types and URIs defined by the
standard content providers in android.provider.
On Fri, Jan 30, 2009 at 2:29 PM,
I'll still say, if it hasn't been documented, then you probably have no
business using it.
If you want to go use private implementation details of the platform, you
can browse through the source code and look at the manifests of the apps.
That is all that the system knows about the intent protocol
I understand the point about trying to stick to intents which have
been documented by their developers.
The problem is, even a well-intentioned but busy developer may simply
not get round to writing that documentation. The system applications
are a great example of that effect.
At least, with a
You shouldn't just look at what intents an app happens to use: unless
someone publishes official protocols, those should be considered private.
Unless an app developer is explicitly maintaining them, they could change
their app arbitrarily and break someone using those implementation details.
And
> The strangeness is not just limited to the lack of a discovery API.
What I'm trying to say is, even if they were discovery APIs they would
be of limited use, because they could never tell you which extras you
have to use, what they mean, and how to interpret the result.
The only thing that can
Peter - I agree completely. OpenIntents is a great idea, but it
doesn't fix my problem either.
The strangeness is not just limited to the lack of a discovery API.
There's also a peculiar lack of documentation on what the built-in
apps can do, leaving us wasting a lot of time poking about making u
You could leave logcat running while you launch Amazon MP3 in various
ways. This will tell you at least the action you need to use, and
probably something about the data and the mime type (if used).
If the intent has extras then you are out of luck (unless you guess
well). Extras are not specifie
On Jan 30, 10:45 am, Peli wrote:
> For this reason, we have created the OpenIntents intents
> registry:http://www.openintents.org/en/http://www.openintents.org/en/intentstable
>
> Even if there is a way to find all intents supported by an
> application, this will not tell you what kind of extras
For this reason, we have created the OpenIntents intents registry:
http://www.openintents.org/en/
http://www.openintents.org/en/intentstable
Even if there is a way to find all intents supported by an
application, this will not tell you what kind of extras are supported
or required or which result
I'd very much like to know the answer to that question.
I have spent some time poking about with PackageManager, thinking that
the intent filters should be available through it, but I have not
found a way.
Not only have I failed to find any API to get the intent filters, I
have also failed to fi
17 matches
Mail list logo
