Dependency Management

[Jens Finkhaeuser]

Hi all!

I've seen bits and pieces of this discussed in fairly old threads, and
I've recently become very interested in this for my own reasons. I'd
like to refresh discussions about the goals of dependency management
by summarizing the current state of ideas, as I am aware of them.
Please forgive the slight "brain dump" nature of this post, I'm trying
to figure out if we're roughly on the same page here.

Goals:

* Promote code re-use/interaction between apps. On this mailing list,
that shouldn't be something I need to convince anyone of ;) But it's a
major goal and needs to be named.
* Promote good user experience. Maybe that's a more personal view,
but I tend to have my mum in mind when I write software. I wouldn't
want to let her figure out how to install e.g. a barcode scanner app
in order to e.g. use my PackRat app. I want the OS/package manager to
resolve such things for her.

Current state:

* It seems people converge on a <uses-intent />-type tag in
AndroidManifest.xml that lists the intent name the app uses. The
expectatation is that the OS/package manager resolves the contents of
the tag in order to offer suggestions as to which intent provider (if
I may call them that) should respond to an intent.
* As an alternative to get things going prior to approval by Google/
OHA, a meta-tag with the same purpose could be used.

Notes:

There is some support for this necessary on the OS level and on the
package manager level. Installing dependencies is one thing, but they
can be uninstalled again. There either needs to be a mechanism to
prevent that. Alternatively the OS could figure out whether there are
unfulfilled intent dependencies at the start of an app and direct the
user to the package manager to install an appropriate app.

There's a clear downside to this. In an app such as my PackRat, the
dependencies on other apps are fairly soft - it works without them,
it's just not as nice. Clearly I'd prefer to check for the
availability of intent providers in code, in order to e.g. pop up a
friendly message telling the user that a particular feature is not
available.

It'd be good if Market (or any other app store) also responded to
searches for apps by intent name. If nothing else, that'd allow people
to pick their preferred intent providers.


Did I miss anything? Got anything wrong that you guys discussed in
more detail?

Jens

[Carl-Gustaf Harroch]

Response in line. For my part, I am very busy til next week and would
not be able to contribute fully until then.

2009/11/12 Jens Finkhaeuser <unw...@gmail.com>:

>
> Hi all!
>
> I've seen bits and pieces of this discussed in fairly old threads, and
> I've recently become very interested in this for my own reasons. I'd
> like to refresh discussions about the goals of dependency management
> by summarizing the current state of ideas, as I am aware of them.
> Please forgive the slight "brain dump" nature of this post, I'm trying
> to figure out if we're roughly on the same page here.
>
> Goals:
>
>  * Promote code re-use/interaction between apps. On this mailing list,
> that shouldn't be something I need to convince anyone of ;) But it's a
> major goal and needs to be named.
>  * Promote good user experience. Maybe that's a more personal view,
> but I tend to have my mum in mind when I write software. I wouldn't
> want to let her figure out how to install e.g. a barcode scanner app
> in order to e.g. use my PackRat app. I want the OS/package manager to
> resolve such things for her.
>
> Current state:
>
>  * It seems people converge on a <uses-intent />-type tag in
> AndroidManifest.xml that lists the intent name the app uses. The
> expectatation is that the OS/package manager resolves the contents of
> the tag in order to offer suggestions as to which intent provider (if
> I may call them that) should respond to an intent.
>  * As an alternative to get things going prior to approval by Google/
> OHA, a meta-tag with the same purpose could be used.
>

We could add a mandatory=true|false attribute to the tag and let the
developer programmatically suggests non mandatory downloads. I
definitely agree that a metatag as POC is what we need now.

> Notes:
>
> There is some support for this necessary on the OS level and on the
> package manager level. Installing dependencies is one thing, but they
> can be uninstalled again. There either needs to be a mechanism to
> prevent that. Alternatively the OS could figure out whether there are
> unfulfilled intent dependencies at the start of an app and direct the
> user to the package manager to install an appropriate app.

There is also a need to ensure the dependencies are free or not. for
instance you could have a free app that depends on a payable one. As
such, when the user installs an app, he should know how much it will
cost with its dependencies.

>
> There's a clear downside to this. In an app such as my PackRat, the
> dependencies on other apps are fairly soft - it works without them,
> it's just not as nice. Clearly I'd prefer to check for the
> availability of intent providers in code, in order to e.g. pop up a
> friendly message telling the user that a particular feature is not
> available.
>
> It'd be good if Market (or any other app store) also responded to
> searches for apps by intent name. If nothing else, that'd allow people
> to pick their preferred intent providers.

I am pondering if this should be done on the server side (dependency
management) or client side. In my opinion server side would probably
be better in terms of user experience as all necessary downloads would
happen when you install the desired one.

>
> Did I miss anything? Got anything wrong that you guys discussed in
> more detail?
>
> Jens
> >
>

--
Carl-Gustaf Harroch

Sent from Windsor, Eng, United Kingdom

[Peli]

Hi Jens,

Good to hear that we are getting some momentum on this issue. Let me
throw in my thoughs on this issue:

* Of course it would be best to have full intent dependency support
included in the platform and in Market. This would be a long-term goal
that would require efforts also from inside Google. We do not have any
control over his process, so it may happen at some point, it may
happen overnight without us doing anything, or it may never happen at
all. Chances are higher that we have some influence, if we can provide
patches for the Android source code - but that is a tough task with
uncertain outcome. For Market, there is not even such possibility,
because it is closed source.

* For the OI applications, we have a couple of depencencies which are
resolved at run-time: E.g. OI Notepad prompts a dialog to download OI
File Manager, if a user wishes to save a note to the SD card, or it
prompts to download OI About, if user presses menu > About, or it
prompts the user to download OI Safe, if the user wishes to encrypt a
note. Note that our intents are designed in an open way, so if the
user had already installed another file manager or safe that supports
the same intents, those would be used instead.

* We already have an intent registry at OpenIntents.org that has been
used by a growing number of developers. It would be wise to build on
top of that.

What we should do:
* Friedger is in the process of building an improved version of the
intent registry. It is easiest to include wishes in this early stage,
so we should discuss and define, what the new intent registry should
be able to do.

* I agree with Jens (and had similar ideas actually, too) that we need
to distinguish between "drafts" and "standards" or implemented
intents. The burdon should not be set too high, though. Anybody
wishing to provide small intents for their individual use case should
be able to do so in their own name space without requiring a long
process of reviews and standardization. Standardization really only
makes sense where several developers want to agree on commonly used
intents (like e.g. used for barcode scanning or in a file manage).

* K.I.S.S. : For each problem, let's try to focus on the easiest
solution. Inventing new tags for the Manifest could be a good idea,
but I'm not sure if many developers would follow this pracise.

* Instead of waiting for Market to support automatic dependencies (and
waiting for third party markets to do the same), it may be quicker to
provide a light-weight "lib" that developers can include in their
applications to resolve Market or links to other download sites the
first time a feature is required.

* As for the search in Market, one could for now simply invent a
search string that is included in the Market description, e.g.
"intents:filemanager". A search for this string would provide all apps
that claim to support file manager intents (like open or save a file
dialog).

Peli

[Jens Finkhaeuser]

I agree with all points. A few comments inline.

> * For the OI applications, we have a couple of depencencies which are
> resolved at run-time: E.g. OI Notepad prompts a dialog to download OI
> File Manager, if a user wishes to save a note to the SD card, or it
> prompts to download OI About, if user presses menu > About, or it
> prompts the user to download OI Safe, if the user wishes to encrypt a
> note. Note that our intents are designed in an open way, so if the
> user had already installed another file manager or safe that supports
> the same intents, those would be used instead.

Indeed. I've been thinking about writing & open sourcing a small lib
that'd make it easy for developers to prompt for the installation of
other apps in this manner. Unfortunately, right now all we can do is
link to specific apps in the market. I'm still unsure whether I want
invest time into an inferiour solution like that.

> * I agree with Jens (and had similar ideas actually, too) that we need
> to distinguish between "drafts" and "standards" or implemented
> intents. The burdon should not be set too high, though. Anybody
> wishing to provide small intents for their individual use case should
> be able to do so in their own name space without requiring a long
> process of reviews and standardization. Standardization really only
> makes sense where several developers want to agree on commonly used
> intents (like e.g. used for barcode scanning or in a file manage).

Absolutely. As far as I am concerned, the difference between a draft
and a standard is little more than more parties than the author a)
agreeing that it's relatively unambiguously worded, and b)
implementing it. It should be as lightweight as possible.

> * K.I.S.S. : For each problem, let's try to focus on the easiest
> solution. Inventing new tags for the Manifest could be a good idea,
> but I'm not sure if many developers would follow this pracise.

IMO that *is* the easiest solution for now.

> * Instead of waiting for Market to support automatic dependencies (and
> waiting for third party markets to do the same), it may be quicker to
> provide a light-weight "lib" that developers can include in their
> applications to resolve Market or links to other download sites the
> first time a feature is required.

See above. I agree, but I'd like to be able to create links to
intents rather than apps. If it's to apps directly, much of the point
is lost IMO.

> * As for the search in Market, one could for now simply invent a
> search string that is included in the Market description, e.g.
> "intents:filemanager". A search for this string would provide all apps
> that claim to support file manager intents (like open or save a file
> dialog).

Something like that is required, yes.

Let me for a moment provide a slightly grander vision. Right now,
the only special keywords for searching the market I know of are
"pname" and "pub" - doesn't matter if you know more. It'd be awesome
if Google published documentation on these, and that became the
standard for searching in app stores. There's nothing keeping e.g.
AndAppStore from responding to the market-URI-scheme AFAIK, and
answering those requests itself. Right?

Maybe one of the things we could focus on as an outcome of these
discussions is a standard proposal to Google for querying Market-like
apps. Together with a lib like discussed above, we might have the
combination of stuff Google would find useful enough to support.

Partially thinking out loud here, of course. Hmm. But yes, I'd
certainly help implement such a lib.

[Peli]

> > * As for the search in Market, one could for now simply invent a
> > search string that is included in the Market description, e.g.
> > "intents:filemanager". A search for this string would provide all apps
> > that claim to support file manager intents (like open or save a file
> > dialog).
>
>   Something like that is required, yes.
>
>   Let me for a moment provide a slightly grander vision. Right now,
> the only special keywords for searching the market I know of are
> "pname" and "pub" - doesn't matter if you know more. It'd be awesome
> if Google published documentation on these, and that became the
> standard for searching in app stores. There's nothing keeping e.g.
> AndAppStore from responding to the market-URI-scheme AFAIK, and
> answering those requests itself. Right?

