Sunday, July 8, 2012

Using null annotations for fields (currently beta) in Eclipse JDT Juno

It is common knowledge by now that Eclipse Juno's JDT shipped with support for null annotations for inter-procedural null analysis. This was very well-received and the work made it to several blogs about the 10 most interesting Eclipse Juno features. While this is only applicable to local variables/method parameters for now, I had also blogged about null analysis support for fields while we worked on it. However, due to the sheer complexity of dealing with problems such as aliasing, concurrency, etc with fields and the current infrastructure's limitations in dealing with these issues comprehensively, we had to withdraw this feature. Because of this, Juno did not come with null annotations support for fields.

However, the good news is that along with the Juno release, the JDT team, with all due credits to Stephan Herrmann, also released a public beta version of null annotations support for fields. Please visit the null analysis beta wiki page to learn about installation and usage of this feature. As Stephan puts it in his post on DZone, "feedback to this experimental solution should help us to decide what will be JDT's final solution regarding null analysis for fields". So, please start using it if you've upgraded to Eclipse Juno. If not, what are you waiting for? ;)

Sunday, May 13, 2012

Monetizing your mobile apps using IBM Worklight and Ad networks - Part 2

In part 1 of this article, we discussed how to leverage ad networks to monetize your apps by showing targeted advertisements through simple tweaks using the ad network SDKs.

Another, relatively less explored way of advertising when you do not want to go through the ad networks or just want to use your app to advertise your own business, is to use IBM Worklight adapters and push notifications.

What are Worklight adapters? An Adapter is a transport layer used by the Worklight Platform to connect to various back-end systems. Worklight supports SQL and HTTP adapters out of the box, which means you can also do RESTful operations using the adapter.




















Some ways in which you can use adapters are:
  1. The simplest way an adapter can be used to retrieve ads is to create a UI element on a page in your application and render this UI element using the data returned from an adapter, which can fetch advertisements from a back-end enterprise database. For example, if you're working with an android app, create a web view using height as "wrap_content". You can also use other UI elements such as Gallery for images or layouts. And then call your adapter to fetch the ad-related data to be rendered in the UI element.
  2. Use two or more worklight adapters to mashup data and display targetted advertisement. Eg: Get the city from a page where the user has to select his city -> use an adapter to query a database to fetch a city ID -> use another adapter which can fetch ads related to that city ID from another data source or application. The worklight city weather demo app shown below is a great example of how such a mashup can be done. Read the Worklight mashup tutorial to learn more.


Adapters can be combined with push notifications to yield yet another way of showing ads. How can this be done? An adapter can listen to an event source and push advertisements as notifications through the app store mediator (Google, Apple). These notifications can be in the form of a notification dialog or a badge. (A badge is a small notification which appears on the corner of the application icon - think facebook mobile app which shows notifications and message alerts right on the icon). The worklight server comes with a browser-based console that can be easily used to dispatch notifications to all devices that have the app installed and subscribed to the notifications.These ads are nice when a user has installed the app and subscribed to the notifications, although they don't provide a very powerful way of in-app advertising, which can be done using ad network integration or adapters. A good example of push notifications is special offers that your business rolls out from time to time. Eg: Christmas Offer - Upgrade to the full version of the app at just 49c. Push notifications give you the power to broadcast ads whenever you want to, thus customizing them according to the needs of your business. The figure below shows how the worklight push mechanism works. 


Push notifications can be used in other ways as well. You can  use them to notify users of new versions or upgrades of the app as soon as a build becomes available. This method truly combines the power of effective lifecycle management of mobile apps with the Worklight builds. This even works in the context of enterprise apps where the primary users of the app are the employees themselves. Eg: if you're using IBM Rational Team Concert (RTC) and you build your app using the Jazz team builds, you can create an adapter that listens to the Jazz server  (or an app store) and as soon as a new build of the app is available, automatically sends push notifs to all devices with the app to upgrade to latest version. Additionally, RTC source control can help in modularizing the adapters into components, so that different departments/units in the company can maintain their own components independently of the apps and yet support an app which is used across departments/units.

Note: To send push notifications to Android devices, you will need to use Android Cloud-to-Device Messaging (C2DM). You need a valid Gmail account to register to Google’s C2DM service at http://code.google.com/android/c2dm/signup.html. To send push notifications to iOS devices, you will need to use Apple Push Notifications Service (APNS).

There are also other powerful tools that can help in making sure that the ads you render, either through ad networks or adapters have a look and feel of your app, and don't look forcefully shoved in. While you cannot control the way the ad will be shown, because they're creatives of a third-party, you can ensure that the UI widget in which the ad appears matches your app's look and feel. You can add custom style sheets to the UI elements if you're using say, the Javascript SDK of InMobi which integrates directly with hybrid/ mobile web apps. You can even use tools such as IBM Rational Application Developer which provide WYSIWYG editing for commonly used UI toolkits such as Dojo mobile.

