It is very easy to create a mock objects of your Spring layer, and not only does it allow you to create a consistent junit tests, but in the process you will end up with a mocked spring layer which you can use for fast front-end development!
Let’s see how.

First of all, junit testing of Stripes comes in a two flavors, first one invoking your action beans directly and as expected is a simple approach but with a big disadvantage (among others) – you can not test spring beans as injection is not started. Second approach, which really looks much more convenient and is introduced into Stripes with version 1.1.1 (wow, that was 6 years ago!) is so called “Mock Container Usage Approach”, so it requires a little bit more work.

For the later, we need to create a MockServlerContext which we will use for each test, so we want to do it with a singleton class (it takes a while to initialize MockServletContext as it actually boots the simulator container). After that, in each test we create MockRoundtrip (based on mocked context), which is a simulation of a request. So, for MockRoundtrip, we set parameters which would “in real life” be set from the JSP (or other presentation layer, Stripes authors mention that FreeMarker can also be used with Stripes), call “execute” and then assert results. But i have skipped the important part and that is configuring of MockServlerContext. This is done java-style, in our singleton, and simulates web.xml configuration. Here i will just say that this is the place where we define which spring configuration file we want to use. But let me first just say a few words about spring mock object and i will return here really fast.

So in our project we connect to the remote server using the REST paradigm, while communicating using JSON objects. This is slow when looking from the perspective that for junit tests you do not really depend on over-the-wire communication, and you know how it goes, test servers are shared among many people and so on, and also, you do not want your junit tests to really on the data that everybody can edit, right? So one layer of junit tests is definitely this, connecting to mock objects that do include spring beans, but not the real ones that use REST calls, but fake ones, that just return some fixed data.

And i promised to return to MockServletContext configuration, so now is the good time because there the developer specifies that the configuration that will be used is the one that points to the mocked spring layer. That way, our junit tests are fast and consistent.


filterParams.put("ActionResolver.Packages", "your.package.with.actions");
filterParams.put("Interceptor.Classes", "net.sourceforge.stripes.integration.spring.SpringInterceptor");
filterParams.put("ActionBeanContext.Class", "your.subclass.of.ActionBeanContext");
filterParams.put("LocalePicker.Locales", "en_US:UTF-8");
mockServletContext.addFilter(StripesFilter.class, "StripesFilter", filterParams);

// spring configuration file
mockServletContext.addInitParameter("contextConfigLocation", "classpath:applicationContext.mock.xml");

Once you have established two versions of spring configuration, it is extremely easy to switch between those two: it is a matter of commenting/uncommenting a line in your web.xml.

For more details on this subject see this, or just ask :)

Recently, we worked on a project that required frequent polling of database table, processing each row, and writing output to different database table(s). The data tables are incoming and outgoing sms messages, and load would get quite high sometimes. We also had to support load balancing. Since our services are already done with spring – the choice was to try Spring Integration.

So what is Spring Integration? “Spring Integration provides an extension of the Spring programming model to support Enterprise Integration Patterns. It enables lightweight messaging within Spring-based applications and supports integration with external systems via declarative adapters.”

Basic concepts when designing Spring Integration applications are Messages (java objects with metadata), Channels (pipes that messages go trough) and Message Endpoints.
Message endpoints can be various – like Transformer (transforms data), Router(route data), Filter (filters data), Splitter (splits messages), Aggregator (inverse of Splitter), Service Activator (connecting messages to Services) and most important Channel Adapters.

Channel Adapters connects Message Channels to “external” world. They can be inbound (create new messages) and outbound (consumes messages). The choice of connection type is pretty big – like AMQP, JDBC, Web Services, FTP, File, HTTP, TCP, UDP, JMS, Mail, MongoDb, RMI, XML, XMPP, Stream and even Twitter.

Spring Integration Sample

Back to our application. Its very easy to add polling of database table. Just add Jdbc Inbound Channel Adapter that will poll database table with query that you specify (load balancing is working as we are using oracles “select for update nowait skip locked” syntax which skips rows with read lock). Specify properties like channel (name of channel where will message go), data-source, row-mapper (converts table row to java objects), update (query that is executed after table is read – you want to delete row once it is processed or put some flag) and fixed-rate (polling interval). There is also possibility to add transaction support , or define cron expression instead of fixed rate polling, but we didn’t need that. What we needed is to add Thread pool with Spring Task Executor, and combine this with Spring Integration by setting message channel as ExecutorChannel

	<int-jdbc:inbound-channel-adapter query="${db.select.userrequest.query}"
		channel="smsInboundChannel" data-source="dataSource" row-mapper="userRequestMapper"
		update="${db.delete.userrequest.query}"  max-rows-per-poll="${db.poller.maxrowsperpoll}" >
			<int:poller fixed-rate="${db.poller.fixedrate}"  >
			</int:poller>
	</int-jdbc:inbound-channel-adapter>

