fernandes.io

Working on the same android app which I posted about a couple of times earlier, I had this one feature I wanted to implement where I show a list of persons and highlight those from that list who have a birthday today. I tried a couple of different approaches to to the "highlight" the list items which had a birthday today for e.g: setting the background colour for those items, setting up a background icon for those, changing the text colour of the list item, and with all of these I faced 1 common problem: if I had to scroll the list or expand/collapse one item group (in case of ExpandableListView ), then it would end up highlighting some random items from the list, and if I continued that excercise, finally almost all items would get highlighted. Since I had used an ExpandableListView , my getGroupView method looked somewhat like this: @Override  public View getGroupView(int groupPosition, ..., ViewGroup parent) {   Person person = (Person) getGroup(groupPosition);  ...

In an android app that I'm currently working on, I wanted use Android's Preference API to provide an interface to modify some app specific settings. I didn't want to create another Activity or PreferenceActivity for that, and hence I thought of simply using a PreferenceFragment . Now, in my project I already had a MainActivity ( extends ActionBarActivity ) which had a MainFragment wired up to it somewhat like this in it's onCreate method: getSupportFragmentManager().beginTransaction()  .add(R.id.container, new MainFragment())  .commit(); And because of that I knew that I had to replace the existing MainFragment with my new SettingsFragment which extended PreferenceFragment . With that in mind, I went ahead and added the following to my MainActivity 's onOptionsItemSelected : getFragmentManager().beginTransaction()  .replace(R.id.container, new SettingsFragment())  .addToBackStack(null)  .commit(); When I saw this work in the emulator, it looked some...

Back to blogging after a long time, and this time its quite a lame one which I usually wouldn't want to blog about, but I did spend close to an hour trying to figure out what I was doing wrong. I just started a small android application and was trying to send a paramter from one Activity to another. Now, after a bit of searching around, I found out that I needed to create an Intent Bundle and put the parameter in it, and the new Activity which gets started will be able to fetch it from the same Bundle using the key that was provided while inserting data into the Bundle . So, I had something like this in the first activity: Intent intent = new Intent(FirstActivity.this, SecondActivity.class); EditText nameText = (EditText) findViewById(R.id.query_textbox); intent.putExtra("queryKey", nameText.getText()); startActivity(intent); and something like this in the second activity: Bundle extras = getIntent().getExtras(); String query = extras.getString("queryKey");...

Lately I have been trying to get an openstack node up and running on an Ubuntu VM. For which, I was following a couple of the many guides available online. Everything went well until I found out that I was not able to create a user with an admin role using the nova-manage command. I was trying to run, nova-manage user admin openstack Much to my disappointment, I got the following error,  nova-manage: error: argument category: invalid choice: 'user' (choose from 'version', 'bash-completion', 'project', 'account', 'shell', 'logs', 'service', 'db', 'vm', 'agent', 'cell', 'instance_type', 'host', 'flavor', 'fixed', 'vpn', 'floating', 'network') I was a bit frustrated after going through the wiki for the nova-manage command which said that nova-manage was going away in the Folsom release of openstack, but never said anything about what is go...

When moving from Jetty 6 to Jetty 8, one of the biggest changes is the jump from Servlet version 2.5 to version 3.0. There is also a change in the JSP version which was 2.0 in Jetty 6.x while it is JSP 2.1 in Jetty 8.x. Keeping that in mind, the dependency for the servlet api needs to be configured to use Servlet 3.0 jars. This should have been sufficient if it wasn't for a change in "maven-jetty-plugin" also. Up to versions 6.x of the maven-jetty-plugin are available under the artifactId of "maven-jetty-plugin". So running, mvn jetty:run with the following in your pom.xml would be sufficient. <plugin>   <groupId>org.mortbay.jetty</groupId>   <artifactId>maven-jetty-plugin</artifactId> </plugin> But if you try to do that with Servlet 3.0, you would end up with a java.lang.ClassNotFoundException for javax.servlet.ServletRegistration$Dynamic.class This is because for jetty 7 and above, the artifactId for the plugin is "jet...

The Drupal API provides a function called db_create_table which allows you to create a table in your database. If you need to add a table for a module, after the module is installed, then you could use this function in your update hook. The documentation of db_create_table says that it accepts three arguments, an array which will contain the query result, the name of the table and an array containing the schema definition of the table. The schema definition has to be in the structure defined by the Drupal Schema API . What I recently noticed was, that db_create_table does not seem to accept primary/unique keys in the schema definition. It seems like you need to first create a table without any constraints. For this, you'll have to provide db_create_table with an array containing the schema without any key constraints. After doing that, you can use db_add_primary_key in order to create a primary key. Similarly, there is a function to create a unique key constraint - db_add_uniq...