I was actually suggesting that it is possible already now:
as application developer, I write: "OI File Manager is a simple file
manager. intents:filemanager bla bla".

and then your application simply searches for "intents.filemanager".

Or, more user friendly, the actual search string could be "filemanager
intents", and the description reads "OI File Manager supports
filemanager intents".

This is already implemented in this way, if you open OI shopping list
> menu > settings > Get extensions
or if you want to look for plug-ins for Locale (they also use a
special search string to look for their extensions).

As for additional tags in Manifest: IMO intent resolution is better at
run-time than at installation time (at least for OI Notepad: Not
everyone needs OI Safe, or OI About right from the beginning, and
memory is sparse on a mobile phone (*)). In this sense, also
additional tags take valuable space that is most of the time not used,
except maybe by a dependency system or by a central intent registry -
certainly not by the end user directly.

(*) It is also one of the advantages of the intent system, that you
only need to install what you really need - at that is most of the
time at run-time than at installation time.

Peli

[Jens Finkhaeuser]

> I was actually suggesting that it is possible already now:
> as application developer, I write: "OI File Manager is a simple file
> manager. intents:filemanager bla bla".
>
> and then your application simply searches for "intents.filemanager".

Fair enough, if it goes into the human-readable description of an
app, it'll work already. I'd prefer not to spam that area with
metadata of this kind, but it'd work.

> As for additional tags in Manifest: IMO intent resolution is better at
> run-time than at installation time (at least for OI Notepad: Not
> everyone needs OI Safe, or OI About right from the beginning, and
> memory is sparse on a mobile phone (*)). In this sense, also
> additional tags take valuable space that is most of the time not used,
> except maybe by a dependency system or by a central intent registry -
> certainly not by the end user directly.

Like I said, I can see a scenario for either. In the case of my app,
I prefer a run-time dependency, because the app works just fine on
it's own.

Imagine ... an app to manage your pictures, for example. It's pretty
pointless without being able to invoke the camera and take new
pictures (yes, I know, it'd be possible to just manage pictures pushed
to the device via the SD card, but grant me that slightly bad
example). In such a case, a hard dependency is a lot more interesting
to me.

IMO it's a question of user experience. Resolving dependencies at
install time does not mean you won't need to resolve them at run time
any longer, you still do. But it means you're not getting bounced back
and forth between an app you just want to try out and the market,
until you *finally* have everything you need.

Maybe that clarifies why I think there's a need for both?

Jens

[Justin]

Instead of <uses-intent> I think you want to hook into the existing
<uses-library> tag, this was meant to express dependencies in Java
code, but I don't see why it couldn't be reused for Intents.

Secondly though, I think this is the wrong thing to do. Intents are
meant to be late binding. What if some module of your code uses a
certain Intent, but the user never uses that module? Making them
download this other app is a waste of their time and storage space.

My current thinking is that there's room for an IntentManager like
there exists a package manager on most systems (including Android). It
runs as a Service and can be queried for a servicer for a given Intent-
data combination. It can than return one or more URIs that contain
packages capable of servicing the Intent. These could be Market URIs
or they could be out to arbitrary websites. The Service probably
maintains a cache of information about the most popular Intents, but
can talk to a web service when it encounters a less common request.
Further, it can analyze exact requirements that we can't even imagine
now. For example, maybe I need something to put captions on images for
me *and* it has to support Hebrew.

Cheers,
Justin

[Peli]

Hi Justin,

It is great to have a Google employee here discussing with us :-)

I like the idea of an IntentManager. Indeed, looking at the bigger
picture, it may be better not to integrate this functionality into
Market, because there could be alternative Android app stores. It
sounds like a doable task that we could start here at OpenIntents, and
in the best case it could be handed over to the Android project and
included there.

A while ago, Friedger already suggested an intent that would have
helped, but it was declined by Google:
http://code.google.com/p/android/issues/detail?id=910

This would have helped to catch intents that can not be resolved by an
IntentManager, that could then search the Market or alternative
Markets for applications that can handle those intents.

But it is not impossible to proceed without this intent. I could
imagine a small lib that application developers could simply include
in their project so that unresolved intents could be caught and an
ACTIVITY_NOT_FOUND intent be raised. In the worst case if no
IntentManager is installed, the light-weight library would prompt to
install the IntentManager from Market or some alternative place.

So we would have the following components that would have to be built
- either by us here at OpenIntents or by Google:
1) Intent registry: central database for developers, which is also
used by IntentManager to resolve intents.
2) IntentManager: Service in background (actually just an intent
receiver) that can resolve unhandled intents, connecting to intent
registry for unknown intents, and suggesting suitable applications
from Market or other download sites.
3) small lib: To be included in applications that want to use cross-
application intents. It either prompts to download IntentManager, or
passes unresolved intents to IntentManager.

Any other ideas? Who would be willing to contribute what?

Peli

[Jens Finkhaeuser]

> I like the idea of an IntentManager. Indeed, looking at the bigger
> picture, it may be better not to integrate this functionality into
> Market, because there could be alternative Android app stores. It
> sounds like a doable task that we could start here at OpenIntents, and
> in the best case it could be handed over to the Android project and
> included there.

As much as I love the idea of this IntentManager (and can contribute
when I find time), I do think uses-intent (or uses-library) is still
important.

Late binding is great for situations where using another app's code
is otional. It's also important to ensure that when a dependency is
uninstalled, your app does not crash & burn horribly.

I still think that any decent package manager should ensure that an
app's dependencies are installed when the app is installed, though -
and that's what the uses-intent tag is all about to me. If you use
apt, rpm, download something from steam, playstation network, wii
ware, you name it - you expect whatever you installed to Just Work
(TM) after installation, right?
That's what the uses-intent tag is about to me, first and foremost.

Note though, that this in no way means that every intent you use
needs to be mentioned in a uses-intent-like tag. Those should be used
only for intents without which your app does not fulfil it's purpose
(up to the dev to decide what that means, IMO). You can use N intents,
and mention M in the manifest, where N >= M.

As icing on the cake, Android might additionally check the tag at
application startup, query IntentManager whether all intents mentioned
in these tags are being serviced by currently installed packages. It
might pop up a dialog warning that the app may not work, and/or offer
to install apps (via the URIs provided by IntentManager) to satisfy
the dependencies.
Think linking against shared libraries versus using them via dlopen
(). There's a use-case for both.

It doesn't even have to be Android that does it. A custom
application class would do the trick, or a hook into the small library
mentioned above. I'm just a fan of pushing what I consider essential
functionality down into the OS layer.

As for contributing, my main interest would lie in IntentManager.
I'll be busy for a few weeks still, though, so don't want to hold
anyone back from jumping in. But if by that time (probably approaching
christmas) nobody has taken it up, I'd like to get started on it
myself.

Jens

[Peli]

>   I still think that any decent package manager should ensure that an
> app's dependencies are installed when the app is installed, though -
> and that's what the uses-intent tag is all about to me. If you use
> apt, rpm, download something from steam, playstation network, wii
> ware, you name it - you expect whatever you installed to Just Work
> (TM) after installation, right?

I agree that for some applications it makes more sense to ensure at
installation time that all necessary components are installed as well.
Here are my arguments, why I think an IntentManager would be better
suited for that task than Market:

* Market is not the only Android store. There are AndAppStore,
SlideMe, and a growing number of other smaller markets. Many devices
don't have access to Market (either because they have custom Android
builds, or they are in countries that don't support it yet). We don't
want to exclude those people from accessing a good dependency system.

* Just Work (TM) after installation would be problematic: For some
intents, there could be more than one application that can handle it,
so the user should be able to choose which additional necessary
component they would like to use. Ideally, the user could choose e.g.
between different bar code scanning libraries after installing a
shopping app that requires a bar code scanner.

* Every additional component may require their own set of permissions,
so the end user has to have the possibility to review the permissions
for each additional component anyway. This would also go beyond Just
Work (TM).

From a technical point of view:
* Intent.ACTION_PACKAGE_ADDED: The IntentManager could easily listen
for this intent, and check the Manifest tags (YES, after all, the uses-
intent tag or meta-tag is useful). It could then suggest a list of
necessary or even optional components that the user may want to
install, and point them to Market or alternative app stores.

* The same could be done for ACTION_PACKAGE_REMOVED and related, to
ensure that all apps would continue to work. The user could be warned
if necessary components had been removed.

Note: I don't think we want to hook into the existing uses-library tag
( http://developer.android.com/guide/topics/manifest/uses-library-element.html
) because this is intended for shared libraries like maps or awt. I
think, a new "uses-intent" would be much more light-weight. It does
not involve the class loader, but is only optional information for a
(third-party) IntentManager that wants to make sure that certain
applications are installed that can handle the required intents.

To summarize:
IntentManager should listen for:
* intent ACTION_ACTIVITY_NOT_FOUND to resolve intents at run-time
* Intent.ACTION_PACKAGE_ADDED: to check whether the newly added
package requires additional intents to be present that the user should
be prompted about.

Would this solve all the problems mentioned?

Peli

[Jens Finkhaeuser]

> To summarize:
> IntentManager should listen for:
> * intent ACTION_ACTIVITY_NOT_FOUND to resolve intents at run-time
> * Intent.ACTION_PACKAGE_ADDED: to check whether the newly added
> package requires additional intents to be present that the user should
> be prompted about.
>
> Would this solve all the problems mentioned?

I think so... at least you've convinced me that IntentManager is the
better place than Market! At first glance this seems to solve all
issues I can think of, at any rate :)

Jens

[Friedger Müffke]

Maybe we can reuse parts of MashupOrganizer at www.androidmashup.org
for the IntentsManager. Hopefully, Falko joins the discussion.

The idea is to have one intents repository that is used by all intents
related sites, (developer) tools and apps.
If you have suggestions or requirements for an API let me know.

(For now, I will use a Drupal module - any help welcome as I am a
newbie to Drupal).

Friedger

2009/11/13 Jens Finkhaeuser <unw...@gmail.com>:

--
OpenIntents UG (haftungsbeschränkt)
Suarezstraße 41
14057 Berlin
tel:+49 30 60982220
mailto:in...@openintents.biz
enum:+493060982220

Vertretungsberechtigter Geschäftsführer: Friedger Müffke
Registergericht: Amtsgericht Berlin (Charlottenburg)
Registernummer: HRB 118597
Ust-IdNr: DE265992701

[pjv]

I've just read through this interesting discussion and it seems all
facets have been covered.