That's it. Now we just needed to make a Spring Integration chain. Add splitter to separate messages per row. Add Service Activator to process message. Finally add Jdbc Outbound Channel Adapter to write to database.The possibilities are numerous. And since everything is done using Spring concepts, the code is easily maintainable and testable.

This example is extracted from a web aplication project build on dependency injection framework Google Guice. To compliment dependency injection, Guice supports method interception that divides a problem into aspects rather than objects. This feature enables you to write code that is executed each time a matching method is invoked. It’s suited for cross cutting concerns (“aspects”), such as transactions, security and logging.

Now lets define our simple user base with this three types:

public enum UserType {
     ADMIN,
     CUSTOMER,
     GUEST;
 }

To mark select methods that need user validation, we define an annotation:

import com.google.inject.BindingAnnotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@BindingAnnotation
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequiresUserType {
    UserType value();
}

…and apply it to the methods that need to be intercepted:

public class ProductService implements IProductService {

    @RequiresUserType(CUSTOMER)
    public Product view(Key key) {
        ...
    }

    @RequiresUserType(ADMIN)
    public void delete(Key key) {
        ...
    }
}

Next, we define the interceptor by implementing the org.aopalliance.intercept.MethodInterceptor interface. When we need to call through to the underlying method, we do so by calling invocation.proceed():

public class UserValidationInterceptor implements MethodInterceptor {

    public Object invoke(MethodInvocation invocation) throws Throwable {
        final UserType requiredType = invocation.getMethod().getAnnotation(RequiresUserType.class).value();
        //cross check current user type and throw an exception if validation fails
        ...
        //if everything checks out proceed to method execution
        return invocation.proceed();
    }
}

Finally, we configure everything. This is where we create matchers for the classes and methods to be intercepted. In this case we match any class, but only the methods with our @RequiresUserType annotation:

import com.google.inject.AbstractModule;
import com.google.inject.matcher.Matchers;

public class SecurityModule extends AbstractModule {
    protected void configure() {
        bindInterceptor(Matchers.any(), Matchers.annotatedWith(RequiresUserType.class), new UserValidationInterceptor());
    }
}

The method interceptor API implemented by Guice is a part of a public specification called AOP Alliance. This makes it possible to use the same interceptors across a variety of frameworks.

In smaller projects or when objects in question are localized to a smaller number of classes, we can find the bug by static code investigation. But if the object is used in a larger scope and often conditionally, we might want to take a look at what is going on in runtime.

To trace memory management related calls to our class, we will need to expand retain, release and autorelease methods. Simplest variant will just call super method, so we can put a breakpoint and see where is it called from. This can be useful, but usually there are lots of instances of the same class and lots of calls to those methods, so this isn’t really practical. It would be much more practical to log all calls to retain/release/autorelease and then dump the data when we need it. We can save three types of information to our log – current event (is it release, retain or autorelease), current time and what is most important, call stack trace so we know how exactly did we end up here. All this information can be stored into a simple array which will we add to the class we want to trace (of course, we want to allocate and release this array where appropriate).

NSMutableArray* _memTrace;

We can fill the _memTrace array with a call to the following method:

-(void) addMemTraceEvent:(NSString*)event
{
    [_memTrace addObject:[NSString stringWithFormat:@"%@ %@ at %@",
                          [NSDate date],
                          event,
                          [NSThread callStackSymbols]
                          ]];
}

We are using [NSDate date] to get current date and time and [NSThread callStackSymbols] to fetch current call stack trace.

To dump _memTrace, we can use following code:

-(void) dumpMemTrace
{
    NSLog(@"%@", _memTrace);
}

We can now update our memory management methods, so they log all calls to them:

-(void)release
{
    [self addMemTraceEvent:@"release"];

    [super release];
}

-(id)retain
{
    [self addMemTraceEvent:@"retain"];

    return [super retain];
}

-(id)autorelease
{
    [self addMemTraceEvent:@"autorelease"];

    return [super autorelease];
}

