It may happen you would need to clear your all of your SharedPreferences without knowing in advance their keys.
This can happen when you are writing tests: you don’t want your production code to publicly expose your SharedPreferenceskeys neither you need a clear() method, so you didn’t implement it. You may also need to clear third party SharedPreferences to which you don’t have direct access.
Without changing your production code there is something you can do:
access the app SharedPreferences folder
get the SharedPreferences editor for each file
clear the SharedPreferences
You can use the following code, called in a @BeforeEach annotated method, to be sure each of your tests will run in a clean environment.
Writing an Annotation Processor in Java/Kotlin is a very interesting task and debugging comes very handy, but unfortunately it seems not so easy to start a debug session.
The following information are valid for Android Studio 3.6.3 and Kotlin 1.3.71. Gradle is the build tool used for the project.
First thing to do is setup a new Run/Debug Configuration in Android Studio:
Choose Run from the main menu
Choose Edit Configurations
Now click on the + symbol in the top left corner to add a new Configuration
Choose Remote from the list
Give it a friendly name (e.g. AnnotationProcessorDebugger)
Setup your breakpoints wherever you need them and then run this command from the terminal:
Replace APP_MODULE_NAME with the name of the module having annotations which you want to debug. You will see the process will start and suddenly stop on > Starting Daemon waiting for you to do something.
Now, click on the Debug icon in the Toolbar (having selected the previously created AnnotationProcessorDebugger configuration) and the debugger will hit your breakpoints!
Additional info:
The clean task seems to be necessary.
Unfortunately, sometimes these steps are not enough, or simply don’t work, the debugger won’t hit your breakpoints. I see somebody else solved the issue after adding the following line to their gradle.properties file.
In the last few weeks the new Android Auto UI is being released by Google but it’s not yet available for everyone. There are some tricks you can use to force enable it before Google releases it to everyone.
It works on my OP6 running Android Pie, but those commands need to be executed each time I want to use the new Android Auto UI, otherwise I see the old one.
To overcome this little issue I made a Tasker profile to automatically run those commands when the smartphone is connected to a power source, so they are executed before Android Auto starts.
Here the Tasker profile! Just import it in your Tasker and enjoy the new Android Auto UI!
Reading this post you will be able to create your smart car’s on-board computer, for example you will be to able to ask your Google Assistant (from your device or from an Android Auto head unit) the temperature of your car’s coolant liquid! Woa!
What do you need:
an Android device (with Google Assistant or Android Auto since your going to use this in your car)
Thanks to Join, a new app from joaomgcd, you can create a URL to push information to your devices in a very easy and powerful way! Read his well written tutorial here and you will be able to generate a URL to use in the Webhook thataction of IFTTT.
As reference, I’d like to report the old way of doing this, so everyone can read it and understand how much Join has simplified and improved this process!
TASKER AND TORQUE INTEGRATION
Now, you will need to make Taskerable to read your car’s data using Torque. To accomplish this, open Torqueand set it up to log your car’s data to a file on your sdcard (you can do it making changes in the Settings – Data Logging and Upload section)
Now Taskerwill be able to read your car’s data reading that log file using the following task which you could import into it.
This task will check for that log file on your external memory and:
if it founds it, it make your speakers say the last engine coolant temperature read by Torque
if it doesn’t found it, it make your speakers say there is no connection between Torqueand you car ECU (your OBD2 adapter).
Another task that you will need is one that deletes that log file when the Torqueapp closes, so the next time you ask Taskerto read that file your are sure the data is new, and if there is no file, a new connection with your car wasn’t established.
GOOGLE ASSISTANT AND IFTTT AND TASKER AND TORQUE INTEGRATION
Now the last part! We have all the pieces, let’s put them together!
Login to IFTTTand create a new applet!
Click on this and look for Google Assistant, then click on it. Select the Say a simple phrase trigger and write your custom question(s) and response; click then on Create trigger
Click now on that and look for Webhooks, then click on it. Select the Make a web request actionand use the URL you generated as explained in the joaomgcd’s tutorial. Click on Create action, then on Finish and your recipe is ready!
Open your Google Assistant and say the phrase you just put in the IFTTTrecipe, your device should say you’re not connected to the ECU, you got the push notification, that’s great!
Now go to your car, turn it on, make Torquepair with your OBD2 adapter…. when it’s ready ask Google Assistant again to read your engine coolant temperature and now you should hear it! Wonderful, it works!!!
FURTHER IMPROVEMENTS OF YOUR SMART CAR
The recipe on IFTTTand the task on Taskercould be improved by using parameters and so making you able to ask for and listen to different details of your car, which could now be called a smart car!
AndroidAutoAlerts is a very simple app for Android Auto I have developed to test my Android Auto unit. Please read through the article to check it out!
What it does and how it works
As I said, the app is very simple and at the moment it has only one functionality: it will notify the driver if the speed limit is exceeded. Wow!
The driver can set the maximum speed limit through the app’s settings (you can also choose the name of your virtual assistant!)
Then, go back to the main screen and start the notification service. A service will run (and will keep running in the foreground using a system notification when you exit the app or attach your device to your Android Auto unit).
So, now, using the speed taken from the GPS sensor, when the app catches you going faster a notification will be displayed on your Android Auto unit from your virtual assistant! Tap it and listen to what it has to say to you! Please slow down, you have exceeded your speed limit!!
Where to get it
At the moment, the app is not following all of the Android Auto requirements (see them here) and Google only allows music and messaging Android Auto apps. For this reason I had to create the notification like a messaging app, like you are going to reply to it, even if you are not. Furthermore, I’m not going to publish it on Google Play at the moment (till apps of this kink will be accepted on it), but you can check its source code which I shared here on github.
Future development
Let’s wait for Google to accept other kinds of apps on the Android Auto platform and let’s hope this platform will become more and more interactive, full of useful apps (maybe some which can control car’s features, would be amazing!) and used by more and more people! I already love it, can’t live without it!
In this post you will learn how to implement a Contextual Action Bar (CAB) which will be useful to do actions on multiple items you have selected in a RecyclerView.
The Contextual Action Mode represents a contextual mode of the user interface and focuses user interaction toward performing contextual actions. In the case of a RecyclerView which shows a list of item, Contextual Action Mode is triggered after a long press on one of this items: this causes the Contextual Action Bar to appear at the top of the screen so then the user can interact with its actions.
Let’s follow these steps!
Initial setup
First of all, create a RecyclerView and its adapter in the usual way you do it. Here in this example I will use a RecyclerView which shows Authentication items (it is a class I made for a project, it doesn’t matter for the purpose of the example, use whatever you want, and change the names accordingly).
Theme changes
Open your styles.xml file and add the following lines:
<!-- It should be true otherwise action mode will not overlay toolbar -->
<item name="windowActionModeOverlay">true</item>
<!-- For Custom Action Mode Background Color/Drawable -->
<item name="actionModeBackground">@color/colorAccent</item>
Comments should be self-explanatory.
Menu file
We need a menu file which contains the available actions for that RecyclerView. Let’s create a file into the res/menu directory like the following:
We added a delete action that will be shown on the CAB.
Adapter changes
Our adapter we created in the first step needs to be able to keep trace of the elements we select. To do this, let’s modify our adapter and create a new field
private final SparseBooleanArray selectedItemsIds;
and initialize it in our constructor
selectedItemsIds = new SparseBooleanArray();
Now, let’s create an Interface which will be useful for all the Adapters which need the CAB, and make our Adapter implements it. Please note this is a generic interface, so adapt it to the model you are displaying in your adapter.
public interface ActionModeAdapterCallbacks<T> {
void toggleSelection(int position);
void clearSelections();
int getSelectedCount();
List<T> getSelectedItems();
}
This is what the implementation should look like:
@Override
public void toggleSelection(final int position) {
if (selectedItemsIds.get(position)) {
selectedItemsIds.delete(position);
} else {
selectedItemsIds.put(position, true);
}
notifyItemChanged(position);
}
@Override
public void clearSelections() {
selectedItemsIds.clear();
notifyDataSetChanged();
}
@Override
public int getSelectedCount() {
return selectedItemsIds.size();
}
@Override
public List<Authentication> getSelectedItems() {
final List<Authentication> selectedItemList = new LinkedList<>();
for (int i = 0; i < selectedItemsIds.size(); i++) {
selectedItemList.add(authenticationList.get(selectedItemsIds.keyAt(i)));
}
return selectedItemList;
}
Now, we also need the Adapter to change the view state when an item gets selected to show the user a visual feedback. To do this we can use a StateListDrawable and in the onBindViewHolder() method add this line.
Doing so, each time an item is selected or deselected, the adapter will change its color accordingly.
Fragment/Activity changes
Now, we need to make our Fragment/Activity class aware that we can trigger the Contextual Action Mode. To do so, let’s create an interface and call it ActionModeViewCallbacks.
public interface ActionModeViewCallbacks {
void onListItemSelect(final int position);
void onDestroyActionMode();
}
This interface has 2 methods:
onListItemSelect(final int position): to be used after a long click on an item to trigger the Action Mode (or after a single click on an item, if Action Mode was already triggered, to select this new item, too);
onDestroyActionMode(): reset actionMode variable to null;
Now, let’s create another interface which extends from this one:
public interface ListAuthenticationActionModeViewCallbacks extends ActionModeViewCallbacks {
void onDeleteActionClicked();
}
This new interface has another method, onDeleteActionClicked(), which is where the presenter gets called (check MVP if you are not aware what MVP and a Presenter are) and asked to delete the items the user has selected (if you have more than a single action, you need to create more methods, each for any action you have).
This interface must be implemented by the Fragment/Activity which wants to use the Contextual Action Mode. The implementation looks like this:
@Override
public void onListItemSelect(final int position) {
listAuthenticationAdapter.toggleSelection(position);
final boolean hasCheckedItems = listAuthenticationAdapter.getSelectedCount() > 0;
if (hasCheckedItems && actionMode == null) {
// there are some selected items, start the actionMode
actionMode = ((AppCompatActivity) getActivity()).startSupportActionMode(new ListAuthenticationToolbarActionModeCallback(this, this, listAuthenticationAdapter));
} else if (!hasCheckedItems && actionMode != null) {
// there no selected items, finish the actionMode
actionMode.finish();
}
if (actionMode != null) {
//set action mode title on item selection
actionMode.setTitle(getString(R.string.cab_selected, listAuthenticationAdapter.getSelectedCount()));
}
}
@Override
public void onDestroyActionMode()
actionMode = null;
}
@Override
public void onDeleteActionClicked() {
presenter.delete(listAuthenticationAdapter.getSelectedItems());
}
In doing startSupportActionMode() we need to pass a ActionMode.Callback item that I haven’t explained yet. Let’s create another class which implements that interface.
public class ListAuthenticationToolbarActionModeCallback implements ActionMode.Callback {
private final ActionModeViewCallbacks actionModeViewCallbacks;
private final ListAuthenticationAdapter listAuthenticationAdapter;
public ListAuthenticationToolbarActionModeCallback(final ActionModeViewCallbacks actionModeViewCallbacks, final ListAuthenticationAdapter listAuthenticationAdapter) {
this.actionModeViewCallbacks = actionModeViewCallbacks;
this.listAuthenticationAdapter = listAuthenticationAdapter;
}
@Override
public boolean onCreateActionMode(final ActionMode mode, final Menu menu) {
mode.getMenuInflater().inflate(R.menu.listauthentication, menu);
return true;
}
@Override
public boolean onPrepareActionMode(final ActionMode mode, final Menu menu) {
menu.findItem(R.id.action_delete).setShowAsAction(MenuItem.SHOW_AS_ACTION_ALWAYS);
return true;
}
@Override
public boolean onActionItemClicked(final ActionMode mode, final MenuItem item) {
switch (item.getItemId()) {
case R.id.action_delete:
actionModeViewCallbacks.onDeleteActionClicked();
mode.finish();
return true;
}
return false;
}
@Override
public void onDestroyActionMode(final ActionMode mode) {
actionModeViewCallbacks.onDestroyActionMode();
listAuthenticationAdapter.clearSelections();
}
}
first one shows the initial situation before Action Mode is triggered;
second one shows the situation after Action Mode was triggered by long press an item;
third one shows the final situation after the item “Auth 2” was deleted.
Conclusions
Your Contextual Action Mode should work now! I suggest you to create different menu files, Fragment/ActivityToolbarActionModeCallback and Fragment/ActivityActionModeViewCallbacks to keep everything separated.
Please note: if you rotate the device, Contextual Action Mode is lost, you need to save its state and restore it. Another post will follow, hopefully soon!
Today I show a simple Android project I wrote which shows the use of Dagger, Retrofit and some other stuff.
The full source code of the project is available for you here
The project’s main purposes are the following:
Show Dagger2 dependency injection;
Show MVP architecture (made through Dagger2)
Show the repository pattern used to cache server data
Show the creation and use of a CustomView
Furthermore, I have used ButterKnife to remove the boilerplate code needed to bind classes/views, and GreenDao to automatically create the SQLite repository/model classes.
This project is based on the Google Android Architecture samples which are available here
Dealing with Fragments is always a pain: after some time I found a way to deal with them in a less painful way, creating a custom Fragment Backstack.
How to create your custom Fragment Backstack navigation
Put this code in your main Activity:
public class MainActivity extends AppCompatActivity {
private Stack<Fragment> fragmentStack;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
fragmentStack = new Stack<>();
}
@Override
public void onBackPressed() {
fragmentStack.pop();
if (fragmentStack.size() == 0) {
super.onBackPressed();
} else {
showFragment(fragmentStack.lastElement(), false);
}
}
public void showFragment(Fragment fragment, boolean addToStack) {
if (addToStack) {
fragmentStack.push(fragment);
}
getFragmentManager().beginTransaction().replace(R.id.container_fragment, fragment).commit();
}
}
We have a fragmentStack field which is a Stack of Fragment: we use this to save the Fragments we show in our app and we initialize it in the onCreate() method of the main Activity.
In the onBackPressed() method we remove the current Fragment from the Stack and then if there is another one, we show it, otherwise we close the app because there is nothing more to be shown.
The method showFragment() is the one we use to show a Fragment on the screen; we invoke it every time we need to change the visible Fragment. If we want to save the current transaction being able to come back to the current Fragment we pass true as addToStack value, otherwise we pass false.
Do you want to automatically hide your keyboard whenever you touch outside it? Please continue reading and you will find out how to do it!
First, we will create our AutoHideKeyboardEditText class like the following:
public class AutoHideKeyboardEditText extends EditText {
public AutoHideKeyboardEditText(Context context) {
super(context);
init();
}
public AutoHideKeyboardEditText(Context context, AttributeSet attrs) {
super(context, attrs);
init();
}
public AutoHideKeyboardEditText(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
init();
}
private void init() {
setOnFocusChangeListener(new OnFocusChangeListener() {
@Override
public void onFocusChange(View v, boolean hasFocus) {
if (!hasFocus) {
hideKeyboard(v);
}
}
});
}
private void hideKeyboard(View view) {
InputMethodManager inputMethodManager = (InputMethodManager)
view.getContext().getSystemService(Activity.INPUT_METHOD_SERVICE);
inputMethodManager.hideSoftInputFromWindow(view.getWindowToken(), 0);
}
}
Whatever Constructor is used, we set an onFocusChangeListener to hide the keyboard using the proper method if we touch outside the EditText area (if the focus is not anymore on it).
You are done! Whenever you touch outside the EditText the keyboard will be automatically dismissed!
Please note: you should add the clickable and focusableInTouchMode attributes to the outermost view but if it is a ScrollView this might not work. For such case, those attributes could be added to the view directly under the ScrollView.
Create a perfect Android Studio .gitignore file is sometimes tedious, so I have gathered some information on the Internet, mainly on StackOverflow, I made some experiments with my sample project over and over and finally I obtained a perfect Android Studio .gitignore file.
Usually, I create my project inside a parent folder which I initialize as my Git repository.
So, for example, this is a sample structure (folders are bolded):
AndroidShowcaseRepository
.git
AndroidShowCase
.gradle
.idea
app
build
gradle
.gitignore
AndroidShowcase.iml
build.gradle
gradlew
gradlew.bat
local.properties
settings.gradle
.gitignore
LICENSE
README.md
I use the following as content for the .gitignore file in the AndroidShowcaseRepository folder
# Built application files
*.apk
*.ap_
# Files for the Dalvik VM
*.dex
# Java class files
*.class
# Generated files
bin/
gen/
# Gradle files
.gradle/
build/
/*/build/
# Local configuration file (sdk path, etc)
local.properties
# Proguard folder generated by Eclipse
proguard/
# Log Files
*.log
and the following as content for the .gitignore file in the AndroidShowcase folder
Using these two .gitignore files (and the default ones created by Android Studio inside the app folder and into other folders you could have) you will likely save only the necessary source code to your repository and not files which could be generated by Android Studio itself.
This website or its third party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the cookie policy.
By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies.OkRead more