Closed GoogleCodeExporter closed 9 years ago
I will see what I can find out to resolve the problem.
Original comment by akshah...@gmail.com
on 5 Jun 2009 at 3:31
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.
Original comment by case.and...@gmail.com
on 8 Jun 2009 at 4:49
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.
Original comment by londinop
on 22 Jun 2009 at 3:23
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?
Original comment by case.and...@gmail.com
on 22 Jun 2009 at 6:09
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.
Original comment by londinop
on 22 Jun 2009 at 6:37
This is not an issue in the redesigned core. If there are no objections I will
mark
this "WontFix"
Original comment by londinop
on 3 Aug 2009 at 3:29
Original comment by londinop
on 3 Aug 2009 at 5:21
Original issue reported on code.google.com by
case.and...@gmail.com
on 4 Jun 2009 at 7:08