LibreTasks
LibreTasks copied to clipboard
Published
20 hours ago •
biotinker
biotinker
Support Third Party Application Registration (Omni-aware apps)
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 [email protected] on 8 Jun 2009 at 5:08
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 [email protected] on 9 Jun 2009 at 4:18
- Changed state: Started
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 [email protected] on 9 Jun 2009 at 5:23
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 [email protected] on 9 Jun 2009 at 5:41
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 [email protected] on 9 Jun 2009 at 3:28
- Changed title: Support Third Party Application Registration (Omni-aware apps)
- Added labels: Component-Persistence, Priority-Critical
- Removed labels: Priority-Medium
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 [email protected] on 14 Jun 2009 at 3:51
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 [email protected] on 14 Jun 2009 at 5:51
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 [email protected] on 14 Jun 2009 at 10:18
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 [email protected] on 15 Jun 2009 at 2:29
Marking as "accepted" in case someone else wants to look into this. If you're
still
interested let us know. Thanks!
Original comment by [email protected] on 27 May 2010 at 3:35
- Changed state: Accepted
- Added labels: Priority-Medium
- Removed labels: Priority-Critical
Original comment by [email protected] on 22 Jun 2010 at 8:28
- Added labels: Milestone-Release1.0, Priority-High
- Removed labels: Priority-Medium
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 [email protected] on 8 Jul 2010 at 3:31
I will work on this and push forward release 1.0.
Original comment by [email protected] on 18 Jul 2010 at 7:07
- Changed state: Started
Original comment by [email protected] on 30 Aug 2010 at 2:39
- Changed state: Accepted
- Added labels: Milestone-Release2.0, Type-Enhancement
- Removed labels: Milestone-Release1.0, Type-Defect