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.

Another possible problem is connected with addition of new method overloads.
For example:

public class A {

  /**
  * @since 1.5
  */
  public void example(Object o) {
  // do something
  }

  /**
  * @since 1.6
  */
  public void example(String s) {
  // do something completely different
  }
}

Class A in Java 5 has a method: public void example(Object o). In Java 6 new overload was added: public void example(String s).
If we do this:

public static void main(String[] args) {
  new A().example("test");
}

Eclipse will tell us we are using newer overload. Our compiler won’t have a problem with this. Even when we build this using JDK 1.5 no error will occur as compiler thinks we are using older overload. Problem is that this will not be caught in compile time. In runtime older overload will be used, a method we did not intend to use.
Severity of this depends on how different are these two overloads. Something like this can have unpredictable side effects and it’s possible for this bug to go unnoticed for a long time.

Let’s start with the top-level rendering function. It will output document doctype information and its root tags. Whole content will be rendered in between by the lambda (or anonymous) function passed in as the only parameter: $contentRenderer. A lambda function can contain other lambda functions and thus form a rendering tree that will result with well-formed HTML markup. Simple as that! :)

function renderHtml($contentRenderer = null)
{
    echo "<!DOCTYPE HTML>\n";
    echo '<html>';
    if ($contentRenderer) $contentRenderer();
    echo '</html>';
}

HTML tags can have attributes, so it’s important to make place for them as the first few parameters of a rendering function. Of course, only attributes needed in project’s scope should be listed. Therefore, even though the <a> element can have a handful of parameters, only “href” (as mandatory) and “target” (the optional one) have been picked and will be used. Again, element’s body will be rendered by an outside lambda function.

function renderA($href, $target = '', $contentRenderer = null)
{
    echo '<a',
        prepareAttribute('href', $href),
        prepareAttribute('target', $target, false),
        '>'
        if ($contentRenderer) $contentRenderer();
        echo '</a>';
}

function prepareAttribute($name, $value = '', $is_mandatory = true)
{
    $attribute = '';
    if ($is_mandatory || $value || $value === 0 || $value === '0')
    {
        $attribute = ' '.$name.'="'.htmlspecialchars($value).'"';
    }
    return $attribute;
}

A new utility function, prepareAttribute(), has been introduced in this example. It takes attribute name and value and concatenates them in the <name>=”<value>” form. If an attribute is marked as optional (that is, the $is_mandatory flag is set to false), its construction will be skipped unless a non-empty value is provided (which includes zero either as a number or a string). This will avoid having optional parameters rendered in the <name>=”" form and hence leave the final markup as clean as possible.

Now that basic concepts have been explained, here’s an example of a complete page rendering tree. It demonstrates how lambda functions are nested in each other and how they can be leveraged to render dynamic data loaded from DB or some other source.

<?php
    renderHtml(function()
    {
        renderHead(function()
        {
            renderTitle('Welcome to my new site!');
        });
        renderBody(function()
        {
            renderH1('Under Construction');
            renderImg('http://www.mysite.com/images/logo.png', 'My Site Ltd.');
            renderP(function()
            {
                echo htmlspecialchars('This site is still being constructed...');
                renderBr();
                renderA('http://www.mysite.com/', '', function()
                {
                    echo htmlspecialchars('> Visit My Site's official website!');
                });
                renderA('http://www.some-other-site.com/', '_blank', function()
                {
                    echo htmlspecialchars('> Get more information here.');
                });
            });

            // load and render some text dynamically
            $textItems = loadTextItems();
            foreach ($textItems as $item)
            {
                renderP(function() use ($item)
                {
                    echo htmlspecialchars($item);
                });
            });
        });
    });
?>

Since lambda rendering functions are expected parameterless and as such simply executed, parameter passing needs to be done via closures. Where necessary, a rendering function can be linked to its calling scope by binding to that scope’s variables, thus forming a closure. Such variables can be used inside the function normally.

Naturally, this approach has its limits and it should be deprecated as project grows. It is intended for quick prototyping or for simple projects that don’t require heavy machinery. Once development starts “for real”, the code should switch to one of (many) PHP frameworks that can do a better job of rendering HTML markup.

In case you are working on an application targeted for Symbian phones, one of the easiest ways to work with zip files is to simply use existing APIs available on Symbian OS. This is a short blog post that will show you how to use those APIs from your Qt application.

If you decide to use Symbian C++ APIs from Qt, probably the first thing you will need is a way to convert data from Qt types to Symbian types. When working with zip files you usually have to specify a path to a zip file, or a destination directory where to unpack a file. In order to do that, you have to convert QString to TPtrC16, here is how to do that:

TPtrC16 aZipFilePath(reinterpret_cast<const TUint16*>(zipFilePath.utf16()));

TPtrC16 extends TDesC16, so you can use it if you want to call a method that takes TDesC as a parameter. If you need to convert a descriptor into a QString, you can do it like this:

QString zipFilePath((QChar *) aZipFilePath.Ptr(), aZipFilePath.Length());

To read the contents of a zip file you will need an instance of CZipFile class. Here is an example of how to create a new CZipFile instance from a file name:

RFs fileSession;
fileSession.Connect();
CleanupClosePushL(fileSession);

// Creating a new instance of CZipFile.
// The first parameter of the two-phase constructor is a session of File Server.
// The second parameter is the file name of the ZIP file.
CZipFile* zipFile = CZipFile::NewL(fileSession, aCompressedFile);

After you have created a CZipFile object, you can get a list of files that are compressed inside a zip file by using GetMembersL method of that object:

CZipFileMemberIterator* members = zipFile->GetMembersL();

CZipFileMember* member;
while ((member = members->NextL()) != 0) {
  // Do something with a member
  delete member;
}

To extract a file from zip file we need to get RZipFileMemberReaderStream from the member object:

RZipFileMemberReaderStream* stream;
aZipFile.GetInputStreamL(member, stream);

Finally, in order to build Symbian code successfully we need to add required Symbian libraries to our .pro file using LIBS directive:

LIBS += -lezip -lbafl -lefsrv -leuser

Besides that, you may also get an error about an extra qualification ‘RZipFileMemberReaderStream::’ on member ‘ConstructL’ in file zipfilememberinputstream.h. This can be easily resolved by removing ‘RZipFileMemberReaderStream::’ prefix from ConstructL method in zipfilememberinputstream.h.

I showed examples of some basic operations that can be done on zip files using CZipFile, a more complete and detailed example that uses CZipFile can be found here.

One important thing to consider before using Symbian C++ APIs is portability. Those APIs may not be the best choice if you plan to port your application to some other platform that runs Qt applications. If that is the case, a better approach would be to use a Qt library to handle zip files. On the other hand, if you are building an application only for Symbian, this is probably the easiest way to work with zip files.