The Agilists - Facebook Group

I have created a Facebook group (what is it?) named 'The Agilists'. As the name suggests, this forum is dedicated to foster collaboration among all agile practitioners (starting with those in my network).

If you are an agile practitioner or just interested to stay tuned, please feel free to join the group by clicking on the below link.
- Join 'The Agilists'

NOTE - Having a Facebook account is a prerequisite.

Frameworks enabling XP Engineering Practices on Android Platform

My recommended frameworks enabling engineering practices for android development:

1. Test Driven development: Use android Test Instrumentation Framework (Android extension to JUnit framework)
2. Automated Blackbox/Functional testing: Consider Robotium (Selenium for Android)

If you are interested, check these out (at your own risk)

1. Automated Build: AndroidAnt
2. (Alternate) Test Driven Development: Positron 

Hope this helps you in writing better Android Applications. 

Please feel free to drop a comment, if you come across any other framework enabling adoption of XP engineering practices on android development

Product lifecycle in an agile enterprise

Borrowing from Dean Leffingwell. 

Part II - Design patterns for scheduling a batch job in an Android Application

In my previous post we discussed usage of AlarmManager to schedule batch Jobs in Android Applications. In this post, we will dig dipper into design patterns specific to scheduled jobs executing resource intensive operations.

Any process having a Broadcast receiver object, is treated as foreground process and get's priority by Android Runtime. Consider a situation where you have a resource intensive process scheduled as a batch job. Let's say, the user has been playing a rich UI game (with significant frame changes/sec) when AlarmManager triggers your resource intensive job via the Broadcast Notification. Since BroadcastReceiver object gets priority in the order of execution, the user may experience slowness / lag in the application (i.e. the game in this case) running on the UI.

In order to circumvent this problem, it's recommended to design your batch job as a service within your application. Use AlarmManager to trigger the notification and let the BroadcastReciever start (or Bind to) the service to execute your job in the background. In this way, the user would not experience any impact on the application running on the UI. As with other components, don't forget to register the Service in the Manifest.

Sample code for registering a service in the AndroidManifest.xml

Refining further, one last scenario to be considered. What happens if your phone is already in a sleep-mode when the scheduled job gets triggered. Incidentally, you can set the 'type' parameter in the AlarmManager to wake-up the phone while Broadcast is being triggered. The Phone will automatically remain awake as long as the BroadcastReceiver is executing. However once the BroadcastReceiver object starts your service and completes it's scope, we run into the risk of the phone again going to sleep mode, there by stopping your (long running) background job abruptly.

To avoid such unpleasant situation, I recommend to obtain a Wake-Lock from PowerManager system service. Release the Wake-Lock after your background process completes successfully. This way you would ensure that your background process gets all due attention from the Android device.

Sample code for a service implementing a Wake-Lock

public class ScheduledPostService extends Service {

 @Override
 public IBinder onBind(Intent arg0) {
  return null;
 }
 
 @Override
 public void onCreate() {
  // initialize the scheduleTimer
  Log.d(Const.TAG, "Scheduled Post Service created");
 }
 
 @Override
 public void onStart(Intent intent, int startId) {
  
  // get a PowerLock
  // Retain the wake lock till this process completes
    
  PowerManager pm = (PowerManager) getSystemService(getApplicationContext().POWER_SERVICE);
  PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "SMSPost Tag");
  
  // Acquire lock
  wl.acquire();
  
  // perform your operation
  
  // Release lock
  wl.release();
 
 }
 
 @Override
 public void onDestroy() {
  super.onDestroy();
  Log.d(Const.TAG, "Scheduled Post Service destroyed"); 
 }
}

Don't forget to update the Android Manifest, giving permission to the application for using the WakeLock

Hope this has been helpful. Please feel free to share your experiences.

Design patterns for scheduling a batch job in an Android Application

In this post, I will discuss design patterns for scheduling periodic jobs in an Android Native Applications. For illustration, i will be referring to sample code from my SMSPost project.

Let's start by discussing how to trigger a job at a predefined time? For many developers, Android Services becomes the default choice. However scheduling jobs through Services is not an optimal solution. Here is why

• Running a service in the background all the time is a resource drain
• There is a risk that Android may terminate the service in case of shortage in RAM (Refer to Android process and lifecycle)

Thankfully Android provides APIs to tap into Android system services. The AlarmManager System Service proves handy in this case. For scheduling your job, simply tap into the AlarmManager and schedule a Broadcast Notification event at the desired time. You have flexibility to schedule any date/ time or set fixed intervals for initiating the Broadcast notification. Your application should provision for receiving these asynchronous Broadcasts and perform desired operations.




Sample code for setting a Broadcast using AlarmManager 

try {
     Long firstTime = SystemClock.elapsedRealtime();
     Intent intent  = new Intent(this, AlarmReceiver.class);
     intent.putExtra("alarm_message", "Alarm Scheduled!");
     PendingIntent sender = PendingIntent.getBroadcast(this, Const.url_REQUEST_CODE, intent, 0);

     AlarmManager am = (AlarmManager) getSystemService(ALARM_SERVICE);
     am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 60*1000, sender); // set your own frequency
} catch (Exception e) {
     Log.e(Const.TAG, "ERROR IN CODE:"+e.toString());
}

Sample code for Receiving the Broadcast Notification

public class AlarmReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
 // TODO Auto-generated method stub
  
 try {
      // your code for scheduled job goes here        
     } catch (Exception e) {
      Log.e(Const.TAG, "ERROR IN CODE:"+e.toString());

     } 
}

Up Next: We would explore design patterns further in specific cases where your scheduled job is expected to execute some heavy resource intensive operations 

How to conduct effective Sprint Reviews

Thinking out loud on how to conduct an effective sprint review. The points below are written keeping project teams in mind.

Structuring the Sprint Review

• Set an objective for the Sprint review (i.e What do you want to achieve out of the meeting?)
• Start with your sprint goal (if you don't have one, spend a few minutes in sprint planning to set one). Share a subjective assessment on how the team fared against the sprint goal
• Outline how the progress on each story (of the sprint) lead towards the eventual sprint goal

Conducting the Sprint review

• Make sure the logistics are in place (Phone, webex, sametime etc) before the meeting
• Organize the sprint review around demo of working-software (though no doubt, but very effective)
• The Project team should drive the meeting (i.e make sure you are sharing your screen, you are showing the features and answering queries)
• Pause at appropriate time to encourage discussion on the value being delivered

Avoidances (if you do any of the below mentioned, you are wasting time)

• Reading stories from the backlog
• Focusing too much on the story points (vis-a-vis actual value being delivered)
• Treating sprint review as just a progress update

Are your project sprint reviews effective? Think again, and please feel free to add your perspective.

Five levels of Leadership

"Five levels of Leadership", Quoting John Maxwell

I couldn't have agreed more. All Managers start at level 1. The picture above outlines what it takes to make a transition from being a good Manager to be a good Leader.

thoughts?