I agree with Justin and Peli. The dependency management should be
loosely set-up, rather than rigid, i.e. meant for runtime. The problem
with the rigidly enforced dependencies in the RPM (or Gentoo ebuilds
for that matter) example is that you go down a path that gets really
hard really soon. Yet still you cannot offer the guarantee that the
installed app will work, as the dependency-app that should handle the
intent might still not handle it properly (versions come into play
here, and, next, different levels of dependencies and versions, etc.).
However, this does not mean that no suggestions can be made at install
time. In that case you can afford to be wrong or incomplete some of
the times. So the initial goals remain in place.

Let me summarize what I believe was discussed:
Ideally (i.e. long term):
- Suggestions at install time from any Market
- Runtime popups to install a dependency, handled by a system function
- It's not one or the other, but both
- App dependency information entered in the manifest via uses-intents
tags or similar
- There might be a distinction between strictly needed apps and nice-
to-haves
- Distinction between form of dependencies: free or paid, which
permissions, ...
- Distinction between location of dependencies: in the Market or not
- Distinction between state of intents: draft, concept, under change
control, deprecated (for now, proposal of new intents should be as
lightweight as it is currently, just adding it yourself, but on the
long term we might want to evolve into some committee approval system
to avoid bad quality intents and duplicates)
- More than one dependency might be needed to satisfy handling an
intent, or to offer choice while suggesting
- Dependency tree, with even double entries as per the above
- All this without much changing screens and processes, minimally
bothering the user, and without performance bottlenecks
- Deal with uninstalls and getting new suggestions


Practical (doable):
- We leave the Market and install time based stuff alone for now
- We take the one Android Market interface as model and expect other
markets to behave accordingly (narrow done to THE Market)
- Not a system/Market function but a service, library or service
+library -> IntentsManager
- The Intents Registry boils down to the (new) OpenIntents database
for now
- IntentsManager searches the Intents Registry for specific matches
and does a wide search on market descriptions a la intents:filemanager
(Beware of the 325 char limit! Also I have already seen this turn out
badly with the T-Mobile Recommended apps as any app could just be
added to that exclusive selection with the right string in the
description.)
- The IntentsManager, when implemented as a Service, might form a
bootstrapping dependency itself on all apps, hampering the
introduction of this system

I would say this is something that can be done.

By the way, I'd like to add that a small part of the Market API
(regarding pname and pub) is in the documentation:
http://developer.android.com/guide/publishing/publishing.html

On Nov 13, 7:41 pm, Friedger Müffke <fried...@googlemail.com> wrote:
> Maybe we can reuse parts of MashupOrganizer atwww.androidmashup.org
> for the IntentsManager. Hopefully, Falko joins the discussion.
>
> The idea is to have one intents repository that is used by all intents
> related sites, (developer) tools and apps.
> If you have suggestions or requirements for an API let me know.
>
> (For now, I will use a Drupal module - any help welcome as I am a
> newbie to Drupal).
>
> Friedger
>

> 2009/11/13 Jens Finkhaeuser <unwe...@gmail.com>:

>
>
>
>
>
> >> To summarize:
> >> IntentManager should listen for:
> >> * intent ACTION_ACTIVITY_NOT_FOUND to resolve intents at run-time
> >> * Intent.ACTION_PACKAGE_ADDED: to check whether the newly added
> >> package requires additional intents to be present that the user should
> >> be prompted about.
>
> >> Would this solve all the problems mentioned?
> >  I think so... at least you've convinced me that IntentManager is the
> > better place than Market! At first glance this seems to solve all
> > issues I can think of, at any rate :)
>
> > Jens
>
> --
> OpenIntents UG (haftungsbeschränkt)
> Suarezstraße 41
> 14057 Berlin
> tel:+49 30 60982220

> mailto:i...@openintents.biz

[Jens Finkhäuser]

Hiya!

Always good to hear/read other opinions on this all :)

> I agree with Justin and Peli. The dependency management should be
> loosely set-up, rather than rigid, i.e. meant for runtime.

I still disagree to the extent that dependencies should ideally be
satisified at install time. That this won't guarantee everything is
clear, I think.

> The problem with the rigidly enforced dependencies in the RPM (or
> Gentoo ebuilds for that matter) example is that you go down a path
> that gets really hard really soon.

Preferences aside, I've always had larger difficulties with RPM
and Gentoo's ebuilds than e.g. Debian's apt or FreeBSD's ports.
Clearly it's possible to do better than those examples you mention
(might as well reach for higher goals, huh?)

> Let me summarize what I believe was discussed:
> Ideally (i.e. long term):
> - Suggestions at install time from any Market
> - Runtime popups to install a dependency, handled by a system function
> - It's not one or the other, but both
> - App dependency information entered in the manifest via uses-intents
> tags or similar
> - There might be a distinction between strictly needed apps and nice-
> to-haves

Strictly needed apps can be entered via uses-intents, nice-to-haves
can be entirely resolved at run-time. That's how I'd handle the
distinction at any rate.

> - Distinction between form of dependencies: free or paid, which
> permissions, ...

I've seen this mentioned, but I'm not sure why it should be an
issue. If a suggestion for installing a dependency is made, the user
will have to choose from the available options, and can pick whichever
they want, free or paid.
For each dependency, you'll need to ask the user whether they want
to install it anyway, if only because they may not want to grant the
required permissions.
I don't think going down the route of trying to automatically
resolve all of that is a good idea. It'd be nice from the Just Works
(TM) perspective, but it'd restrict the user's ability to choose.

Also, I don't think Android apps can be treated quite the same as
dependencies between packages in your average Linux distribution; in
general an <insert your favourite distro package format> file tends
to hold a smaller chunk of functionality.
As a result I'd be surprised if the number dependencies (and their
dependencies) of your average Android app would be as high as that of
your average RPM (or whatever).

If that were the case, then it'd be even more important to resolve
dependencies at install-time IMO.

> - Distinction between location of dependencies: in the Market or not

I don't think that's an issue. Let me get back to that in a moment.

> - Distinction between state of intents: draft, concept, under change
> control, deprecated (for now, proposal of new intents should be as
> lightweight as it is currently, just adding it yourself, but on the
> long term we might want to evolve into some committee approval system
> to avoid bad quality intents and duplicates)

That's more the standards process; I don't think that needs to be
dragged into dependency management.

> - More than one dependency might be needed to satisfy handling an
> intent, or to offer choice while suggesting
> - Dependency tree, with even double entries as per the above
> - All this without much changing screens and processes, minimally
> bothering the user, and without performance bottlenecks
> - Deal with uninstalls and getting new suggestions
>
>
> Practical (doable):
> - We leave the Market and install time based stuff alone for now
> - We take the one Android Market interface as model and expect other
> markets to behave accordingly (narrow done to THE Market)
> - Not a system/Market function but a service, library or service
> +library -> IntentsManager
> - The Intents Registry boils down to the (new) OpenIntents database
> for now
> - IntentsManager searches the Intents Registry for specific matches
> and does a wide search on market descriptions a la intents:filemanager
> (Beware of the 325 char limit! Also I have already seen this turn out
> badly with the T-Mobile Recommended apps as any app could just be
> added to that exclusive selection with the right string in the
> description.)
> - The IntentsManager, when implemented as a Service, might form a
> bootstrapping dependency itself on all apps, hampering the
> introduction of this system

Reading through your list of practical/doable points, maybe I've
understood IntentManager differently from you, or the rest of the
list.

As I understand the service, it acts a bit like the new contact
providers in 1.6+: that is, any store app can feed its data into
IntentManager, and IntentManager "just" provides a collective
interface for that information.

Similarly, any store app could use IntentManager to verify whether
Intent-dependencies are satisfied. The mini-lib to make checking for
dependencies at run-time easier would do the same.