Now, when such updated object makes a Zombie access exception, we can simply call -dumpMemTrace from gdb’s command window, examine the log and find the extra release.

After setting up the required environment (see links below), we need a class that will implement EntryPoint interface, which will force it to implement onModuleLoad() method, with self-explanatory name.

Now, let’s create our tree structures:

Tree leftTree = new Tree();

leftTree.setModelType(TreeModelType.CHILDREN);

leftTree.setRoot ...

Setting model type to CHILDREN means that we will specify children nodes for each node. Other way would be to use PARENT type and then we would be specifying parent ids for each node that has a parent.

We set the actual data using setRoot method. I omitted the details for readability here. Numerous other method for filling up the tree could be used also, like variants of simple add, addList or even connecting our structure to some data source like XML Schema, relational database or EJB.

Note that this is only a data structure and we still need some “physical” representation:

final PartsTreeGrid leftGrid = new PartsTreeGrid();

leftGrid.setDragDataAction(DragDataAction.MOVE);

leftGrid.setData(leftTree);

grid1.getData().openAll();

DragDataAction.MOVE means that the dragged item will not stay in the originating tree (in contrast to DragDataAction.COPY).

setData is used to bind earlier created data-set to this graphical representation.

PartsTreeGrid is actually a custom extension of TreeGrid adding some face-lifting instructions, and i will emphasize only these lines here:

setCanReorderRecords(true);

setCanAcceptDroppedRecords(true);

setCanDragRecordsOut(true);

Yes, this is all you have to do to enable drag&drop in your application!

Analogously we add the gird to the right and also the arrow buttons to demonstrate transfer of the selected nodes with mouse click.

And to demonstrate the layout capabilities let’s see how we construct our parts together:

HStack grids = new HStack(10);

grids.setHeight(160);

grids.addMember(leftGrid);

grids.addMember(moveControls);

grids.addMember(rightGrid);

grids.draw();

Those familiar with Java Swing will see the similarities. Basically we create appropriate layout and fill it with elements. Layouts can be nested, so combining horizontal and vertical layouts (or some more complex layouts) we can create whatever we want to.

Ah i almost forgot! Our program is finished.

OK, almost completely, this example is using demonstration framework, but what we would additionally need to do would be to create a simple html page referencing generated JavaScript code (GWT is compiled into JavaScript) and add our grid to the rootPanel using

