#92 SIP address dialer - improvements

[Anonymous]

Originally created by: dc3de...@gmail.com
Originally owned by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

(No comment was entered for this change.)

Labels: -Priority-Low Priority-Medium

[Anonymous]

Originally posted by: dc3de...@gmail.com

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

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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!

[Anonymous]

Originally posted by: dc3de...@gmail.com

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

[Anonymous]

Originally posted by: r3gis...@gmail.com

> 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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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 '@' :-)

[Anonymous]

Originally posted by: dc3de...@gmail.com

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?

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: dc3de...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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-android.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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

Status: Fixed