More specifically, I did *not* think that IntentManager would
actually download a list of Intents from OpenIntents.org (I do not see
a reason for that as per the above), nor would apps register with
OpenIntents.org what Intents they provide (which would be required for
resolving dependencies).
That is not to say that OpenIntents.org cannot (theoretically, I
can't speak for the people running it) host a registry for the Intents
apps provide. I'd expect that to be part of each store app's backend.

That'd also offer a nice migration path: if you want to make use of
relatively good dependency management, use that mini-lib. For better
dependency management, a store app can itself use IntentManager.

Mini-lib's use of IntentManager:
0. App wants to use an Intent.
1. Query if Intent is satisifed by currently installed app (needs
IntentManager to keep a local registry of apps and the Intents
they provide) (ACTION_ACTIVITY_NOT_FOUND)
2. If not, ask IntentManager for suggestions that would satisfy the
dependency. Each suggestion comes from a store app, with a link
or other information required to install the app.
3. Provide some standard UI for displaying/selecting to install
suggestions.
4. Repeat until user aborts or Intent is satisfied. In the latter
case, fire the Intent.

Market's use of IntentManager:
- Add suggestions for apps to IntentManager.
- Notify IntentManager that an app has been installed
(ACTION_PACKAGE_ADDED)
- Notify IntentManager that an app has been uninstalled
(ACTION_PACKAGE_REMOVED)
- Same as mini-lib's during installation of an app, but for all
Intents the app lists in uses-intent, as opposed to only the
Intent the app wants to use.

Did I really understand that so differently?

> By the way, I'd like to add that a small part of the Market API
> (regarding pname and pub) is in the documentation:
> http://developer.android.com/guide/publishing/publishing.html

Awesome! I hadn't really seen that documented before.

Jens

[Jens Finkhäuser]

> As I understand the service, it acts a bit like the new contact
> providers in 1.6+: that is, any store app can feed its data into
> IntentManager, and IntentManager "just" provides a collective
> interface for that information.

That was a late post yesterday. Like providing search suggestions to
the quick search box in 1.6+, or contacts providers in 2.0+ I meant.

--
1.21 Jiggabytes of memory should be enough for anybody.

[pjv]

I'll split up my answer, to not confuse the long term goals with the
current proposal for a first implementation.

As to the long term:

Free or paid is of interest because only paid apps might be available
that solve a certain dependency. If the user does not want to pay or
is in a market without paid apps, this would leave a gap in his
dependency tree.

Same goes for dependencies not on the Market. What if something highly
popular is created, that is only available as an apk straight of the
web, and app developers decide to add this functionality in anyway via
a dependency. If you build a system where a market needs to interact
with an IntentsManager, then how will you deal with this gap in your
dependencies?

If the dependency management system does not offer any guarantees that
it closes these gaps and makes sure everything just works, then of
course I have to admit the above does not matter, but here also
applies reaching for the highest goal.

I agree that Android apps will have less dependencies. On the other
hand the markets (or repositories) are far more complex, with
geographical, price, network, and other limitations. There is no
single market, and sideways exist to install apps. Also the fortune
for linux distros has been that they package themselves (and this way
have been able to minimize and cover up some of the shortcomings of
their dependency/install systems), whereas here we would give
developers tools to interact with the dependency management system,
but without having any correctional control on how they use it
ourselves. So if things go broke we can't fix them ourselves. What I
am trying to say is it would seem that this system needs to be more
watertight, for more parties, to ever work.

[Jens Finkhäuser]

> Free or paid is of interest because only paid apps might be available
> that solve a certain dependency. If the user does not want to pay or
> is in a market without paid apps, this would leave a gap in his
> dependency tree.

True, but the user would still have that choice. By considering free
vs. paid, you'd make things a bit more comfortable for them because
they can refuse to install any of the dependencies if one of them
somewhere down the line is paid. Fair enough, that'd be nice.

> Same goes for dependencies not on the Market. What if something highly
> popular is created, that is only available as an apk straight of the
> web, and app developers decide to add this functionality in anyway via
> a dependency. If you build a system where a market needs to interact
> with an IntentsManager, then how will you deal with this gap in your
> dependencies?

Interoperate or die?

The dependency does not have to be on *the* market, it has to be on
*a* market that uses IntentManager, and your problem is solved.

Saying that, IntentManager in the form I've imagined it would know
that an Intent can be served if you install an .apk, regardless of the
source. It's finding not-yet-installed dependencies that would serve
the Intent and are not on any store app supporting IntentManager that's
an issue.
But nothing would stop anyone - OI or someone else - to provide an
online registry for such apps, and feed that data into IntentManager.

You need to either assume that store apps interact with
IntentManager, or you need to assume that every dev will manually
submit what Intents their apps serve to a central registry in addition
to submitting the app to a market or publishing it as a direct
download.
Either way, you need to make assumptions. My thinking here is that
if IntentManager serves the needs of any store app, then the right
conditions are met for store app developers to consider using
IntentManager.
If we don't go that way, you'll have to rope in all developers of
all apps to submit their Intent information properly.
I'd take my chances with the former.

It's either that, or I completely misunderstand you?

> If the dependency management system does not offer any guarantees that
> it closes these gaps and makes sure everything just works, then of
> course I have to admit the above does not matter, but here also
> applies reaching for the highest goal.

See above.

> I agree that Android apps will have less dependencies. On the other
> hand the markets (or repositories) are far more complex, with
> geographical, price, network, and other limitations. There is no
> single market, and sideways exist to install apps. Also the fortune
> for linux distros has been that they package themselves (and this way
> have been able to minimize and cover up some of the shortcomings of
> their dependency/install systems), whereas here we would give
> developers tools to interact with the dependency management system,
> but without having any correctional control on how they use it
> ourselves. So if things go broke we can't fix them ourselves. What I
> am trying to say is it would seem that this system needs to be more
> watertight, for more parties, to ever work.

In an ideal world, I'd like more guarantess that things will just
work, regardless of where you get your apps from. I'm with you on
that. I just don't see a clear path towards making that happen.

Jens

[pjv]

As to the doable part:

Your idea of a passive IntentManager to which the Market need to feed
in data is an interesting one. But I would not consider this for the
current workable proposal because we can't change the Market app.
That's why I mentioned an active IntentManager that gathers data
itself by searching the Market for intent:filemanager strings via the
public API.

The OpenIntents database comes into play at least to jumpstart the
system when early adoption is still low. Remember that developers need
to add intent:filemanager tags to their app descriptions themselves.
The database can hardwire and overrule a few dependencies already so
we can start off with a working system.

Please also take in mind that the ACTION_ACTIVITY_NOT_FOUND intent, as
far as I understand, does not exist and was not approved (yet).

[pjv]

On Nov 17, 2:51 pm, Jens Finkhäuser <unwe...@gmail.com> wrote:

>   Saying that, IntentManager in the form I've imagined it would know
> that an Intent can be served if you install an .apk, regardless of the
> source.

That seems like a useful property of such a system we need to keep in
mind.

>   But nothing would stop anyone - OI or someone else - to provide an
> online registry for such apps, and feed that data into IntentManager.

Actually, legalities might prohibit anybody other than the app
developers from doing that.

>
>   You need to either assume that store apps interact with
> IntentManager, or you need to assume that every dev will manually
> submit what Intents their apps serve to a central registry in addition
> to submitting the app to a market or publishing it as a direct
> download.
>   Either way, you need to make assumptions. My thinking here is that
> if IntentManager serves the needs of any store app, then the right
> conditions are met for store app developers to consider using
> IntentManager.
>   If we don't go that way, you'll have to rope in all developers of
> all apps to submit their Intent information properly.
>   I'd take my chances with the former.
>
>   It's either that, or I completely misunderstand you?

We seem to both agree that a perfect system is not achievable, even in
the long run. And I have to admit that there are still advantages to a
system that goes further than just the current proposal. So we want to
evolve into a system where there is tight integration between the
markets and the IntentManager, and where inherent knowledge already
present is used, for example via the <uses-intents> tags, instead of
relying on developers to add searchtags a la intent:filemanager
manually.

Maybe you misunderstood some of my remarks/objections as that I would
not consider an install time based system. I do, on the long term, see
use for a system that presents the user with suggestions on what
dependencies to install with the app he is currently installing. But
as these are suggestions, the runtime based part is still also
required. I don't however see a working system that always forces
dependencies to be installed, and by doing so also discards the late
binding principal that Justin mentioned.

[Jens Finkhäuser]

> >   But nothing would stop anyone - OI or someone else - to provide an

> > online registry for such apps, and feed that data into IntentManager.
> Actually, legalities might prohibit anybody other than the app
> developers from doing that.

Running the registry versus feeding the registry. I'm sure the
legalities of running the registry are simple enough, as long as app
developers feed it themselves.

> Maybe you misunderstood some of my remarks/objections as that I would
> not consider an install time based system. I do, on the long term, see
> use for a system that presents the user with suggestions on what
> dependencies to install with the app he is currently installing. But
> as these are suggestions, the runtime based part is still also
> required.

Absolutely.

> I don't however see a working system that always forces
> dependencies to be installed, and by doing so also discards the late
> binding principal that Justin mentioned.

I don't think I ever spoke of "forcing" installs. Maybe that's where
our perceptions differ. I'm all for "offering" installs that satsify
the requirements of an app you've just selected, "forcing" hasn't been
on my mind.
That also means that the late binding principle isn't discarded.

Contrary to you I see such a working system to be easier to achieve
than with a system such as RPM/deb/port(age)/etc. where dependencies are
forced, simply because the case were a dependency graph is broken is
expected as a valid state, not an error state.
That's why you'd query IntentManager whether the Intent you want to
use in your app can currently be served by the system. If it cannot be
served, you'll have all the information available to make suggestions to
the user how they can fix it.

I'd love to write up a more detailed proposal, but right now I don't
have the time. In 1-2 weeks, probably.

Jens

[Justin]

I apologize if I missed anything in the above, it was a lot of catch
up on.

I think some install-time binding makes sense. I think there's the
concept of "needs dependency" and "may need dependency", but I would
hope that developers are wise and error on the side of "may need".

There's been a lot of discussion about how this idea relates to
"traditional" package managers in things like Linux system. One thing
I'd like to point out is the difference in the environment that those
systems were conceived in. Those systems were built with the
"sometimes connected" device in mind. This was a machine that may or
may not have access to a network to get additional data as needed, so
full install time dependency resolution made sense because the user
was more likely to be connected to a data network at that time than at
run time. Android is built with the idea of constant or near-constant
connectivity, so "may need" dependency resolution is best done at
execution time.

Jens gets right to the point about where an IntentManager would get
its info. I think it should be *not* from any one market, but from
something else where markets, stores, and independent publishers can
feed it information. The beauty of this approach is also that you
don't need agreement from anyone to get started. Finally the goals of
a market and an Intent resolution system are not always aligned and so
they should be separate to allow them the necessary degrees of
freedom. Alternately, the IntentManager itself could just punt
entirely on the data source and provide a way for data sources
providers to plug into it, ala the contacts system in Android 2.0.
This way mutually suspicious and independent parties can provide their
data without having to mix it together. So, just require a data
provider to accept ContentProvider-type queries of a certain format
and although different ContentProviders to register with the manager.

Regards,
Justin

[Jens Finkhaeuser]

Just to let everybody know, I haven't forgotten about this. I expected
to have had time by now to follow up with something more detailled,
but that'll have to wait at least another week. Sorry! Paid work
always interferes with the fun stuff, it seems :)

Jens

[Carl-Gustaf Harroch]

I have been very busy as well with payed work. xmass is the time I ll
be able to contribute :)

I discussed the idea of uses-intent with manufacturers at droidcon -
London and the idea was very well received. Is there any place we
could draft the protocol/xml definition? I like the idea of
uses-intent - can be a mandatory or not - within the manifest as the
manifest is an expose of what your application is doing. We also have
andappstore who is willing to implement an intent dependency
management on his market.

In order to get this right, we could look into OSGi. From the several
talks on OSGi at droidcon - Berlin, it seems that most of the need for
OSGi on android is based on 2 missing functionalities within android:
1. dependency management
2. version control
(3). centralized deployment - more on the enterprise side

Hotspot deployment could be seen as feasible with android - however it
differs from the OSGi mindset. If the above 3 points are solved
natively on Android, it will be a very good contestant for enterprise
mobile application. Anybody wants to make a million or 2 :)?

I believe there are 2 concerns here. One is the ability for a
developer to declare the needed intents within his application, the
other is to ensure the dependency is managed correctly. At first, we
could just create a lib as POC which scans the extra metadata of the
manifest for uses-intent. Secondly define the protocol for markets to
implement. In such fashion, we ensure we always roll back to manual
installation if the market does not support the dependency management.

To be more precise:

1. Create a super class which extends Application
2. onCreate scans the metadata within its own manifest
a. a mandatory intent is found -> dialog box redirecting to the market
requesting the user to download the specified app (need to manually
map intent with an actual application at this stage)
b. an optional intent is found -> could or could not display the above dialog?
3. during runtime if an optional call to an intent is intercepted,
show the dialog with (download app? yes/no)

./c

2009/12/7 Jens Finkhaeuser <unw...@gmail.com>:

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

[Jens Finkhaeuser]

It's late, so I'll wait with details. But I've found time to wrap my
head around this issue again, and read some Android code to fill in a
few blanks on this issue.

First of all...

> To be more precise:
>
> 1. Create a super class which extends Application
> 2. onCreate scans the metadata within its own manifest
> a. a mandatory intent is found -> dialog box redirecting to the market
> requesting the user to download the specified app (need to manually
> map intent with an actual application at this stage)
> b. an optional intent is found -> could or could not display the above dialog?
> 3. during runtime if an optional call to an intent is intercepted,
> show the dialog with (download app? yes/no)