RootLayoutPanel.get().add(...

If we were not connected to some data source, then now we need to manually handle the data changes. We could subscribe the gird for changes, update the data on exit event or else, whatever suits our needs.

For info about GWT please see: http://code.google.com/intl/hr-HR/webtoolkit/

For info about SmartGwt, see: http://code.google.com/p/smartgwt/

Only recently in version 5 iOS began to support CSS position:fixed and before that fixed positioned elements behaved like they’re absolute positioned relative to document body. On Android it is officially supported since version 2.2 but actual behavior of scroll greatly depends on device and manufacturer with end result ranging from great user experience on some Androids v2.2 to horrible glitchy animation on latest versions. Thumbs up to HTC which did a good job on improving stock browsers with their HTC Sense framework and because of that fixed positioning mostly works fine.

JavaScript touch scroll libraries offer a way out of this mess by trying to provide stable cross platform scroll emulation. Basically the idea is to attach JavaScript handlers to document’s touch events, detect swipe gestures on scrollable element, and emulate scroll behavior with CSS3 transitions. At first these JavaScript libraries enabled only basic scrolling, but today there are features like pinch zoom, fancy fading scrollbars, pull to refresh, etc.

iOS devices

On iOS there no support for position fixed until version 5 that only recently came out. By far the best library to use is Matteo Spinelli’s iScroll because of both features it offers and overall smoothness that almost resembles native scroll. Current version is 4 which is a complete rewrite of older iScroll 3 and offers much more than just scrolling. It comes in two flavors, full version with all features and support for desktop browsers, and lite version which offers only touch scrolling in mobile Webkit. It’s written in pure JavaScript and doesn’t require any third party library to function (e.g. jQuery). Unlike version 3, iScroll v4 no longer supports automatic refresh when content updates so you’ll have to call refresh method manually. Although performance is very good, you might want to use native scroll in iOS5 which can be detected through browser’s user agent.

if ((navigator.userAgent.match(/iPhone/i)
  || navigator.userAgent.match(/iPod/i)
  || navigator.userAgent.match(/iPad/i))
  && navigator.userAgent.match(/ OS 5_/i)) {
    // do not use iScroll
}


Android

To get usable and consistent scroll experience on Android proved to be a real challenge. Although position fixed is officially supported since version 2.2 this was only partially true and in most cases did not work. We tested a lot of libraries and best one is touchScroll jQuery plugin by Paul Neave. Under the hood it uses the same scrolling logic as iScroll but works much better and refreshes automatically when content updates. Few things to keep in mind is that there’s a bug causing content flicker when elastic bounce is turned off so it’s best to leave it active. Also there’s no way of destroying touchScroll once it’s been activated.

One other bug we noticed is present only on vanilla Androids (e.g. Nexus S) where scroll freezes after returning to page using back button. To fix this rewrite touch event bindings to use addEventListener instead of jQuery bind() method and fix bug in getTouches(e) method:


function getTouches(e) {
  if (e.originalEvent) {
    if (e.originalEvent.touches && e.originalEvent.touches.length) {
      return e.originalEvent.touches;
    } else if (e.originalEvent.changedTouches && e.originalEvent.changedTouches.length) {
      return e.originalEvent.changedTouches;
    }
  } else {
    if (e.touches.length) {
      return e.touches;
    } else if (e.changedTouches.length) {
      return e.changedTouches;
    }
  }
  return null;
}

Like I said before HTCs handle position fixed much better so you might want to use native scroll. This will also prevent problems with input fields being offset that sometimes occur on HTC devices. For detection you can once again use user agent string but it’s not 100% reliable because Android browser allows user to change it.

if (navigator.userAgent.match(/ HTC/i)
  // other Androids that don't have HTC in user agent
  || navigator.userAgent.match(/ Desire_A8181/i)
  || navigator.userAgent.match(/ myTouch4G/i)
  || navigator.userAgent.match(/ ADR6200/i)) {
    // do not use touchScroll
}


Tips for better performance

• 1. do not use CSS gradients
• 2. keep content simple and reduce number of html elements
• 3. if possible avoid JavaScript scroll entirely. From user experience point of view mobile web sites shouldn’t try to emulate mobile application with fixed header and footer

Git merge and rebase have the same purpose – to converge multiple branches of development. Although the final goal is the same, those two methods get to it walking different paths.

Here is a sample repository that has two diverging branches: master and feature. Commit hashes will be represented with integers to help comprehension. They are also representing timestamps – smaller number means earlier commit.

      +--3--5   master
      |
1--2--+
      |
      +--4--6   feature

Merge

Merge is a new commit. That is very important thing to remember and one that is elusive to the newcomers. It is a simple commit with one difference – it has two parents. All other regular commits have only one. How do you check that? Fire up terminal and type git status. See that first two lines for merge?

commit 7777777777777777777777777777777777777777
Merge: 5555555 6666666
Author: Merlin <no.spam@for.me>
Date:   Thu Nov 3 10:11:27 2011 +0100

    Merge branch 'feature' into master.

Merge in ASCII art.

      +--3--5--+
      |        |
1--2--+        +--7
      |        |
      +--4--6--+

If you type git log on master branch, you’ll get a linear output: 7 6 5 4 3 2 1, sorted by date. But be mindful that is just eye-candy. The history is not linear under the hood. If you checkout at the commit 5, and type git log you’ll get: 5 3 2 1. Commit 4 is not a child of 5 or a parent of 3, so it’s not in the output.

Fast-forward merge

The only time a merge creates no new commits is the fast-forward merge. It happens in a situation when there are no commits in an another branch. Than it just updates the branch pointer to the last commit (number 4 in the graph).

Before

1--2--+         master
      |
      +--3--4   feature

After

1--2--3--4   master/feature

Rebase

Rebase is recreating your work of one branch onto another. For every commit that you have on the feature branch and not in master, new commit will be created on top of the master. Read this again, slowly: new commit for every old one, with the same changes.

When you checkout to feature branch and then rebase onto master, you will get this:

      +--3--5   master
      |
1--2--+
      |
      +--3--5--7--8   feature
              (4)(6)

Rebase has removed changes 4 and 6, synced with master changes 3 and 5, and then – remember the above statement – created new commits for old ones. It added commit 7 with the changes of commit 4 and commit 8 with the changes of commit 6. That way the feature branch has all changes from the master plus its own.

After you do fast-forward merge, you will have:

1--2--3--5--7--8   master/feature

git log will output: 8 7 5 3 2 1. And it’s important to notice that the history is linear under the hood too.

Conclusion

So, when to use merge and when rebase? As you may have guessed, the answer is “it depends”. And it depends mostly on the agreed workflow. But there are a few good guidelines.

Use rebase when:
● You have a need to merge local changes and don’t need an exact history. Why litter it with merge commits?
● You prefer a linear history and use git bisect very often (it can get confused with a non-linear history).

Use merge when:
● You have shared some of the changes with others and it’s important not to break their repositories. git rebase changes a lot of history so a normal merge is much safer and cleaner for others.
● You care about history and development tracks.

Picture credits

C(p) = ∑ Pi Bi,n(p)		i∈[0,n]

Note that this expands to two equations – one for x, and one for y coordinate. Since the curve is cubic, n = 3:

Cx(p) = ∑ Pxi Bi,3(p)
Cy(p) = ∑ Pyi Bi,3(p)

In each equation, B_i,3 is one Bernstein polynomial. Bernstein polynomials have all kinds of nice properties – but we’re currently not interested in them, so we’ll just write down all four polynomials of third degree:

b0,3(p) = (1 - p)3
b1,3(p) = 3p (1 - p)2
b2,3(p) = 3p2 (1 - p)
b3,3(p) = p3

So, what exactly is going on? Parameter p gradually changes from 0 to 1. For each value of p, we evaluate the polynomials, then multiply each polynomial with the coordinate of its corresponding control point. Finally, we add all these values to obtain the x coordinate of curve point at p:

Cx(p) = ∑ Pxi Bi,n(p)
      = x0 b0,3(p) + x1 b1,3(p) + x2 b2,3(p) + x3 b3,3(p)

Calculating the y coordinate is the same, except that y coordinates of control points are used instead of x. To speed things up, previous equation can be expanded, and the terms rearranged:

Cx(p) = ax p3 + bx p2 + cx p + dx        (*)

where:

ax = x3 - 3x2 + 3x1 - x0
bx = 3x2 - 6x1 + 3x0
cx = 3x1 - 3x0
dx = x0

Now, as soon as you are given four control points, you can calculate a_x, b_x, c_x and d_x. After that, all you have to do is vary the value of p from 0 to 1, and use it to evaluate (*). Then, repeat the procedure for y coordinates. Smaller changes of p will result in more calculations, but the curve will appear smoother. And that’s all there is to it.

For simplicity sake, we’ll ignore the 7″ phonetabs which (mostly) fall into the hdpi/large group anyway.

In our case we had a HTC Hero, HTC Desire and an ASUS Transformer tablet. Hero has a HVGA screen with density of ~180dpi. Desire has a WVGA screen with density of ~250dpi. Transformer has a much larger WXGA screen but a lower density of ~160dpi.

In Android terms, Desire occupies the hdpi group.

Strange as it may seem, Transformer and Hero fall into the mdpi density group. This makes perfect sense from density point of view. But still, Hero has a screen couple of times smaller then the Transformer. So naturally, not all resources will apply to both devices.

Android documentation suggests to use density qualifiers (ldpi, mdpi, hdpi) for images and size qualifiers (normal, large, xlarge) for layouts.

Purpose of this post is to outline that other combinations are also possible. You are free to have a resource folder drawable-xlarge. This also applies to other resources such as values. Even though this setup makes sense, it’s not as straightforward in the official docs so it takes some playing around to see what works and how.

This is exactly what we need for our device set. We don’t want the Transformer to use the exact same image and value set as the Hero just because they fall into the same density group. Playing with the xlarge qualifier we are able to provide a set of resources specific to the tablet.

Note that if you’re developing a 3.2+ app then you can specify the exact minimum screen size you app needs to work properly. This simplifies things further for the developer.

Check out the official docs on multiple screen support!

String userAgent = request.getHeader(“User-Agent”);
MDC.put(“user-agent”, userAgent );

Now there is only one more thing left to do - add ConversionPattern property “%X{user-agent}” in your log4j configuration file, like in an example below:

<appender name="console" class="org.apache.log4j.ConsoleAppender">
	<param name="Target" value="System.out" />
	<layout class="org.apache.log4j.PatternLayout">
		<param name="ConversionPattern" value="[%X{user-agent}] %d %-5p %l - %m%n" />
	</layout>
</appender>

Similar to Log4j MDC, there is also a NDC (Nested Diagonostic Context), which is basically stack implementations onto which context information can be pushed and popped.