[KnownUsernameField] Engine update (make the system more flexible)

[contribucious]

CONTEXT: This is an update of this new system (system allowing "user ID" field detection — i.e. email/username/phone/whatever — without "password" field using the accessibility service).

UPDATED: Engine.
↪️ Prerequisite for my next PR which concerns the entries.

---

 
This:

• allows to have multiple pairs "path / username view ID" per domain;

• adds more advanced path support:

  • in its case-sensitive version: startswith:string, contains:string, endswith:string and
  • in its case-insensitive version: istartswith:string, icontains:string, iendswith:string.
     

💡 About using StringComparison.Ordinal and StringComparison.OrdinalIgnoreCase, this is recommended for a variety of reasons including better performance. See the page Best Practices for Using Strings in .NET from Microsoft documentation.
 
 

[contribucious]

When you have some time @mportune-bw, could you take a look at this slight update of your system?

My next PR is already ready @ local side (big update of entries).
This one being only a required preamble. 👍

Thanks!

[cscharf]

@contribucious , is there a chance you can refactor a little bit using Tuples or actual types vs. multidimensional arrays (string[,]) for Access Options in the KnownUsernameField class? That way it can be explicit on how those dimensions are to be defined and used (code as documentation). It seems as if the only the first value of each dimension of the array is being used, explicitly, which feels more like a Tuple, Dictionary, etc.

[contribucious]

Hello @cscharf,

Sorry for the delay.

You are right. Is it better now?
 

Note: Compiles successfully and is functional in practice (APK installed and tested).

[contribucious]

@cscharf Is last week's change OK for you?

[cscharf]

Just one question/open comment and then yes, we should be good.

[cscharf]

Awesome, thanks!

[contribucious]

You're welcome. 👍