... this is pretty much exactly what I think we should do. I'm also of
the opinion that we can very, very likely skip 2b. If you're
interested in resolving the dependency early on, why not make it a
mandatory Intent? If you're not interested in that, why resolve it
until it's actually used? I guess I don't see the use-case for that.

Apart from that, I've made plenty of notes as to how I'd implement the
whole thing. The good news is that I think we can forego patching
Android, and still get all the features we've discussed.

If I don't get around to posting details tomorrow, I should find time
on Tuesday.

It's been a week since I said I'd need another week, so I wanted to
reply with *something* ;)

> Is there any place we could draft the protocol/xml definition?

I'd do that here :)

Jens

[Jens Finkhaeuser]

Alright, I made it. I should warn that this is a lengthy email - I
might as well have written code instead of this, it would've taken
more or less the same amount of time ;) But I suppose open discussion
is important at this point.

First of all, the library. You mention an Application subclass - I
think that should definitely be there as a convenience thing, but
thinking about this again, I'd to split the functionality you
discussed as part of that class's onCreate() implementation into a
few public functions. Who knows, people may have good reasons for not
wanting to subclass from our Application class. But the principle
remains, that's just a detail.

I've looked into adding a uses-intent tag, and into how we could use
the existing meta-data tag to achieve our end, and ended up preferring
something very similar to what the SearchManager in Android 1.6+ does.
That is, within the <application> scope in an app's
AndroidManifest.xml, something like this should be included:

<meta-data android:name="openintents.intents.mandatory"
android:resource="@xml/foo" />

(I have no emotional attachment whatsoever to the name I picked above.
It just needs to be well-defined. Please make suggestions on this and
other names I'll use.)

The file res/xml/foo.xml then needs to contain something that defines
all the intents the package requires. Just listing actions won't cut
it, I'm afraid - we'll need to define the intents pretty much in the
same detail they're used in code, or else the dependency resolution
won't work well enough.

We've already got most of the format for defining intents the
<intent-filter> tags used for Activities, etc. The main differences
to <intent-filter> would be:
a) Intents can be explicit, i.e. you'd need an optional <component>
bit, and
b) you *may* want to specify whether you're targetting an Activity,
a Receiver, or some other type of component.

As a result, I think the xml file should look something along the
lines of this here:
<?xml version="1.0" encoding="utf-8"?>
<mandatory-intents>
<!-- Implicit Intent -->
<intent component-type="activity">
<action android:name="android.intent.action.BAZ"/>
<data android:scheme="quux" />
</intent>
<!-- Explicit Intent -->
<intent component-type="receiver">
<component android:name="foo.bar.BazReceiver" />
</intent>
</mandatory-intents>

The component-type attribute is something of a convenience feature.
It'll just give a hint as to whether PackageManager's
queryIntentActivities() or queryBroadcastReceivers(), etc. should be
used to try and resolve whether the Intent can be served.

As a first stab at defining how to specify mandatory Intents, that
should do the trick, I think.

Of course, if an Intent cannot be served, then we'd like to prompt
the user to install packages that would. For that, we won't be able
to avoid the IntentManager that's been discussed before.

To the library (and to the rest of the system), I think IntentManager
should act as a ContentProvider that primarily defines one content URI
that returns package information in return for an Intent specification.

The unpleasant part here is that in order to specify an Intent
completely, we'll need a fair amount of query parameters for that URI,
with most of them optional - after all, we'll need to be able to
specify all the elements that the <intent> tag discussed above can
contain.

For e.g. '<action android:name="android.intent.action.BAZ"/>' that's
not too bad, it translates nicely enough to e.g.
'?action=android.intent.action.BAZ'. All of <data>'s possible
attributes will need to be listed separately, as e.g. 'data-scheme',
etc. All workable, but it doesn't make for very pretty URIs. I'm not
too upset about that, given that this isn't something user-visible.

The Cursor returned for that URI should define a number of fields
that make it possible to display a Market-app-agnostic selecton
dialog, similar to what ResolverActivity shows. Looking towards
Android Market's lists of apps as inspiration, the required fields
would be:
* Package name (TEXT NOT NULL, e.g. com.example.app)
* Package display name (TEXT NOT NULL, e.g. ExampleApp)
* Package vendor (TEXT NOT NULL, e.g. OpenIntents)
* Package price (INTEGER, can be NULL for free apps, in cents)
* Currency (TEXT, can be NULL if price is NULL)
* Icon URI (TEXT, can be a content: URI or an http: URI. Might allow
this to be NULL, I don't really mind).
* Market package name (TEXT NOT NULL, e.g. com.mymarket.app - I'll
get back to that later)
* Market display name (TEXT NOT NULL, displayed as the "source" of
the package - if nothing else, this'll give minimal branding/
credits to the vendors providing Market-like apps)

With that information, it'd be possible to create a selection dialog
that shows pretty much the same information as any of the package
lists you'd currently find in Android Market. The one thing that's
missing would be a rating field - I'm not sure if that's maybe a bit
too specific to Android Market, but wouldn't mind including it.

Given the package name of the app offered for installation, and the
package name of the Market-like app that's offering, we'll have just
enough information to instruct the Market-like app to install a
package.

Well, but there's more required. IntentManager also needs to retrieve
all this information from somewhere. So here's how I think those
things should be handled, and again I'm looking towards SearchManager
for inspiration.

What SearchManager (indirectly) does is scan installed packages for
specific metadata. More precisely, it constructs an Intent (in this
case ACTION_SEARCH), resolves packages that respond to it, and then
scans those packages for meta-data named "android.app.searchable".
That meta-data again points to an xml file with some definition of
how the package is searchable.

Using the same basic mechanism, we can search for packages that
respond to ACTION_PACKAGE_INSTALL - or possibly an action we define
ourselves. (Note: ACTION_PACKAGE_INSTALL is documented as a
"protected" action, so probably won't be the best choice - it's
likely better that we define our own.)

We can find the Activity that responds to it, and launch it with the
package name of the package to be installed when an entry in the
selection list is clicked.

But we should also look for meta-data. At the very least, this should
contain the content URI of a ContentProvider in the same package,
that can be queried for package information, so e.g.
<?xml version="1.0" encoding="utf-8"?>
<intent-resolver
content-uri="content://foo/bar/baz"
/>

Yes, with only one piece of data, that meta-data could be defined
inline in AndroidManifest.xml. By keeping the meta-data in a resource
file, we'll be able to extend it more easily later on, though.

Now that ContentProvider should in the first instance respond to the
same URI path as IntentManager itself, returning much the same data.
The only thing we don't strictly speaking need is the package name of
the Market-style app, because we could deduce that - but it'll be
simpler to require it, and simple to provide it.

Armed with that information, IntentManager can provide as good a
choice of options for satisfying a dependency as I think we can get.

Now there are a few things in all this that are slightly less cleanly
solved as I think would be good:

1. Currently, Android Market does not provide a ContentProvider
that we can query for packages. It does not respond to whatever
ACTION_PACKAGE_INSTALL-like action we define.

My personal view on this is that what we're building here *should*
be a standard that Market-like apps implement, if at all possible.
So just catering to what Android Market already does seems wrong
to me. Still, it'd be good if we could use it somehow.

I think with a little tweak to the fields the ContentProviders are
supposed to return we can easily create and ship a "fallback"
provider that will, if Android Market is installed, always reply
that it knows a package. When selecting this field in the
selection dialog, an external search should be launched.

Obviously for such an entry, the package name, vendor, price and
currency can't be returned. We could easily e.g. define that a
negative price means the data set refers to an external search.
Or we add a new field for that.

The display name and icon are still useful; those two bits of
info won't refer to a specific package, but rather describe the
external search being launched. Add an optional field with a
search URI, and we can launch a search in Market.

That's where the suggestion of stating what Intents a package
responds to in the package description comes in - I don't think
that that's a good solution in the longer term, but for hooking
up an external search in Android Market, it might be a good
starting point.

2. I've conveniently ignored that it seems pretty hard to find the
IntentFilters for a given Activity name. Yes, PackageManager
defines a GET_INTENT_FILTERS flag, but I can't seem to find any
IntentFilter-related data member in ActivityInfo or one of it's
ancestors. Maybe I'm just blind.

Until/unless Android opens up that information, I think the best
a Market-like app can do is copy & extend the private
PackageParser from AOSP and parse AndroidManifest.xml from each
package in it's repository.
That's not hard - all the code for parsing IntentFilters is there.
They're just not added to the ActivityInfo.

3. I've somewhat skipped over whether the ResolverActivity-like
dialog should be part of the library, or part of IntentManager.
I'm thinking it should be the latter, but I'm not too concerned
about that detail.

4. I've skipped discussing what the library should do if
IntentManager is not installed. IMO there's only two things it
can do:
a) If Android Market is installed, prompt the user to download
IntentManager from there, with a link to the appropriate
search URL.
b) If Android Market is not installed, provide a link to a
website where IntentManager can be downloaded & installed
from.

Unfortunately, if IntentManager does not yet exist on the system,
we're in a classic bootstrapping situation where whatever options
we offer won't be as nice as the ones available after we're
already bootstrapped.
I think betting on Android Market, with a fallback to a website
is pretty much the best that can be done.

5. Aside from our ACTION_PACKAGE_INSTALL-clone, we might also
optionally support an ACTION_PACKAGE_VIEW action. I'm thinking
many users would like to see whatever details the Market-like
app can show on a package before installing it.

6. I think it'll be perfectly possible to add a query parameter to
the IntentManager's URL that specifies a package name. In that
way, we could support resolving dependencies on specific packages.

It'd also require some extension to the meta-data specifying
dependencies, but that wouldn't be too big a change.

7. Dependency resolution as I've outlined it is fairly primitive.
Let's pick an example to illustrate that:
* Package A requred Intent I1 and Intent I2
* Package B responds to Intent I1
* Package C responds to Intent I2
* Package D responds to Intents I1 and I2

Clearly, with all other things being equal, installing Package D
should be preferrable, but the current protocol does not permit
specifying more than one Intent via the IntentManager's provided
URI.

That's mostly a problem with specifying Intents via query
parameters. I think other schemes than the one proposed above
would allow for specifying more than one Intent, but things'll
get uglier quickly. One option would be to e.g. define each
Intent as a query string:

I1: action=foo.bar&data-scheme=http
I2: action=baz.quux&category=blargh

Then, urlencode those query strings and append them to the
IntentManager's URI (broken across lines):

content://intent-manager/resolve
?intent1=action%3Dfoo.bar%26data-scheme%3Dhttp
&intent2=action%3Dbaz.quux%26category%3Dblargh