So join the mobile bandwagon and start making money from your apps!

Catch me at IBM Innovate 2012, and hopefully not by the collar! ;)


Monetizing your mobile apps using IBM Worklight and Ad networks - Part 1

While mobile has become a platform that can no longer be ignored by businesses and developers alike and efforts are on way almost in all industry sectors to leverage this platform, it is silently becoming one of the best marketing and advertising platform of our times. Why? With 300,000+ apps and 10 billion downloads in the last 3 years alone, people are spending ever-increasing amounts of time on their smartphones. The mobile revolution has been much faster than the PC revolution in its reach and adoption. "Mobile media consumption is growing fast, as people worldwide are now spending more time on their mobile devices than watching TV. In the U.S., people are spending about 142 minutes a day on their devices, compared to 135 minutes for TV and 96 minutes on PCs, making mobile the primary media consumption channel in the nation.", says InMobi's Anne Frisbie. An infographic I stumbled upon recently has some even more convincing numbers. Click on the image below to see the complete infographic.




That being said, how does an application developer or an enterprise show targeted ads to consumers or clients? The more popular approach is to incorporate ad banners that can be used to show ads from a mobile ad network such as Google AdMob or InMobi. What are mobile ad networks? They're agencies that purchase ads from companies who want to promote their products on mobile apps. An app developer, also known as a publisher, gets paid on different pricing models if he agrees to show those ads on his app, using the SDKs or services provided by the ad networks. You can read more about the different kinds of ad networks here


While its relatively easy to use these SDKs in native applications, its still not straightforward to do so in a hybrid or mobile web application, which are becoming more popular with the cross-platform advantage they offer. So if I'm developing, say, a hybrid app, how do I use say, the Google AdMob SDK, which is primarily for an Android app? IBM Worklight, part of the IBM Mobile Foundation is a powerful development platform which allows you to do this easily. Here are some steps that outline how native ad SDKs can be used along with a hybrid app:


1. Create a Worklight project, adding all the common web code to the 'common' folder and overriding Android specific behavior in the 'android' folder by creating a new Android environment. If you're new to Worklight, you can read the Worklight tutorials to learn how to work with a Worklight project.




3. Add the SDK JAR to the android>native>libs folder.

4. Declare com.google.ads.AdActivity in AndroidManifest.xml located in the android>native folder.

5. Setup the required network permissions(INTERNET and ACCESS_NETWORK) in the AndroidManifest.

6. Now navigate to android>native>res>layout>main.xml and open it in the xml view. You will see a single WebView declared in the xml. All you need to do is add an AdView to the layout right above the WebView



<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >    
     <com.google.ads.AdView android:id="@+id/adView"
                         android:layout_width="wrap_content"
                         android:layout_height="wrap_content"
                         ads:adUnitId="MY_AD_UNIT_ID"
                         ads:adSize="BANNER"
                         ads:testDevices="TEST_EMULATOR, TEST_DEVICE_ID"
                         ads:loadAdOnCreate="true"/>

     <WebView android:id="@+id/appView"
     android:layout_height="wrap_content"
     android:layout_width="fill_parent"
     />

</LinearLayout>

Voila! You have your add banner in the application. An alternate way of doing this would be to first generate the Android project from the Worklight project by using "Build Environment and Deploy" option, and then modify the main.xml in the native Android project using the nice UI.

Any native code for the ad banner such as ad listeners etc. can be added to the Android activity class which references the main.xml or any other layout where the ad was added. For example:
public class HelloWorklight extends WLDroidGap {
    @Override
    public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       super.loadUrl(getWebMainFilePath());
    }        
}


In the same fashion, you can add Interstitial ads by combining native and web pages in the Worklight project. Also, you can add ads into iOS/ Blackberry/ Other apps using the other SDKs provided by Google AdMob, InMobi and other networks.

In the part two of this post, I'll discuss how to use Worklight adapters and push notifications to render ads for your own business through your database or other data sources.

Friday, March 2, 2012

Contributing to Eclipse Java Development Tools project

In recent times, we've been getting several contributions in the Eclipse JDT project. Thats a great thing and we want to encourage that. However, several times small issues viz. patch not based on latest code, formatting issues, whitespace issues, failing tests etc. delay the process of review and release. It is painful for both the contributor, as well as the JDT committer.

In order to make sure all JDT contributions go through a standard series of steps before they make it to bugzilla, we've updated the contributing to JDT/UI and the JDT/Core FAQ page. Please spend a few minutes reading through the steps and go ahead to submit a patch on bugzilla. Looking forward to more community participation in both JDT projects.

Also, whenever you start working on a bug, please drop a small comment on the bug page to say you intend to submit a patch, to avoid duplication of effort. Thanks! :)

Saturday, February 18, 2012

Null analysis for fields in Eclipse JDT withdrawn for Juno

Null analysis for fields with Eclipse JDT , introduced in Juno M5, has been withdrawn and will not be available in the Juno release. Only Juno M5 will contain this feature. The reason for withdrawal is the fact that becuase of implementation constraints, it could not support analysis for alien field references i.e. non-static fields of objects other than 'this'. We will rework the implementation and come back with a full fledged support for fields, including annotations to support null analysis for fields. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=247564#c176 for more details.



Apologies to those who were looking forward to a complete null annotations support for fields as well. We are considering making the current implementation of the feature available as a plugin patch. I will keep you posted.

Also, even when using annotations for method return and parameters, be careful in dealing with fields because we don't warn there. Eg:

class A{
     Object o = null;

     void goo(@NonNull Object param) {}
     @NonNull Object foo() {
            goo(this.o);
            return this.o;
       }
}

Monday, January 30, 2012

Null Analysis for Fields with Eclipse JDT

It is common knowledge that Eclipse has an intra-procedural null analysis capability, augmented recently with null annotations for inter-procedural analysis in Juno M4. However, a big flaw and pain point till now was that the anlsysis would only work for local variables/parameters, and NOT for fields! Strange, innit? Well, a bunch of problems with handling fields prevented the initial null analysis implementation to be generic enough to handle fields as well. Access from different threads, through different objects, initialization of even final fields in different constructors were some of the roadblocks because of which this work was put on the backburner. However, even though we haven't found a holy grail to tackle these problems, we've come out with atleast a basic implementation of null analysis for fields! Rejoice!

A. The Problem
Prior to Juno M5, the following code snippet would raise null warnings only on the local variable, but not on the field.


B. The Solution
See the Juno M5 new and noteworthy page for the new null analysis for fields.
Note that for non-constant fields, we only raise "potential NPE" warnings even if the field has been assigned null or compared against null because we assume that there's always a chance of another thread modifying it between the assignment/comaparison and the actual reference. So consider the following snippet


C. Not quite there yet?
There are a few limitations with the current null analysis for fields:
  • Yet to be done for final fields that are initialized at the time of declaration. This will be done with the fix for bug 237236 soon.
  • The analysis only works for non-static fields of the current object or static fields of the current type ONLY. That means, in the following code snippet. you get null warnings on direct access of field1 or access via "this", but not if field1 is accessed via another object 'test'.
class Test{
   public Object field1;

   void foo(Test test) {
      if (field1 == null) { 
         System.out.println( field1 .toString());  // "potential" NPE warning
     } else {
        // do something
     }
     System.out.println(field1.toString());  // Potential NPE warning here

     if (this.field1 == null) { 
         System.out.println( this.field1 .toString());  // "potential" NPE warning
     } else {
        // do something
     }
     System.out.println(this.field1.toString());  // Potential NPE warning here
    // access through object 'test' will raise no warnings. See below

     if (test.field1 == null) { 
         System.out.println( test.field1 .toString());  // no warning
     } else {
        // do something
     }
     System.out.println(test.field1.toString());  // no warning


  }
}

This is a limitation of the current code analysis infrastructure and we hope to address this sometime soon. The soon to be released null annotations support for fields will greatly assuage this problem in the short term.

Please do start using this new feature. Even with its limitations, its quite useful and we've found a long list of unsafe code patterns in the Eclipse SDK itself. Deepak's post here presents one such example


Apart from this, Juno M5 has more interesting items. See my previous post on pre-built indexes, Stephan's post on Resource leak warnings and the Juno M5 new and noteworthy page for more.

Stay tuned!



Thursday, January 26, 2012

Faster Java search using pre-built indexes with Eclipse JDT

JDT indexes referenced libraries (or JARs) in your projects for use in the Java search. However, in most cases these libraries seldom change, and the indexing may be costly and take time when you invoke search for the first time after adding the JAR on the buildpath.

From 3.8M5 onwards, you can avoid this redundant indexing by providing a pre-built index for each classpath entry in the classpath container. This feature was recently implemented in bug 356620.

So how do you generate the indexes in the first place?
1. Create the JAR
2. Go to Run Configurations>Eclipse Application. Give a name to the configuration, viz. indexer, and in 'Main' tab choose Run an application, and use the list to select org.eclipse.jdt.core.JavaIndexer

3. Go to the 'Arguments' tab and use the arguments -option <indexFileLocation> <jarFileLocation> in addition to the existing ones.

4. The index file will be generated at the specified location.

Now when the JAR in question is being added to the build path of a project, the classpath containers can add the index location to classpath, which will look as follows:

<classpathentry kind="lib" path="C:/Users/IBM_ADMIN/Desktop/TestIndex.jar">
<attributes>
<attribute name="javadoc_location" value="file://C://abc"/>
</attributes>
</classpathentry>

Voila! JDT will no longer index the JAR and even the first search will be lightning fast!

Note: This feature is mainly intended for plug-ins that implement their own classpath container, not for the end user.