[Bitpim-devel] Samsung SCH-A650 and A310 notes

[d***@netzero.com]

My notes on the A650 and A310 implementation in BITPIM. Editorial & technical comments & suggestions are welcome & appreciated.

Thanks,

Joe Pham

[Vic Heintz]

Post by d***@netzero.com
My notes on the A650 and A310 implementation in BITPIM. Editorial &
technical comments & suggestions are welcome & appreciated.

I don't know what the ultimate destination of this text is to be but as
a statement of BitPim's current support for those phones I guess it
looks OK to me. I do have a few comments about possible changes and
future direction.

I'm not really sure what the intended use of the phonebook entry
"alias" is on Samsung phones, but I would find it more useful to store
the BitPim "URL" field there rather than "NickName". I would probably
remember nicknames of my contacts but not their websites.

Apparently your phones don't have the feature of associating a
wallpaper with a pb entry but the A670 and the A610 do and I hope to
get this implemented.

You say that currently, only built-in ringtones can be assigned.
Hopefully you saw my notes about the file /nvm/nvm/brew_melody. It
should be relatively easy to support uploaded ringtones also.

Vic

[d***@netzero.com]

Post by Vic Heintz
I'm not really sure what the intended use of the phonebook entry
"alias" is on Samsung phones, but I would find it more useful to > > store
the BitPim "URL" field there rather than "NickName". I would probably
remember nicknames of my contacts but not their websites.

Technically, it's possible; but I think it might be too confusing to users, some of whom may already use the Alias fields in their phonebooks. Obviously, you're welcome to use that field anyway you wish for yourself.

Post by Vic Heintz
Apparently your phones don't have the feature of associating a
wallpaper with a pb entry but the A670 and the A610 do and I hope to
get this implemented.

I offer my help, but it's tough to test the code without a real phone.

Post by Vic Heintz
You say that currently, only built-in ringtones can be assigned.
Hopefully you saw my notes about the file /nvm/nvm/brew_melody. It
should be relatively easy to support uploaded ringtones also.

For my A650, the constraint is at the AT protocol level (it sounds like the same constraint does not exist for your A670). Mixing BREW and non-BREW operations does not sound too practical at this point due to the phone reset thing. But I'll try to improve on what I have.

Thanks for your comments.

-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
My notes on the A650 and A310 implementation in BITPIM. Editorial &
technical comments & suggestions are welcome & appreciated.

Next time please submit it as plain text so we can comment easier!

Post by d***@netzero.com
Only "Full" names are supported, the other fields are ignored. The
length of the name is limited to 22 characters. Longer names will
be flagged as an invalid entry.

Longer fields are not invalid, and should just be truncated to whatever
the phone has. Similarly multiple fields beyond what the phone has
should just be ignored. For example, BitPim will quite happily let
you create 10,000 home phone numbers for someone. You just need
to copy across as many as the phone will support.

Post by d***@netzero.com
Do not use the " (double quote) character in the name.

You should just remove invalid characters from fields. For example
the LG code does this for phone numbers:

def phonize(str):
"""Convert the phone number into something the phone understands
All digits, P, T, * and # are kept, everything else is removed"""
return re.sub("[^0-9PT#*]", "", str)

We'll need to do the same with Unicode characters etc.

Post by d***@netzero.com
BP " Nickname" will be used as "Alias".

Cool. I have added a comment to the effect of alias and nickname being
the same thing at the top of phonebook.py.

Post by d***@netzero.com
Each phonebook entry needs to have at least one number or email,
otherwise it will be flagged as an invalid entry.

That doesn't make an entry invalid - it just shouldn't be copied
to the phone. It isn't a big deal if the user has data they
have imported from other sources, and some of it can't go on
particular phones.

Post by d***@netzero.com
Each phonebook entry can include up to 5 phone numbers, only one of
which can be assigned a speed dial. Speed dial assignments must also
be unique among entries. If no speed dial number is specified for a
new entry, the next available one will be assigned.

