I'm trying to implement search into my app and have trouble understanding the difference between these two methods. Why is it that we have to define a search configuration (described here: http://developer.android.com/guide/topics/search/search-dialog.html), add a bunch of meta-data to the manifest, and have a separate activity just for search, when we can treat it like any other TextView, grab it's text, and query the database with that? Is there any advantage to the former method, or any disadvantage to the latter? In my mind directly getting the text and doing my own stuff off of that seems a lot easier, especially when after dealing with the search interface I'll still need to get the query from the intent and perform the actual search with that. Am I missing something here? Thanks!
Here's what I mean by directly getting the search query (without using the search interface):
#Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
super.onCreateOptionsMenu(menu, inflater);
MenuItem search = menu.findItem(R.id.action_search);
SearchView searchView = (SearchView) search.getActionView();
searchView.setOnQueryTextListener(new SearchView.OnQueryTextListener() {
#Override
public boolean onQueryTextSubmit(String query) {
// Do stuff with query
return true;
}
#Override
public boolean onQueryTextChange(String newText) {
// Do stuff with newText
return true;
}
});
}
You have few advantages in working with the "standard" searching feature:
The search will look as the user is use to have is "search" boxes on any device. If you design something this will be for all devices. I love to be in the "standard" because in this way for the users is very simple to use it and compatibility over devices is much wider
Activity Life Cycle : see here. This a huge advantage.
If the Look & Feel fit's with your design you have a lot of other features that are available and checked and working and almost bugles.
Daniel
Related
In a project I have 3 Actors and 5 Use cases.I want to regulate Actors access to entities based on their roles(RBAC).Also all Actors see the same UI,but some UI controls are disabled for each actor according to his/her Role.I can use If statements to decide specific control must be enabled for current Actor or disabled? For example:
If (User.Roles(...))
{
btnEditOrder.enabled = false;
}
That is possible,but UI is complex and each layout has many UI controls.So managing all these possible options and hard-code that logic in the application seems daunting.Specially, number of use cases,actors and their permissions may change later.Do you know how I can avoid hard-code such logic and have a good design?
IMHO it would be good to create separate menu.xml files for each role.
Let's say you make separate menu.xml files namely:
options_menu_manager.xml
options_menu_engineer.xml
options_menu_director.xml
You will need to make a Helper class around it. I am assuming you have the role already in the memory, you can do something like:
class Helper{
public static int getOptionsMenu(){
switch(Global.role){
case Constants.MANAGER:
return R.menu.options_menu_manager.xml;
...
...
}
}
}
and wherever you need to get the menus, you can use a helper function instead of using a R.menu.* file.
#Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(Helper.getOptionsMenu(), menu);
return true;
}
Although, this is just a way of getting ROLE based menu. You should still have a good background validation of the authorization of all the performed actions. For that also you can create a helper that matches the current user's role against the allowed actions to see if he is allowed to do what he is doing or not.
Beginner here, targetting sdk v14 and v17 for my learning...no need for older support.
I am using the master/detail template and trying to get an action menu (for SEARCH) to show up both in phone and tablet view. Actually I can get it to work, but I have to duplicate up my code in both ItemDetailActivity.java and ItemListActivity.java
These are the methods that I have to have in both for SEARCH to work:
public boolean onQueryTextChange(String newText) {
public boolean onQueryTextSubmit (String query) {
public boolean onClose () {
I only want to search the "detail", not the "list".
So my question: is there a way to associate the action bar with only the list fragment? That way I can keep the search functions in 1 file.
Thanks!
I'll go ahead and answer what I (think) I know as I don't want to leave this question open.
From tracing in the debugger, it looks to me like the phone activity and the tablet activity are separate and if you want to hook up an actionmenu, you have to hook it up to both separately.
My android application targets the latest platform. I am new to the platform, and read bit conflicting information on actionbar. The way I was using it for navigation was.
menu.xml
<menu>
<item android:id="#+id/action_sort_size"
android:icon="#android:drawable/ic_menu_sort_by_size"
android:title="#string/action_barabc"
android:onClick="abc" />
<item android:id="#+id/action_sort_alpha"
....
In my activity
#Override
public boolean onCreateOptionsMenu(Menu menu) {
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
public void abc(MenuItem item) {
//...
}
this works, but the back/up navigation is not working correctly. could be unrelated, still like to confirm.
But, I also see implementation like here
where it switches on item.
#Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case R.id.menuitem1:
Toast.makeText(this, "Menu Item 1 selected", Toast.LENGTH_SHORT)
.show();
break;
case R.id.menuitem2:
....
}
Which is the better approach?
The better approach, in my opinion, is the switch approach. There aren't many reasons why, but I'll list them:
The code is centralized. You don't have x amount of methods that basically do the same thing. It keeps your code more readable; it is "cleaner". You also get a default statement using the switch, this can help if you mess up and forget to make a case specifically for an element in the layout.
If you really wanted to have a centralized method using xml, you would have onClick reference the same method and check the ids of the View parameter. Which is essentially the same asonOptionsItemSelected.
It is a part of the API. The Android engineers would not have made it a part of the API if they didn't want the developer to use it. Yes the XML is techinally API, but XML should be used more for layouts and visuals, not for logic.
Everyone uses it. All the tutorials I have seen and everyone's code uses this method. It is now more of a convention.
It's largely personal, but if it looks like it's a convention, and everyone uses it, I'd adhere to it. Especially if you're working as part of a team. Different coding styles for such arbritrary things should be avoided.
And concerning your back/up navigation, it shouldn't make a difference which way you do it, since you have to implement the same code to get that navigation type.
Hello Android developers,
I've got a problem with the Android SearchView widget. What I'm trying to do is to attach a "live" text filter to my ListView (text input automatically refreshes filter results). It works actually fine and it was no huge effort to get it working on my ListActivity with these lines:
private SearchView listFilter;
this.listFilter = (SearchView) findViewById(R.id.listFilter);
this.listFilter.setOnQueryTextListener(this);
this.listFilter.setSubmitButtonEnabled(false);
this.getListView().setOnItemClickListener(this);
this.getListView().setTextFilterEnabled(true);
// from OnQueryTextListener
public boolean onQueryTextChange(String newText) {
if (newText.isEmpty()) {
this.getListView().clearTextFilter();
} else {
this.getListView().setFilterText(newText);
}
return true;
}
And here the xml widget declaration
<SearchView
android:id="#+id/listFilter"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:iconifiedByDefault="false"
android:queryHint="enter text to filter" />
Now what my problem is that every time I enter text into the SearchView, a strange text field pops up instantly showing the same text as I just entered which is kind of useless since I can see my input in the SearchView itself and it partly blocks the sight on my list entries, which is just annoying.
Is there any way to prevent that text field from popping up on typing into the SearchView? I couldn't find any property neither on the xml defined widget options nor on the java class reference.
I know there is another way to provide the filter functionality by using EditText and TextWatcher, but then I have to handle the filtering all by myself and couldn't profit from the SearchView handling it for me.
Any suggestions are appreciated.
Best regards
Felix
i found out how to get rid of that ugly popup window. The trick is to work with filter directly.The code below assumes you have implemented filterable in your customAdapter.
public boolean onQueryTextChange(String newText) {
if (TextUtils.isEmpty(newText)) {
m_listView.clearTextFilter();
} else {
ContactsAdapter ca = (ContactsAdapter)lv.getAdapter();
ca.getFilter().filter(newText);
//following line was causing the ugly popup window.
//m_listView.setFilterText(newText);
}
return true;
}
I realise this is a specific problem however I feel like others who are dealing with compatibility must have dealt with this.
As the user swipes through various fragments in the ViewPager I would also like the actionBar menu items to change. I am not sure if this is easily doable for the compatibility actionbar, any direction or help would be extremely appreciated. I am changing the title simply via setTitle() since the ActionBarHelper handles this however i cant find anything for updating the menu items. I tried the following but it fails..
public void setMenuDynamically(int resId){
MenuInflater menuInflater = getMenuInflater();
menuInflater.inflate(resId, menu);
}
Looking through the code it seems there should be an easy/obvious way to get a handle to the SimpleMenu and add an item and set its icon.
Thanks in advance ( I am hoping the google boys are reading this as the android developers Google+ suggests)
Ok well please let me know if I suck as describing things or if there just is not much knowledge on this topic. If the first I am really sorry guys. Regardless I seemed to get this to work but am unsure if this is the correct way.
AcitonBarHelper
public void updateMenu(MenuItem item) {
}
ActionBarHelperBase (for 2.2 - 3.0 devices )
#Override
public void updateMenu(MenuItem item){
addActionItemCompatFromMenuItem(item);
}
And create similar methods for honeycomb and ICS
finally i have a listener for page changing and in that listener i call...
public void setMenuDynamically(int resId, String title){
MenuItem item = menu.add(title);
item.setIcon(resId);
getActionBarHelper().updateMenu(item);
MenuItemCompat.setShowAsAction(item, MenuItemCompat.SHOW_AS_ACTION_ALWAYS);
}
I am not sure if the MenuItemCompat is necessary but I included it nonetheless. Everything seems to work great for 2.2 at least. I will most likely have to make changes in the Overrides but I can handle myself from here.