[Stephen asked this privately but I figured it should be documented for
all to see]
> For the existing phones in Bitpim, how does the code put the phone into
> DM mode? I believe this happens when one clicks on get phone data in
> the GUI and that _setmodebrew in com_brew.py actually does it, but due
> to my lack of Python and OO understanding, I don't understand how it
> gets from here to there.
Multiple inheritance and introspection :-)
Examine com_lgvx4400 and see how it inherits from generic phone, brew
and lg.
There is a function in generic phone called setmode. Generic phone
also has defines the constants for MODENONE (which is how things
start out) and MODEMODEM.
brew defines MODEBREW, and lg defines MODEPHONEBOOK.
vx4400 gets all of these because of the inheritance.
Then what happens is that any code that needs the phone to be in a
particular mode calls the setmode function. For example the sendbrewcommand
function calls setmode(MODEBREW)
The setmode function immediately returns if the desiredmode is the same
as the current mode. It then removes the front MODE and lowercases
the rest.
It looks for function named _setmodeoldtonew where old and new are
the old and new modes. If none is found, it looks for _setmodenew.
This lets you write code for specific mode changes, or just a
generic one ignoring the previous mode.
> It seems that one of the first communications with the phone is to get
> the ESN by retrieving the file nvm/$SYS.ESN. I read in some of your
> comments on the devel list, that the phone can be confused switching
> between brew commands and non brew commands. Should I avoid letting the
> Sanyo code make the filesystem call to get the ESN?
The 4400 phonebook does get confused if you keep reading it. Other sync
software actually reboots the phone after each read or write. I found
that forcing brew mode before going into phonebook mode solves that problem.
The ESN is read because I wanted a unique identifier per phone. Each entry
that is read in has a list of identifiers of the source device, as well as
some sort of serial for that device. This makes it really easy to match up
entries read in the future, especially if the user has altered the name
and/or some of the numbers.
Here is an actual test entry from my phone:
{
'categories': [{'category': 0}],
'emails': [{'email': 'email1 adadadadadadbdadadadaebdadadadadbdadadada'}],
'flags': [{'secret': True}],
'memos': [{'memo': ''}],
'names': [{'full': 'Nnadadadadadadadadadad'}],
'numbers': [{'type': 'home', 'number': '111111111111111111111111111111111111111111111111'},
{'type': 'office', 'number': '222222222222222222222222222222222222222222222222'}],
'ringtones': [{'use': 'call', 'ringtone': 0}, {'use': 'message', 'ringtone': 0}],
'serials': [{'serial2': 234, 'serial1': 234, 'sourcetype': 'lgvx4400',
'sourceuniqueid': '1aadcbb3d92021e92b614f326e2de9f3cb1f77d2'}],
'urls': [{'url': 'www.jmjmjmjmjmjmjmjmjmjmjmjmjmkmjmjnjmjmjmjmjmjm'}],
'wallpapers': [{'use': 'call', 'wallpaper': 12}],
}
On the 4400, Brew mode is also needed to turn wallpaper and ringtone indices back into
filenames. I haven't implemented that yet (as you can see above it still uses the
index numbers) but I will be doing so.
Roger