Action Data is Off-by-one (or more) about omnidroid HOT 7 CLOSED

I will see what I can find out to resolve the problem.

Akshah,

Here were some notes from one of the previous developers on the subject.
  Off-By-One Data Error Solution:
    1) Have a separate "SMS plug in" which understands our framework.
    2) This plug in will generate EVENTS as required to interact with
       OmniDroid.(ie Event containing the URI pointing to the exact record). At
       the moment we do not get the exact URI from the SMS application; so we
       query the last record in the CP. This causes the "off by one" bug.
       Our suggested SMS plugin will have a "CONTENT PROVIDER OBSERVER" with
       generates OmniDroid events only when the SMS CP is updated with the
       required record.
    3) These plug ins could be provided for all important applications; till
       they interact in the way we would like them to. ie. Once applications
       adapt to our framework we can get rid of the plugins.
    4) These plug ins could have their own CP if there is no CP for the
       original application.

This isn't a trivial bug, but it probably is the most critical bug we currently 
have
as it may require significant architectural change that would mean 
re-implementing
how we handle events.  I think what we need right now is for you to take a 
close look
at how the code is getting the data currently.  Then look to see how it could be
handled differently.  After that, we can try to determine if the solution 
proposed
currently is the way we want to go for future development, or if there is a 
better
solution.

I addressed this issue in the new version of the DummyActivity class (.  Right 
now,
the way the class fills the dynamic data (e.g. sender phone, message text) is by
reading the last line of the content provider.  The problem is that we are 
reading
the same broadcast intent that the system is using to populate the message 
content
provider, so it's a problem when we get there first (an awful issue to debug, 
since
adding a breakpoint before checking the table solves the problem!).  Adding a 1
second delay before checking the table allows the system time to populate the
database first.

However, this method of checking the database is not very reliable, as messages 
tend
to get missed if there is a flood of new messages.  Google doesn't seem to have 
a
supported method for getting text message data at the moment but between Ankit's
example code and some other pages I've found I think we can get the data right 
out of
the intent.

Addressed?  Does that mean it's already been resolved?  Or just that you've
determined the cause?  I didn't notice a commit or a code review for a fix.  Is 
there
one (if so, what's the appropriate rev# or link)?  If not, and you're working 
on it,
are you already pulling this data from the intent or you just believe you're 
able to?

Sorry, to be more clear, retrieving data from the content provider is fixed in 
the
code uploaded for review http://codereview.appspot.com/82054.  If you send a 
text
message with a reply rule enabled, you will get the same text back.

I have tested code fragments that successfully retrieve the data from the 
intent, but
I wanted to bring this up in a group discussion before making any major changes 
since
there are a few issues around processing intents in general.

This is not an issue in the redesigned core.  If there are no objections I will 
mark
this "WontFix"