I don't know exactly how the speed dials work on the Samsung. However
on other phones speed dials can be empty. It is a *really* bad
idea to automatically assign speed dials. BitPim has the ability
for users to assign speed dials. If you automatically assign the
speed dials, then when reading back from the phone later you won't
know if a particular entry has a speed dial because the user wanted
it that way, or because the software randomly assigned it.

Some phones also have "slots" which are somewhat similar to speed
dials. They shouldn't be confused though.

Post by d***@netzero.com
Each entry can be assigned a "category" or "group" name. The number
and names of these groups are retrieved from the phone and should
not be changed in BP. Since both the A650 and A310 only support a
maximum of 5 groups, changes can be easily made from the phone.

You can't stop people from changing stuff within BitPim and many
will do so, or in places BitPim imports data from.

What the LG and Audiovox code does is when doign the
convertphonebooktophone stuff, it goes through and does a popularity
contest of the groups used. Based on that it calculates the new
list of groups within the constraint of the phone (eg the LG requires
a "No Group" entry and the Audiovox has 4 predefined slots/names with
3 changeable ones). The new groups are written out at the same time
as the phonebook data.

Post by d***@netzero.com
Prior to sending phonebook data to the phone, BP will go through
all entries and check for invalid invalid entries. If one or more
invalid entries are found, BP will not send any data to the phone.

There is no such thing as an invalid entry. There may be some entries
that can't be written to the phone, but they should just be ignored.
Remember that the data is coming from multiple places and can be
sent to multiple devices.

For the calendar stuff, the BitPim internals are a bit silly so
you have to work around that, as you did.

Roger

[Stephen Wood]

Post by Roger Binns

Post by d***@netzero.com
Each phonebook entry can include up to 5 phone numbers, only one of
which can be assigned a speed dial. Speed dial assignments must also
be unique among entries. If no speed dial number is specified for a
new entry, the next available one will be assigned.

I don't know exactly how the speed dials work on the Samsung. However
on other phones speed dials can be empty. It is a *really* bad
idea to automatically assign speed dials. BitPim has the ability
for users to assign speed dials. If you automatically assign the
speed dials, then when reading back from the phone later you won't
know if a particular entry has a speed dial because the user wanted
it that way, or because the software randomly assigned it.

On the Samsung, every name in the phone book is a speed dial, the only
choice you get is which of the 5 numbers is the one that the speed dial
will dial.

Perhaps what we could do is is reserve the single digit numbers (first
nine) for ones selected by the user, (Perhaps start at 300 or 500 and
work down for one where the user has not selected a speed dial).

Stephen

[Roger Binns]

Post by Stephen Wood
On the Samsung, every name in the phone book is a speed dial, the only
choice you get is which of the 5 numbers is the one that the speed
dial will dial.

That's a suitably user hostile feature!

Post by Stephen Wood
Perhaps what we could do is is reserve the single digit numbers (first
nine) for ones selected by the user, (Perhaps start at 300 or 500 and
work down for one where the user has not selected a speed dial).

I really want to be able to distinguish from the software assigning a
number and the user assigning a number when we later read things back.
This is especially important in the case where the user has two phones
and wants the speed dials to be the same across both phones.

You algorithm sounds like the best way of approaching this.

On other phones you can typically only assign one or two digit speed dials.

Roger

[Vic Heintz]

Post by Stephen Wood

Post by Roger Binns
I don't know exactly how the speed dials work on the Samsung. However
on other phones speed dials can be empty. It is a *really* bad
idea to automatically assign speed dials. BitPim has the ability
for users to assign speed dials. If you automatically assign the
speed dials, then when reading back from the phone later you won't
know if a particular entry has a speed dial because the user wanted
it that way, or because the software randomly assigned it.

On the Samsung, every name in the phone book is a speed dial, the only
choice you get is which of the 5 numbers is the one that the speed dial
will dial.
Perhaps what we could do is is reserve the single digit numbers (first
nine) for ones selected by the user, (Perhaps start at 300 or 500 and
work down for one where the user has not selected a speed dial).

