SIP address dialer - improvements

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Flip to the SIP dialer

What is the expected output? What do you see instead?

Expected: blank fields for address and domain
Saw: domain has freephonie in it (which many people don't use)

Please use labels and text to provide additional information.

The freephonie should not show. It requires erasing before the desired domain 
is entered.

Additional idea: Add a way to indicate a "preferred" account (if more than one 
exists), and pre-fill the domain with the domain of the preferred account.

Original issue reported on code.google.com by dc3de...@gmail.com on 14 Jul 2010 at 6:54

[GoogleCodeExporter]

Yes, should be the preferred account instead of this default value.

As I didn't implemented reordering of accounts, we can start by choosing the 
first registered account.

What is in my mind on this subject : 
* The text and digit dialer will have a sliding chooser on the top of interface 
to allow the user to choose the account used for the outgoing call.
* The text dialer should be only one field instead of theses two ones. The 
current interface with split name and domain is not clear.

Original comment by r3gis...@gmail.com on 14 Jul 2010 at 7:03

[GoogleCodeExporter]

Original comment by dc3de...@gmail.com on 14 Jul 2010 at 7:33

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Increasing the intent priority to 1 results in the looping behavior. Clearly 
this is not the focus of the problem :-)

Original comment by dc3de...@gmail.com on 14 Jul 2010 at 7:54

[GoogleCodeExporter]

I think that you are talking about issue #63. 
In fact, yes, priority 1 is less than -1 (that's strange but appears that 
negative values has a special behavior on this intent). 
And if I well understand the SDK reference on this particular intent, we should 
be at least 0, or better, a negative value.

Original comment by r3gis...@gmail.com on 14 Jul 2010 at 8:19

[GoogleCodeExporter]

Yes, I posted in the wrong place.

I think your idea of only supporting the domains of listed SIP accounts is a 
bit of a problem. For example, my SIP phone number is rdenny@dc3.com, just like 
my main office email address. So it is important to be able to specify ANY 
domain in a SIP call destination address!

Original comment by dc3de...@gmail.com on 15 Jul 2010 at 1:53

[GoogleCodeExporter]

I have at least removed the default freephonie from the text dialer :-)

Original comment by dc3de...@gmail.com on 15 Jul 2010 at 2:27

[GoogleCodeExporter]

> I think your idea of only supporting the domains of listed SIP accounts is a 
bit of a problem.

It's not my idea.
What I described is in order to allow user to choose outgoing account for an 
outgoing call. But not the outgoing domain.
In the case of the digit dialer, yes, it will match the domain. 
But in the case of the text dialer, my idea is to provide one single 'mail' 
field in which you can enter a full sip address (with domain - and maybe with 
completion on existing email addresses in the address book).
In fact it's just to merge username and domain in a single field. A designer of 
my enterprise advise me to do so, since he think that one field is more easy to 
understand for users.

Original comment by r3gis...@gmail.com on 15 Jul 2010 at 8:18

[GoogleCodeExporter]

Oh, I'm sorry I misunderstood. 

The idea of auto-complete on the SIP address using the contact info it good! 
However using the email address might result in many matches on addresses that 
won't work for SIP calls :-))) My wife's Moto Droid allows a "custom" labeled 
email address on a contact, and one could use the label SIP. I have an HTC 
Incredible and it does not allow labeling of email addresses! Grr... The 
Incredible address book does labeled  Instant Message (IM) addresses though. I 
am thinking that the auto-complete source shouold somehow be configurable? I 
know, more settings :-( 

And I agree with your designer on 1 field vs 2. It's trivial (and common) to 
type an '@' :-)

Original comment by dc3de...@gmail.com on 15 Jul 2010 at 3:17

[GoogleCodeExporter]

Looking for email OR IM address itself (not any label) that must begin with 
'sip:' might be an idea, and would eliminate the configuration I mentioned 
above. And could a press on such an email address be trapped by CSipSimple and 
start a call?

Original comment by dc3de...@gmail.com on 15 Jul 2010 at 3:24

[GoogleCodeExporter]

We could also explore the contact provider API.
The problem is that it is available only after 2.0 API.

Another approach, that could be really interesting, is to develop a third party 
application that really plug into a targeted device. CSipSimple is already 
capable to manage sip: protocol (not yet really tested but should be ok) . 
For example, if another application launch an intent with sip:xxxxx as data, 
csipsimple chooser will be prompted.

Original comment by r3gis...@gmail.com on 15 Jul 2010 at 5:51

[GoogleCodeExporter]

Should we continue to support below 2.0 and decide not to do things "right", 
instead working out our own solutions to things that are already solved in the 
OS, or adding code to detect OS and providing "brain damaged" functions if the 
OS is old? Just a question, not a suggestion.

Original comment by dc3de...@gmail.com on 20 Jul 2010 at 1:05

[GoogleCodeExporter]

My approach on this question is the following :

If there is an available API that could be cool to use in CSipSimple :

We can implement the feature, but must not break the backward compatibility.

If the feature is a must have, we try to find a workaround for incompatible 
device and use the official API for compatible ones.
If the feature is not necessary and is just a nice to have, we can disable 
feature for unsupported OS version.
This can be done using wrappers approach as described in this android article :
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-androi
d.html

What I think that is important is to be able to provide the same software to 
all OS from 1.5 to 2.2 (and more ;) ). If features are not allowed in 1.5 or 
1.6 it's not so important. But what I want absolutely to avoid is to release a 
version of CSipSimple by android OS version.

The reason is that it can become really really hard to maintain two concurrent 
version of the same software. 

Making wrappers that ensure backward compatibility is complicated but certainly 
less than maintaining two version of the software.

And why not just saying CSipSimple is not available on 1.5/1.6 devices... 
because it's still about 40% of the installed android and some manufacturers 
has just decided to not upgrade the OS version. That's a pity, but we have to 
take this into account.

Original comment by r3gis...@gmail.com on 21 Jul 2010 at 3:28

[GoogleCodeExporter]

Only thing that remains to fix the initial issue is to allow account reordering.
Issue 282 should allow that, so I close this one to make things more clear.

Original comment by r3gis...@gmail.com on 13 Oct 2010 at 7:06

• Changed state: Fixed