In order to determine what to install, the Cursor returned by
IntentManager must at minimum also define which intents each
package will respond to, e.g. by returning them query string
encoded like above.

But what is the caller meant to do with that information? Should
we try and compute all possible combinations of installations
that would satisfy all requirements, and order them by the number
of packages installed? Is that worth the hassle?

8. The point of whether a user should be offered free and paid apps
as equal can easily be solved as a setting to IntentManager, or
as a toggle in the ResolverActivity-like dialog.

Similarly, it would probably be good to provide settings for
IntentManager that list all available sources for packages, and
let the user select which they want to use.


As you can see, with that much text, I might as well have started
implementing already - but like I said in the beginning, I think
discussing stuff is necessary if we want to come up with something
that more than one Market-like app ends up interacting with.

Speaking of implementing stuff, I think I'll just go ahead with that
in the next few days anyway - the main reason is that I'll be tied up
with other work from January on again, so if I don't get some stuff
done now, I won't for a while. I'll post details on the code
repository and stuff when I get to that point, this email has been
long enough already.

If you made it to this point, you're entitled to a cookie.

Jens

[Peli]

Hi Jens,

Thank is one huge impressive email! Instead of trying to comment on
all of the issues, I will first pick out a few things that caught my
eye:

1) meta-data -> xml is a very nice solution that I like. I wonder:
should we keep in the xml file the xml structure of the Manifest file?
Specifically, instead of introducing new tags and elements, (like
intent, component, and component-type), couldn't we just keep
<activity...> and <receiver...> tags surrounding <intent-filter>s
(instead of <intent>) - (where all unneeded elements are simply
ignored)? The advantage would be that I could simply "copy and paste"
the intent specifications that my app needs from another application's
Manifest file into my mandatory-intents.xml file.

2) This is a more fundamental change suggestion: Instead of having
each application separately check for mandatory intents, the
applications could take a more passive role, and let the IntentManager
have a more active role:
* my application only contains the meta-tag and the mandatory-
intents.xml file. No additional code is necessary in principle.
* the IntentManager, upon having received PACKAGE_INSTALLED, looks for
the new packages Manifest file, finds the meta-tag of the newly
installed application, reads out the mandatory-intents.xml file and
prompts the user for additional applications to be installed.

Advantages:
2a) less code in each application -> less redundant code installed.
2b) it would also solve the issue how to pass parameters to
IntentManager through query parameters - they don't need to be passed,
they are read out from the xml file directly.
2c) as such, it would solve your point 7, as all resolution is handled
by the IntentManager, which can be coded as fancy as we want.

3) Intent resolution on-the-fly: This has not been really discussed,
but the simplest way (from a developer's point of view) would be to
catch an ActivityNotFoundException (if an intent could not get
resolved), pack the missing intent into another intent and launch
IntentManager. From this point of view, IntentManager acts like an
activity, more than like a ContentProvider. By forwarding the intent
that previously did not work, the IntentManager could actually
directly start the intent right after package installation and let the
user continue where they were just interrupted. If additional
specification for the intent is required, this could again be put into
an optional-intent.xml file that is read out directly by the
IntentManager. (or put mandatory-intents.xml and optional-intents.xml
into a single intents.xml file with <mandatory..>[list of intents]</
mandatory><optional ..>[list of intents]</optional> tags)

4) Where does IntentManager get the links to the downloadable
installation files from? In your point 1 you favor a solution where
this information is read from Market. While in the long-term it would
be nice, to get something working now, I guess we have to do it
differently. Here are some suggestions with increasing level of
sophistication:
4a) hard-code an xml file into IntentManager that contains all known
applications and the intents they resolve. (is probably the quickest
to get things started). (*)
4b) Hard-code an URL from which the xml file from 4a is downloaded.
4c) POST/GET a specific intent and receive an xml file that has been
generated on a server with applications that respond to the desired
intent.
4d) Download a list of servers that can be polled for intent
resolution and let user add additional servers.
Note that this solution does not involve Market so far, but it would
not be difficult to retrieve the same information from Market instead
of from a server.

One server for 4c / 4d could be the OpenIntents intent registry, but
alternatives (e.g. generated from Markets and app stores) are welcome
as well.

(*) technically, the xml file could be more or less just a
concatenation of Manifest files ("copy&paste"):
<download name="Obscura" >
<site store="Market" url="market://..." price="7.99 USD" />
<site store="AndAppStore" url="http://..." price="7.99 USD" />
<site store="SlideMe" url="http://..." price="8.49 USD" />
<manifest ...>
...[copy&paste package name, available intent filters, ... from
Manifest.xml]
</manifest>
</download>
<download name="OI Notepad" >
<site store="Market" url="market://..." price="free" />
<site store="AndAppStore" url="http://..." />
<site store="SlideMe" url="http://..." />
<site store="OpenIntents.org" url="http://..." />
<manifest...>
...[copy&paste package name, available intent filters, ... from
Manifest.xml]
</manifest>
</download>
, where additional surrounding tags could specify download location in
Market and on various other download sites.

Peli

[Peli]

> Speaking of implementing stuff, I think I'll just go ahead with that
> in the next few days anyway - the main reason is that I'll be tied up
> with other work from January on again, so if I don't get some stuff
> done now, I won't for a while. I'll post details on the code
> repository and stuff when I get to that point, this email has been
> long enough already.

It would be great if we could have the IntentManager hosted here at
OpenIntents. Anyway, I think there is in principle room for several
independent intent managers, so why not have one "OI Intent
Manager" (package org.openintents.intentmanager), at least until
Android has their own android.app.IntentManager.

Peli

[Jens Finkhäuser]

Hi!

I sent this under an unsubscribed address, so resending it. Might turn
up twice - sorry if that happens.

On Tue, Dec 15, 2009 at 07:12:53AM -0800, Peli wrote:
> 1) meta-data -> xml is a very nice solution that I like. I wonder:
> should we keep in the xml file the xml structure of the Manifest file?
> Specifically, instead of introducing new tags and elements, (like
> intent, component, and component-type), couldn't we just keep
> <activity...> and <receiver...> tags surrounding <intent-filter>s
> (instead of <intent>) - (where all unneeded elements are simply
> ignored)? The advantage would be that I could simply "copy and paste"
> the intent specifications that my app needs from another application's
> Manifest file into my mandatory-intents.xml file.

Well, I think that naming what's essentially an Intent specification
<intent-filter> is semantically wrong.

> 2) This is a more fundamental change suggestion: Instead of having
> each application separately check for mandatory intents, the
> applications could take a more passive role, and let the IntentManager
> have a more active role:
> * my application only contains the meta-tag and the mandatory-
> intents.xml file. No additional code is necessary in principle.
> * the IntentManager, upon having received PACKAGE_INSTALLED, looks for
> the new packages Manifest file, finds the meta-tag of the newly
> installed application, reads out the mandatory-intents.xml file and
> prompts the user for additional applications to be installed.

The difference is that by offering a small library with an
Application subclass that does this checking in onCreate(), we're
moving more towards the late binding that many people seem to favour:
dependencies are resolved when the app is run.

IntentManager can *additionally* listen for PACKAGE_INSTALLED, fwiw.
One can make that a setting as well, whether it should try and
enforce install-time dependencies or not.

> Advantages:
> 2a) less code in each application -> less redundant code installed.

I agree that the library code should be minimal. But that can be
solved by making it a stub that calls functions on a service, and make
that service part of IntentManager. That is, the only thing the
library needs to do itself is check whether IntentManager is

installed.

> 2b) it would also solve the issue how to pass parameters to
> IntentManager through query parameters - they don't need to be passed,
> they are read out from the xml file directly.

True, but passing them on to the data sources that feed
IntentManager remains the same. It's not a big problem anyway - just
kind of ugly.
Note that it's entirely possible to make the primary interface to
IntentManager a service interface rather than a ContentProvider. The
reason I don't like that so much is that AFAIK there's nothing better
for populating a list as results come in as a Cursor.
By making IntentManager's interface a ContentProvider, it can
support online searches as well as locally installed databases for
it's sources.

> 3) Intent resolution on-the-fly: This has not been really discussed,
> but the simplest way (from a developer's point of view) would be to
> catch an ActivityNotFoundException (if an intent could not get
> resolved), pack the missing intent into another intent and launch
> IntentManager.

Whether you launch the ResolverActivity-like dialog at app startup
or on-the-fly does not matter all that much, as long as it can be
launched easily. And yes, catching ActivityNotFoundException would be
the simplest way for detecting that it's necessary to do so.
I'd favour wrappers for startActivity*() in the Application subclass
that do that.

> 4) Where does IntentManager get the links to the downloadable
> installation files from?

It doesn't get links the way I think about it. The way I think about
it, it creates explicit Intents for those Market-like apps to handle
that feed data to IntentManager in the first place. That's the
ACTION_PACKAGE_INSTALL-like action I've been talking about.

> In your point 1 you favor a solution where this information is read
> from Market. While in the long-term it would be nice, to get something
> working now, I guess we have to do it differently.

No, that's just my short-term kludge until Market and other
Market-like apps support the above action.

Hope that clarifies a few points,
Jens

[Peli]

Hi Jens,

>   Well, I think that naming what's essentially an Intent specification
> <intent-filter> is semantically wrong.

Call it <needs><activity...><intent-filter...> ... </..></..></..>,
then you demand that your application needs a certain activity with a
certain intent-filter - so this should be semantically correct again,
and be compatible to a standard Manifest.

>   The difference is that by offering a small library with an
> Application subclass that does this checking in onCreate(), we're
> moving more towards the late binding that many people seem to favour:
> dependencies are resolved when the app is run.

Nothing against a small library. Indeed it is useful to have several
ways to envoke an intent check with IntentManager.

Putting a test into onCreate is not particularly good, because it
would require a check at every application launch and would
unnecessarily slow down program start up.

Having it either at installation time (ACTION_PACKAGE_INSTALLED) or
when a startActivity.() failed in catch (ActivityNotFoundException)
{..} imposes no additional overhead during normal program execution.

Of course, there is nothing wrong with offering additionally the
possibility to check every time in onCreate() if IntentManager is
present, and let it check all mandatory intents, but I don't really
think this is necessary in most cases.

>   I agree that the library code should be minimal. But that can be
> solved by making it a stub that calls functions on a service, and make
> that service part of IntentManager. That is, the only thing the
> library needs to do itself is check whether IntentManager is
> installed.

Agreed conceptually. On a technical side, Android services are
comparatively "expensive" for a developer, requiring AIDL interfaces
etc. Intents are much more lightweight (though slower), so if the
communication can be done through intents I'd prefer those.