Good idea.

Since the phone will not allow you to NOT have an assigned speed dial
for an entry (AT command produces an error if this field is empty) and
BitPim does not make it easy to see what speed dial numbers are
available, I agree with Stephen about starting at the high end and
working down. Assigning speed dials to desired values is best done ON
the phone. I (and probably most people) would rarely choose a number at
the high end. This would be a flag that it needs to be reassigned.

Just as an aside: Everyone has their own scheme for assigning speed
dials at the low end. My daughter has a numerical priority that she
keeps in her head. I use initials. If I had a friend "Guy Smith" he
would normally get speed dial 4 for G except 4 is already used for
Home. If 47 for "GS" is already taken I would probably resort to 489
for GUY. That would be an unusually high number for me. (Unfortunately
I can't use 546 for my friend JIM because that is beyond 500.) My
daughter thinks I'm weird for this scheme.

Bottom line is if BitPim assigns them at the top I may never wish to
reassign them because they are not important enough that I would ever
want to speed dial them. However, I am frequently having to move
entries at the low end out of the way so I can use that number for a
closer friend.

Vic

[Roger Binns]

Post by Vic Heintz
BitPim does not make it easy to see what speed dial numbers are
available,

Yes, that is some UI work that needs to be done.

Post by Vic Heintz
working down. Assigning speed dials to desired values is best done ON
the phone.

One of the goals of BitPim is to avoid having to do stuff on your phone
since the UI on the phone is horrid, the keys are tiny, the screen is
small etc.

Roger

[d***@netzero.com]

Thank you all for your comments. I found them to be very helpful. A quick summary of the comments I have so far:

1. Docs being submitted should be in plain text format.
2. Long entry names should be truncated and sent forward to the phone.
3. Illegal chars from entry fields should be automatically removed, and the corrected entry should be sent to the phone.
4. If an entry has neither a number nor an email, it should be automatically discarded.
5. As Stephen and Vic pointed out, Samsung phones use memory slots as the speed dial numbers, ie, if a number is stored at memory slot 100, pressing 100 as the speed dial will dial that number. In the current implementation, if an user does not assign a speed dial, implying that he does not want/care for a speed dial for this entry, BITPIM would pick one for him: the next empty memory slot. Roger is correct in pointing out that once the phonebook entries are retrieved from the phone, users cannot differentiate between the speed dials that they assigned and the ones BP assigned, but does it matter either way? Stephen's suggestion is a good one and is certainly feasible, but would it make any difference: BP would either assign the next lowest empty slot, or the next highest empty slot. I guess my point is that if a user wants speed dials, he'd enter them himself, if not he shouldn't care what BP assigned. In any case, I could work with either approach.
6. Currently, if two entries have the same speed dial, it will be flagged as illegal and must be corrected prior to sending them to the phone. Should this approach be changed?
7. Understand Roger's comment about categories. Currently, any changes to the either the number and the names of the categories in BP are ignored. While doing the read or save phonebook, the categories are retrieved from the phone and overwrite what's in BP. Unrecognized categories in phonebook entries are automatically set to the first valid category in the list. I thought that this approach has been pretty consistent with Roger's philosophy all along.
8. In general, illegal entries will be discarded and removed from 'results'. When possible, illegal fields will be corrected and sent forward such as long names, illegal chars, unassgined speed dials, invalid/unassigned category and ringtones, etc.

Please let me know if I missed anything else.

I'll start working on the changes. When's the next Build?

Thanks

-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
2. Long entry names should be truncated and sent forward to the phone.
3. Illegal chars from entry fields should be automatically removed,
and the corrected entry should be sent to the phone.
4. If an entry has neither a number nor an email, it should be
automatically discarded.

That all falls under the general premise that BitPim should make a
best effort to put each entry on the phone.

Post by d***@netzero.com
the phone, users cannot differentiate between the speed dials that
they assigned and the ones BP assigned, but does it matter either
way?

Note that more importantly, BitPim can't tell. Lets say you owned
two phones. If you read the phonebook from your Samsung and then
go to dump everything on the second phone (a different model),
should that include those speed dials? We only want to deal with
what users explicitly set, rather than have that intermingled
with "noise" due to the way some models operate.

Post by d***@netzero.com
6. Currently, if two entries have the same speed dial, it will be
flagged as illegal and must be corrected prior to sending them to the
phone. Should this approach be changed?

Yes, just pick one. It isn't an error. Once we have a full blown
speed dial UI users will be able to see this for themselves.

Post by d***@netzero.com
7. Understand Roger's comment about categories. Currently, any
changes to the either the number and the names of the categories in
BP are ignored. While doing the read or save phonebook, the
categories are retrieved from the phone and overwrite what's in BP.
Unrecognized categories in phonebook entries are automatically set to
the first valid category in the list. I thought that this approach
has been pretty consistent with Roger's philosophy all along.

The LG phones have a "No Group" category, and the Audiovox has a
"Etc." category. When reading from the phone, the resulting
entry will be given to BitPim with no category at all. On
sending back to the phone, the popularity contest ensures we
have the most popular categories available. For entries that
have no category, or not in the list available on the phone
(which we may have just modified), they get assigned to the
"No group"/"Etc." groups.

In general you need to ensure that the data you present survives
round trips. For example if you read the whole phonebook into
BitPim, make no changes, and then send it back, nothing should
change. This requires being really careful with how you map
stuff.

Similarly, if I import some data from Outlook, send it to the
phone and read back again, the data should remain the same.

Where this gets real tricky is field mapping. For example
if the original data source differentiates between home and
work email, and the phone doesn't, then it shouldn't be the
case that the email starts out as work, goes to the phone
as "email" and then comes back as "home email".

Post by d***@netzero.com
8. In general, illegal entries will be discarded and removed from
'results'. When possible, illegal fields will be corrected and sent
forward such as long names, illegal chars, unassgined speed dials,
invalid/unassigned category and ringtones, etc.

Other than using the word "illegal", this is just a continuation
of 2,3 and 4. Make the best effort to get the data on the phone.

Post by d***@netzero.com
I'll start working on the changes. When's the next Build?

Every two weeks, so next weekend.

Roger

[Michael Bonar]

In the A660, you can assign a new speed dial location. If there is already a number at that location the phone askes you if you want to swap it. The phone makes a direct swap. I put one number in slot #004 and another in #100 (only 13 numbers entered in the phone so far) to see if the phone would put the number from #100 into #004 and the number from #004 into the next highest empty slot, but the phone simply swapped the slots.

I then created an empty slot in #004 and tried to create a new entry. The phone automatically assigned it to #004, not #101. So, it picks the next avaiable _empty_ slot for new ID's.

If you are created a new number in Bitpim, you probably want to pick tne next available empty slot. If you want the user to be able to pick their own slots, you should build in a routine that scans the slots to see if a swap is required. I haven't had a chance to review the source code, so I don't know if this is already implemented.

Hope this helps.

Mike Bonar



----- Original Message -----
From: "***@netzero.com" <***@netzero.com>
Date: Saturday, November 6, 2004 12:46 pm
Subject: Re: [Bitpim-devel] Samsung SCH-A650 and A310 notes

Post by d***@netzero.com
Thank you all for your comments. I found them to be very helpful.
1. Docs being submitted should be in plain text format.
2. Long entry names should be truncated and sent forward to the phone.
3. Illegal chars from entry fields should be automatically
removed, and the corrected entry should be sent to the phone.
4. If an entry has neither a number nor an email, it should be
automatically discarded.
5. As Stephen and Vic pointed out, Samsung phones use memory slots
as the speed dial numbers, ie, if a number is stored at memory
slot 100, pressing 100 as the speed dial will dial that number.
In the current implementation, if an user does not assign a speed
dial, implying that he does not want/care for a speed dial for
this entry, BITPIM would pick one for him: the next empty memory
slot. Roger is correct in pointing out that once the phonebook
entries are retrieved from the phone, users cannot differentiate
between the speed dials that they assigned and the ones BP
assigned, but does it matter either way? Stephen's suggestion is
a good one and is certainly feasible, but would it make any
difference: BP would either assign the next lowest empty slot, or
the next highest empty slot. I guess my point is that if a user
wants speed dials, he'd enter them himself, if not he shouldn't
care what BP assigned. In any case, I could work with either
approach.6. Currently, if two entries have the same speed dial, it
will be flagged as illegal and must be corrected prior to sending
them to the phone. Should this approach be changed?
7. Understand Roger's comment about categories. Currently, any
changes to the either the number and the names of the categories
in BP are ignored. While doing the read or save phonebook, the
categories are retrieved from the phone and overwrite what's in
BP. Unrecognized categories in phonebook entries are
automatically set to the first valid category in the list. I
thought that this approach has been pretty consistent with Roger's
philosophy all along.
8. In general, illegal entries will be discarded and removed from
'results'. When possible, illegal fields will be corrected and
sent forward such as long names, illegal chars, unassgined speed
dials, invalid/unassigned category and ringtones, etc.
Please let me know if I missed anything else.
I'll start working on the changes. When's the next Build?
Thanks
-Joe Pham
________________________________________________________________
Look for special offers on
NetZero Platinum & NetZero HiSpeed
Visit Best Buy, RadioShack or Kmart Today.
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Vic Heintz]

