Archive for July, 2014

Summary of Calabash iOS Ruby API – QUERY

July 28, 2014 1 comment

Just a summary of useful commands !


query(uiquery, *args)
irb(main):003:0> query("button index:0")
=> [{"class"=>"UIRoundedRectButton", "frame"=>{"y"=>287, "width"=>72, "x"=>100, "height"=>37}, "UIType"=>"UIControl", "description"=>">"}] 
irb(main):005:0> query("button index:0").first.keys
=> ["class", "frame", "UIType", "description"]

irb(main):006:0> query("button index:0").first["frame"]["width"]
=> 72

irb(main):031:0> query("tableView","numberOfSections")
=> [1]
irb(main):033:0> query("tableView","delegate","description")
=> [""]
irb(main):034:0> query("tableView",numberOfRowsInSection:0)
=> [30]
irb(main):035:0> query("tableView","numberOfRowsInSection"=>0)
=> [30]
irb(main):036:0> query("pickerView",:delegate, [{pickerView:nil},{titleForRow:1},{forComponent:0}])
=> ["1,0"]
[pickerView.delegate pickerView:nil titleForRow:1 forComponent:0]


def classes(uiquery,*args)
irb(main):001:0> classes("view")
=> ["UILayoutContainerView", "UITransitionView", "UIViewControllerWrapperView", "UIView", "UITextField", "UITextFieldRoundedRectBackgroundView", "UIImageView", "UIImageView", "UIImageView", "UITextFieldLabel", "UILabel", "UIRoundedRectButton", "UIButtonLabel", "UISwitch", "_UISwitchInternalView", "UIImageView", "UIView", "UIImageView", "UIImageView", "UIImageView", "UIRoundedRectButton", "UIButtonLabel", "UITabBar", "UITabBarButton", "UITabBarSelectionIndicatorView", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel", "UITabBarButton", "UITabBarSwappableImageView", "UITabBarButtonLabel"]


 def label(uiquery)
  query(uiquery, :accessibilityLabel)
irb(main):001:0> label("view")
[nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, "Empty list", nil, nil, nil, "Mon", "Dec 17", nil, nil, nil, "Tue", "Dec 18", nil, nil, nil, nil, "Today", nil, nil, nil, "Thu", "Dec 20", nil, nil, nil, nil, nil, "Empty list", nil, nil, "12", "12", nil, nil, "1", "1", nil, nil, "2", "2", nil, nil, "3", "3", nil, nil, nil, nil, nil, "Empty list", nil, nil, "56", "56", nil, nil, "57", "57", nil, nil, "58", "58", nil, nil, nil, nil, nil, "Empty list", nil, nil, "AM", "AM", nil, nil, "PM", "PM", nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, "Name", "First View", "First", "First", nil, "Second", "Second", nil, "other", "switch", nil, nil, nil, nil, nil, nil, "login", "Login", nil, "First", nil, nil, "First", "Second", nil, "Second", "Third", nil, "Third", "Fourth", nil, "Fourth"]




element_exists("view marked:'#{expected_mark}'")


wait_for(options, &block)
{:timeout => 10, #maximum number of seconds to wait
 :retry_frequency => 0.2, #wait this long before retrying the block
 :post_timeout => 0.1, #wait this long after the block returns true
 :timeout_message => "Timed out waiting...", #error message in case options[:timeout] is exceeded
 :screenshot_on_error => true # take a screenshot in case of error
irb(main):030:0> wait_for(:timeout => 5) { not query("label text:'Cell 11'").empty? }
irb(main):031:0> wait_for(:timeout => 5) { element_exists("label text:'Cell 20'") }
wait_for(:timeout => 30) do
    res = query("button marked:'Player play icon'", :isSelected)
    res.first == "1"        

wait_for_elements_exist(elements_arr, options={})

irb(main):008:0> wait_for_elements_exist( ["label text:'Cell 11'", "tabBarButton marked:'Third'"], :timeout => 2)
wait_for_elements_do_not_exist(elements_arr, options={})
wait_poll(opts, &block)
{:until => nil #a predicate which should return true when the condition is satisfied
 :until_exists => nil #a uiquery to function as predicate (i.e. element_exists(opts[:until_exists]))
 :timeout => 10, #maximum number of seconds to wait
 :retry_frequency => 0.2, #wait this long before retrying the block
 :post_timeout => 0.1, #wait this long after the block returns true
 :timeout_message => "Timed out waiting...", #error message in case options[:timeout] is exceeded
 :screenshot_on_error => true # take a screenshot in case of error
irb(main):023:0> wait_poll(:until_exists => "label text:'Cell 22'", :timeout => 20) do
irb(main):024:1* scroll("tableView", :down)
irb(main):025:1> end


Bye Guys 😀


Query Calabash Android

July 22, 2014 1 comment

Hey guys, I will post today some queries to find elements in different ways with calabash-android in console !


Basic usage

Using the class of the elements (Button, Label, View, Webview, Tableview, etc…). If you don’t know what is the class, you can use only * to find all the elements on the screen.




You can use size, to know the qty of the elements with this class:



Filtering by class


Simple class name

Filtering by class means that we only want to look at certain types of views. This is what we’ve done before when we were searching for Button or TextView:

This is called filtering by simple name. The result shows you that the full class name is android.widget.Button: this is what we call fully qualified class name and the andorid.widgetpart is called package name.

When you query with simple name Calabash only looks at the last bit of the name. This is also case insensitive, so Button, button or bUtTOn is the same in this context.


Fully qualified class name

You can also use the fully qualified class name in the query:

Interestingly this gives us two results: the login button and a checkbox. Why is the CheckBox included? In order to understand this you have to understand subclasses.

Let’s look at an example:

There are a lot different buttons in Android like ToggleButton and the Switch. A ToogleButton is just a specific type of Button with some extra functionality and look. A Button is just a simple button with a text in it where the ToggleButton has two states (on and off). So every ToggleButton is a Button but not every Button is a ToggleButton.

The CheckBox is also a subclass of Button – which explains why we get two results. If you use the fully qualified name in the query it will give you the class and all of it’s subclasses. So if there were ToggleButtons and Switches it would also return those.

The main distinction is this:

  • using simple name only looks at the last part of the class and does a simple comparison
  • using the qualified name looks at the class hierarchy and gives back all the class and all of it’s subclasses


Filtering by property

Usually there are several buttons, textviews and edit texts on the screen so filtering by class is not enough to identify a single element.

In the query results you get back a set of properties for each view like id, text, class.

Calabash allows you to filter on these properties.

The most used property is the id. On Android every view can have an id, which is an invisible string identifier. The id is not necessarily unique and also not every view has one. Even with these restriction using id is the most reliable way to find views.


id property

Let’s try to find the login button by id:

The first part of the query is the class filtering: * means give me all the views. The second part is the property filtering: id:'login_button' means find the view that has the id login_button.

The filtering happens on the result of the first part of the query string. Previously we used "*" so the filtering was applied to all the views. But we could have used different class.


text property

Of course id is not the only property that you can filter on. Another commonly used one is the text. This is the label of the view which is visible on the screen:

This will find the view on the screen which has a text Login. Once I found them though I use id instead of text. This results in more stable tests. Labels tend to change more frequently than ids. It also eliminates all the translation and localisation problems.

What if a view doesn’t have an id? Ask the developers to add one. It’s a 5 second task and it will make your life a lot easier.


Other properties

Let’s try to find all the disabled buttons:

Notice that while we used single quotes for string parameters we’re not using anything here for false.

The third type of parameter is the integer parameter (numbers). One example is the width parameter:

This gives you all the views that are exactly 200 pixel wide. Notice that we are not using the single quotes to define the value.

You can also combine the filters using multiple criteria. Let’s get all the views which are enabled and the are 50 pixel heigh:


How it works

The general syntax for property filtering is the following:

The prop is the name of the property and the value is either a string, a boolean or an integer value.

We’ve already used a couple of properties like id, text, enabled and width. There are a lot more. For starters you can use all the attributes that you see in the query results. But that’s not everything.

Every view object supports a set of methods – you can find all the supported methods on the view’s documentation. For example the View class has an isEnabled() method. When Calabash tries to resolve the property it find the following methods on the view: prop(), getProp() and isProp() in this order.

So for the enabled property it tries to find the enabled(), getEnabled() or isEnabled() methods.

If Calabash does find a method it calls it and compares the return value with the value you specified. If it doesn’t match it gets rid of that view. It also discards the view if it can’t find the appropriate methods.


Useful things

In addition to the basic query syntax there are a couple of useful things you can use.



The marked keyword is a shorthand for identifying an element by it’s name. It’s a convenience method to filter by id, text or contentDescription properties.



The result of each query is a standard Ruby array. Because of this you can access the elements directly in it. If you want to get the first view on screen you can do it like this:

The query language also supports the index keyword. The index is very similar than using the array indexing – it gives you the element at a given index:

This is usually used with lists and other collection views. Often you just want to click on the first element on a list.

Be warned though: you should only use index if you really need it. Using index to identify elements in the layout is usually not a good idea – it leads to brittle tests and hard to diagnose problems.

Use ids, text and other identifiers and don’t rely on the ordering of the items!


Returning certain properties

Sometimes you’re only interested in certain properties not the full result. Let’s say you want to get all the id’s on the screen:

As you can see a result is an array of strings where only the ids are shown. Isn’t this much nicer?

You can put any property as the second argument of query to get the data you’re interested in. Another example to get all the labels for the enabled views:

query("* enabled:true", :text)



Calabash supports some filters that are not present in UIScript. Particularly we support filtering by simple NSPredicates. For example searching for a string prefix:

"label {text BEGINSWITH 'Cell 1'}"

which would return the labels with text Cell 1 and Cell 10.

In general you use a NSPredicate by writing a filter: {selector OP val}, where selector is the name of an Objective-C selector to perform on the object, OP is operation, and val is a string or integer value.

Common operations

  • BEGINSWITH, prefix, e.g., "label {text BEGINSWITH 'Cell 1'}"
  • ENDSWITH, suffix, e.g., "label {text ENDSWITH '10'}"
  • LIKE, wildcard searches, e.g., "label {text LIKE 'C*ll'}"
  • CONTAINS, substring, e.g., "label {text CONTAINS 'ell'}"
  • Comparison, <, >, …
  • Case or diacritic insensitive lookups, e.g., "label {text CONTAINS[cd] 'cell'}"

To understand what additional options are available, consult the full syntax for NSPredicate documented by Apple: NSPredicate Syntax



There are four directions descendant, child, parent and sibling. These determines the direction in which search proceeds.

Often, query expressions are a sequence of ClassName expressions. For example:

 "tableViewCell label"

this means “first find all UITableViewCell views, then inside of those, find all the UILabel views”. The key here is the word inside. This is determined by the query direction.

By default the direction is descendant, which intuitively means “search amongst all subviews (or sub-views of sub-views, etc).” But you can change the traversal direction. Here is an advanced example:

label marked:'Tears in Heaven' parent tableViewCell descendant 

This query finds a label ‘Tears in Heaven’, and then proceeds to find the tableViewCell that contains this label (i.e., moving in the parent instead of descendant direction). From the tableViewCell we move down and find the tableViewCellReorderControl.

Valid directions are descendant, parent, child and sibling. Both descendant and childlooks for subviews inside a view. The difference is that descendant keep searching down in the sub-view’s subviews, whereas child only looks down one level. The direction sibling searches for views that are “at the same level” as the present view (this is the same as: first find the immediate parent, then find all subviews except for the view itself).


Thank you again !

Bye 🙂


Error with signature on the app Android

July 15, 2014 2 comments
If you got some of these errors when try create the signature of your app (or try run calabash-android run) on Android:


> fingerprint_from_apk': No RSA file found in META-INF. Cannot proceed. 




> jarsigner: unable to open jar file (When try re-signed)


Try these steps:


– Verify if the file zipalign is inside of the folder sdk/tools.


– If the zipalign don’t exist inside the tools folder, download on this link :


– Give the execute permissions:

chmod 777 zipalign


– Open the Eclipse, Click in Preferences:

Screen Shot 2014-07-16 at 0.06.31


– Open the Android Tab, Click on Build, Click on Apply and OK:


Screen Shot 2014-07-16 at 0.07.03
– Try runs the command again:
calabash-android resign NAMEAPP.apk
– After try run the cucumber again 🙂
calabash-android run NAMEAPP.apk


Worked for me !


Bye guys 🙂

Calabash-Android Install Example Project

Hello guys,

Today I will post about install calabash-android in your machine. And for this I will use the project sample of this git repository:

You can do the download too if you don’t have a project neither an apk file.

Download and install ruby and RVM:

\curl -sSL | bash -s stable --ruby
rvm install ruby 1.9.3
Install calabash-android:
sudo gem install calabash-android


Install bundler unless you already have it installed:

gem install bundler

(or sudo gem install bundler)

Install gems in the Gemfile:

bundle install


To run the iOS tests, make sure Xcode 5.1 is installed with command line tools.


bundle exec cucumber -p ios


To run the Android tests, ensure a recent Android SDK is installed, and that

  • environment variable ANDROID_HOME is set to point to the sdk folder, for example/Users/krukow/android/adt/sdk

PS: This an example of a project with generated key and certificates, so you don’t need assign the app.


bundle exec calabash-android run prebuilt/Android-debug.apk -p android

This example you must to install bundle too. If you have any question or comment, just write below. Thank you again 🙂



Abstract Methods and Classes

Hello guys,

I will continue with more technical posts today… 🙂

What is ? 

An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed.

An abstract method is a method that is declared without an implementation (without braces, and followed by a semicolon), like this:

abstract void moveTo(double deltaX, double deltaY);

If a class includes abstract methods, then the class itself must be declared abstract, as in:

public abstract class GraphicObject {
   // declare fields
   // declare nonabstract methods
   abstract void draw();

When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class. However, if it does not, then the subclass must also be declared abstract.

An Abstract Class Example

In an object-oriented drawing application, you can draw circles, rectangles, lines, Bezier curves, and many other graphic objects. These objects all have certain states (for example: position, orientation, line color, fill color) and behaviors (for example: moveTo, rotate, resize, draw) in common. Some of these states and behaviors are the same for all graphic objects (for example: position, fill color, and moveTo). Others require different implementations (for example, resize or draw). All GraphicObjects must be able to draw or resize themselves; they just differ in how they do it. This is a perfect situation for an abstract superclass. You can take advantage of the similarities and declare all the graphic objects to inherit from the same abstract parent object (for example, GraphicObject) as shown in the following figure.

Classes Rectangle, Line, Bezier, and Circle Inherit from GraphicObject  

Classes Rectangle, Line, Bezier, and Circle Inherit from GraphicObject

First, you declare an abstract class, GraphicObject, to provide member variables and methods that are wholly shared by all subclasses, such as the current position and the moveTo method. GraphicObject also declares abstract methods for methods, such as draw or resize, that need to be implemented by all subclasses but must be implemented in different ways. The GraphicObject class can look something like this:

abstract class GraphicObject {
    int x, y;
    void moveTo(int newX, int newY) {
    abstract void draw();
    abstract void resize();

Each nonabstract subclass of GraphicObject, such as Circle and Rectangle, must provide implementations for the draw and resize methods:

class Circle extends GraphicObject {
    void draw() {
    void resize() {
class Rectangle extends GraphicObject {
    void draw() {
    void resize() {

Class Members

An abstract class may have static fields and static methods. You can use these static members with a class reference (for example,AbstractClass.staticMethod()) as you would with any other class.

When ?

Abstract Classes is to create templates for future classes and offer the added benefit of letting you define functionality that your child classes can utilize later. You can’t provide an implementation for an Interface.

Why ?

Abstract Classes are a good fit if you want to provide implementation details to your children but don’t want to allow an instance of your class to be directly instantiated (which allows you to partially define a class). If you want to simply define a contract for Objects to follow, then use an Interface.

Abstract methods are useful ?

Abstract methods are useful in the same way that defining methods in an Interface is useful. It’s a way for the designer of the Abstract class to say “any child of mine MUST implement this method”.


Any question or comment, just write below ! Thank you again ! 

Bye 🙂



%d bloggers like this: