zeroomega / omnidroid Goto Github PK

What steps will reproduce the problem?
1. Set an auto-reply OmniHandler for incoming TXT that reply to "SENDER
PHONE NUMER"
2. Have phone A send a text to you
3. OmniDroid will most likely ignore this incoming message
4. Have phone B send a text to you
5. OmniDroid will reply to sender A after receiving message from B

Each OmniHandler should be able to have multiple Filters added.  Currently
only one is allowed.

This issue is about how to test the pre-populated data in database.

More detail about this:

1. The code to pre-populate data is in
edu.nyu.cs.omnidroid.model.db.DbHelper.populateDefaultData()

2. This method got called by onCreate() callback in
edu.nyu.cs.omnidroid.model.db.DbHelper

UI tests will require changes to the AndroidManifest.xml, and they will 
test individual Activity classes by instantiating and using them with fake 
objects.

See android.test package: 
http://developer.android.com/reference/android/test/package-summary.html

Create icons for buttons in ActivityChooseFiltersAndActions:

1) Add filter
2) Add action
3) Edit action/filter
4) Delete action/filter
5) Save rule

right now we are just using single characters on the buttons like:

1) +F
2) +A
3) E
4) D
5) S

When the phone is connected to the internet through the data plan instead of 
Wifi and if 
you receive / make a call, the internet gets disconnected. So any rule with a 
call event and 
an internet (gmail send) action would fail.

What steps will reproduce the problem?
1. Run in the debug mode
2. Setup some rules
3. When the action triggered, look at the log.

IllegalStateException caused android system kill the SQLite process
especially when an action process tried to use some I/O stream.

This must be caused by some dbHelper was leaving their db cursor open.

Not a high priority, since nothing shows up on screen, but it would be nice
to solve this.

Rewrite the data model of Omnidroid to adopt build-in sqlite of the system.
I open this issue for discussions about this.  

The DummyActivity doesn't present a UI so it shouldn't be an activity.  It
should be some sort of service that runs in the background.

Originally it was created as an Activity in the case that it needed to
present an activity to the User to get input before performing the action.
 For example, if we wanted to automate birthday messages to friends, but
wanted to be able to customize the message sent, OmniDroid would present
the template email and allow the user to customize it before being sent.

The secondary part however shouldn't be a part of the actual service, but
an Acitivty the service starts up if it needs it.

This issue can be resolved if the DummyActivity is renamed and extends a
Service instead of the activity.

Users should be able to pull up the context menu for an existing
OmniHandler and select "Edit" to edit and existing OmniHandler's attributes.

As it relates to Issue 5.  The autobuild on commit, should run these tests
to verify that new commits don't cause any test failures.  Autobuild
related scripts are stored in:
   https://omnidroid.googlecode.com/svn/tools/autobuild/

PasswordInput is a datatype to store user's password input. It has a UI that 
mask user input, and 
persist the input string. 

PasswordInput should have some encryption feature so that the plain text are 
protected when it is 
stored into the database. 

Since the password needs to be retrieved and used for certain services, (like 
Sending Gmail) so 
simple hash algorithms are not feasible, both encrypt/decrypt methods needs to 
be provided. 

See StringMap.java. It holds a String "key" and "value." This class is
unnecessary, and should be removed in favor of a more standard Java object.
Decide what it should be replaced with, and remove throughout the project.

In eclipse, select the class name or constructor name, and use References
--> In Workspace to find all users or creators of StringMap objects. This
will let you know if you've touched all the code necessary.

What steps will reproduce the problem?
1. Create a rule when phone is called, send an email with the phone number 
in subject or body.

What is the expected output? What do you see instead?

Expected output should be the actual phone number of the caller. Instead I 
see <phone number> in the e-mail.

What version of the product are you using? On what operating system?
1.5 

We need an Ant build script that will run all the available Junit tests.

We should address the handful of eclipse workspace warnings (either remove
them or suppress them).

As a policy we should make sure we do not commit new code that introduces
warnings.

We need a standard omnidroid notification icon to display in the status bar
after OmniDroid has executed an OmniHandler.

Users should be able to pull up the context menu for an existing action and
select "Edit" to edit and existing OmniHandler's action.

As a new feature, it would be great if we can catch the event that the user 
just took a picture.  

Eventually, this can be used to auto-upload the picture to a website, email 
to your address or may be even geo-tag it.

When the phone is connected to the internet through the data plan instead of 
Wifi and if 
you receive / make a call, the internet gets disconnected. So any rule with a 
call event and 
an internet (gmail send) action would fail.

There is an Issue in SDK 1.5 that prevents emulators to dial or send SMS to
each other. 

I've tried to do what Andrew demo on Tuesday, but get this error:
emulator: could not connect client socket to :::::::00001:5556: Invalid
argument.

There is a issue tracking this but not solved yet:
http://code.google.com/p/android/issues/detail?id=2660

I think this is critical because we rely on this feature to test omnidroid.

What steps will reproduce the problem?
1. Open any xml file in eclipse with our formatter from 
http://code.google.com/p/omnidroid/wiki/StyleGuide loaded
2. Press Ctrl + Shift + F to format the file

What is the expected output? What do you see instead?
Should see XML nested with indentation similar to Java (2 spaces per level), 
instead it's eclipse's default 8 spaces.

For each OmniHandler that is triggered based on the events stored. 
OmniDroid should keep a Log of what event occurred and what actions were
performed as a result (like a CallLog).

What steps will reproduce the problem?
1. Start OmniDroid
2. Don't use it for a long time (run other apps)
3. See that the Broadcast Receiver Service restarts randomly (toast is
displayed)

Issue:
Perhaps need to research the OnBind method of the Service.  I think this
occurs when the Receiver is booted from memory, then is restarted when an
event it listens for occurs.  The solution may be just to disable the
toasts, but this also could be a bug (it needs research).

