Mobile Java Application used for mobile banking are a great idea, but they do come with some few complexities. J2ME is great, the application is sandboxed on the device so there is little bit more security, the Java application will run on a number of handsets, they are written in java and not some obscure phone OS, but two issues in particular bother me.
Although the application is in Java and will run on a wide variety of handsets, there is a complexity firstly to make the user interface look 'nice' on different screen sizes and phone types. The Java APIs and classes on different handsets also differ so whenever your application does something that is not within the standard J2ME spec you are not sure whether it will work or not on all the handsets and this forces the application to be tested on every handset that you want to support. This is a huge overhead for testing and there does not seem to be a clear solution to the problem.
The second issue, particularly with banking applications is that to reduce network traffic you would like to save some data on the device. If you do this you have a big problem because users often change their phones. Even if there is a process to 'rebuild' this data from the server what happens to the data on the old phone. It is not likely that the average user would delete the application and therefore this data could get into the wrong hands. If no data is stored on the phone then you do not get much gain over using J2ME vs simply using the phone's web browser.
Wednesday, June 25, 2008
Choosing an application server
How do you go about choosing a Java application server? We are currently in the process of doing this and after much deliberation we have come to the following conclusion. There are only really a handful to choose from: IBM Websphere, Sun GlassFish, JBoss, BEA Weblogic and Oracle. Oracle has just bought BEA Weblogic so one of these will be phase out over time. So right I am not sure which one more clarity on this will probably be available from Oracle soon. So the first question is cost. JBoss and GlassFish are free and only require a support license so if you want to embed or setup the app server as part of your product then I would choose one of these. IBM Websphere has all the bells and whistles, but in my mind is far to bulky for most applications and besides the last time I looked it only supports the IBM Java VM. This Java VM is always at least few months behind the Sun VM in terms of supported Java versions.
The next question is whether your client requires a 'big name' behind the server. This eliminates JBoss as it is perceived to be open-source and therefore unreliable. Although in practice this is not the case.
So the bottom line is that with the uncertainty of the BEA-Oracle takeover, Websphere's bloat and JBoss being opensource, the only real option at the moment is Sun's GlassFish.
The next question is whether your client requires a 'big name' behind the server. This eliminates JBoss as it is perceived to be open-source and therefore unreliable. Although in practice this is not the case.
So the bottom line is that with the uncertainty of the BEA-Oracle takeover, Websphere's bloat and JBoss being opensource, the only real option at the moment is Sun's GlassFish.
Thursday, June 19, 2008
Coding with incomplete specs
With the current project deadlines it is important to have coding techniques which work when the specifications are being developed after coding has started. So how do you do this. I use two techniques:
Delay decisions as long as possible
I group the work items of an increment into three types namely:
Items that are fully spec'ed with specs that will not change, items that have incompete specs and then items that are fully spec'ed that might change due to dependencies on other incompletely spec'ed items.
First I tackle the completely spec'ed items that will not change and in parallel firm up the specs of the incomplete items that have dependencies.
Next I tackle the items that are completely spec'ed by still have dependencies on incomplete spec'ed items. Choose the order of these items and make a firm best guess decision using all the information that you have at this point on what the dependent item spec would be. After these items are developed the and the best guesss decisions are make ther might be some changes required later where you guessed incorrectly, but the decisions you have made will help define the outstanding specs.
Note that this is not procrastinating, it is a process of waiting as long as possible before you make the decision so that you can make the decision with as many facts as possible. Make a firm decision based on all the facts you have at that time.
Isolating unknown areas of code
The second technique I use is to isolate and code where the specs are unclear. Typically I would create an interface to the unspec'ed area or create a stub of some sort. This allows me to continue with the development without worrying about the details of the unspec'ed or unclear portion of code. When these spec's become clear I can then flesh out the stub or implement the classes according to the spec without impacting the other code.
Delay decisions as long as possible
I group the work items of an increment into three types namely:
Items that are fully spec'ed with specs that will not change, items that have incompete specs and then items that are fully spec'ed that might change due to dependencies on other incompletely spec'ed items.
First I tackle the completely spec'ed items that will not change and in parallel firm up the specs of the incomplete items that have dependencies.
Next I tackle the items that are completely spec'ed by still have dependencies on incomplete spec'ed items. Choose the order of these items and make a firm best guess decision using all the information that you have at this point on what the dependent item spec would be. After these items are developed the and the best guesss decisions are make ther might be some changes required later where you guessed incorrectly, but the decisions you have made will help define the outstanding specs.
Note that this is not procrastinating, it is a process of waiting as long as possible before you make the decision so that you can make the decision with as many facts as possible. Make a firm decision based on all the facts you have at that time.
Isolating unknown areas of code
The second technique I use is to isolate and code where the specs are unclear. Typically I would create an interface to the unspec'ed area or create a stub of some sort. This allows me to continue with the development without worrying about the details of the unspec'ed or unclear portion of code. When these spec's become clear I can then flesh out the stub or implement the classes according to the spec without impacting the other code.
Tuesday, June 17, 2008
Mobile Channels
Yet again I see a newscast of a mobile application that was developed in a 1st world country being deployed into a 3rd world country assuming that the environment is similar to what they are used to. This article covers a deployment into Africa, but they want to deploy a Java based solution! Most users in Africa do not even own a compatible handset. It is essential when purchasing or building a mobile application to look at the demographics and environment of the target market to ensure compatibility or else you will be severely limiting your reach.
Continous Builds
Continuous builds are an XP and Agile developer process. It is a process where changes made by the development team are automatically picked up and then followed by a build and a set of automated tests. This the generates a dashboard of all the code modules and their current state. Flagging broken tests or code. Developers can then pick these up and fix them as soon as possible before continuing with more development.
We use Hudson (https://hudson.dev.java.net/) because it is very easy to setup, integrates easily to any and maven as build tools and CVS and SVN for the version control.
The key thing to get right when setting up a continuous build server is to ensure that the build and automated testing can run without user interaction and outside of any IDE. It is no good having unit test that work from inside Eclipse, because you need to be able to run these in a batch type mode. Without this ability, you will always be relying on your developers/testers to run these tests and under pressure this is the first thing that a developer will stop doing right.
Hudson also has the ability to run and report on other checks such as code coverage of the automated tests and 3rd party tools to check for silly coding mistakes. We are using Cobertura (cobertura.sourceforge.net/) for code coverage and Findbugs (findbugs.sourceforge.net/) for code checking and they both work really well particularly in Hudson where we can flag tests that do not have enough code coverage.
We use Hudson (https://hudson.dev.java.net/) because it is very easy to setup, integrates easily to any and maven as build tools and CVS and SVN for the version control.
The key thing to get right when setting up a continuous build server is to ensure that the build and automated testing can run without user interaction and outside of any IDE. It is no good having unit test that work from inside Eclipse, because you need to be able to run these in a batch type mode. Without this ability, you will always be relying on your developers/testers to run these tests and under pressure this is the first thing that a developer will stop doing right.
Hudson also has the ability to run and report on other checks such as code coverage of the automated tests and 3rd party tools to check for silly coding mistakes. We are using Cobertura (cobertura.sourceforge.net/) for code coverage and Findbugs (findbugs.sourceforge.net/) for code checking and they both work really well particularly in Hudson where we can flag tests that do not have enough code coverage.
Tuesday, June 10, 2008
Get Agile
Not only is it good practice but in the current environment it is essential that development of new feature is rapid. So with this in mind whether you are starting out on a new project or are adding features to an existing one it is very important that automated tests are built for the application. These tests should be both unit tests and integration tests.
For our unit tests we use JUnit and MockControl. You have probably all heard of JUnit, but possibly not MockControl. MockControl allows you to teach an interface to respond a certain way, thus allowing you to create a stub, but without the need to build a new class. It can check the number of calls made to the stub and it can respond a certain with a certain object by integrating the calling parameter values.
For our Domain layer we use an in-memory database such as HypersonicSQL for this type of testing.
Integration testing is a little more complicated since a certain amount of data needs to be available on the database. For these we use a database of the same type as the production database and load the database using DBUnit.
Next time I will look at automated build and continuous integration using Hudson.
For our unit tests we use JUnit and MockControl. You have probably all heard of JUnit, but possibly not MockControl. MockControl allows you to teach an interface to respond a certain way, thus allowing you to create a stub, but without the need to build a new class. It can check the number of calls made to the stub and it can respond a certain with a certain object by integrating the calling parameter values.
For our Domain layer we use an in-memory database such as HypersonicSQL for this type of testing.
Integration testing is a little more complicated since a certain amount of data needs to be available on the database. For these we use a database of the same type as the production database and load the database using DBUnit.
Next time I will look at automated build and continuous integration using Hudson.
Subscribe to:
Posts (Atom)