search

xhsyy / omnidroid

Automatically exported from code.google.com/p/omnidroid
Apache License 2.0
1 stars 0 forks source link

Support Third Party Application Registration (Omni-aware apps) #26

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
At the core of OmniDroid is the ability to let omni-aware applications
register with OmniDroid and provide us with an Application Configuration
that tells omindroid the following things about itself:
 * Events it triggers
 * Actions it can perform
 * What data it needs for both of these things, and how it maps to
omnidroid stored data.

Currently there is no way for an application to register with OmniDroid, or
for OmniDroid to query applications to see if they are omni-aware and can
provide us with this data.

This functionality needs to be developed.

Original issue reported on code.google.com by case.and...@gmail.com on 8 Jun 2009 at 5:08

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
What I understand is that applications need to provide omnidroid certain 
information
so that omidroid can populate the Application configuration file.
I am not sure what the correct way would be to solve this. I suggest this : at 
boot
up of an application or at boot up of the OS, we take into account all the
applications that are running, I think we can get this information from a 
Application
Manager, based on this list we can raise a question like whether this 
application
wants to be omni aware. If yes then I think we need to look into all the Events,
Filters and Actions that the application might raise and then store it onto the
Application Configuration file.

Original comment by apoorv.r...@gmail.com on 9 Jun 2009 at 4:18

GoogleCodeExporter commented 9 years ago

Original comment by apoorv.r...@gmail.com on 9 Jun 2009 at 4:19

GoogleCodeExporter commented 9 years ago 
This is what I understand.

omni-aware applications: They have there own app config file which list all the
events, filters and actions that they might raise.

Non-omni-aware application: They don't have there own app config file.

Registering with OmniDroid: Adding application's app config file contents to
OmniDroid app config file.

For omni-aware application to register with OmniDroid: We have to provide a
functionality to add contents of app config files of applications to OmniDroid 
app
config file.

For Non-omni-aware applications(if they want to register): We first have to 
create
there app config files and then proceed like omni-aware applications.

Let me know if I am not correct.

Original comment by rohitbha...@gmail.com on 9 Jun 2009 at 5:23

GoogleCodeExporter commented 9 years ago 
Yes, I absolutely agree with what you have said, however there is one point 
that I
think you are missing out on. The application Configuration file for an 
application
is a logic that the previous group have thought of and they are currently 
assuming
that they get the app config file in whatever format they want it to be. (right 
now
the files has been hard coded as per my understanding). Thus, we need to self
generate the app config file, and also think of something to make sure that all 
or
certain applications become omni aware in a way and that is equivalent to 
saying that
we are able to generate the information of that application in the config file.
I hope I have made myself clear, I might be wrong too.

Original comment by apoorv.r...@gmail.com on 9 Jun 2009 at 5:41

GoogleCodeExporter commented 9 years ago 
You are both pretty close (I think rohitbhatia was pretty right on, but I want 
to
clarify a bit).  From the big picture perspective you both have the right idea, 
but I
think this bug is a specific subset of what Apoorv is discussing.

Apoorv, to address your issue about self generating the app config file instead 
of
assuming that we get the app config file directly from the app.  I don't think 
we can
possibly analyze all applications to figure out what events, filters, actions, 
and
content map they provide.  This is why we're expecting third party apps to 
provide
it.  If you think otherwise, lets take the discussion to the omnidroid-devel
mailinglist instead of muddying this bug with the discussion.

Just to make sure we're one the same page, the DesignOverview
(http://code.google.com/p/omnidroid/wiki/DesignOverview) defines both Omni-ware 
and
Omni-compatible as:

Omni-aware - applications which provide an OmniDroid Application Configuration 
File
for their app.

Omni-compatible - applications which are either Omni-aware or have built-in 
OmniDroid
support. 

There are really two forms of Registering applications that I think must get 
done
before release.
1) Registering Omni-compatible applications
2) Registering Omni-aware applications

Registering Omni-compatible applications
----------------------------------------
We already do this.  As mentioned, this is built-in functionality that as we've
hardcoded into OmniDroid.  It's pretty ugly and really isn't the way things 
should be
done and once we have support for Registering Omni-aware applications, we should
probably ditch this in favor of the latter.

