Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>you <em>could</em> query your server's database of users with the currently entered username on every keypress event for the specified input component(<code>EditText</code>, etc), but that might be pretty network intensive and spawn a lot of threads to handle:</p> <ol> <li>add a <code>TextWatcher</code> to your input <code>EditText</code> or whatever the user is entering his name into</li> <li>in the <code>onTextChanged</code> method, you would spawn a thread to contact your database sending along the <code>CharSequence</code> value. the response from your server would output some JSON perhaps with a boolean property which says if the username is available or not</li> <li>user hits "ok" and expects their name to be registered for themself. a final check needs to be made before they actually get this nickname, as the availability may have changed since(say a ton of people are registering all at once)</li> </ol> <p>or... </p> <ol> <li>let the user type in their desired name</li> <li>let them hit "save" or "register"</li> <li>at this point, send along the registration data and save it in the database if their name is available. otherwise, let the user know that it isn't and they must try again</li> </ol> <p>or...</p> <p>when you app starts(right before they must pick a name), contact your server's database and send the app a response holding a list of names that are already taken.</p> <p>this way, you can easily check if the name is taken locally on the phone rather then sending off a request to check. </p> <p>you must still always check the availability of the nickname right before saving it on the server side</p> <p>edit: I've implemented #2, which seems like that's what the majority of apps do for registering a unique name(that ive seen)</p> <p>problem with #1 - user enters in 1 letter(network thread started) - user enteres another letter(another thread started) - user enters a 3rd letter(another thread) - thread 2 finishes first, name is valid, user is notified - thread 1 finishes, name is invalid, user is notified - thread 3 finishes, name is invalid, user is notified</p> <p>thread 2 took 4 seconds thread 1 took 5 seconds thread 3 took 5 seconds</p> <p>say user keeps typing for 25 letters, there is a lot you have to keep track of in terms if the name is valid or not, if and what threads are still running, etc</p> <p>this approach seems a bit too tedious for such a simple registration task, too much hassle</p> <p>problem with #3 - requires 1 extra network request to the server</p> <p>i like this approach because you can easily and quickly notify the user if their name is available without any threading(depending how large your user list is) or worrying about how long it will take to check</p> <p>number 2 is simple, easy, and can have the chance to only require 1 server request</p>
    singulars
    1. This table or related slice is empty.
    1. POAndroid - Ajax style auto check of username availability
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USbinnyb
    1. USbinnyb
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAndroid - Ajax style auto check of username availability
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COthanks a lot for your answer. You have pretty much listed out all the choice I have. You are right about the first one. This is the pretty network intensive one. But out of second and third which one is better. Have you ever implemented this kind of functionality. If yes, can you please elaborate more on the performance issue. Thanks again.
      singulars
      1. PO
      1. USSaKet
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload