[appcelerator-titanium] Android: Intents API

[donthorp]

There have been several requests for an Intents module for Android.
I'm opening up this thread so we can explore what that module's API
should be.

--
You received this message because you are subscribed to the Google Groups "Appcelerator Titanium" group.
To post to this group, send email to appcelerat...@googlegroups.com.
To unsubscribe from this group, send email to appcelerator-tit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/appcelerator-titanium?hl=en.

[David (dasher)]

Great to see the thread Don!

I'm pretty green around Intents so excuse the ignorance.

First thoughts - assuming there is a generic approach without needing
a proxy interface for each Intent you want to use: listAvailable,
hasIntent, connectIntent & disconnectIntent

David

[Don Thorp]

Let me add couple of reference links and some background.

Intents and Intent Filters: http://developer.android.com/guide/topics/intents/intents-filters.html

OpenIntents: http://www.openintents.org/en/

android.content.Intent: http://developer.android.com/reference/android/content/Intent.html

One thing to keep in mind is that all devices will not have the same set of intents. Standard intents are most likely supported but not always. For example, if you haven't set up an email account, the intent we use for EmailDialog will not be able to send.

We'll probably get the most bang for the buck with Activity intents to start. Those basically come in two forms. Fire and forget, and Fire for result. Launching a URL for telephone is a fire and forget intent we use in Titanium. Obtaining a photo is an example of a fire for result.

Intents are configured via an embedded Bundle which is basically a serializable hash. The data used to configure an intent must usually be marshalled from one process to another. A generic intent may be possible. It might result in an easier API if there were proxies for common Intents that hid some of the complexity.

A bigger step, is to allow Titanium applications to publish their own intents. To support this feature, we'll need to extend the build tools to allow injecting configuration information for the intent into the AndroidManifest.xml. 

What might be useful is for folks to post ideas about what you want to accomplish with specific intents and start iterating to and API from there.

[Marshall Culpepper]

FWIW, I also opened a feature request last week regarding this
subject.. Maybe we should expand it to a more generic Intent API:
https://appcelerator.lighthouseapp.com/projects/32238/tickets/889-provide-an-api-to-launch-custom-intents-in-android

On May 11, 11:07 am, Don Thorp <dth...@appcelerator.com> wrote:
> Let me add couple of reference links and some background.
>
> Intents and Intent Filters:http://developer.android.com/guide/topics/intents/intents-filters.html
> OpenIntents:http://www.openintents.org/en/
>
> android.content.Intent:http://developer.android.com/reference/android/content/Intent.html
>
> One thing to keep in mind is that all devices will not have the same set of
> intents. Standard intents are most likely supported but not always. For
> example, if you haven't set up an email account, the intent we use for
> EmailDialog will not be able to send.
>
> We'll probably get the most bang for the buck with Activity intents to
> start. Those basically come in two forms. Fire and forget, and Fire for
> result. Launching a URL for telephone is a fire and forget intent we use in
> Titanium. Obtaining a photo is an example of a fire for result.
>
> Intents are configured via an embedded Bundle which is basically a
> serializable hash. The data used to configure an intent must usually be
> marshalled from one process to another. A generic intent may be possible. It
> might result in an easier API if there were proxies for common Intents that
> hid some of the complexity.
>
> A bigger step, is to allow Titanium applications to publish their own
> intents. To support this feature, we'll need to extend the build tools to
> allow injecting configuration information for the intent into the
> AndroidManifest.xml.
>
> What might be useful is for folks to post ideas about what you want to
> accomplish with specific intents and start iterating to and API from there.
>

> On Tue, May 11, 2010 at 10:41 AM, David (dasher) <onlydas...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Great to see the thread Don!
>
> > I'm pretty green around Intents so excuse the ignorance.
>
> > First thoughts - assuming there is a generic approach without needing
> > a proxy interface for each Intent you want to use: listAvailable,
> > hasIntent, connectIntent & disconnectIntent
>
> > David
>
> > On May 11, 5:01 pm, donthorp <dth...@appcelerator.com> wrote:
> > > There have been several requests for an Intents module for Android.
> > > I'm opening up this thread so we can explore what that module's API
> > > should be.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Appcelerator Titanium" group.
> > > To post to this group, send email to
> > appcelerat...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com>
> > .

> > > For more options, visit this group athttp://
> > groups.google.com/group/appcelerator-titanium?hl=en.
>

> > --
> > You received this message because you are subscribed to the Google Groups
> > "Appcelerator Titanium" group.
> > To post to this group, send email to
> > appcelerat...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com>
> > .

[Jeff Haynie]

i wonder if we could do some of this by config/convention.

i.e., in tiapp.xml you could register your intentions:

<android>
<intent some_meta_data="value">foo.js</intent>
</android>

Then, this would translate to something like:

foo.js
------

function invokeIntent(properties)
{
}

whereby you would define a common entry point in your intent as a
named function that will be invoked when your intent is invoked. the
intent could take an object of properties of metadata that the intent
passes.



The compiler could then use the tiapp.xml to determine the intents,
compile the appropriate stubbed Java code and AndroidManifest.xml
entries and wire everything up.


We could also possibly use a very similar approach to background
services. Background services could be registered in a very similar
way and invoked almost the same way.

The nice part is that then these types of capabilities could easily be
dropped in through sharing or through the upcoming Module SDK. There's
a nice, clean separation between the intents, the configuration and
the application code.

On May 11, 9:48 am, Marshall Culpepper <marshall....@gmail.com> wrote:
> FWIW, I also opened a feature request last week regarding this

> subject.. Maybe we should expand it to a more generic Intent API:https://appcelerator.lighthouseapp.com/projects/32238/tickets/889-pro...