In any case, each intent should be wrapped in the following way:
try {
[original intent]
catch (ActivityNotFoundException e) {
try {
[ask IntentManager for original intent]
catch (ActivityNotFoundException e) {
if ([Market installed]) {
[dialog to download IntentManager from Market]
} else {
[dialog to download IntentManager from alternative sites]
}
}
}

and this whole block can be put into the lightweight library. (e.g.
through startSafeActivity(context, intent))

>   Note that it's entirely possible to make the primary interface to
> IntentManager a service interface rather than a ContentProvider. The
> reason I don't like that so much is that AFAIK there's nothing better
> for populating a list as results come in as a Cursor.
>   By making IntentManager's interface a ContentProvider, it can
> support online searches as well as locally installed databases for
> it's sources.

You seem to assume that somehow results have to be passed back to the
original application. I think, it could care less: The application
never needs to see a selection of applications. The IntentManager will
install the apps that the user selects within IntentManager.

There is only need for one-way communication from application to
IntentManager, and for this purpose, a simple intent should be
sufficient.

Whether internally within IntentManager you maintain a content
provider, or store your internal data in any other way is irrelevant
for the interface between an application and the IntentManager.

The simpler interface will make it also easier to maintain in the
future (nobody wants to maintain various content provider versions, if
clients may use all versions).

>   Whether you launch the ResolverActivity-like dialog at app startup
> or on-the-fly does not matter all that much, as long as it can be
> launched easily. And yes, catching ActivityNotFoundException would be
> the simplest way for detecting that it's necessary to do so.
>   I'd favour wrappers for startActivity*() in the Application subclass
> that do that.

A startActivity() would be put in a Context / Activity subclass, but I
don't think it is even necessary to subclass anything or override
startActivity().

Just call a static function within the library from the catch (...)
block or instead of startActivity(). (actually you noted this in your
previous reply... I agree with you that it is not necessary to
subclass Application - this would just introduce additional
complications)

>   No, that's just my short-term kludge until Market and other
> Market-like apps support the above action.

Then I have to admit, I did not understand what your short-term idea
is to make things work... somewhere the information has to come from
which applications support which intent. Who would be responsible for
providing that information?

Peli

[Jens Finkhäuser]

On Tue, Dec 15, 2009 at 10:35:48PM -0800, Peli wrote:
> Call it <needs><activity...><intent-filter...> ... </..></..></..>,
> then you demand that your application needs a certain activity with a
> certain intent-filter - so this should be semantically correct again,
> and be compatible to a standard Manifest.

Let me rephrase: I don't think anything is gained by keeping the
<intent-filter> name.

On the contrary: because my proposed <intent>-tag must also allow
for a <component>-child that <intent-filter> does not define, I think
keeping the same name would only be confusing.

> >   The difference is that by offering a small library with an

> > Application subclass that does this checking in onCreate(), we're
> > moving more towards the late binding that many people seem to favour:
> > dependencies are resolved when the app is run.
>
> Nothing against a small library. Indeed it is useful to have several
> ways to envoke an intent check with IntentManager.
>
> Putting a test into onCreate is not particularly good, because it
> would require a check at every application launch and would
> unnecessarily slow down program start up.
>
> Having it either at installation time (ACTION_PACKAGE_INSTALLED) or
> when a startActivity.() failed in catch (ActivityNotFoundException)
> {..} imposes no additional overhead during normal program execution.
>
> Of course, there is nothing wrong with offering additionally the
> possibility to check every time in onCreate() if IntentManager is
> present, and let it check all mandatory intents, but I don't really
> think this is necessary in most cases.

I'm not sure if the overhead is signifcant, but we'll see once stuff
is implemented. But that's not the point.

I was under the impression that many people explicitly did *not*
want install-time checks.

On the other hand, resolving dependencies on ActivityNotFoundException
is pretty much the minimal functionality this library will need in order
to be useful, so I don't think that part is debated.

But if there are no install-time checks, and very late resolution on
ANFE is not desired (because the app *depends* on an Intent being
served), then checks at app startup are the only option left.

But yes, the whole reason I suggested not implementing everything in
an Application class, but rather in separate functions, is to leave
the users of the library some choice in all this.

> >   I agree that the library code should be minimal. But that can be

> > solved by making it a stub that calls functions on a service, and make
> > that service part of IntentManager. That is, the only thing the
> > library needs to do itself is check whether IntentManager is
> > installed.
>
> Agreed conceptually. On a technical side, Android services are
> comparatively "expensive" for a developer, requiring AIDL interfaces
> etc. Intents are much more lightweight (though slower), so if the
> communication can be done through intents I'd prefer those.

If the library is a stub, developers won't have to know about the
service.

> You seem to assume that somehow results have to be passed back to the
> original application. I think, it could care less: The application
> never needs to see a selection of applications. The IntentManager will
> install the apps that the user selects within IntentManager.

No, I don't assume that. I said that's an option. I also said that
I'd favour this being handled in IntentManager - see #3 in my
original lengthy email.

> >   No, that's just my short-term kludge until Market and other

> > Market-like apps support the above action.
>
> Then I have to admit, I did not understand what your short-term idea
> is to make things work... somewhere the information has to come from
> which applications support which intent. Who would be responsible for
> providing that information?

I'm first and foremost concerned about providing infrastructure that
enables Market-like apps to feed that information to IntentManager.
From that point of view, I don't care much where information comes from
in the short term.

The tweak I described introduces a small change to the design that
allows for launching external searches. Those can be used as a
starting point for intent resolution, until Market-like apps properly
use the above infrastructure.

One such search could search Android Market for action strings in
app descriptions, as was proposed a few weeks ago - but that's just an
example. Another might launch a search on a web-based registry.


Overall, I think it'll all become a bit clearer once there is some
code.

Jens

[Peli]

> >   No, that's just my short-term kludge until Market and other
> > Market-like apps support the above action.
>
> Then I have to admit, I did not understand what your short-term idea
> is to make things work...

Ok, re-reading your penultimate post, I understand that you were
refering to searching for strings in Market descriptions. This would
of course work immediately.
(But then there would be no point in investing time in devising /
creating a content provider that will not yet be used by any
application and can therefore not be tested yet - just to populate it
by dummy fields to invoke the "simple search".)

The alternative I was referring to, is to not use the "description
string hack" at all, but to have some external team maintain a
separate list (like the OpenIntents intent registry or simply a
manually maintained xml file). It does not necessarily have to come
from Market itself.

In any case, any such implementation will be an order of magnitude
harder to implement and maintain, so I'd suggest that we aim at the
simple solution / implementation first .. (i.e. focus just on the hack
suggested above).
Actually this would be compatible with other Markets as well, as every
app store implements a "search" feature.
The user could set their favorite Market / app store in IntentManager
settings (or be asked for it the first time).

How do we construct the search string? Maybe just the action string
itself (i.e. "com.company.ACTION_FIRE")? Or a well-defined
abbreviation of it? (e.g. 6 letter/digit hash of the action String?)
(to save space in valuable Market description)

The alternative is to have developers define search strings for their
intents. But those are either long, or also likely to collide (except
if there is a central database to maintain search strings?)
So a simple hash seems to be the easiest?

Peli

(*) 6 letter/digit combination allows for 36^4 = 2.2 billion different
search strings, but due to the Birthday paradox (
http://en.wikipedia.org/wiki/Birthday_paradox ), maybe 2000 intent
strings are safely hashable without collision (at 0.1% likelihood of
collision).

Using the formula here ( http://en.wikipedia.org/wiki/Birthday_paradox#Reverse_problem
), I get the following numbers:
4 character hash: 1.6 mio combinations (instead of 365 days), but 60
action strings (at 0.1%)
5 character hash: 350 action strings
6 character hash: 2000 action strings
7 character hash: 12000 action strings
8 character hash: 75000 action strings.
(for 0.01% safety, take only a third of the numbers given).

so it is a matter of choice how many different action strings we want
to support in this hackish way vs. how much space we want to take up
in Market description, before we have something better :-)

[Jens Finkhäuser]

On Wed, Dec 16, 2009 at 03:13:37AM -0800, Peli wrote:
> (But then there would be no point in investing time in devising /
> creating a content provider that will not yet be used by any
> application and can therefore not be tested yet - just to populate it
> by dummy fields to invoke the "simple search".)

The idea is to provide infrastructure. I see no point in investing
(my) time if what I build is not somewhat future-proof.
I think Carl said that AndAppStore expressed some intrest in
whatever we come up with here. If they do, maybe the Android Market
team will.

> The alternative is to have developers define search strings for their
> intents. But those are either long, or also likely to collide (except
> if there is a central database to maintain search strings?)
> So a simple hash seems to be the easiest?

If we're hashing, we might as well hash a normalized/serialized version
of the full intent definition. That way we can actually expect decent
matches.

Jens

[Peli]

> > Call it <needs><activity...><intent-filter...> ... </..></..></..>,

>   Let me rephrase: I don't think anything is gained by keeping the
> <intent-filter> name.
>
>   On the contrary: because my proposed <intent>-tag must also allow
> for a <component>-child that <intent-filter> does not define, I think
> keeping the same name would only be confusing.

I mean, by also keeping the <activity> or <receiver> tags, you don't
need to introduce any additional <component> child - all the info is
in principle in the Manifest file already.

But I agree that this is a minor point and choosing one way or the
other should not keep the overall project from getting implemented.

>   If the library is a stub, developers won't have to know about the
> service.

Ok. So we should probably differentiate between implementation
details, and the interface that each application developer is going to
see / use. I'm all for simpler solutions at this stage regarding this
interface, and at this point I don't care too much about the actual
implementation details. I was suggesting that the simplest interface
on Android is actually the intent system itself.

> I also said that
> I'd favour this being handled in IntentManager - see #3 in my
> original lengthy email.

Ok :-) Then we agree on this point. Your lengthy email was so long so
it was easy to miss / forget certain points.

>   I'm first and foremost concerned about providing infrastructure that
> enables Market-like apps to feed that information to IntentManager.

Ok, point taken.

>   Overall, I think it'll all become a bit clearer once there is some
> code.

I think the discussion is also very good :-)

Peli

[Peli]

>   The idea is to provide infrastructure. I see no point in investing
> (my) time if what I build is not somewhat future-proof.
>   I think Carl said that AndAppStore expressed some intrest in
> whatever we come up with here. If they do, maybe the Android Market
> team will.

Ok. I also agree that good future-proof infrastructure is important.

To summarize, there are 3 possible sources for intent resolution:
A) Directly from Market or app stores: Best solution in the long run.
B) Provided by independent server (i.e. OpenIntents intent registry,
or manually maintained file). Maybe faster at start, but more
cumbersome to maintain in the long run.
C) "Hash Hack" in Market descriptions. Quickest to get started, but
ugliest.

