Blog Archives

Miscellaneous (part 6)

Being at the last step of our Android Wear journey suggests us to make some assumptions and considerations on how to take advantage of this new platform in real scenarios. Beside this, we are going to have a brief look at some of the missing elements that we did not touch before, focusing our attention on answering the questions those might have risen in the mind of the readers while going through the entire path.

Read the rest of this entry

Data Exchange and Sync (part 5)

Since the beginning of our journey, we have tried to create a wearable experience starting from our existing handheld app. A first working solution has been achieved just taking advantage of the WearableExtender that has allowed us to easily extend the status bar notifications, providing detailed info and extended functionalities to the wearable device. Even if this approach can work for the majority of the applications and it is really straightforward to achieve, it has some drawbacks in terms of achievable features and availability of content on the smartwatch. In fact, if the smartphone and the wearable device are not coupled, the latter one cannot offer any more access to the previously shown content. Keeping in mind that the wearable device is not a substitute of the handheld one but more like an extension that should try to simplify the user life, we have then exposed a limited number of functionalities into a custom wearable app. In order to achieve this result both applications currently share a common module but are decoupled in terms of single application modules. In this way it is possible to recycle and share code elements like the ContentProvider, the models and common utilities but at the same time keep distinct the different platform based implementations. In Pimp my Wear, this solution has led us to a wearable application that can be used by the user even if the two devices are temporarily disconnected but at the same time to a situation where the content gets out-synced. In this chapter we are going to have a look at how the Wearable Api can help us exchanging and syncing data between the two different devices.

Read the rest of this entry

Pimp my Wear (part 4)

In Colonizing Wearables, after a first attempt of running the existing handheld version of the Books application on a smartwatch, we ended up creating a simple Android Wear module that displays the number of available book entries. This has been done not only to discover more about Android Wear, but because a handheld app should not be just ported to a wearable device. During our journey, we have introduced few of the new UI components offered by the wear support library. Among them, WatchViewStub has allowed us to handle different screen shapes, figuring out at runtime the type of display. We also had a chance to understand the reason why and how the wearable module has to be included into the handheld build. Therefore, the goal of this part is to evolve the previous module into something that can be easily used by user and that tries to follow as much as possible the android wear design patterns.

Read the rest of this entry

Colonizing Wearables (part 3)

In Landing on Wearables we have approached wearables devices extending our existing app’s notifications and explaining briefly how to bind them to our development machine for debugging purposes. Now it is time to study more in deep what we can achieve directly on a device running Android Wear, understanding the constraints and the possibilities that the platform introduces. We will continue to keep as reference the Books application previously developed and we will try to create an Android Wear module.

Read the rest of this entry

Landing on Wearables (part 2)

In Introduction to Wearables we had a look at some of the concepts those are the foundations of Android Wear. In this part we are going to skip completely any considerations on that and we’ll have a look at how things work underneath. In particular, we’ll have a look at how to extend existing application’s notifications and how to debug on wearables(this second part will be used for the following tutorials). In order to achieve this, we’ll start with a sample application that runs just on a handheld device and we’ll try step by step to extend it, trying to create a beautiful user experience even on a device running Android Wear. Read the rest of this entry

Introduction to Wearables (part 1)

Wearable devices are definitely one of the most exciting and coolest technologies of 2014 along with drones and smart cars. Hardware producers, software companies and even start-ups are pushing the boundaries beyond what is just being on a handheld device, struggling to open new challenges and attract new customers. Something similar has been already seen when smartphones were just at the beginning of their appearance, but this time the purposes and targets of this technology are a little bit different. It is not just a matter of keeping the user connected with the World outside but it’s more about offering him new services, getting more from/into his life. Sensors can collect data about user activities (heart rate, pedometer, burn calories, sleep hours…) allowing to know more from the user’s context and his behaviors. Embedding them on wearable devices(smartwatches, rings, betls,…) can grant almost a 24 hours coverage, attracting the user to use something that he is already used to wear but with more functionalities and fancier. Read the rest of this entry