Dmitriy,

This doesn't look right to me:

      // Only broadcasts if the Phone exceeded minimum acceleration.
      if (acceleration < MIN_ACCELERATION) {
          [snip]
      }

Seems like this is the opposite of what it should be (less-than instead of
greater-than), but in further consideration I would think maybe it should be:

      // Only broadcasts if the device is outside of accepted parameters
      if (MIN_ACCELERATION < acceleration > MAX_ACCELERATION) {
          [snip]
      }

If you're still working on the project, maybe you can take ownership of
this.  If you're moving on, let me know if you think this is right and I'll
make the change.

Thanks for all the hard work this summer!  I hope you'll continue to
develop the app with us.

--
Drew

Omnidroid's content provider doesn't keep any pre-existing data in the
database after reinstall.

We don't have any officially documented use cases or user stories. We'll
need these to make design decisions and to avoid too many features creeping in.

Update the Project page at code.google.com to describe the most important
use cases.

OmniDroid should have an option to reset all settings back to the default.
 It should confirm that all user stored data will be lost if this is done.

Our icon looks pretty pathetic in my opinion, especially at 48x48 pixels (I
made the one we currently have and even I am not a fan).  I'd like to see a
better looking icon.

For anyone that wants to take this challenge up, here are some android icon
design guidelines:
http://android-developers.blogspot.com/2009/05/android-icon-guidelines.html

Android should load app config when it boot up. Right now we have to
manually run test -> app config to do that

The following two UI pages are rather unintuitive:
  ui/ActionData
  ui/ActionDatumAdd

They need to be redesigned in a more user intuitive manor.

In Omnidroid:

1. Press Menu -> Help
2. Go to end of page
3. Press link after words 
     "For more help see our webpage: http://omni-droid.com/help"

I'd expect to see a browser opening the page. Instead nothing happens, it 
is not a linked text.

In my view there are really two issues at hand: one is to set up the web 
page (discussed by Michael in class), the other one is to correct the code 
so that the link works.

If Issue 27 is fixed, then our "welcome to omnidroid" dialog will no longer
be displayed.  The logic for when to display the welcome message needs to
be changed.  Perhaps from:

If no OmniHandlers are present
then
  present Welcome dialog
done

to:

If user hasn't made any config changes from the default configuration
then
  present Welcome dialog
done

Take a unit test unfriendly class, pull out some of the code into other 
methods / classes, and then add unit tests. Use this code review to teach 
other developers how unit testing can be used in Android classes.

What steps will reproduce the problem?  I think this will:
0. emulator with OmniDroid on 5554
1. Start a second emulator on 5556
2. On 5554, Clear all TXT messages from the phone so the CP will be empty
3. On 5554, OmniDroid -> Menu -> Run Tests -> App Config
4. On 5554, New OmniHandler -> SMS -> SMS Received -> Done (Filters) -> Add
Action -> SMS -> SEND SMS -> Set Data for Phone -> 5556, Done -> Set Data
for Text -> foo, Done -> Save -> bar, Save.
5. On 5556, Send TXT message to 5554
6. Because we still have the "off-by-one" error, it tries to pull a record
that isn't in the CP yet, which results in a Force Close.

If there isn't a record something is probably wrong, but we need to catch
the exception and handle it nicely, I assume the CP of the Messaging app is
returning null and we're trying to use it.

When the application is run for the first time, it should load some
OmniHandler use cases by default (i.e. "AutoReply in a Meeting").  These
OmniHandlers should be disabled by default.

Each OmniHandler should allow for multiple actions.  Currently only one is
supported.

We need to write up some ant build instructions for developers.

Users should be able to pull up the context menu for an existing filter and
select "Edit" to edit and existing OmniHandler's filters.

On both the Filters and Actions page.  If you're phone is open exposing the
keyboard after you've create a new filter or action, and you close the
keyboard before you move on to the next page.  The filters or actions you
entered will be erased when the keyboard closes.

What is the expected output?

It should keep this data.

It would be nice if we included an Ant build file in the project root with
some useful targets.

What steps will reproduce the problem?
1. Add a few OmniHandlers
2. Delete an OmniHandler using the Context menu
3. Watch all OmniHandlers disappear

What is the expected output? What do you see instead?

Just the one selected should be removed.

URI's between CP and other threads are being passed using strings in the
extras of Intents, instead of being passed as URIs.  Instead URIs data
structures should be used.  Original developers were unable to pass them as
URI's for some reason.

Please add the following license header to the source files:

/*
 * Copyright 2009 OmniDroid - http://code.google.com/p/omnidroid
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

When OmniDroid catches an event that matches an OmniHandler and that
OmniHandler's actions are performed a status notification should show up on
the status bar.

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.

Check out AGParser.java readEvents(). The return type is
ArrayList<HashMap<String, String>>. This exposes the implementation of the
List to the user of the method. It's preferable to return a
List<Map<String, String>> because the user shouldn't care that it's a
HashMap or an ArrayList specifically.

Throughout the project, most methods shouldn't be returning implementation
classes for Collections, but instead the more general List, Set, and Map.
Refactor code where necessary to fix this.

Some eclipse advice: Make copious use of selecting the method name of the
method to be refactored, and right clicking, selecting Refactor --> Change
Method Signature and making changes that way. 

Also use References --> In Workspace to find all users of the methods.

There are two definitions of these in the AndroidManifest.xml file:
<service android:name=".bkgservice.BRService" >
<receiver android:name=".bkgservice.BCReceiver">

This issue is to keep track of data that needed to be pre-populated into
the database.

Create tests/ src dir and add some junit tests. This will be used for unit 
testing so that the test files can be in the same package as the classes 
under test, but not in the same directory tree.