From: Roger B. <ro...@ro...> - 2003-10-02 18:48:53
|
> Can the Sanyo phone book structure be > fit into the bitpim structure that is being developed? Yes. Note that other data sources such as the Windows Address Book also just have them seperately, with no idea of priority. > I am guessing > that if one wanted to import a phone book with duplicate types (e.g. a > Home1, Home2, Home3), a sanyo sync could accept the first phone number > with a type matching Home.* and discard the rest. (Perhaps extra > numbers could optionally be shoved into less used types such as "No > Label", "Data", and perhaps Fax and Pager.) Yes, that would be the general theory. They way I have it structured now is that when you choose to write out the phonebook, getfundamentals() is called on the Phone object. It needs to get whatever information is appropriate from the phone. For the 4400, it gets the group listing and the ESN. It will also get the ringtone and wallpaper index (which I need to do some work on). Then the convertphonebooktophone() method is called in the Profile object. This runs in the main thread (all serial comms is done in a background thread). convertphonebooktophone needs to massage the data into what it intends to write. It can generate warnings and in very serious cases, errors. I am hoping to "score" them in some way, and allow the user to see the most important ones first, and potentially abort. Some examples of warnings are that some phones (eg the 4400) can't have entries without phone numbers. Also fields may be truncated to various lengths. The helper class passed in to convertphonebooktophone will log all this and do most of the conversion work. See com_lgvx4400.Profile and phonebook.PhoneWidget for them working together. > Is there a framework within bitpim for holding call history and received > SMS messages? Not yet, but it is on my todo list :-) > The call history and messages all have dates and times on > them, so perhaps this stuff could be read from the phone and put in > bitpim's calendar (and exported to vcalendar?). This could be handy for > someone who likes to keep a log of calls. If these call history and > message "calendar" entries are tagged, then they could be ignored when > syncing to the phone since it seems to me that the value is getting this > stuff out of the phone, not sending to the phone. Can you put a feature request into SourceForge for this, giving your example etc so that we don't forget about it? My current priorities are to get address book syncing working (as well as a UI for the address book), and release that as 0.7. Then the other fluffy stuff follows like you SMS and call history. > In interpreting 32 bit dates on the Sanyo4900, I had a fudge factor of 5 > days different from starting the epoch on July 1, 1980. I noticed that > the fudge factor is 4 days and 17 hours for the LG-VX4400. Is that > because BITPIM translates times into GMT, whereas I am translating into > localtime? I don't believe my phone really knows what timezone it is > in, it just makes time whatever the towers tell it is. I use GMT in the code because I don't want timezone conversion done. I too believe the phone has no idea of timezones. So if the phone thinks that something is at 3pm, in the routines I call I supply that 3pm as a GMT number, but display it to the user as is, but saying it is local time (ie 3pm). If I did try to use local timezone then the original number would have to be fudged and other fun things. The other possibility is that the phone may actually be operating in GMT for date/timestamps. The TM520/VX10 also used something different which Scott/Alan can remind us of. Roger |