#Java @nnotations

“Annotations, a form of metadata, provide data about a program that is not part of the program itself. Annotations have no direct effect on the operation of the code they annotate.

Java Tutorial – Oracle (Sun)


public @interface <name>{

<type> <method_name>();

<type> <method_name>() default <value>;


  • @Retention annotation specifies how the marked annotation is stored:
    • RetentionPolicy.SOURCE – The marked annotation is retained only in the source level and is ignored by the compiler.
    • RetentionPolicy.CLASS – The marked annotation is retained by the compiler at compile time, but is ignored by the Java Virtual Machine (JVM).
    • RetentionPolicy.RUNTIME – The marked annotation is retained by the JVM so it can be used by the runtime environment.
  • @Target annotation marks another annotation to restrict what kind of Java elements the annotation can be applied to. A target annotation specifies one of the following element types as its value:
    • ElementType.ANNOTATION_TYPE can be applied to an annotation type.
    • ElementType.CONSTRUCTOR can be applied to a constructor.
    • ElementType.FIELD can be applied to a field or property.
    • ElementType.LOCAL_VARIABLE can be applied to a local variable.
    • ElementType.METHOD can be applied to a method-level annotation.
    • ElementType.PACKAGE can be applied to a package declaration.
    • ElementType.PARAMETER can be applied to the parameters of a method.
    • ElementType.TYPE can be applied to any element of a class.
  • @Inherited annotation indicates that the annotation type can be inherited from the super class. (This is not true by default.) When the user queries the annotation type and the class has no annotation for this type, the class’ superclass is queried for the annotation type. This annotation applies only to class declarations.

Read the rest of this entry

[TUTORIAL] Working in the background

In this tutorial we’ll talk some aspects that involves a mobile developer in many situations. In particular we’ll deepen concepts like threads (in particular AsyncTasks) and JSON parsing through Google GSON.

This slideshow requires JavaScript.

Before you start, take a look at:

Now you are ready to perform this simple steps:

  1. Take TWITTER_URL that you find in the project in AsyncTaskActivity
  2. Past it into JSONLint board and press Validate

In this way you’ll view if your JSON is valid and how it’s structured.

After that you need to create (there’s mine 😛 ) an android project in which you add into AndroidManifest.xml the internet permission and an Activity that’ll be your ListActivity implementation. It’s important to that because our application uses an Internet connection to contact Twitter servers. After that you need to prepare your xml layouts and resources: you’ll find them into res folder.

Now there is the core of your application that it’s related to code implementation and in particular to the AsyncTaskActivity and HTTPUtil that you can read in the attached project.

  • HTTPUtil: it’s a very simple utility class that performs a get request and returns the result as String
  • AsyncTaskActivity: it’s the ListActivity implementation that I have provided to allow you to download some tweets from Twitter and show them on screen

Into your ListActivity implementation to avoid to stop your main UI Thread we’ll implement the data fetching into a background Thread. That’s not a good practise but a must that grants to user a good experience and  to avoid “Your application has unexpectedly…. bla bla”. Hence, I have provide an implementation of AsyncTask that allows you to perform into the background the following operations:

  • contact Twitter servers
  • retrieve JSON response
  • parse response into a List of Tweets

In fact all these operations are performed into doInBackground(….) method. All those updates those involves UI, in our case list refresh, are done in the UI thread and for that are done in onPostExecute(…). Pay attention that if you perform these actions out of your main Thread you get a fatal error and your app crashes relentlessly. If you try this tutorial on your mobile phone or into emulator you’ll obtain the screens that you can see in the SlideShow.

The solution that I have provided is very simple and there are other mechanism that connected to data persistance grants to user a better UE (user-experience).

I hope that this tutorial will be very helpful,


[TUTORIAL] MultiCheckableListView (by ids)

Hi guys, this time I want to furnish you a tutorial about ListView, SqliteOpenHelper and in particular an extension about CheckedView.

We’ll obtain a result like in these pictures and don’t worry if you see ICS: it’s backward compatible from android 2.2 Froyo.

This slideshow requires JavaScript.

(You can download this tutorial here)

As you can see in those pictures, we have got an Activity that allows user to fill a ListView with contacts names and pictures. At the same time user can clear it and check some of them.

The first of our steps is the creation of the database that will hold our data and the implementation of a basic DAO for our contacts.

So in the project under the path “it.trento.alchemiasoft.casagranda.simone.db” you’ll find the implementation of two classes:

