I am redesigning the search interface for my Android App. I've red Google's API guide (http://developer.android.com/guide/topics/search/search-dialog.html).
The current version of the app uses the classic system search dialog. It lacks autocompletion which I want to provide in the new version.
My requirements in terms of auto-completion: If the query string is less than 3 characters, the app should auto-suggest search results based on the set of stored favorites which are stored locally. If the query consists of at least 3 characters, the search shall be conducted remotely via a search API.
Since historically, the App's minimum API will be level 7, I cannot use Honeycomb's SearchView (API 11+) or ActionBarSherlock SearchView (API 8+). I decided to stick with search dialog provided by the SearchManager.
I've sucessfully implemented all requirements stated above.
Though, one thing reduces the usability.
When the user starts the search, the search dialog gains focus. The desired behaviour is that instantly, all favorites are suggested. Though, this is only true on my HTC Legend running Froyo (2.2). On my Galaxy Nexus, the app most of the times does not instantly show all suggestions. I get callbacks to my SearchProvider not until the user has entered at least one character.
My question: is there a way to instantly show suggestions/get a callback to the SearchProvider across all Android versions starting API 7+?
I've tried different calls to the SearchManager (startSearch()) but with no luck.
Related
Should the (title of various android/ios screens, labels of various form-controls) be hardcoded in android/ios apps OR such data should be brought from the API responsei?
Most of the page/section-of-page has a title. In form with textbox/combo box, we have labels for each of these controls as well. Should such UI information be hard-coded OR brought from the API?
Few questions here:
Pros of having all this hard-coded on android/ios apps: Clean and light weight API data. APIs will carry only the data part and not the user-interface elements like title, labels etc. This would save bandwidth and make APIs bit fast.
Cons of having all this hard-coded on android/ios apps: If we want to change these title, labels in future, we can only do that on the newer version. All previous app version will continue to show the old title/labels only. If we had brought this data from APIs, we can change these anytime across all the versions.
Which is correct approach? Or should we decide this based on the fact if titles/labels can change in future and they need to be changed for all app versions, if this is the case, then it should be in API otherwise they could be hard coded?
Can Apps use firebase to get such information and change it in previous app versions too?
It would probably not be a very good user experience to populate all of the UI elements from API calls without at least having some hardcoded defaults in place to allow the user to initially navigate within the app without waiting for the API calls to retrieve information. Also, if you try to create an app using this server-side UI design you probably want to use mostly web components and possibly even serve up the html to the app because there can be a mismatch between the content (i.e. the text for the labels, buttons, and text fields) and the UI elements themselves. For example, imagine a segmented control that initially was designed to only accommodate two options ("Home" and "Work") and then later an additional text option is added to the list ("Home," "Work" and "Gym").
I'm looking to make an app that adds a bunch of words to the users dictionary.
I know I can use UserDictionary.Words.AddWords however it is not actually adding the words to the dictionary.
It looks like "WRITE_USER_DICTIONARY" permission was removed in M, is there a different way to add words to a users dictionary or is that completely gone now?
UserDictionary.Words can no longer be accessed from Marshmallow (API 23) onwards.
Reference : Android Issue Tracker - Issue 199199
The user dictionary is now accessible only by the current spellchecker and keyboard. It was heavily abused by apps to scoop user dictionary. Out of the ten top apps using it there wasn't a single legit one. My favorite was the one which used a bug in keyguard to unlock the device after [it] "scans" [your] fingerprint from the screen! This is intended behavior.
it is hard to search for what i want because i have no idea what it is called so i do not know how exactly to ask this.
i want to make the user to choose numbers just like this in my application.
for example i put 3 of those and i set a certain number of values for each (for example from 0 to 22 in the first, from 5 to 40 in the second and 0 to 60 in third). and later the user chooses his values and when submitting the app reacts considering his choices.
thanks
That widget that you're looking for is called a 'Number Picker' and you can find more info about it here.
Android has a native implementation for a widget like this, it's called NumberPicker.
However, it was added alongside API 11 (3.0 or Honeycomb). So it might give you trouble if you want to support older Android versions. As an aternative, this library will help you if you're planning to support older APIs, it has been tested and confirmed working down to API 7 (2.1 or Eclair).
As a bonus, you could also give BetterPicker library a shot - it supports many kind of beautiful and customizable pickers.
I have been doing some research on the upgrading my app (android:maxSdkVersion = “10”) to Honeycomb and would like some advice.
First, one of the activities in my application is a List Activity. Once the user selects an item from the listview, a new activity/layout starts that gives information about the item selected from the listview. The user must then back out of the info screen to get back to the listview. (Simple)
If I move this application to Honeycomb, then I can use Fragments. Using Fragments, I can use both of the above mentioned activities on the screen at once.
Now the dilemma. If I use Fragments to get the functionality I would like, but then I will have to use the Android Compatibility library in order for my FROYO users to use the application. And by using the Android Compatibility library I will bind my application to a lower level of honeycomb OS.
So, if I want to continue upgrading my application past ICE CREAM, then the best thing to do might be to create one application that remains maxSdkVersion = “10” and a second application using minSdkVersion=”11”.
So, for a paid app, users will have to buy two versions of the application?
What am I missing here?
Thanks in advance!
So, for a paid app, users will have to buy two versions of the
application?
If you are using Google Market then, no, you can upload multiple apks and target different configurations using some constraints.
You can read this post from the official android dev blog
I have uploaded an application in Android market. But when I search for the app the app do not appear in the autocomplete box which appears below the search box.
For example, if I type "h" in the search box the autocomplete box will have the applications with "h". But in my case I need to type the complete name of the application.
Why is it so? Is there something that I am missing.
For my phone, HTC Magic Android 1.6 it doesn't dynamically search the market as I type. You have to type something then hit enter/search and it will find it. Just like using Google.
It does however dynamically show my recent search entries. So if I start type "h" it will show my recent keywords I used to search starting with "h".
I don't know if this goes for newer versions of Android....