Post by Roger Binns
We'll need to do the same with Unicode characters etc.

Post by d***@netzero.com
BP " Nickname" will be used as "Alias".

Cool. I have added a comment to the effect of alias and nickname
being the same thing at the top of phonebook.py.

Do we have to be consistent across phone models on this? Because I
actually don't like this at all. In the A670 code I am working on I
have equated phone "alias" with bitpim "url" This is infinitely more
useful and there is evidence that this is the intended use of alias
anyway. (Why else would there be an option of selecting [.com, .edu,
.net] from a menu while editing the alias field on the phone?)

Having a separate nickname field on my phone is of no value to me.
Instead, I'd be inclined to give nickname priority over fullname as the
name uploaded to the phone. If I import my brother's vcard for upload
to the phone, even though his full name might be Dr. Willam Heintz,
what I want to find him by on my phone is his nickname, Bill. True, I
may have other friends with the nickname Bill and I don't know how that
would play out if nicknames were not unique. That is why I haven't
pursued this change yet.

Vic

[Roger Binns]

Post by Vic Heintz
Do we have to be consistent across phone models on this?

That is about how BitPim is storing the fields internally.

For each phone you need to write out the information representing
those values and semantics as closely as possible. Similarly when
reading from the phone, the information needs to be mapped to the
BitPim storage as closely as possible.

What is really important is that information survives round trips.
If you read from the phone and then write back out again, nothing
should actually change. (This can often be quite difficult!)

Post by Vic Heintz
Because I
actually don't like this at all. In the A670 code I am working on I
have equated phone "alias" with bitpim "url"

More accurately you have done that on your phone. I doubt every user
does that!

In the short term, do this:

- map that field to nickname
- check for your phone's ESN and in that case map it to URL
- you should be getting the ESN or equivalent during
getfundamentals


The plan is to have configuration settings where per phone information
can be stored. The configuration will be storable in two places. One
will be a file on the phone itself. The second will be as part of
the BitPim config. The former has the advantage that it will work
with BitPim on any machine you try without having to tell each machine
what your settings are. The disadvantage is that it will consume a small
amount of space on the filesystem and anyone who has your phone (eg if you
take it to a carrier store) will be able to tell you use BitPim. The
latter has the disadvantage that you have to configure your phone for
BitPim on every machine you use.

The way it would work is that getfundamentals would get the config off
the phone if it existed. If it doesn't then the BitPim config is checked.
If that doesn't exist either then the user is offered the choice of
where to create the config.

(We did debate making a phonebook entry and storing data in that. It
would be possible but highly brittle and annoying to users.)


Roger