[Bitpim-devel] Update data in phonebook

[d***@netzero.com]

Roger, Stephen,

While working on the Samsung code, I came to realize that there's no "official" way of passing changes from commphone to phonebook. One example would be the case of a long name: commphone would truncate the name and send it the phone, while phonebook still maintains the original longer name. Any thoughts or suggestions?

-Joe Pham


________________________________________________________________
Look for special offers on
NetZero Platinum & NetZero HiSpeed
Visit Best Buy, RadioShack or Kmart Today.

[Roger Binns]

Post by d***@netzero.com
While working on the Samsung code, I came to realize that there's no "official"
way of passing changes from commphone to phonebook. One example would
be the case of a long name: commphone would truncate the name and send
it the phone, while phonebook still maintains the original longer
name. Any thoughts or suggestions?

The information you can officially pass is updated serials.

Why exactly would I want my nice clean data truncated because I just
happened to send a copy to a constrained phone? Imagine I have two
phones and the other one is even more limited (lets call it an
Audiovox). Do you want all entries damaged to the lowest common
denominator? :-)

The original versions of BitPim used to actually work the way you
describe. But that is of no value if you have multiple phones,
or if you import and export data.

Roger

[d***@netzero.com]

I have no problem with that, that would actually simplify the code. The reason I ask for the clarification is because of Stephen's opinion of maintaining and reflecting BITPIM data to be the same of what was sent to the phone, which appeared to be not always possible with this approach.

-Joe Pham

Post by d***@netzero.com
While working on the Samsung code, I came to realize that there's no "official"
way of passing changes from commphone to phonebook. One example would
be the case of a long name: commphone would truncate the name and send
it the phone, while phonebook still maintains the original longer
name. Any thoughts or suggestions?

The information you can officially pass is updated serials.

Why exactly would I want my nice clean data truncated because I just
happened to send a copy to a constrained phone? Imagine I have two
phones and the other one is even more limited (lets call it an
Audiovox). Do you want all entries damaged to the lowest common
denominator? :-)

The original versions of BitPim used to actually work the way you
describe. But that is of no value if you have multiple phones,
or if you import and export data.

Roger



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bitpim-devel mailing list
Bitpim-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitpim-devel


________________________________________________________________
Look for special offers on
NetZero Platinum & NetZero HiSpeed
Visit Best Buy, RadioShack or Kmart Today.

[Stephen Wood]

Post by d***@netzero.com
I have no problem with that, that would actually simplify the code.
The reason I ask for the clarification is because of Stephen's opinion
of maintaining and reflecting BITPIM data to be the same of what was
sent to the phone, which appeared to be not always possible with this
approach.
-Joe Pham

When I first wrote the Sanyo code, either the code was supposed to
return a modified phone book, or I thought it was. I'll be able to take
some code out of the Sanyo drivers too.

By the, way, if looking at phone specific code for examples of how
things are supposed to be done to communicate with the rest of BitPim,
don't use the Sanyo code as a reference. The best examples are probably
the LG VX4400 and VX6000. (By virtue of being essentially complete and
being written by Roger!)

The Sanyo code is probably a reasonable example of how to support many
similar phones with minimal code duplication.

Stephen

[Roger Binns]

Post by d***@netzero.com
I have no problem with that, that would actually simplify the
code. The reason I ask for the clarification is because of
Stephen's opinion of maintaining and reflecting BITPIM data to
be the same of what was sent to the phone, which appeared to be
not always possible with this approach.

We are going to need to know what was put on the phone in order
to do syncing properly. For example if the data BitPim has is
"John Smith", and we later read back "John Smi" from the phone,
we need to be able to distinguish from the user editing the name
on the phone, vs that being the way it was sent to the phone.

Things get more complicated than just truncation. There are also
issues over allowed characters etc.

What should happen behind the scenes is that when a write to phone
is done, BitPim also saves a copy of what what was written (hence
the need for a database).

Later on, when we read back from the phone, that information has to
be compared with what was written. Any changes are then something
the user did.

For the phones I wrote code for, the easiest thing is going to be
for me to just re-read stuff back from the phone rather than try
and work out exactly what I supplied it.

Roger

[Vic Heintz]

I discovered something new regarding the AT phonebook write command and
caller ID wallpapers for the Samsung A670. It is best shown by examples
(note the last 3 fields before the final timestamp field):

at#pbokw=0,3,3,1,18,"Eric",2,0,,,,,5551234567,0,,,,,,,,,"",3,0,"digital_
cam/Image033",20041111T080637

will set Eric's caller ID wallpaper image to Image033 in the phone's
picture gallery.

at#pbokw=0,3,3,1,18,"Eric",2,0,,,,,5551234567,0,,,,,,,,,"",4,2,"",200411
11T080637

will set Eric's caller ID wallpaper image to the image whose ID is "2"
in the file /nvm/nvm/brew_image

at#pbokw=0,3,3,1,18,"Eric",2,0,,,,,5551234567,0,,,,,,,,,"",5,0,"",200411
11T080637

will set Eric's caller ID wallpaper image to the unassigned state.

So the 3rd to the last field [3, 4, or 5] is a flag.
The 2nd to the last is used when the flag is 4 to give the id of the
assigned wallpaper image.
The next-to-last is used to give the full path of the gallery photo
assigned when the flag is 3.

Perhaps for now this info can just be added to
examples/samsungnotes.txt. Ultimately it can be used to correctly
handle the caller ID assignments. I'll be using it in the short term to
fix BitPim's undoing of the assignment of camera photos for caller ID.

Vic