I would like any suggestions on how to implement a fast autocomplete search box on android.
Useful info:
1) Data will be stored locally on phone memory. No database or network should be needed.
2) There is no restriction on the type of file that will be used. Could be simple text file, XML file, or whatever suits best.
3) The file will contain a large amount of records that are distinguished by a unique ID/CODE.
There will be also a human readable name for the record and a text with more info on the record like
CODE: HUMAN_REPRESENTATION: EXTRA_INFO:
AF32 Orange The orange (specifically, the sweet orange) is the fruit of the citrus species Citrus...
AF33 Apple The apple is the pomaceous fruit of the apple tree...
4) The user will type on the text area the HUMAN_REPRESENTATION string he wants, and he will be shown a list of matching records to select of.
5) While typing he should be given auto-complete suggestions so he would not have to type the exact phrase.
6) The amount of records will be about 15,000.
So which is the best way to store and retrieve data as fast as possible?
What file type would you suggest? Should the data be split into many files? Can I use a specific API?
I would really be thankful for any directions here, as I am new in android development, but experienced in desktop applications.
EDIT :
Since I had no answers in many days, I would like to know if my question is not clear enough or if it has already been answered. Please comment.
Related
I want to add words to android keyboard dictionary programmatically.
Am I correct to assume that speech to text will for a certain word will improve if it is in dictionary
How many words can I add in dictionary 1000, 10,000 or 100,000, is there any offical limit around size of dictionary (in MB)
You are right. If the system knows how the word is written correctly it will then match the spoken word more exactly. Otherwise it will search between the existing words and probably takes something wrong. But the algorithm is allready really strong and precise.
There is no exact number or limit (nothing published officially). It depends on the device storage. But I did a research and will provide it to you:
Way to store a large dictionary
How to achieve a little dictionary
Hope that answers your questions a bit. Cheers! :)
I am making a framework in order to easily "appify" books.
This framework will need to automatically detect chapter and heading to make a table of contents. The idea is to also be able to easily search through the text and find what you are looking for.
Now what I still need to figure out is:
how to store the data in such a way that I can easily detect the chapters and heading
and still be able to search through the text.
The text that is stored needs to be formatted, so I thought I would store them as HTML or Markdown (which will be translated to HTML). I don't think it would be very searchable if the text is in HTML.
P.S. it does not have to be HTML if there are other more efficient ways to format the text.
Do you really want to do such thing on the device itself?
I can suggest you to use separate sqlite database for every book. With separate tables for table of contents, chapters, summarized keywords of chapters(for faster search) and other service info.
Also here you can find full text search example
Also I recommend you to bring your own sqlite build with your app.
Now lets talk about the main problem of yours - the book scraping.
I have no competency here, I believe this problem is the same as the web sites scraping.
Upd:
Please do not store book contents as HTML, you can store it as markdown for example, it takes less amount of storage, easier to sanitize and you can always apply your styles later
The question is based on using the ODK Collect on an Android platform:
I am working with multiple choice questions type where the choices are being sourced from a .csv file. Thus far it is a standard ODK procedure, however, I want to include a string search option in the question due to the large number of options in the .csv. The string search is to reduce the number of choices the participant has to go through, and hence the search needs to be performed multiple times.
What is the best way to go about this?
My thoughts so far: Work with the ODK Collect source code to "inject" a string search option into the respective activity windows.
You can use the search function in the "appearance column", and example is given below
search('locationset','matches','countryid',1)
where locationset is the name of csv file, and countryid is a column in the csv, 1 is the value that i want it to search
I've attached an image of a form, to have a better idea. Hope this helps
What I want to do:
display a text box as an input field, which will accept a city name (any city throughout the world)
as the user starts typing, I'll auto-(complete/suggest) city names.
when the user selects a city name from the dropdown, the name appears in the text box as well, and the background gets highlighted to a very light blue.
Is there any existing widget that does this? If not, what would be a good way to auto-(complete/suggest) city names?
Edit: I know AutoCompleteTextView does autocompletes. The problem is more about dealing with an exhaustive datasource of cities (hopefully available as an API online somewhere), and connecting the widget with this list of datasource.
As you already pointed out yourself, a widget as described could be fairly easily built using standard components in the Android SDK, with the main one being an AutoCompleteTextView. In terms of "where to get the city data from", you basically have two options:
Bundle the data with the app.
Use a webservice.
Both obviously have their pros and cons. Bundling the data will blow up your APK size, a lot, whereas webservices are usually subject to a courtesy limit. Whichever option is the 'best', will depend on several factors, including the size of your app's userbase.
Some concrete resources for bundling the data:
MaxMind's Free World Cities Database (33MB)
GeoNames (233MB!)
And webservices:
GeoNames (cc-by licence, 30k requests/day, 2k requests/hr).
Google Places API - Autocomplete (1k requests/day, or 100k requests/day if you verify your identity with Google, or try your luck and request a higher courtesy quota)
Note that these lists are by no means exhaustive - I'm sure there are plenty of other options. They should offer you a decent starting point though.
You could try the AutoCompleteTextView class
http://developer.android.com/reference/android/widget/AutoCompleteTextView.html
I guess what you are looking for is something similar to Typeahead address picker.
https://github.com/sgruhier/typeahead-addresspicker
It can both recommend autocomplete while you type, and use a map to select/show the address. Looks good :)
What I have is an app that displays some documents. In the string resources I have the documents divided into smaller pieces in anticipation of making them searchable. Think of them like newspapers with a number of articles where each article is a separate string resource. There will not be any storing of user input (unless I decide to store recent searches). In the search part of the android developer docs it mentions this but says it is not going to go into details of how to store and search data just how to use the search dialog and widget.
What kind of storage of my data should I be using. Is simple string resources good? should I look into a real databasing? which of these make it the most efficient and quickest to search? I'm new to android so any help would be appreciated.
answer:using android's built in sqlite database system and FTS3 tables.
I would definitely use a database for this.
Read all the documents and link each word to each document in a database.
A word search would then produce a list of documents containing this word quickly.
Make sure you reindex each time you add and remove a document.
By the way, you should see to improving your accept rate.
Also, this is problably not a Android question.