Closed GoogleCodeExporter closed 9 years ago
What core data model are you referring to? Anything besides how the
configuration
files are stored?
Original comment by case.and...@gmail.com
on 10 Jun 2009 at 3:25
Per our discussion this week, we agreed on replacing AppConfig and UserConfig
by a
new date model using sqlite databass. This thing will be used by BRService,
BCReceiver, DummyActivity ,UI and RegisteredApp. So we're trying to provide
with an
API such that other groups can start working on it. The API should be similar
to what
we have now in AGParser and UGParser. But definitely, lots of methods will be
changed
or added.
Original comment by EHo...@gmail.com
on 10 Jun 2009 at 3:50
Some wrapper objects have already been constructed for OmniHandler and
RegisteredApp
data types. I'd suggest using them to encapsulate the storage/retreival from
these
items from SQL library inside these objects. This way none of the other classes
mentioned need to know how the data is stored. This makes it flexible incase
the
data storage structure ever changes, you only have to update these two classes
and
not all the other classes.
Original comment by case.and...@gmail.com
on 10 Jun 2009 at 4:12
Yeah, that is very good point.
Original comment by EHo...@gmail.com
on 10 Jun 2009 at 4:30
Here is a preliminary design for ApplicationConfiguration class. I would
appreciate
the comments. One of the holes is data type for action/event parameters. The
main
concerns are what types are we handling (a.k.a. text, number, phone number,
list of
values, etc.) and how user interface group is planning to use them. Appreciate
the
feedback. Also we will need a reference on how to execute the actions and
receive events.
Original comment by dvo...@gmail.com
on 14 Jun 2009 at 2:45
Attachments:
Hi
I've come up with a new version of design, let's start discussing on this.
This is more flexible than the earlier version I have.
I'm sure we still need to add in some Intent specific information.
Regards,
Evan
Original comment by EHo...@gmail.com
on 15 Jun 2009 at 1:04
Attachments:
Hi I re-factor some part of the diagram to fix some bugs and change the naming
convention to be more fitted in our existing code. Please check out this
version.
Original comment by EHo...@gmail.com
on 15 Jun 2009 at 3:53
Attachments:
I created a wiki page for later updates of the diagram. Working on coding db
adapters
now.
http://code.google.com/p/omnidroid/wiki/DatabaseDesign0
Original comment by EHo...@gmail.com
on 16 Jun 2009 at 1:57
Hey guys, I put up some db codes for review, cause I want you guys to find out
problems that I may be terribly doing wrong.
These are basically those "Red" tables in the diagram. I'll be keep working on
the
other adapters.
http://codereview.appspot.com/78058
Original comment by EHo...@gmail.com
on 19 Jun 2009 at 4:01
Hi Guys:
Per our discussion yesterday, I renamed some of the table names here:
http://code.google.com/p/omnidroid/wiki/DatabaseDesign0
Evan
Original comment by EHo...@gmail.com
on 24 Jun 2009 at 5:16
Hi Guys:
Per our discussion yesterday, I added additional columns, and
ExternalAttributes table
to the diagram.
http://code.google.com/p/omnidroid/wiki/DatabaseDesign0
Evan
Original comment by EHo...@gmail.com
on 26 Jun 2009 at 1:59
Hi
Just fixed some bugs I found in the DB diagram.
http://code.google.com/p/omnidroid/wiki/DatabaseDesign0
Regards
Evan
Original comment by EHo...@gmail.com
on 29 Jun 2009 at 7:07
Consider this issue as fixed, since we've already done with most of the design
part
of the new database. More enhancement and extension to the database should be
separated issues.
Original comment by EHo...@gmail.com
on 2 Aug 2009 at 6:05
Original issue reported on code.google.com by
EHo...@gmail.com
on 10 Jun 2009 at 1:28