Comments (16)
[deleted comment]
from omnidroid.
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
from omnidroid.
Original comment by [email protected]
on 9 Jun 2009 at 4:19
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
Original comment by [email protected]
on 22 Jun 2010 at 8:28
- Added labels: Milestone-Release1.0, Priority-High
- Removed labels: Priority-Medium
from omnidroid.
Original comment by [email protected]
on 6 Jul 2010 at 1:42
from omnidroid.
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
from omnidroid.
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
from omnidroid.
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
from omnidroid.
Related Issues (20)
- Event Handler Limit Crash HOT 1
- Events not executing until lock/unlock performed HOT 12
- no market access HOT 2
- Adopt Guice
- Filter, between pre-midnight and post-midnight HOT 1
- contact groups/aliases for recipient/blacklists HOT 3
- decide whether to perform actions smartly
- An action to Enable/disable actions HOT 1
- Crash when using "Time is day of week" filter HOT 2
- Sensor data not fully utilized in some cases HOT 6
- Enhancement: Disable Data traffic on low battery HOT 2
- Trigger on Wi-Fi SSID HOT 1
- Performance improvement suggestion
- Slow operation in UI thread HOT 1
- Add phone filter : in contact / not in contact
- Enhancement request: action on enter/leave WiFi or mobile base station HOT 1
- Unlock attempt event
- Phone shut down action
- Feature request: event on wifi network available / unavailable
- wrong orders of longitude and latitude when constructing a new OmniArea object in the LocationMonitor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omnidroid.