Wireframes, prototypes and design

The first step of any process is finding out who the users are. In this case, there are two groups that use the app simultaneously – parents and children. Parents manage children’s accounts, food items and browse through a groceries list. Children use the central part of the application – the lunchbox – to prepare their meals for the week. The former part had to be efficient and organized. The latter had to be fun and engaging like a game. Those two requirements are not easily mixed together.

We had great and continuous communication with the client and used online wireframing tools extensively. The path between the client’s initial idea and a finished product is very obscure and if all situations are not thought through, it’ll bite you near the end. That’s why wireframing is all about problem solving.

During that phase the dev team was brought in. They checked the technical feasibility and brought a different perspective with good questions and discussions. This is also the best time to quickly prototype some new ideas (new types of selection, animation, etc) and see how they behave on a device.

Designing for grown-ups and children at the same time is not easy, but we’ll let the pictures do the talking.

About 40% of the total time spent on the app was on design and user experience before the first line of production code was written. It was a good decision.

Development and QA

Coding custom game-like consumer application is never an easy task. There are many non-standard technical requirements and if you want to impress your users, you’ll have to code like a boss. One of the examples is the custom scroll and inertia our dev team implemented because the out-of-the-box solution just wasn’t good enough for our specific situation. Small things like that and not cutting corners is the way to a great application and user experience.

As soon as the first usable builds landed on a device, QA team started tracking bugs and testing all edge cases. Finding those as early as possible saved us time later.

Complete involvement

In the second half of development, the whole team and the client were fully involved. The design team didn’t just said “OK, we did our part”. They used development builds to conduct user testing, sometimes very short, sometimes more elaborate. The dev team implemented the feedback from testing and QA made sure everything worked as planned without problems.

Waterfall workflows where functional departments do their work on a project and pass it on to never see it again are things of the past and should never be used if you want to create this type of consumer application. Be agile and respond to feedback.

If you have children and value the effort that has been put into the LaLa Lunchbox app, be sure to check it out on App Store.

Spotify is an awesome music streaming service launched in 2008 by a Swedish startup. Just recently it became available in 14 different countries including US and UK. What’s rather interesting about this particular music streaming service is that at the end of last year they introduced an app platform. It opened up a whole new world inside the Spotify desktop client. There were various cool apps released in the first batch, like Last.fm and Moodagent. Be sure to check them out if you’re a Spotify user.

But the first batch of apps was just a start. Two weeks ago, a second batch of apps went out. And we are proud to be a part of it. We got an opportunity to build a Spotify app for Matador Records. It’s a well-known independent record label famous for their indie rock artists and bands. So we jumped on the opportunity and went to work.

The goal was to create a simple, but usable and useful app that will provide some real value for the end user. While we had a bunch of cool ideas, due to the tight deadline, we needed to restrain ourselves and focus on the most important information we could provide. So we concluded that what Matador Records music fans really care about are releases and tour dates. After about a week of development, here is what we got.

On the home screen you can see new and upcoming releases. Upcoming releases appear only if announced, though.

If you scroll down a bit, you can see the upcoming concerts from Matador Records bands.

If you want to explore further, All releases tab shows the whole history of Matador Records releases. Most curious fans will definitely want to check out some of the older albums from early 90′s, which they can easily filter out in the app.

Although listening to the music via Spotify is awesome, both at home and on the go, what every true fan really wants is to see the band performing live in her or his neighborhood. That’s why Tour dates tab contains all concerts planned for this year with dates and locations.

Initial feedback from the users is very positive and there are also improvement suggestions. We are aware there is room for improvements and we hope to have them in the app soon.

We invite you to check out the app and let us know in the comments how you liked it.

P.S.

Few notes to the developers:

1. pay special attention to developing a responsive design so that your app still looks great when the user decides to resize the client window

2. expect rigorous QA from the Spotify team, follow the guidelines as much as you can

3. useful resources: Spotify Apps API Documentation, StackOverflow, Demo application for the Spotify Apps API created by Peter Watts. (Thanks dude!)

The problem: very simple, i need to send an user id with each http request sent from out Spring layer to the REST API server. We use Stripes as a front-end layer and user is easily accessible there from the session as at the login time we store user in the session. But the problem with Spring Framework is that it is not session aware by default, particularly, all Spring beans are singletons, that is, only one instance of object exists for the whole application. Setting userId in a static field for example would result in overwriting of that field each time the new user logs in as that field would be shared.

Obvious solution would be to send user it with each call made from Stripes to Spring, but i think that Robert C. Martin, author of Clean Code would be very disappointed to see that. I think there are several reasons why this approach, well – is not good, to be polite:

- adding mandatory parameter to each and every call is simply a burden to the developer
- it adds a lot of duplication
- it is error prone

So, after googling the topic i found that it is possible to change the scope of Spring bean using the configuration. It is possible to change scope from default singleton to prototype, request and the one we need here – session. This approach is only possible in web-aware applications, but we certainly have one, and it means that bean instantiation will be made per session

Now we have a session scoped object which is used to keep track of the logged in user and is also responsible for factoring of the http requests. Now the information that needs to be added to each http request is really close (in the same object).

Another point is that this session scoped object (i simply named it SessionScope) needs to be accessible from every other bean that consumes http request factory and also by the user management service as it needs to initially set the userId. This means that we need to SessionScope bean as a dependency (Spring calls this collaborator) but we can not simply add it as a standard dependency as the beans that are using this session bean are still singleton beans, and technically this would result in our collaborator bean to act like a singleton bean also (it would be injected once the singleton bean is created), so we need to add element:

<aop:scoped-proxy/>

in the session bean configuration and the result will be that only proxy object is injected, and by default, cglib will take care of the session management of real per-session data.

1. HeapDumpOnCtrlBreak
Add this option when starting JVM. It will create heap dump every time ctrl+break (kill -3) signal is sent to JVM. HeapDumpPath is used to set location of heap dumps.

2. HeapDumpOnOutOfMemoryError
This JVM option will create heap dump every time when your application throws an OutOfMemoryError. HeapDumpPath is used to set location of heap dumps.

3. Jmap
Jmap is a tool that comes with JDK installation. To use it we need a PID of our java process.
Then we can use it like this:
jmap -dump:file=D:\temp\heapdumps\dump.bin pid 1234

4. Jmap (from the application)
We can also use jmap from our code. To get a pid from code use we need to use java.lang.management.ManagementFactory.

String name = ManagementFactory.getRuntimeMXBean().getName();
String pid = name.substring(0, name.indexOf("@"));
After that we can start jmap process like this:
String[] cmd = { "jmap", "-dump:file=D:\\temp\\heapdumps\\dump.bin", pid };
Process p = Runtime.getRuntime().exec(cmd);

5. HotSpotDiagnosticMXBean
This option is available in Java 1.6+ and uses sun.management.ManagementFactory.

ManagementFactory.getDiagnosticMXBean().dumpHeap("D:\\temp\\heapdumps\\dump.bin", true);


When we get the heap dump we need to use a tool like VisualVM (also included in JDK installation)to actually try and find the leak.
There are of course a lot of different tools, free and commercial, that can provide monitoring and creating of heap dumps. But in some cases there are restrictions in including 3rd party tools in the picture and that is where this list comes in.

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