Registering Omni-aware applications
-----------------------------------
This is the part that we don't have yet, but the part that is really crucial.  I
think ideally registration happens at two times and they consist of performing 
the
following functionality:

A) When OmniDroid is first installed
   1. Query the application configuration manager for a list of installed apps (a
sample of how to do this is already in the source as tests/PackageLister.java)
   2. Query each application's CP (Content Provider) to see if they have an OmniDroid
Application Configuration File
   3. If they do, then load it into our global application configuration

B) Whenever a new application is installed (we should be able to catch this 
system event)
   1. Query the newly install application's CP (Content Provider) to see if they have
an OmniDroid Application Configuration File
   2. If they do, then load it into our global application configuration

Issue 26 is specific to handling the steps A2/A3 and B1/B2.  The other parts of 
the
process like how to trigger these should be part of a new issue.

Original comment by case.and...@gmail.com on 9 Jun 2009 at 3:28

GoogleCodeExporter commented 9 years ago 
Andrew, I am trying to create a service that runs in the background and detects 
the
new applications and also all the existing ones, and looks for the OmniDroid
Application Configuration File, is this the right approach ?

Also, when you say "application's CP (Content Provider) to see if they have an
OmniDroid Application Configuration File " should I assume that the file resides
there ? Can you elaborate more on this. I want to know where exactly I should 
look
for the OmniDroid App Config file.

Original comment by apoorv.r...@gmail.com on 14 Jun 2009 at 3:51

GoogleCodeExporter commented 9 years ago 
I think a background process is too expensive to do this. We should have a 
broadcast
receiver which runs whenever an intent message says an app is installed.

Original comment by EHo...@gmail.com on 14 Jun 2009 at 5:51

GoogleCodeExporter commented 9 years ago 
Evan is right, we should just have a receiver that listens for that type of 
intent. 
You'll need to do some research to find out what system intent broadcast when 
an app
is installed.

Start here for intent handling:
http://developer.android.com/guide/topics/intents/intents-filters.html

As for the "application's CP...", this is still up in the air.  We currently 
haven't
specified where an application has to store this.  I think for now something 
simple
would be good.  For example if we define the specification to be
"AppCpName:///omnidroid/appconfig" that would be fine.  For example, so lets say
there is the "Contacts" app, you would query it's CP with the URI
"Contacts:///omnidroid/appconfig" and you would expect it to either give you an
AppConfigFile back, or return null or something if it didn't have that in it's 
CP. 
You can define what you think the URI should be and then document it in the
specifications for OmniDroid.

If that doesn't make sense, let me know.

Original comment by case.and...@gmail.com on 14 Jun 2009 at 10:18

GoogleCodeExporter commented 9 years ago 
Hey guys, I totally agree with you, making this as a service was a bad idea, 
I'll
change it into a receiver. Thanks !

Original comment by apoorv.r...@gmail.com on 15 Jun 2009 at 2:29

GoogleCodeExporter commented 9 years ago 
Marking as "accepted" in case someone else wants to look into this.  If you're 
still
interested let us know.  Thanks!

Original comment by case.and...@gmail.com on 27 May 2010 at 3:35

GoogleCodeExporter commented 9 years ago

Original comment by case.and...@gmail.com on 22 Jun 2010 at 8:28

GoogleCodeExporter commented 9 years ago

Original comment by case.and...@gmail.com on 6 Jul 2010 at 1:42

GoogleCodeExporter commented 9 years ago 
I think this post is worth reviewing with this bug as what we're considering is 
a type of plug-in framework:
http://mylifewithandroid.blogspot.com/2010/06/plugins.html

Original comment by case.and...@gmail.com on 8 Jul 2010 at 3:31

GoogleCodeExporter commented 9 years ago 
I will work on this and push forward release 1.0.

Original comment by chengsh...@gmail.com on 18 Jul 2010 at 7:07

GoogleCodeExporter commented 9 years ago

Original comment by case.and...@gmail.com on 30 Aug 2010 at 2:39