ImageView and FrameLayout with gestures control and position animation.

source: https://android-arsenal.com/details/1/2705

GestureViews

ImageView and FrameLayout with gestures control and position animation.

Main goal of this library is to make images viewing process as smooth as possible and to make it easier for developers to integrate it into their apps.

Demo video

(Click for full demo video)

Sample app

Usage

Add dependency to your build.gradle file:

compile 'com.alexvasilkov:gesture-views:2.0.0'

Note: min SDK version for library is 9, but it was tested mainly on 15+.

Usage wiki

Javadoc

Sample app sources

License

Copyright 2014 Alex Vasilkov

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Android Application UI Testing (with monkey and monkeyrunner)

source: http://hariniachala.blogspot.in/2011/09/android-application-ui-testing-with.html

Android Application UI Testing (with monkey and monkeyrunner)

Android has some built in UI testing tools. These tools can be used for automated UI testing. However the tools are not so simple to use. This post is an attempt to set a guideline towards using these tools.

There are 2 main UI testing tools available

1.monkey (aka. UI/Application Exerciser Monkey)

This tool is a command line based tool that can be primarily used to stress test your application UI. It is the simplest tool to use. Here's how..

Running monkey as an application UI stress tester (runs a random set of commands on the application. useful to UI stress testing)

- Open a command console.
- First direct your console to the location of the adb (Android Debug Bridge) program in the android sdk. Typically you can use the following command for this..

$cd path_to_android_sdk/platform-tools/

path_to_android_sdk should be the path to the sdk on your pc

- Now make sure you device is connected with the application running on it or that the emulator is running the application.

- To test on device issue the following command in the console

$./adb -d shell monkey -p package_name -v 1000

(replace -d with -e to test on the emulator.
package_name is the name of the application package abnd it usually begins with com.
-v specifies the number of UI events to be generated, in this case we ask it to generate 1000 random events)

Now you will see the monkey stress testing your app.

If you get force close message while running monkey you have just discovered a bug that needs fixing. You can run

./adb logcat

in the console to generate the relevant logs.


Running specific commands in monkey
The monkey tool can also be used to run a specific set of commands on the application. However it is easier to use the monkeyrunner for this purpose.

On the connected device (to run on emulator simply replace -d with -e)

./adb -d shell monkey -p package_name --port 1080 &
./adb -d forward tcp:1080 tcp:1080
telnet localhost 1080

Now the following will be printed on cmd line..

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Now you can type in your instructions

>tap 150 200

you can write all instruction into a script (script.txt) as below..

# monkey
tap 100 180
type 123
tap 100 280
press DEL
press DEL
press DEL
press DEL
press DEL
press DEL
press DEL
press DEL
type -460.3

now run..

./adb -d shell monkey -p package_name --port 1080 &
./adb -d forward tcp:1080 tcp:1080
nc localhost 1080 < script.txt


2. monkeyrunner

The monkeyrunner tool is an API for writing automated UI tests. You can use it to write specific scripts that run a series of commands and inspects the output by taking screenshots etc. The android SDK includes two special scripts written using monkeyrunner which help in running automated UI tests. The scripts are..

monkey_recorder.py
monkey_playback.py

Copy these scripts to /tools folder in the android sdk. Set the console path to the tools directory. Open up the application on the emulator.

You can run the recorder as follows..

./monkeyrunner monkey_recorder.py

Below is a screenshot of monkey_recorder recording actions for calculator.



Use 'Export Actions' button to export the set of actions into a script (eg: calc.mr)

now run the cal.mr script on a connected device as follows.. (first make sure the emulator is shut down)

./monkeyrunner monkey_playback.py calc.mr

For playback to run properly you need to take precautions of setting the correct wait times and using the correct press, fling, type methods in the recorder.

Conclusion: Android has a good collection of tools meant to enable UI test automation. However they still have a lot more room for improvement especially in terms of ease of use and efficiency.

References:

http://developer.android.com/guide/developing/tools/monkey.html
http://developer.android.com/guide/developing/tools/monkeyrunner_concepts.html
Android Application Testing Guide - Diego Torres Milano

source: http://blog.danlew.net/2015/09/09/dont-use-dynamic-versions-for-your-dependencies/

Beware EditText on API 21

Check out these two EditTexts. One is on an API 21 device, the other on an API 22 device.

See the difference? It's even more pronounced with "show layout bounds" enabled:

The height and vertical alignment of the EditTexts are different! This was caused by a change in the background of EditText between v21 and v22 (diff).

This change can cause sadness if your EditText is vertically aligned with otherViews, such as this case in Trello:

The text should be aligned with the icons, yet clearly it's not. The screenshot above is from 5.0; any other version of Android looks perfectly fine.

This problem crops up even if you're using AppCompat. AppCompat usually defers to the system material styles on v21+, which is the source of the problem.

Solution

Both solutions I've come up with use resource qualifiers to handle API 21 in a special manner.

One possibility is to import your own EditText background assets for API 21. Unless your app is filled with vertically-aligned EditTexts this seems like more effort than it's worth, since precision-targeting the background of EditTexts for just a single API version is tricky.

The hackier (but easier) solution is to just define different margins or paddings based on the API level. For example, I found that they're ~6dp off, so you end up with resources like this:

<!-- values/dimens.xml -->  
<dimen name="edit_text_spacing">6dp</dimen>

<!-- values-v21/dimens.xml -->  
<dimen name="edit_text_spacing">0dp</dimen>

<!-- values-v22/dimens.xml -->  
<dimen name="edit_text_spacing">6dp</dimen>  

I'd be the first to admit it's ugly, but if there's only a handful of places you're fixing the problem, it's not so bad.