Closed GoogleCodeExporter closed 9 years ago
Ok.
I also want to add the grouping of call logs from several consecutive identical
call logs. I'll try to do this enhancement when I'll do that.
Original comment by r3gis...@gmail.com
on 8 Jul 2011 at 9:12
Regis, I see that you've working on GUI changes lately. May be it's time to
revisit this proposal too ;)
Here is one way how you may want to do it:
1. When in call log tab, user may click on "Delete" (see Note below, p2) button
from "Menu".
2. Call log tab comes into its "Selection" mode. In this mode new bar at the
bottom appears (and stays, while tab is in this mode) and it contains 3
buttons: "Select all", "Delete", "Cancel". Because there is no item is selected
yet, the "Delete" button is grayed.
3. User can click on "Select all" button and all items become highlighted
(selected). Or he may tap specific item(s) one by one and by tapping them
toggle its/their status (from un-selected to selected and vice versa).
4. At the moment when at least one item is selected the button "Select all"
changes to "Invert". Pressing this button inverts selection of all items. If
all items become unselected - it may change back to "Select all" (and "Delete"
button becomes grayed again).
5. When user done with selection, he may press "Delete" button. It will delete
all selected items at once.
6. Pressing on "Cancel" button at any time returns call log tab into its
original mode without making any changes.
Note:
1. Changing tabs (sliding to sides or clicking on tabs directly) doesn't change
the mode of call log tab. Pressing on "Delete" or "Cancel" does (bottom bar
disappears and no selection is allowed anymore).
2. You may change the name in menu from current "Delete all calls" to simply
"Select". If you do so, you may use selection mode for more then just "Delete"
action later on. For example, you may offer new function - "Save" (to save
selected items) or other similar actions, applicable to a subset or items.
3. Example of similar additional menu bar containing controls (buttons, check
boxes) you may find in "OS Monitor" application.
Original comment by yok...@gmail.com
on 12 Feb 2012 at 7:06
Yep it makes sense. It becomes some common user interface experience indeed.
What's a little bit surprising is that android guys only applies that to emails
and not to stock call logs in android 4.0.
That's the reason why it was not directly in the changes made, because I simply
reused the source code of ICS for the new interface of call logs.
I guess google engineers considers that as over engineering -- and also
probably expect third party apps to allow such call log management.
Since in csipsimple there is no way (for now?) to have such third party apps to
manage its call logs, your issue is still valid and will go in the good same
way that the ICS redesign of the app.
However not highest priority for now, I've still to put the priority list
adapter back to retrieve same level of feature as previously. Then I'll have a
look to new features. I would have preferred that this one has been
automatically get from android ICS source code, but sounds I'll have to code it
by my own ;).
For reference, mainly for me as working base when I'll work on this task : http://developer.android.com/design/patterns/selection.html
Original comment by r3gis...@gmail.com
on 12 Feb 2012 at 11:40
Just couple of points related to the issue:
1. I'm running 1 year old HTC Aria. And I don't think it will ever get Android
3, not to mention Android 4. It will be updated from v2.1 to 2.2 though, but
perhaps that's it. So, waiting for Android to implement "Select" functionality
is not an option for me, not at all.
2. The page linked in your post suggests to use long press gesture as a
"Select" action. It's quite stupid, if you ask me... While it may work with one
or two items, it's not suitable for any real work. Good luck selecting more
than several items with that long press action. For example, my call log
currently contains may be a hundred items or may be even more. If I'd need to
select most of them (e.g. to delete) I spend all my day just making long taps
on every item individually.
The proposed solution is: set "Select" mode and tap (note - a short tap, not
long one) several items you want to keep (important calls only). Then press on
"Invert" button and delete the inverted set. That's it. No long taps required
and you cleaned up your long call list very fast.
I'm afraid that you'll have to code that by your own ;). Sorry to say that, but
I need (and I suspect, I'm not the only one) to clean up my call log, while
keeping important calls in the log safe. Especially in case, if I make a lot of
test calls and call log becomes very big very fast... :) I'm sure you know what
I mean here...
Original comment by yok...@gmail.com
on 13 Feb 2012 at 3:50
About point 1, that's not a problem. I can easily do backward compatibility.
About point 2, the link is the android design guidelines. So that the way
things should be implemented by android application. They did big efforts to
not see android developers reinventing the wheel for each feature.
Besides I think that you misunderstood the explaination they give. But since
you never used an android 4.0 device it's quite normal :).
Let me try to explain more in details what it's about.
The long press is something additional to the checkbox. In the link they talk
about long press because that's what changed compared to previous version.
It's still possible to add checkbox, and a single tap on checkbox just behaves
as you described it.
Their point is about the fact the long press does not anymore display a context
dialog anymore but rather change in the action bar actions that could be
performed on the selection. The checkbox is still an option to quickly select
rows.
When in selection mode, there is obviously the delete button, but also other
action that can be performed on the selection. If only one item is selected the
action are the one there where previously on context dialog. If multiple there
is all actions that can apply to multiple selection. We can also add an action
"invert" in this case.
So don't be so worried, the fact that it comes from an android design guideline
is a good point, android designers thought about usability of that. And
besides, as they did this work I think that it's a good idea to follow their
guidelines. My point was not about going against your description because it's
almost the same thing that the one described by the link I gave. It's just
about enrich the description and give me the ref to the more detailed and
complete guideline of google designers.
Original comment by r3gis...@gmail.com
on 13 Feb 2012 at 7:39
You're right. I have never seen Android v4 and, therefore, could misunderstood
the new prospective feature. Thanks for explanation. And I agree with your
point that it's better to follow standards then invent something special (in
case if those standards allow the needed functionality, of course).
The feature to manage long list of calls (to remove many, while keeping some
set of calls untouched) is quite hot. I see my log is growing bigger and bigger
every day (especially if I do a lot of test calls). I don't want to remove all
entries at once (as I can do it right now), because log keeps relatively small
subset of calls (some are tricky test calls), that I'd like to keep for a
while, but, at the same time, don't want to add them into my personal contact
list. The feature becomes important, because I don't know a way to save URL
from some records in the log to clipboard (or a file) now.
An ability to copy / paste full URL from logged calls would somehow mitigate
the quite urgent need to manage (using select / invert actions) of the long
list of logged calls. I'd copy those URL's into my notepad app, remove all
calls from the log altogether and then I may to repeat the calls by copy /
paste saved URL's/Numbers to dial pad of CSS. But so far, I don't know how to
save URL from logged calls.
BTW, it could be a nice feature by itself (independently of removing calls) -
to allow copy data from calls in history to clipboard (or may be a file). I
guess it's easy to implement even now... What do you think?
Original comment by yok...@gmail.com
on 15 Feb 2012 at 8:07
I think that it would be better to have such kind of feature as external
application.
The benefit allowing a third party app to do such import/export/treatment on
call logs would be to allow third party apps to do more things.
For example, there is a very cool app that I use to synchronize stock call logs
to my gmail account (it also do for sms). Each time I get a call log it push it
to some gmail label.
I think that it would be more valuable to spend time on allowing third party
apps doing integration with csipsimple call log database (BTW, the interface
will be almost the same than the stock call logs one) to allow apps that
already allow to manage stock call logs to also manage csipsimple call logs.
I always resent doing specific not sip related things inside the app while the
spirit of android is to have apps specialized in doing things to suit specific
use case.
Original comment by r3gis...@gmail.com
on 15 Feb 2012 at 8:56
The option to batch delete call logs just landed in nightly builds.
As I said, it follows new ICS user interface guidelines.
Just long press a row, and you'll enter the "batch" mode. You can then simple
click each row you want to delete by single clicking it. And finally choose the
delete option in the bottom action bar.
The copy option will also land soon but I wonder if would not be more efficient
to switch to text dialer with sip uri pre-filled - it will allow to copy/paste
anyway and that would match the "Modify before dialing" option of the stock
dialer.
I'm not fan of the idea to save a list of call logs (in file or clipboard)
because it would mean to some not expected result. I mean some lambda user will
not necessarily expect that it will export to plain text format with just uris.
If there is a normalized format for call logs it could be interesting and clear
for users (something like "Export these calls logs to format xxx"). But since
there is not, it's probably better to leave a third party app to manage that
kind of processing. While the "modify before call" remains in the same
application and so make more sense as core feature.
This design pattern should also allow to do more batch actions on call logs
items. But I have none in mind for now. If you have don't hesitate to ask :).
I'm also considering the "Select All"/"Invert" option but I have to check if
possible using the compatibility library for action bar.
Original comment by r3gis...@gmail.com
on 21 Apr 2012 at 8:32
First of all, thank you for implementing this useful feature!
At this point of time (since beginning of February I have a very large
amount of items in the log, may be a thousand records) the "Select
All"/"Invert" option would be the most desirable one. What I need is
to keep may be 20-30 records and the rest must be gone. And "Select
All"/"Invert" would help to do it very quickly.
Without that option I went to go through the list manually marking one
by one items in the list from the beginning. Marking worked fine. But
after marking a lot of items in the list (may be more then a hundred),
suddenly all list become unchecked... It happened at a routine mark of
a next item, nothing special at all. May be there is a limit of marked
items that program supports? Or perhaps, there is an other
explanation...
I tired to continue again from the beginning. But then, in a while,
application crashed with this message box:
--------
Sorry!
The application CSipSimple (process com.csipsimple) has stopped
unexpectedly. Please try again.
Force close
--------
It could be related or it could not (I've seen it time-to-time before
with the new GUI implementation).
After restarting the application, I' started the process again. But
now I mark no more then 100 items and delete them, repeating the whole
process again and again. The problems above (both sudden clearance of
the list and crash) have repeated itself after next several hundreds
of marked/deleted items...
BTW, with HTC Aria (screen 480x320) and the current width (height) of
every record in the log list I effectively can mark about only 3 items
per page and then I have move to the new page. Then mark next 3-4
items and move to the page further. You got the picture... I mention
about it because I value every pixel of vertical space in those
records. The less one item takes from the screen, the more items I can
see in one page (and mark) in call log. Please keep it in mind when
you design the layout.
Small notice. When I delete next 100 items by pressing on 'X' icon I
expect to continue to mark items in the list. What I'm getting is the
internal pointer (including pages) now points about 100 below the item
I checked last time. I guess some re-calculation of the pointer would
be useful here, so I may just continue marking process from the place
I left it (before pressing on 'X' icon).
Good. I need it to do a very simple task. If I have a record and I
need to make a small change in URI and make a new call, using changed
URI, I have to be able to _copy_ the URI from that record into
clipboard. Then I can edit it in dialer as I need. But the problem is
- there is no way I can copy data (sometimes a long URI) from current
record in the log... That's what I'm missing now.
About copy / paste at once number of selected records from the log (as
a batch operation), I don't think we create an additional security
risk here. Android phones are inherently insecure. It's just a matter
of time for a person, who got the possession of your phone, to analyze
(and copy) all of your records there. There is no security or serious
privacy protection offered. On the other hand, this feature may create
additional convenience for legitimate phone user, who knows that he
can save important records from the list to clipboard for further use.
Export marked records with different formats (including text) sounds
like an interesting idea. But the plain text would be fine as first
option...
So, so far I see followed items for batch operations:
"Delete", "Mark All", "Invert", "Copy".
I guess someone else could contribute other ideas here :)
On Sat, Apr 21, 2012 at 13:32, <csipsimple@googlecode.com> wrote:
Original comment by yok...@gmail.com
on 22 Apr 2012 at 7:59
Original issue reported on code.google.com by
yok...@gmail.com
on 8 Jul 2011 at 6:19