While A) and B) require some kind of infrastructure (data in content
provider, filtering / matching of intents,... ), solution C) does in
principle not require any of this. Therefore I suggested to bypass A)
and B) for now, and concentrate on C).

This would of course at no point exclude the possibility to work on an
infrastructure that is required for A) and B). But the infrastructure
is not necesesary for solution C).

>   If we're hashing, we might as well hash a normalized/serialized version
> of the full intent definition. That way we can actually expect decent
> matches.

This is of course a possibility. On the other hand, if the hash is too
"fine-grained", the app description would have to contain several hash
strings to cover all possible "variations" of intents. So we need some
practical tradeoff between matching accuracy vs. required length in
Market description.

Looking at existing intents: http://www.openintents.org/en/intentstable
I see basically 2 main types of intents:
* generic intents that are differentiated by their MIME type: VIEW,
EDIT, INSERT, ...
* intents that are more or less fully specified by their action: SCAN,
SHOW_RADAR, SHOW_ABOUT_DIALOG ...
(but in most cases those don't carry a MIME type).

So, maybe after all, a combination of action string + mime type may be
a good candidate for a hash, without going into other details of the
intent definition (like optional categories, etc.).

Peli

[Jens Finkhäuser]

On Wed, Dec 16, 2009 at 04:03:23AM -0800, Peli wrote:
> I mean, by also keeping the <activity> or <receiver> tags, you don't
> need to introduce any additional <component> child - all the info is
> in principle in the Manifest file already.

The <component> child is optional, and used to make an intent explicit.
Given it's optional nature, it should be a child of the <intent> tag,
not a parent.

> >   Overall, I think it'll all become a bit clearer once there is some

> > code.
> I think the discussion is also very good :-)

Absolutely.

I wish someone from AndAppStore and/or the Android Market team would
comment, though - a lot of this is aimed at them :)

Jens

[Peli]

> > I mean, by also keeping the <activity> or <receiver> tags, you don't
> > need to introduce any additional <component> child - all the info is
> > in principle in the Manifest file already.
>
>   The <component> child is optional, and used to make an intent explicit.
> Given it's optional nature, it should be a child of the <intent> tag,
> not a parent.

Ok, you beat me here. Indeed, just copy&pasting everything literally
from the Manifest does not allow one to specify whether the component
is mandatory or not.

Also, aplication developers who provide intents could publish intent
specifications on their homepage in the way they are required in the
mandatory-intents.xml, so developers could copy&paste from there as
well.

If a specific component is required, the search is actually simpler,
because it contains the package name already: One can search on Market
directly for a specific package to download and install that (which
must contain the desired intent). So even the hash hack is not
necessary here.

Peli

[Jens Finkhaeuser]

Right, to breathe some life into this whole thing again.

While I'm not quite done implementing yet, I had a few hours to spare
most days since I last posted here. I think what I've got now should
give a good impression of what I had in mind. It works, too - for a
definition of "works": while the critical part of enabling the user to
install dependencies is still mostly absent, the way packages interact
is done, and seems to work.

I've started development at http://code.google.com/p/android-dependencymanager/
so you guys can review before a decision is made whether or not to add
this to your OpenIntents repository. Doing so also let me create a few
issues for the things that still need doing, which in turn should help
you understand what's there.

The code is structured as follows:
- trunk/tests/TestApp contains a simple example/test application.
- trunk/tests/TestStore contains a simple example/test Market-like
app. You'll see that feeding data into DependencyManager is little
more than adding a bit of meta-data and a ContentProvider to your
store.
- trunk/common contains shared constants; the contract between
DependencyManager, Market-like apps, and apps using DependencyManager.
- trunk/client contains the client lib that apps would use; while
TestApp is set up to build that lib from scratch, pre-compiled .jars
would work just as well.
- trunk/DependencyManager contains the main code.

I could give a ton of comments, but I'm prone to hitting you over the
head with walls of text, so shall refrain - you can just poke around
the source now and ask questions, if you want.

Enjoy (and Merry Christmas to those of you that celebrate!)
Jens

[Peli]

Great!

I would like to try out what you have so far, but I face some very
basic problems, I guess.
How did you set up your project in Eclipse? (did you use Eclipse?) The
problem I'm having is how to include the "common" folder in the
various projects.

Downloading from SVN, most of the things can be downloaded as
anonymous user, but I obtain the following error after I had been
asked a password for a few files (I don't have a password):
External failed: C:\dependencymanager\DependencyManager\src\de
\finkhaeuser\dm\common
Error: OPTIONS of
Error: 'https://android-dependencymanager.googlecode.com/svn/trunk/
common/src/de/finkhaeuser/dm/common':
Error: authorization failed: Could not authenticate to server:
rejected Basic
Error: challenge (https://android-dependencymanager.googlecode.com)

Note that somehow the common folder tries to connect to https: instead
of http:
Did you do anything fancy with the common folder (like include it in
every project?)

Peli

On 27 Dez., 20:33, Jens Finkhaeuser <unwe...@gmail.com> wrote:
> Right, to breathe some life into this whole thing again.
>
> While I'm not quite done implementing yet, I had a few hours to spare
> most days since I last posted here. I think what I've got now should
> give a good impression of what I had in mind. It works, too - for a
> definition of "works": while the critical part of enabling the user to
> install dependencies is still mostly absent, the way packages interact
> is done, and seems to work.
>

> I've started development athttp://code.google.com/p/android-dependencymanager/

[Jens Finkhäuser]

Hi!

> How did you set up your project in Eclipse? (did you use Eclipse?)

No, I don't use Eclipse.

> The
> problem I'm having is how to include the "common" folder in the
> various projects.

It's included via svn:externals, so you shouldn't have to do
anything.

> Downloading from SVN, most of the things can be downloaded as
> anonymous user, but I obtain the following error after I had been
> asked a password for a few files (I don't have a password):
> External failed: C:\dependencymanager\DependencyManager\src\de
> \finkhaeuser\dm\common
> Error: OPTIONS of
> Error: 'https://android-dependencymanager.googlecode.com/svn/trunk/
> common/src/de/finkhaeuser/dm/common':
> Error: authorization failed: Could not authenticate to server:
> rejected Basic
> Error: challenge (https://android-dependencymanager.googlecode.com)
>
> Note that somehow the common folder tries to connect to https: instead
> of http:
> Did you do anything fancy with the common folder (like include it in
> every project?)

See above. That's interesting... bit of an annoying problem with
google code, it seems. You should be able to use
svn propedit svn:externals path/to/parent/of/common
And change the externals to http, then 'svn up'.

Will have to think of something clever to make that work better for
anonymous access.

Jens

[Friedger Müffke]

I faced the same problem. No solution yet.
I am working on the Broadcast receiver.

Friedger

2009/12/28 Jens Finkhäuser <unw...@gmail.com>:

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

--
OpenIntents UG (haftungsbeschränkt)
Suarezstraße 41
14057 Berlin
tel:+49 30 60982220
mailto:in...@openintents.biz
enum:+493060982220

Vertretungsberechtigter Geschäftsführer: Friedger Müffke
Registergericht: Amtsgericht Berlin (Charlottenburg)
Registernummer: HRB 118597
Ust-IdNr: DE265992701

[Jens Finkhäuser]

On Mon, Dec 28, 2009 at 11:08:06PM +0100, Friedger MÃŒffke wrote:
> I faced the same problem. No solution yet.

Should work fine now, I've switched to relative URLs. But you'll
need subversion 1.6+ because 1.5 doesn't yet support externals that
point to files.

Jens

[Peli]

Good! It works for DependencyManagerSettings and TestStore now.

I'm still having problems with TestApp:

de.finkhaeuser.dm.client.DMActivity
and
de.finkhaeuser.dm.common.DependencyManagerContract
do not get included properly.

Are svn properties set correctly for those as well?

Peli

[Jens Finkhäuser]

On Tue, Dec 29, 2009 at 12:49:18AM -0800, Peli wrote:
> Good! It works for DependencyManagerSettings and TestStore now.
>
> I'm still having problems with TestApp:
>
> de.finkhaeuser.dm.client.DMActivity
> and
> de.finkhaeuser.dm.common.DependencyManagerContract
> do not get included properly.
>
> Are svn properties set correctly for those as well?
>
> Peli
>

> On 29 Dez., 00:44, Jens FinkhÀuser <unwe...@gmail.com> wrote:

> > On Mon, Dec 28, 2009 at 11:08:06PM +0100, Friedger MÃŒffke wrote:
> > > I faced the same problem. No solution yet.
> >

> >   Should work fine now, I've switched to relative URLs. But you'll

> > need subversion 1.6+ because 1.5 doesn't yet support externals that
> > point to files.

Are you using subversion 1.6 or above?

Jens

[Peli]

The problem was not subversion, but that I was using Eclipse instead
of the ant build scripts. "external/client/src" was not automatically
included in a new Eclipse project.

I've sent in a patch for that here:
http://code.google.com/p/android-dependencymanager/issues/detail?id=10

Looks good so far.

One thing that comes to my mind in TestApp:
Since you have a DMActivity anyway, onCreateDialog() and if (!
bindResult()) {..} could be moved in there as well? (one has to think
about how to handle String resources in that case...)

Peli

[Jens Finkhäuser]

On Tue, Dec 29, 2009 at 04:32:44PM -0800, Peli wrote:
> The problem was not subversion, but that I was using Eclipse instead
> of the ant build scripts. "external/client/src" was not automatically
> included in a new Eclipse project.
>
> I've sent in a patch for that here:
> http://code.google.com/p/android-dependencymanager/issues/detail?id=10

Thanks!

> Looks good so far.
>
> One thing that comes to my mind in TestApp:
> Since you have a DMActivity anyway, onCreateDialog() and if (!
> bindResult()) {..} could be moved in there as well? (one has to think
> about how to handle String resources in that case...)

String resources is exactly the reason I hadn't done that. But yes,
it'd be nicer of course.

[Jens Finkhäuser]

Hi all!

Well, I hardly think this'll come as a surprise to anyone. Given that
I haven't been able to continue on this project for the past months,
and the coming months look even busier, I should admit to myself and
you guys that I won't be able to finish it.

If anyone wants to continue this, feel free to ping me - I'll gladly
answer any questions you might have; I still have an interest in
seeing this done, but not enough time.

Sorry to anyone who might have been waiting!
Jens

[Friedger Müffke]

Hi Jens,
Thanks for your status mail. I am working to get an Appstore on board.
Hopefully, I can submit a patch to AOSP within the next weeks.
Anyone interested in a online hacksession?
Friedger

2010/7/7, Jens Finkhäuser <unw...@gmail.com>: