Xml on despatches

JBossWS CXF - POJO vs Stateless [1104]

Sat, 05 Nov 2011 15:32:32 +0000

Cleaning up a bunch of code to reduce object instantiations got me thinking about the webservice layer. We are using POJO based webservices but it got to me wondering whether useless Stateless web service beans would improve memory usage. More accurately, whether it would improve garbage collection performance.

To test this, the plan was to build two versions of the same web service and load test it to see the memory and cpu utilisation to compare cost / performance.

In the process, I also discovered other differences.

Both the web services were built against this interface

```java @WebService public interface WSTest { @WebMethod public String greetClient(String name); } ```

That is of course a simple enough interface.

The EJB version of this is as follows:

```java @WebService(endpointInterface = "uk.co.kraya.wstest.WSTest") @Stateless @Remote(WSTest.class) public class EJBWebTest implements WSTest { public String greetClient(String name) { return "EJB Says Hello to " + name; } } ```

Simple and straightforward enough and the POJO version is not that different

```java @WebService public class PojoWebTest implements WSTest { @WebMethod public String greetClient(String name) { return "Pojo Says Hello to " + name; } } ```

I also used the following web.xml. This may not be a necessary step any more.

```xml

Archetype Created Web Application

GreetingWebService

uk.co.kraya.wstest.pojo.PojoWebTest

GreetingWebService

```

Now that was complete, there was the deployment to consider. I had assumed that I could just do one build, package it as an war and just deploy it but as it turns out, that didn’t work. This only deployed the Pojo web service. To deploy the EJB web service, I had to package it as an EJB (maven) and deploy a jar file.

This meant that I ended up with two deployments, wstestpojo.war and wstestejb.jar.

Once deployed, I used SoapUI to load test both the web services and the results were interesting.

In the grand scheme of things, the difference was pretty minimal between the two. However, the Stateless EJB web service used a little extra (3% - 5%) CPU presumably from the pooling of the beans and accessing them.

I used JBoss 5.1 and ran into an issue with log pollution

EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

This was printed every time an EJB based web service was called.

I found more information about the EJBTHREE-1337 issue and a workaround for it The workaround simply involves updating log4j to not log it which is good enough for me… :-)

As a final note, I am unsure as to how this would scale with complex web services that have multiple instantiated objects as part of it. I have a sneaky suspicion that web services with expensive object instantiations would perform better if using Stateless EJB Beans as would web services that are memory hungry. However, this has not been tested.

Android - Managing Global Configuration

Sun, 25 Apr 2010 00:39:13 +0000

The Problem

Accessing preferences / configuration / settings from Android is actually pretty straightforward as long as you are in an Activity. To read:

```java // PREFS_FILENAME = "nameOfPrefsFile"; SharedPreferences pref = getSharedPreferences(PREFS_FILENAME, Context.MODE_PRIVATE); String string = pref.getString("key", "default"); // 1 is the default if key isn't set int intValue = pref.getInt("intKey", 1); // and so on ```

SharedPreferences is the key class. To write, you also need the [SharedPreferences.Editor](http://developer.android.com/reference/android/content/SharedPreferences.Editor.html{ class, as follows:

```java // PREFS_FILENAME = "nameOfPrefsFile"; SharedPreferences pref = getSharedPreferences(PREFS_FILENAME, Context.MODE_PRIVATE); Editor editor = pref.edit(); editor.putString("key", "value"); editor.putInt("intKey", 5); // Until you call commit, the changes will not // be written, so don't forget this step editor.commit(); ```

In general however, you will need access to settings in more than one activity and it seems a bit wasteful to get these bits littered through the application. Since I am lazy and like to write things just once, I separated all the prefs stuff into one class called Settings.

It has a constructor which takes a Context (We need this to access the SharedPreferences Object). It also has setters and getters for each property being saved. This example, just saves/retrieves a username and password.

```java import uk.co.kraya.HelloWS; import android.content.Context; import android.content.SharedPreferences; import android.content.SharedPreferences.Editor; /** * @author Shriram Shri Shrikumar * * This class stores and manages all the preferences * for the application. * */ public class Settings { private static final String USERNAME_KEY = "username"; private static final String PASSWORD_KEY = "password"; private static final String USERNAME_DEFAULT = "username"; private static final String PASSWORD_DEFAULT = "password"; private final SharedPreferences settings; /** * @param act The context from which to pick SharedPreferences */ public Settings (Context act) { settings = act.getSharedPreferences(HelloWS.PREFS_NAME, Context.MODE_PRIVATE); } /** * Set the username in the preferences. * * @param username the username to save into prefs */ public void setUsername(String username) { Editor editor = settings.edit(); editor.putString(USERNAME_KEY, username); editor.commit(); } /** * @return the username from the prefs */ public String getUsername() { return settings.getString(USERNAME_KEY, USERNAME_DEFAULT); } /** * * Set the password in the preferences. * * @param password password to save into prefs */ public void setPassword(String password) { Editor editor = settings.edit(); editor.putString(PASSWORD_KEY, password); editor.commit(); } /** * @return the password stored in prefs */ public String getPassword() { return settings.getString(PASSWORD_KEY, PASSWORD_DEFAULT); } // Check if there are any stored settings. // can be used to automatically load the settings page // where necessary public boolean hasSettings() { // We just check if a username has been set return (!settings.getString(USERNAME_KEY, "").equals("")); } } ```

Nothing particularly exciting. Now, how do we access this. The Android framework has a neat little feature that is not very well documented and it involved the use of the Application class. If you inherit from this class, and point to it in the manifest file, it will get initialised first before any other objects. This is an ideal place for bits that need global access. You could use Singletons or static fields but this works with the framework.

There are two parts to making this work

The application class:

``` public class MyApp extends Application { private Settings settings; @Override public void onCreate() { settings = new Settings(this); } public Settings getSettings() { return settings; } } ```

The onCreate method on MyApp will be called before onCreate on any of the Activities. The Settings class described above, needs a Context to be passed in. Lucky for us ;-) Application is also a Context.

