But no one of them seems to work in every situation.
Looking into stackoverflow I’ve come to this post which seems to hold the best working answer that I’ve tried.
Except when I’ve tried to use it when textAllCaps=”true”.
The solution to this issue has already been reported in one of the comments.
So I put up all togheter, and the result is the following AutoResizeTextView implementation:
Oggi si è tenuto al FabLab di Padova un Workshop sull’Internet of Things, durante il quale ho avuto il piacere di anticipare l’intervento di Intel con un intervento dal titolo #Google, #Android, #IoT.
Durante questo intervento ho fornito agli attendenti una panoramica sui servizi che Google mette a disposizione per l’universo dell’Internet of Things e mostrato come è possibile far comunicare una app Android con una scheda Arduino, sia a corto raggio tramite Bluetooth che da remoto appoggiandosi su un server Firebase.
When you run your Android tests (like espresso tests), you may want to be able to force the locale of your device to some specific value at runtime (during test execution). This could be really helpful if you want to test some features of your app against multiple locales.
You can do this by using Junit4 rules.
The rule implementation looks like this:
The test locale is passed in as a parameter to the constructor. Before test execution we set the test locale. When test is executed, the previous device’s locale will be automatically restored.
And here’s an example of a test where locale il setted to Locale.UK before test execution:
Sometimes some fetaures of your app must behave differently for different flavors o build type.
Think about when you need to enable logging for a specific flavor only, or you have to disable crash reporting for your “dev build”. All this behaviours can be configured at compile time, insted of using many if/else blocks that are evaluated at runtime.
In the following example I’ll use Gradle and Dagger.
Use case: enable crash reporting only for production flavor.
First step: create an interface CrashReporter and two implementations: CrashReporterRealImpl and CrashReporterNullImpl.
Second step: configure the build.gradle file for our app.
Third step: use dagger to provide the right instance of CrashReporter.
Final step: inject and use!
It could seem a lot of code for just enabling/disabling a feature, but with this approach the code is modular (for example you could easily replace CrashReporterRealImpl with another one that uses another service, or you can temporarly enable crash reporting for another flavor for testing purposes) and there’s no logic that needs to be tested.
With this approach you could also develop new functions directly in the master branch without using a “feature branch”.
Use case: develop a new feture in master branch.
Suppose that we have to work on our new feature called “Experimental Feature”. We just need to create an interface and two implementations as done before:
Then create the definitions in build.gradle and add provide method to the dagger module:
Now we can continue to develop in the master branch and commit even when our ExperimentalFeatureControllerRealImpl does not work correctly: FEATURE_EXPERIMENTAL_ENABLED will be TRUE only for our “dev build”, and in FALSE for production build.
When ExperimentalFeatureControllerRealImpl will be ready for production, we will just have to set FEATURE_EXPERIMENTAL_ENABLED to TRUE also for production build!