[Don Thorp]

That's a great idea for incoming intents where the application is a producer and services. We should also lump broadcast receivers in the same discussion. I think we would still need a runtime API for invoking other intents and receiving results or at least tying it to a native implementation.

We have a bug around this, but the IMAGE_CAPTURE intent is a good example of requesting the results from an Activity where the implementation of the intent differs between vendors in how the data is returned. You would need a specific implementation of IMAGE_CAPTURE to deal with the intent incompatibility. But in this case, it's an intent consumer and that could easily be part of a custom module.

As part of the configuration/implementation we would want to capture whether the intent should be wrapped in a chooser or not. This is commonly done for "sharing" using one of the SEND intents.

http://developer.android.com/reference/android/content/Intent.html#ACTION_SEND

[David (dasher)]

Isn't part of the plumbing already in place with the AndroidManifest-
custom.xml rather than using tiapp?
The main app Activities and Intents for launching are currently
published.

[David (dasher)]

How much of the js we write is parsed at compile time?
Would it be possible to build upon std oo in js along the lines of:

jabber.prototype = new ti.Android.IntentPublish();
jabber.prototype.signIn = function(username,password){
return( 'foo' );
}

We could then overload as & when required

On May 11, 8:42 pm, Don Thorp <dth...@appcelerator.com> wrote:
> That's a great idea for incoming intents where the application is a producer
> and services. We should also lump broadcast receivers in the same
> discussion. I think we would still need a runtime API for invoking other
> intents and receiving results or at least tying it to a native
> implementation.
>
> We have a bug around this, but the IMAGE_CAPTURE intent is a good example of
> requesting the results from an Activity where the implementation of the
> intent differs between vendors in how the data is returned. You would need a
> specific implementation of IMAGE_CAPTURE to deal with the intent
> incompatibility. But in this case, it's an intent consumer and that could
> easily be part of a custom module.
>
> As part of the configuration/implementation we would want to capture whether
> the intent should be wrapped in a chooser or not. This is commonly done for
> "sharing" using one of the SEND intents.
>

> http://developer.android.com/reference/android/content/Intent.html#AC...

> > > > > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com><appcelerator-titanium%2B

> > unsub...@googlegroups.com>
> > > > > .
> > > > > > For more options, visit this group athttp://
> > > > > groups.google.com/group/appcelerator-titanium?hl=en.
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > Groups
> > > > > "Appcelerator Titanium" group.
> > > > > To post to this group, send email to
> > > > > appcelerat...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to

> > > > > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com><appcelerator-titanium%2B

[David (dasher)]

Thanks for the links Don - it's been a while since I read them :)

Ok - then it appears that to consume an Activity, the class can be
very simple along the lines of startActivity, startActivityForResult
and an onActivityResult for any results.
To start with any of the simple standard Android Activities can be
used for testing. Something early and iterative is better than too
much planning. We're not sure yet what issues will come up around
security & permissions or performance.

As things progress then some kind of activity browser - packageManager
query() would be helpful - it's something people can use easily just
to sanity check what they're doing and it'll come in handy later when
people start publishing their own activities to check what's going on.

On May 11, 6:07 pm, Don Thorp <dth...@appcelerator.com> wrote:
> Let me add couple of reference links and some background.
>
> Intents and Intent Filters:http://developer.android.com/guide/topics/intents/intents-filters.html
> OpenIntents:http://www.openintents.org/en/
>
> android.content.Intent:http://developer.android.com/reference/android/content/Intent.html
>
> One thing to keep in mind is that all devices will not have the same set of
> intents. Standard intents are most likely supported but not always. For
> example, if you haven't set up an email account, the intent we use for
> EmailDialog will not be able to send.
>
> We'll probably get the most bang for the buck with Activity intents to
> start. Those basically come in two forms. Fire and forget, and Fire for
> result. Launching a URL for telephone is a fire and forget intent we use in
> Titanium. Obtaining a photo is an example of a fire for result.
>
> Intents are configured via an embedded Bundle which is basically a
> serializable hash. The data used to configure an intent must usually be
> marshalled from one process to another. A generic intent may be possible. It
> might result in an easier API if there were proxies for common Intents that
> hid some of the complexity.
>
> A bigger step, is to allow Titanium applications to publish their own
> intents. To support this feature, we'll need to extend the build tools to
> allow injecting configuration information for the intent into the
> AndroidManifest.xml.
>
> What might be useful is for folks to post ideas about what you want to
> accomplish with specific intents and start iterating to and API from there.
>

> On Tue, May 11, 2010 at 10:41 AM, David (dasher) <onlydas...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Great to see the thread Don!
>
> > I'm pretty green around Intents so excuse the ignorance.
>
> > First thoughts - assuming there is a generic approach without needing
> > a proxy interface for each Intent you want to use: listAvailable,
> > hasIntent, connectIntent & disconnectIntent
>
> > David
>
> > On May 11, 5:01 pm, donthorp <dth...@appcelerator.com> wrote:
> > > There have been several requests for an Intents module for Android.
> > > I'm opening up this thread so we can explore what that module's API
> > > should be.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "Appcelerator Titanium" group.
> > > To post to this group, send email to
> > appcelerat...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com>
> > .

> > > For more options, visit this group athttp://
> > groups.google.com/group/appcelerator-titanium?hl=en.
>

> > --
> > You received this message because you are subscribed to the Google Groups
> > "Appcelerator Titanium" group.
> > To post to this group, send email to
> > appcelerat...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > appcelerator-tit...@googlegroups.com<appcelerator-titanium%2B unsub...@googlegroups.com>
> > .