  • Contact: bean representation of a contact and DAO implementation to perform some basic operations on Cursors and Database.
  • OpenHelper: an extension of the android SqliteOpenHelper that creates our Contacts Table performing an SQL statement.

Then we can prepare our <layout>.xml for our views:

  • pick_contacts_container.xml: it’s a RelativeLayout that contains two Buttons to clear and fill list, a particular ListView and an header with a title
  • simple_checked_contact_list_item.xml: another RelativeLayout that contains an ImageView to hold contact picture, and a particular CheckedTextview to keep selection state and hold contact name

Pay attention: I have said “particular” because as you can see the listview and empty label refer to id that the framework uses in a ListActivity to identify a listview and an empty label (so you can write your own layout instead of use the just inflated ones). Our list_item contains a CheckedTextView that has is checked symbol that refers to the one used by android.R.layout.simple_list_item_multiple_choice.xml

The last step of this tutorial is the implementation of our Activity that will manage next points:

  • Creation and maintenance of the application database
  • Data loading
  • Data persistence (including user selection to avoid losses after screen-orientation changes, …)

In TutorialActivity you’ll find this activity that is well commented and that allows you to understand step by step how I had built its life cycle and the related events.

The most important feature of the Adapter set into the ListView is that it uses “the database table _id field” to refers to list_item_views, instead of the position.

I have used an HashSet of Long to that and to keep trace of the inserted elements after rotation I store/restore these elements in the bundle with whom your Activity keeps its state.

If you have got doubts or if you want to thank me ( 😛 ) don’t hesitate to write me an email or under this post.

See you,


[TUTORIAL] Working with Fragments in a ViewPager



Hi to all, it’s time to post the first android tutorial in this blog and this time  I want to talk about the comunication mechanism between Fragments (you can find my other tutorials at

In this tutorial we’ll focused on a communication between two Fragment (one in the role of sender and one in the role of receiver) across a FragmentActivity, that’ll work as container and channel between them.

You’ll find the project as attachment.

Difficulty level: 3/5

Terms and Documentation that you have to know:

  • Fragment: it’s a piece of code and layout that works as it is inside a container
  • FragmentActivity: it’s a container that can ingest fragments
  • MessageLoader: in this project it’s an interface that defines a method to send a message between fragments
  • ViewPager: it’s a laoyut manager that allows user to flip with his finger between “pages”
  • FragmentPagerAdapter: it’s the adapter that’ll we associate to our ViewPager


We want to create a communication channel between two Fragments allowing our developer to pass information between them.

  • FirstFragment: it’s our receiver; it has a TextView that contains received message and a Button to reset the view.
  • SecondFragmet: it’s our sender; it has an EditText to digit our message and a Button to send it.

This goals will satisfied creating a sort of Publisher and Subscriber model between them.


  1. Our ViewPagerActivity eats our Fragments and choses to visualize the sender as first visible fragment
  2. The FirstFragment hasn’t a message in its TextView
  3. You need to flip, with your finger or sender button, to SecondFragment
  4. Here you can write a simple message
  5. The sent message will arrive to our FirstFragment travelling through the container

Download the project related to this tutorial (link).

What do you think about this tutorial? It’s useful to solve your problems and/or curiosities?

See you next time,