You also need to wire it into the AndroidManifest.xml. You need to add the android:name element into the application tag{

```xml ```

Now that is all wired in, accessing the settings object from any activity is simple:

```java MyApp app = (MyApp) getApplicationContext(); Settings settings = app.getSettings(); ```

Easy - right? While you won’t be able to access the application subclass outside of a context, the Setting class, with its local context variable can be passed around with impunity :-D

Android - Multi-line Select List

Mon, 19 Apr 2010 23:37:54 +0000

It turns out that it is surprisingly easy to add a multi line select list to the UI. There are four main parts to it. The layout file, a subclass to the adapter, the activity and of course the data itself.

Lets start with the data. For the sake of this demo, lets use a simple contact list:

```java package uk.co.kraya.android.demos.MultiLineList.domain; public class Contact { private String firstName; private String lastName; private String mobile; public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } public String getMobile() { return mobile; } public void setMobile(String mobile) { this.mobile = mobile; } } ```

Some straightforward fields and getters/setters

Next, we need an Adapter. For this one, we will use a ArrayAdapter. We will extend it so that we can override the getView method.

```java package uk.co.kraya.android.demos.MultiLineList.domain.adapters; import java.util.List; import uk.co.kraya.android.demos.MultiLineList.domain.Contact; import android.content.Context; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; import android.widget.ArrayAdapter; import android.widget.TwoLineListItem; public class ContactArrayAdapter extends ArrayAdapter { private final int resourceId; public ContactArrayAdapter(Context context, int textViewResourceId, List objects) { super(context, textViewResourceId, objects); resourceId = textViewResourceId; } @Override public View getView(int position, View convertView, ViewGroup parent) { Contact c = getItem(position); // if the array item is null, nothing to display, just return null if (c == null) { return null; } // We need the layoutinflater to pick up the view from xml LayoutInflater inflater = (LayoutInflater) getContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE); // Pick up the TwoLineListItem defined in the xml file TwoLineListItem view; if (convertView == null) { view = (TwoLineListItem) inflater.inflate(resourceId, parent, false); } else { view = (TwoLineListItem) convertView; } // Set value for the first text field if (view.getText1() != null) { view.getText1().setText(c.getFirstName() + " " + c.getLastName()); } // set value for the second text field if (view.getText2() != null) { view.getText2().setText("mobile: " + c.getMobile()); } return view; } } ```

The key bit here is the getView method. We pick up the LayoutInflater which we can use to pick up the view that defines the TwoLineListItem view. This allows us to use two different snippets of text as part of the list. We then pick up the each of the TextView items and set the text against them. The formatting of these item are defined in the xml file.

The TwoLineListItem class also defines a placeholder for the selectedIcon. Check the documentation for more info.

The xml file for the layout goes as follows:

```xml ```

As you can see, we are just defining a TwoLineListItem element with two embedded TextItems. Tthe android:id parts are important. It ensures that the getText1() and getText2() methods work as expected!

Finally, we have the activity. In fact, we will be using a ListActivity as follows:

```java package uk.co.kraya.android.demos.MultiLineList; import java.util.ArrayList; import java.util.List; import uk.co.kraya.android.demos.MultiLineList.domain.Contact; import uk.co.kraya.android.demos.MultiLineList.domain.adapters.ContactArrayAdapter; import android.app.ListActivity; import android.os.Bundle; public class MultiLineListDemo extends ListActivity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setListAdapter(new ContactArrayAdapter(this, R.layout.main, getContacts())); } private List getContacts() { List contacts = new ArrayList(); Contact c; c = new Contact(); c.setFirstName("Shriram"); c.setLastName("Shrikumar"); c.setMobile("07777777777"); contacts.add(c); c = new Contact(); c.setFirstName("John"); c.setLastName("Doe"); c.setMobile("MOBILE.NUMBER"); contacts.add(c); return contacts; } } ```

getContacts clearly just creates a couple of contacts for the sake of the demo. its the setListAdapter that is the key here. It creates a new ContactArrayAdapter that we have written, passes in the context (which is just the current activity), a resource ID and a List of items to display.

Run it and you should see something like:

So easy when you know how. I believe could use a View or a ViewGroup as needed instead of the TwoLineListItem but I shall leave that to you to discover.

I have included all the files that I created/modified but if you want the whole project tarred up, just drop me a note ;-)