FastContact - an alternative contact list for KaiOS (seeking volunteers)

[Luxferre]

Hi again,

Most of us know how slow the stock KaiOS contact app is, especially when importing over 300 contacts. So, this weekend I've started to write an alternative KaiOS phonebook app, and it does quite all the most basic stuff right now, including fast T9-like search, multi-number support, dialing and basic contact creation/editing. See it here and try it out (installable via WebIDE): https://gitlab.com/suborg/fastcontact  

Strongly recommend to read the README, but if anything, T9 search is done by directly pressing the digits, you can exit the search mode with End/Back key, switch active SIM for calling or saving contacts (if you have a dualsim setup) with Left/Right arrows, and delete contacts with #.

This might remain a fun weekend project, however, I wanna make it better and more usable for everyone. Right now, I'm seeking volunteers to:

1) test this app on large amount of contacts (over 300, over 800 and even over 1000) - namely, whether the app lags on such loads;

2) provide the maps of keypad digits to characters in your own language (umlauts etc., if it doesn't use basic Latin or basic Cyrillic).

Thanks in advance!

Luxferre, BananaHackers group

[Luxferre]

A bit of an update: now, direct dialer has been added and longpress support implemented (for instance, contact deletion is now on lon-pressing # and you can enter + by long-pressing 0). See the updated README. Lots of things still are in the experimental phase but feel free to try on large amounts of contacts.

[PuriShnit]

Great project!!

Tried with 1300 contacts, takes 4.5 seconds to fully load.
-Much quicker than original contacts app.
-Can start searching before loading finishes - unlike the original contacts app.

How about caching the contacts into a .json file, wouldn't this load much quicker?

T9 search is really practical...
However, one has to type the full first name & a zero for space, then the last name, eg:
when searching for John smith, must do 5646076 to search for "John Sm...", can't just do 56076 "Jo Sm".

--
You received this message because you are subscribed to the Google Groups "comp.mobile.nokia.8110" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bananahacker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bananahackers/d1e9e4ff-4f9c-499d-82f7-c3067943b6b1n%40googlegroups.com.

[Luxferre]

Thanks a lot for the feedback! Yep, 4.5 seconds on 1300 contacts is fast but I want to make it faster, so need to identify which part is the bottleneck:

- loading from MozContacts DB;

- indexing for T9 search (more on that later);

- rendering in the DOM itself.

If it's a rendering problem (I hope there isn't), there's not much we can do if we want to keep the structure simple.

If it's a loading problem - yes, we can also track internal objects (like name, SIM origin and the original contact id from MozContacts DB) and only operate on a full MozContact object when editing or creating a new contact entry, or reloading the list after such an operation.

If it's an indexing problem, that's the easiest one to fix. Answering your question - the whole idea of the fast T9 indexing is basing it on a prefix key-value storage, so the best we can do is to not only index/search on the whole name, but also on the parts separated by whitespace. So that entering 76056 ("Sm Jo") will also find the contact named "John Smith".

For these last two, we must, however, also track the situation when a contact has been edited outside while the app was shut down completely and the contactchange event wasn't fired for an obvious reason.

I'll see what can be done next. Once again, thanks a lot.

[Daniel Haber]

This sounds like a game changer.  Thank you for working on this!

[Luxferre]

Thanks!

Another update - search index is now getting saved to DOM storage and updating only on contact creation/editing/deletion (or, if some contact had been modified outside the app while it was off, you can long-press on left softkey to force-reindex it). Also, as PuriShnit requested, you can now search by any whitespace-separated part of the contact name in any order.

[PuriShnit]

Installed new version.

-T9 search is now recognizing "Jo Sm", great!
-Loading is still taking 4.5 sec.

[Luxferre]

Refactored both the contact indexer and dynamic list renderer component. Tested with generated 2000 contacts + native 49 ones, the very first loading/reindexing (you can force-reindex by longpressing the Soft Left key) takes under 10 seconds on the Crosscall Core-S4, afterwards everything is fast. The only downside as of now is that full reindexing is also triggered on any contact change. Will implement a partial index sometime soon.

Also, now the Latin and Cyrillic support for the index is hugely extended for a lot of European languages (and even some non-European like Kazakh and Vietnamese), and Greek, Georgian and Armenian contact search is now also supported.

[Luxferre]

Implemented non-blocking reindexing after contact list modification. Now, search results are updated after reindexing is complete but you can use it unless it's the first launch or you have run the force-reindex procedure.

[Luxferre]

Now, instead of relying on longpresses for contact deletion or reindexing, FastContact has more traditional Options menu for both main and editor modes. These menus also allow fast selection with the digit keys.

Longpresses still remain a thing to enter pause and + characters in the dialer, for instance.

[joe-net]

Hi i tried the latest version on the nokia 8110 and nokia 6300 and dono why but the new version when i try to add a contact i cant put in a number (meaning that if i make it number mode i cant enter any numbers) only when i press each button few times to get to the number of that button, only then it comes up a number

[Luxferre]

Thanks for the report, will figure it out soon.

[Luxferre]

I have fixed this issue, now you can enter the numeric mode. But I still need to investigate why <input type="tel"> doesn't work on KaiOS properly.

On Tuesday, November 16, 2021 at 4:26:09 PM UTC+2 joe-net wrote:

[Luxferre]

Ok, now fixed refocusing issue fully. Please verify.

On Tuesday, November 16, 2021 at 4:26:09 PM UTC+2 joe-net wrote:

[joseph weiss]

#Luxferre

Thanks very much,

yes now it's working fine to input numbers.

(can't wait when all other apps will be replaced with faster ones)

--
You received this message because you are subscribed to a topic in the Google Groups "comp.mobile.nokia.8110" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bananahackers/F9sBwcS7qg4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bananahacker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bananahackers/3d8f6778-a179-47e3-ac87-310e793399ddn%40googlegroups.com.

[joe-net]

Just a little thing,

That when pressing the up button for long when in the fast-contact app it turns on/off the light in back

[Luxferre]

That's expected behavior. Like in old Nokias. Even described in the README.

[eliyahu desmond]

Hi

Here with a Nokia 6300, (2.5.4) and when I turn on the app it just says "indexing, please wait" forever

i have around 300 contacts in the phone's memory banks but typically with the standard contacts app it syncs in maybe 500 more...

Another thing to note is that it seems to have frozen the original contact app. If I restart the phone it does not help :(

[eliyahu desmond]

uninstalled the app. it seems to have totally bricked the contacts app :/

[eliyahu desmond]

Adding contacts is still possible through whatsapp, but any method to bring up the contact list just freezes the app...

[eliyahu desmond]

This might have to do with the fact that many of my contacts are in Hebrew...

[Dana C.]

Seems to be working well here! A couple of small notes though,

The highlighted contact always stays at the very top of the screen until you get to the bottom, I feel like it should go to either the very top or bottom or the second from the top or bottom entry on screen before it starts scrolling in either direction, if that makes sense.

Is there any possibility of having a configurable text size - and making the phone icon on the right of each entry smaller, so that there can be more entries on the screen? I feel like they could be maybe 2/3 the size they are now and it probably still wouldn't really be very crowded.

And is it possible to label numbers as "Mobile", "Home", "Work", etc.?

Maybe these features are already planned, but I just figured I would mention them. It is way faster than the stock app, especially when opening it. And I only have 25 contacts!

[Luxferre]

Thanks for the report. Yes, Hebrew, Arabic and other right-to-left language contact name indexing is out of support right now. Stay tuned, the support might be added some time later.

[Luxferre]

Mobile/Home/Work and other B2G contact types from the stock app will be added later, as well as configurable (via the KaiOS accessibility settings) font text size.

As for the contact source icon, please keep in mind that it can also be SIM1 and SIM2, and I plan on keeping them as large and informative as possible.

[Luxferre]

Also, when reporting any errors from FastContact or FastLog, please also post the error messages from WebIDE debug console, if there are any. It will make investigating the issues much easier.

[Dana C.]

Speaking of FastLog, I don't know if this should get its own thread or not, but I saw it linked from the GerdaOS announcement and thought I would try it out as well! I did find a couple things that don't seem to behave quite right -

The call type for me seems to be reported as outgoing_lte and incoming_lte, so I get a weird result shown like:

I found that I can add a couple if statements to initialRender() and set results[i].type to "outgoing" or "incoming" and that seems to fix the issue, though I'm sure this isn't the "correct" way to fix it:

  function initialRender() {

    var results = CallLogMgr.find(''), names = [], i, l = results.length

    var ctypes = ['sim1', 'sim2'], foundIds = []

    backendRecords = []

    fullIdCache = {}

    for(i=0;i<l;i++) {

      foundIds.push(results[i].id)

      backendRecords.push(results[i])

      fullIdCache[results[i].id] = i

      var contactNumberField = '', callMeta = getTimeStr(results[i].timestamp) + '&nbsp;' + getDateStr(results[i].timestamp)

      if(results[i].duration)

        callMeta += '&nbsp;' + getDurationStr(results[i].duration)

      if(results[i].type === 'outgoing_lte') {

        results[i].type = 'outgoing'

      } else if(results[i].type === 'incoming_lte') {

        results[i].type = 'incoming'

      }

      if(results[i].contactName)

        contactNumberField = '<span class="contact-number">' + escapeName(results[i].number) + '</span>'

      names.push('<span class="contact-' + ctypes[results[i].simId] + (results[i].blocked ? ' blocked' : '') + '" data-icon="call-' + results[i].type + '">'

        + '<span class="contact-name">' + escapeName(results[i].contactName || results[i].number) + '</span>'

        + contactNumberField + '<span class="call-meta">' + callMeta + '</span>'

        + '</span>')

    }

    mainList.render(names, true)

    mainList.update()

    return foundIds

  }

The other thing is that it isn't seeming to pick up on new calls until I manually reindex. I am completely closing the app every time I close it (long press "End Call"), maybe that has something to do with it?

One other thing, it seems it won't ignore a "+1" at the beginning of a phone number, so if the number in my contacts is, for example, (555)555-555, that doesn't match to a call coming in from +1(555)555-555 when it really should.

[Luxferre]

Dana, please verify the new FastLog version, it should be handling the types based on the direction, duration and hangUpLocal parameters instead of the unobvious type labels from the stock app.
As for the call picking up, yes, it should react on the telephony-call-ended system message. If it doesn't do this properly, please reboot the device (after installing the new version) and launch it the first thing afterwards.

As for +1cccxxxxxxx not matching cccxxxxxxx, this is strange, because that's why navigator.mozPhoneNumberService.fuzzyMatch method had been used to find an existing contact when a new log record is added. I had seen some internals of this method and it should work for +1 as long as you have US-based SIM.

I have tested this with our local numbers (0ccxxxxxxx vs +380ccxxxxxxx) and everything works as expected.

But obviosly, the most failproof way is to have all your contacts in the international format.

Also, which device are you testing all this on?

[joseph weiss]

About the Fast apps (contacts and log): for me it came out that i found my device torch on even without knowing that i pressed the up button for to long,

So i don't know if anyone had the same thoughts, but i would think that to take away the shortcut to turn on the torch (the up press) would be even much better as it gets on sometimes without knowing, as sometimes the button gets pressed a bit longer and before you know the torch is already on.

Thanks

You received this message because you are subscribed to the Google Groups "comp.mobile.nokia.8110" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bananahacker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bananahackers/2b296997-dee6-4272-8fda-da8b71a0401bn%40googlegroups.com.

[Luxferre]

Ok, it was conceived as some Easter-egg or convenience feature, but if it's uncomfortable, I'll reassign the shortcut to some other key (probably #) on the next significant update.

[Dana Conrad]

Thanks for the changes Luxferre, it does seem to be showing the icons correctly now! I’m on an Alcatel 4052 (Smartflip).

If I start the app and then dial a number, the call does successfully get added into the list, but it will not get added in if it is not running in the background. If the app is not running in the background, then it needs to be manually re-indexed when it’s next opened. I’m not sure if that’s the intended/expected behavior?

It looks like the fuzzyMatch works for calls that come in while the app is in the background, but not for calls that are found by manually reindexing. I can have the same person whose entries already found by manual reindex (but the phone does not find the contact to display a name) call me and the contact name shows up OK, but only for the new call. So perhaps the reindexing needs to run through the fuzzyMatch method? It seems that any action that forces a reindex (such as attempting to delete a call) actually breaks these entries - they no longer show the contact name.

I’ve also found that the app is not capable of finding calls at all unless the phone is rebooted after installation. It does work after updating to a newer build without a reboot, but not after a fresh install. Is this expected?

It also does not seem to be able to successfully delete calls from the log. Unfortunately the WebIDE console isn’t showing any output so I’m not sure what’s going on there.

As a sidenote, the weird scrolling behavior mentioned already for FastContact is present here as well. I remember finding what seemed to be a CSS solution for that when I was messing with a kai 1.0 phone, but I for the life of me I can’t remember what it was...

I think that’s the extent of the bugs I’ve found. Great work!

To view this discussion on the web visit https://groups.google.com/d/msgid/bananahackers/2b296997-dee6-4272-8fda-da8b71a0401bn%40googlegroups.com.

[Dana C.]

> If I start the app and then dial a number, the call does successfully get added into the list, but it will not get added in if it is not running in the background. If the app is not running in the background, then it needs to be manually re-indexed when it’s next opened. I’m not sure if that’s the intended/expected behavior?

Just wanted to clarify this a bit, I mean that if I start the app and then go back to the home screen with a short press of end call, calls get added to the list like they should. So, the app needs to be running in the background.

[Luxferre]

Computational complexity. This is why fuzzyMatch against existing contacts can only be done on the record adding. Otherwise the reindexing will take virtually forever even on modest 200 records * 200 contacts.

The reason why the search result gets rewrittten or records don't seem to get deleted is that the usual reindexing imports the existing records from the stock call log first. I'm going to fully decouple the FastLog storage from the stock one with a menu option to one-time import the existing records. That would be fair and fix a lot of speed and stability issues. And since it's aimed for future GerdaOS release where it will be the only preinstalled call log app, this move would make even more sense.

As for the list scrolling logic... sorry, for now it's going to stay the same. At least this is the fastest (in terms of performance and optimization for thousands of items) implementation of DynaList I could think of. Maybe it will change in some future but for now there are more fundamental things to work on.

Anyway, I'll notify when these changes are in place for FastLog. And will probably create an official announcement thread for it.

[Luxferre]

Also, stock records don't get imported unless the app is launched first after reboot or deep memory cleanup. This happens because of some bug in KaiOS that doesn't allow the stock calllog datastore to be properly readable until the B2G restart. There's absolutely nothing we can do about that except not use the stock log unless one-time importing.

[Dana C.]

Sounds good on all counts. Regarding not picking up on new calls unless the app is running in the background (or manually reindexed), is that the same situation where it can't really be fixed until it's integrated into GerdaOS?

[Luxferre]

I have found the root cause, it has something to do with how message handling works in KaiOS. Fixed in the most recent version. You can test it now. Also made external log entry imports a completely separate thing in the menu.

[Dana C.]

Something buggy in KaiOS... Who would have thought?? :-P

It looks like it's working really well now - it pulls in new entries whether or not it's running in the background, the fuzzy number matching seems to be working 100%, and I can delete entries!

Thanks for the fixes! One more question for my own curiosity, I presume the stock application will need to be retained in order to clean out kai's logged calls from time to time - no way to do that now that FastLog has its own internal index of calls, right?

[Dana C.]

Another suggestion - maybe the "Call log Reindexed" toast message is unnecessary. It sits at the top of the screen for a long time, obscuring the first entry for about 3 whole seconds when you start the app or manually reindex. The large "Reindexing please wait..." text already let us know that we reindexed, anyway.

[Dana C.]

Actually, that's true for the contacts app as well, I just noticed. It obscures the first entry for 3 seconds there as well!

[Luxferre]

FastContact has been updated to 0.1.7 with three fixes:

1) the case when only SIM2 is active is now handled correctly;

2) the older 2-parameter MozTelephony API (Nokia 8110 4G and older) to dial the numbers is now called correctly in case the current 4-parameter one is unavailable;

3) long contact names are now auto-truncated with ellipsis.

[M.A.U Arari]

Make a fast gallery  it is very helpful.