Android Studio and the future of Java IDE’s

Yesterday, when they announced Android Studio during the keynote of Google I/O, my very first reaction was “Oh no! Too bad for Jetbrains! Even though they build awesome plugins for Android development, they will be taken over by Android Studio, beaten by their own platform!”. But then I saw this:

And I realized that even though they will probably have to sit on months of in-house development, so many Android developers will get used to the amazing productivity of the IntelliJ platform, realize how much Eclipse sucks as an IDE, and switch to IntelliJ IDEA as their primary Java IDE. Even more so as I expect other platform providers to switch now that Google has opened the way. Adobe? SpringSource? Are you listening?

But there is one question that still bothers me: mobile development very often requires backend development as well. So will Android Studio be available as a plugin for IntelliJ IDEA or will I have to keep 2 IntelliJ-based IDE’s opened at all times? Because if that’s the case, it will suck productivity-wise and I’ll have to upgrade my memory.

UPDATE: And… all my questions are now answered! Good job guys!

My Case for DTO’s

In many of my posts about Grails and Flex integration, I take for granted that I use Data Transfer Objects to transfer data between my Grails backend and my Flex frontend. Put simply, Data Transfer Object are pure data containing classes different from the domain entity classes used to store data in the backend. I take it for granted because I’m deeply convinced that it’s the best way to do things and so far, experience has never proved me wrong. But I often get this question in comments or by mail (this is for you Martijn): why bother create an entirely separate class structure and copy data from entities to DTO’s and back instead of just using entities?

I’ve expressed my arguments a couple of times across various posts but I thought it would be nice to sum things up in here for future reference.

Where does it come from?

When I first started to work on enterprise applications and ORM-based architectures, it was with a Model-Driven Architecture framework called AndroMDA. AndroMDA was absolutely key in helping me getting started with Spring and Hibernate and I was especially inspired by one paragraph in their “getting started” tutorial, which I quote here:

Data Propagation Between Layers

In addition to the concepts discussed previously, it is important to understand how data propagates between various layers of an application. Follow along the diagram above as we start from the bottom up.

As you know, relational databases store data as records in tables. The data access layer fetches these records from the database and transforms them into objects that represent entities in the business domain. Hence, these objects are called business entities.

Going one level up, the data access layer passes the entities to the business layer where business logic is performed.

The last thing to discuss is the propagation of data between the business layer and the presentation layer, for which there are two schools of thought. Some people recommend that the presentation layer should be given direct access to business entities. Others recommend just the opposite, i.e. business entities should be off limits to the presentation layer and that the business layer should package necessary information into so-called “value objects” and transfer these value objects to the presentation layer. Let’s look at the pros and cons of these two approaches.

The first approach (entities only, no value objects) is simpler to implement. You do not have to create value objects or write any code to transfer information between entities and value objects. In fact, this approach will probably work well for simple, small applications where the the presentation layer and the service layer run on the same machine. However, this approach does not scale well for larger and more complex applications. Here’s why:

  • Business logic is no longer contained in the business layer. It is tempting to freely manipulate entities in the presentation layer and thus spread the business logic in multiple places — definitely a maintenance nightmare. In case there are multiple front-ends to a service, business logic must be duplicated in all these front-ends. In addition, there is no protection against the presentation layer corrupting the entities – intentionally or unintentionally!
  • When the presentation layer is running on a different machine (as in the case of a rich client), it is very inefficient to serialize a whole network of entities and send it across the wire. Take the example of showing a list of orders to the user. In this scenario, you really don’t need to transfer the gory details of every order to the client application. All you need is perhaps the order number, order date and total amount for each order. If the user later wishes to see the details of a specific order, you can always serialize that entire order and send it across the wire.
  • Passing real entities to the client may pose a security risk. Do you want the client application to have access to the salary information inside the Employee object or your profit margins inside the Order object?

Value objects provide a solution for all these problems. Yes, they require you to write a little extra code; but in return, you get a bullet-proof business layer that communicates efficiently with the presentation layer. You can think of a value object as a controlled view into one or more entities relevant to your client application. Note that AndroMDA provides some basic support for translation between entities and value objects, as you will see in the tutorial.

Because of this paragraph, I started writing all my business services with only data transfer objects (what they call “value objects”) as input and output. And it worked great. Yes it did require a little bit of coding, especially as I had not discovered Groovy yet, but it was worth the time, for all the following reasons.

The conceptual argument: presentation/storage impedance mismatch

Object-relational mapping is what Joel Spolsky calls a “Leaky Abstraction“. It’s supposed to hide away the fact that your business entities are in fact stored in a relational database, but it forces you to do all sorts of choices because of that very fact. You have to save data in a certain order in order not to break certain integrity constraints, certain patterns are to be avoided for better query performance, and so on and so forth. So whether we like it or not, our domain model is filled with “relational choices”.

Now the way data is presented involves a whole different set of constraints. Data is very often presented in a master/detail format, which means you first display a list of items, with only a few fields for each item, and possible some of those fields are calculated based on data that is stored in the database. For example, you may store a country code in your database, but you will display the full country name in the list. And then when the user double-clicks an item, he can see all the fields for that item. This pattern is totally different from how you actually store the data.

So even though some of the fields in your DTO’s will be mere copies of their counterparts in the entity, that’s only true for simple String-typed fields. As soon as you start dealing with dates, formatted floats or enum codes, there is some transformation involved, and doing all that transformation on the client-side is not always the best option, especially when you have several user interfaces on top of your backend (a Flex app and an iPhone app for example), in which case you’re better off doing most of these transformations on the server.

In anyway, if you change the way you store data, it should not influence too much the way you present the same data, and vice-versa. This decoupling is very important for me.

The bandwidth argument: load just the data you need

In the master/data use case, when you display the list of items, you just need a subset of the fields from your entities, not all of them. And even though you’re using Hibernate on the backend with lazy-loading enabled, fields are still initialized and transferred over the wire. So if you use entity classes for data transfer, you will end up transferring a whole bunch of data that may never be used. Now it might not be very important for hundreds of records, but it starts being a problem with thousands of records, especially when there is some parsing involved. The less data you transfer the better.

The security argument: show only the data you want to show

Let’s say you’re displaying a list of users, and in the database, each user has a credit card number. Now of course when you display a list of users, you might not want everyone to see the list of credit card numbers. You might want to expose this data only in detail view for certain users with certain privileges. DTO’s allow you to tailor your API to expose just the data you need.

The error-prone argument: argh! Yet another LazyInitializationException!

Of course there are associations between your business entities, and by default, those associations are lazy-loaded, which means they are not initialized until you actually query them. So if you just load a bunch of instances from your entity manager and send them over to your client, the client might end up with null collections. Now of course you can always pay attention, or use some tricks to initialize associations up to a certain level before you send your data, but this process is not automatic and it’s very error-prone. As for using things like dpHibernate, I think it just adds too much complexity and uncontrolled server requests.

The laziness argument: Come on! It’s not that hard!

I think that most of the time, the real reason why people don’t want to use DTO’s is because they’re lazy. Creating new classes, maintaining code that does “almost” the same as existing code, adding some code to service implementation to copy data back and forth, all of that takes time and effort. But laziness has never been a good reason for ditching a design pattern altogether. Yes, sometimes, best practices force us to do more stuff for the sake of maintainability and robustness of our code, and for me the solution is certainly not to shortcut the whole practice, but just to find the best tools to minimize the added work. With its property support and collection closures, Groovy makes both creating, maintaining and feeding DTO’s as simple and fast as it can be. AndroMDA had converters. There are even some DTO-mapping frameworks like Dozer to help you. No excuse for laziness.

For me, all the reasons above largely overcome the added work to maintain a parallel DTO structure.

Now of course, this is a very opinionated topic and you will probably have a different view. So all your comments are welcome as long as they remain constructive and argumented.

How To Introduce Yourself… I Mean Practically

For years, I’ve been using a very simple but very effective technique to introduce myself in job interviews, and I’ve always got some excellent feedback about it. I’m not talking about the content here, but the format. It can always be a bit tricky to introduce yourself without diving too much into irrelevant details, or losing yourself along the way, or boring the interviewer to death. To avoid all that, I’ve learnt this technique at Axen, but since Axen doesn’t exist anymore per se, I might as well share it with you guys, because it’s always a shame to miss a good recruitment because the candidate wasn’t clear enough during his/her interview. So here you go…

WWDC 2010 Review

Still one session to attend about closures in Objective-C, and I’ll call it a week. A little bit of shopping this afternoon in order to spend my last dollars and I’ll be ready for take-off tomorrow afternoon. So it’s time for a little summary of this week.

Overall, it was my first WWDC and I’m very glad I did it, but I probably won’t do it again. San Francisco is definitely a very nice city, and seeing Steve in live, even from very far away in the audience was an interesting experience. I also learnt a few very interesting things and psychologically a conference like this always has the same side-effect on me: first I’m depressed and humbled by all the ambient intelligence, but then it motivates me a lot to move forward, learn and do something about it. So it has definitely been a very positive experience.

Now was it worth the budget I put in it?

My Discoveries of the Year

logoEvery year, the main reason why I go to Devoxx is to discover new stuff. For me it’s all about technology watch. The internet and RSS feeds are my main tech watch instrument but there is one thing that is harder to get through RSS: feelings. Conferences like Devoxx are a unique opportunity, not only to see what’s happening but also to sense how the community is feeling about it, which is at least as important to anticipate on what’s going to be important.

Now you’ve certainly read here and there that there have been a lot of talks about Java EE6 and Closures in JDK 7. There sure were, and there was quite a lot of reactions to those. But frankly, I’m not interested in any of those. I’m not interested in Java EE6 because even though it finally leverages the concepts that have been pushed by the community for so long, the very fact that Sun has been so late in implementing them shows one thing to me: it’s not about them, it’s about us. Sun has been trying to partner with big companies around the JCP, to create a lot of business around those standards. And why were those standards so complex? Because there were so many companies involved in their elaboration? Or was there any interest from those companies to create technologies complicated enough to require a lot of consultants, and books, and trainings, and tools to make things easier? If the first option is true, then how did it happen that a gigantic community of individual software developers made it so that Spring, Hibernate and other Open Source technologies became de facto standards?

Which brings me to the second point I don’t really care about: closures in JDK 7. People have taken matters into their own hands. Other languages have appeared implementing some of the missing features of Java: Scala, Groovy, etc. Some other languages have been imported into the Java landscape, like Ruby and Python. I’ve been using Groovy myself for some time now, and I couldn’t be happier with it. Now Sun is coming after the war, but does it matter? What I see here is that it’s good to have a base language, a base platform. But as soon as you start extending it for purely mercantile reasons, or as soon as you start avoiding certain innovations because you’re afraid it might harm your business or the one of your partners, then things go messy. But once again, the good news is that software gives us power. We developers have the ability not only to decide which technology is better, but to build and promote our own technologies. And I think this is why our world is so dynamic and why things change so fast. What I see here is that languages matter less than our ability to create new ones, to solve more specific problems, to provide some more advanced features. And that strengthens my belief that Language-Oriented Programming is the next big step in the evolution of our technologies.

Now about the things I do care about. My discoveries.

kanbanMy first one is definitely Kanban. I’ve heard about it for quite some time. But I didn’t understand why people were already trying to push it forward, even though we are still fighting to push companies away from waterfall messes. It’s even more radical than Scrum and for that it’s very interesting because it gets closer to what software development really is. The key phrase that kept popping in my head during the 3-hour session about Kanban was “It’s going to take the time it’s going to take.” And that’s why it’s brilliant. Now that I understand Kanban a little better, I see Scrum as a compromise. We’ve taken some of the principles of Lean Manufacturing, we have dissolved them into trusted concepts like RUP’s iterative cycles. And for years, we have been trying to pour that cocktail into their mouth. And in doing that we forgot something important: if they don’t trust us, they will never drink the whole thing, all the more so as it looks weird with all those colors not really mixed together. The way I see it, Lean and Kanban are all about getting back to the basics, and relying on trust. We have to build trust first, we have to make them understand that at least some of us are not interested in building artificial business on top of poor practices. That at least some of us desperately want the software we build to have a real impact on their business. We have to show them our good will so that they let us do our job. And they have to understand that the more they trust us, the faster we will be, the more we will be able to solve other problems. Big software vendors and resource providers will not like that, because every new project comes with its own overhead, because their business thrives on poor practices, stupid methodologies and complex technologies. But once again, power is in our hands, it lies in collaboration, not in corporation.

My second discovery was Spring-Actionscript. Those guys really have a thing to do things in a clever way. Cairngorm, PureMVC, Swiz, they all impose some sort of a structure to your Flex applications, forcing you to surrender some great powers of Flex itself in the process. And here comes Spring-Actionscript, more like a toolbox than a real framework. It doesn’t impose anything. It just gives you all the tools you need, all the glue you miss, to make things fit together perfectly. Their asynchronous abstraction is just brilliant, their configuration options are complete, your code just looks better with it, simpler, more natural. I think that’s what I love most with Spring: not only does it create great technology, but it also instigates a whole pragmatic and elegant way of thinking into the minds of a whole generation of developers, thus encouraging the community to come up with their own technologies: Spring Actionscript used to be called the Prana Framework, developed independently by a Belgian guy who took inspiration in Spring for Java. That’s just awesome. I will definitely integrate Spring Actionscript in a couple of Spring/Flex projects. I think I will even update my todolist sample application with it. Stay tuned.

My third discovery is a couple of technologies to detect and prevent coding errors BEFORE they actually happen. I insist on “before” because of my previous post about TDD: unit tests are all about writing code to check that some other code you have already written (or not written yet) does its job. But to me, this is equivalent to the old prevention versus repression debate. TDD is just repression, and it’s tempting to go there only, because it’s always easier to catch the bad guys than trying to understand why they became bad in the first place. JSR-308 and its pluggable type checkers is all about strengthening the compiler so that it prevents more of the most frequent bugs like NullPointerExceptions. It allows us to make our code more expressive, to give the compiler more information about our intents so that we can prevent bugs from happening. Brilliant! Project Lombok also goes in that direction: it adds a couple of annotations and customizes the Java compiler in order to minimize the amount of boilerplate code we have to type. Once again, by doing so, it improves the expressiveness of the language, allowing us to say more things with less words, thus reducing the likeliness of ambiguities and errors. Awesome! Lombok and type checkers will definitely be part of a couple of projects too. The only thing that really made me uncomfortable with both of these presentations was this question: “Why the hell weren’t those techniques in Java 5 already?”

pomodoroMy fourth and last discovery was Pomodoro technique. Once again, heard of it before, but never dug into it. And then we had this guy with a strange Swedish accent in front of us, playing with dolls, showing us handwritten slides with simplistic drawings. And you could hear the disappointed reaction of a lot of people in the room: “sounds nice, but not applicable to me”. That was my first reaction too. Software development requires long slots of concentration because we need time to load the whole conceptual model of what we’re working on into our mind before being effective, and this implies some overhead. But then when someone asked this very question to the speaker, he answered something like “what if you are loading too much? what if limiting the amount of time you are going to spend on a given task forces you to load just the minimum you need to solve the matter at hand? what if it made you more productive?”. And it made me think: “hmmm… It’s worth a try.” So I will probably try that as well soon.

Overall, this edition of Devoxx was great! The first 2 days, I was somewhat afraid that it would be disappointing, because you could feel that everything was “cheaper”, that there were less sponsors, less schwag, less tempting hostesses. But then the most important part was preserved: amazing independent content and a great community spirit. Finally there was an interesting special guest this year: Twitter. Twitter was everywhere. People were tweeting live from the sessions, there was a projection board with all devoxx-related tweets in the hallway. I and a bunch of my colleagues were even using twitter to cover Devoxx live for our fellow Axenian java developers on our intranet. Twitter was really everywhere this year.

So thanks a lot to Axen for allowing me to go there. Thanks to Stephan and the BeJUG for putting it all together. Thanks to all the great speakers and to my colleagues. This was really a great edition and I can’t wait for the next one.

PS: All the talks will be available in the weeks to com on So stay tuned.

Conference Guide Available

Conference Guide Icon

Woohooo! Exciting times! It’s confirmed, I will be at Devoxx the whole week, and my Conference Guide iPhone application has just been approved. For your information, it only covers Devoxx 2009 for now, but it’s meant to be generic and I will add more information for other conferences soon: TEDxBrussels, JFokus, etc. The application is free for a limited period of time, so go ahead and install it!

More features for the iPhone application are coming, maybe not for Devoxx (the Apple review process makes things really slow), as well as other mobile clients. An Android client is already in the pipe, and if you are a Palm Pre or Symbian developer, feel free to contact me. I can give you access to the same public API I’m using for the iPhone version.

Finally, if you are a conference organizer and you want your event information to be available on mobile platforms without having to develop your own applications, feel free to contact me as well.

And by the way, if you are a company, and you are thinking about developing your own iPhone application, whether it is for marketing purposes, to sell content or to improve the productivity of your salesforce, I’m your guy. And I can do much more than just iPhone development ;o)

Text, Expressivity and Culture-Oriented Programming

Following up on my reflexion about what could software development look like a few years or decades from now, there is this big problem that has been bugging me for years now and that I have never found the time to really tackle: expressivity. In the same way as files appear to me as the biggest obstacle to collaboration, I think the main barrier in the way of expressivity is TEXT.

It’s hard to admit, but we’re still building software like cavemen. We don’t have spoken language, just a bunch of noises, we don’t conceptualize much but we do communicate with a few gestures and more importantly some colored drawings on cave walls. The way I see it, we are not much more advanced than that, but it’s normal, software is still relatively young as a discipline and although it has already changed our lives, we have to imagine that it’s just the beginning. And the good news is that we are headed in the right direction.


We started off with most elementary way of storing information and communicating with a machine: zeros and ones. Binary. It was too elementary, more like noises coming out of our mouths, so we started to group bits in octets corresponding to hardware instructions and characters. In fact, we added gestures to noises. Then we grouped instructions into statements and procedures, and we designed a way to translate those into the most elementary form of language that machines could understand. We started drawing on walls. But as procedures multiplied like crazy, we needed to conceptualize some more, talking about classes, objects, methods, properties, and so on. Spoken language was born. And with higher level concepts like services, components and multiple programming languages, we added written language. OK, the analogy is not that good, but you get my point: I’m convinced we’re still very early in the overall evolution of communication with machines, and although this evolution is somewhat slow and creates a lot of inertia, I believe that if we want computers to really expand our capabilities (note that I didn’t say “replace us”), we need to go further in abstraction levels.

So what’s next? Binary, assembly, procedural, object-oriented (yes, and functional, if you want), then what? Model-driven? I’ve tried that, it’s just replacing the constraints of text with the constraints of visual representations. It sure makes it easier to conceptualize, but at some point we’re still translating those visual models into text code, which we have to compile. The roundtrip is just too long. What about domain-specific languages? Well, I’m more into that right now. It looks like communicating is naturally based on languages, collections of concepts that relate with one another to describe what a software is and what it does. So focusing on making it easier to define new languages definitely goes in the right direction. That’s why it’s so linked with meta-programming: instead of statically defining layers upon layers of fixed concepts to describe systems with even higher level abstractions, let’s define the root concepts we will use to describe languages that will allow us to describe our systems. That’s why I’m so interested in Groovy at the moment for internal DSLs, although I prefer the more elegant idea of external DSLs and language workbenches, like Jetbrains MPS does.

All of this evolution makes me think of a video I saw recently, that tried to make String theory more accessible:

Let’s say binary is our dimension 0. Assembly is dimension 1: a line. Procedural programming is dimension 2: a plane. Object-Oriented Programming is then 3rd dimension: a volume. And it’s very hard for us to leave it, as it is our most natural way of seeing things. But that’s where I find this explanation of String theory particulary interesting (although not rigorous as some math geek friends of mine pointed out): there starts a cycle. Dimension 4 is a line again, formed by 2 different Object-Oriented Languages, like Java and C++ for example. Still there? Good! That’s where the fun starts: dimension 5 is a plane composed by all the parallel universes that are created by our own choices. Functional programming and OOP can be considered as forming such a plan. Now what if we could design a way to go directly from one of those paradigms to another one, to fold the plane in the 6th dimension: please welcome language-oriented (or meta-) programming! See the cycle? Now most of us are stuck in the 3rd dimension, and some of us are already experiencing the 6th dimension.

So there we are. Seventh dimension is the line joining the set of all possible timelines starting from our software big bang, which is the binary transistor, to another set of possible timelines, starting from another big bang. Quantum computing can be another option, but it’s a hardware one. What about software? Isn’t virtualization a way to forget about the physical hardware? And there we go 8th dimension: going from binary transistors to quantum computing is one line in the seventh dimension. Choosing to go to virtualization instead creates an branching line in the 8th dimension. Which means that if we want to create our ninth dimension, we need to fold the eighth in order to jump from quantum to virtual computing. And that’s where I locate what I call Culture-Oriented Programming. The third stage of the third 3-stage cycle. The final frontier? The next step? Hooooo… my head hurts.

But wait a second, I only talked about computing here. A virtual reality. What if dimension 10 was the line uniting computing with the real world in the purest possible way. Direct communication between human beings and computers. Who said “scary”?

PS: I didn’t intend this post to be so “theoretical”. I only thought with my keyboard and let my imagination go. But I’d love to know what you think about that crazy analogy? Do you think we are limited to 11 dimensions like in string theory?

PPS: That might be my geekiest post EVER!

iPhone ORM Just Rocks

I have been pretty quiet lately, mostly for 2 reasons:

  1. I’ve been busy with
  2. I’ve been playing a lot with the iPhone SDK.

I didn’t know anything about Objective-C so it is a challenging experience to go back to the C world, but I’m starting to find it very exciting. After I had read Cocoa Fundamentals and the iPhone Application Programming Guide (very boring stuff, but hardly avoidable), after having gone through “Your First iPhone Application“, I found myself pretty frustrated because I missed a lot of knowledge to jump into sample projects.

Fortunately, I stumbled upon this great blog with plenty of very complete and up-to-date tutorials. There is this especially this TodoList example that taught me how to do most of the things I couldn’t figure out by myself just by reading the code of the Books sample.

But at the end of that tutorial, I realized that a very important part of my code was made of boilerplate and ugly ANSI-C code to setup database stuff, like in the old days of JDBC. Google was my best friend and allowed me to find SQLitePersistentObjects.  And boy it works great! And it makes the code so simpler. Make your own mind:

This used to be the application launching code:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
    [self createEditableCopyOfDatabaseIfNeeded];
    [self initializeDatabase];
    // Configure and show the window
    [window addSubview:[navigationController view]];
    [window makeKeyAndVisible];

// Creates a writable copy of the bundled default database in the application Documents directory.
- (void)createEditableCopyOfDatabaseIfNeeded {
    // First, test for existence.
    BOOL success;
    NSFileManager *fileManager = [NSFileManager defaultManager];
    NSError *error;
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];
    NSString *writableDBPath = [documentsDirectory stringByAppendingPathComponent:@"todo.sqlite"];
    success = [fileManager fileExistsAtPath:writableDBPath];
    if (success) return;
    // The writable database does not exist, so copy the default to the appropriate location.
    NSString *defaultDBPath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"todo.sqlite"];
    success = [fileManager copyItemAtPath:defaultDBPath toPath:writableDBPath error:&error];
    if (!success) {
        NSAssert1(0, @"Failed to create writable database file with message '%@'.", [error localizedDescription]);

// Open the database connection and retrieve minimal information for all objects.
- (void)initializeDatabase {
    NSMutableArray *todoArray = [[NSMutableArray alloc] init];
    self.todos = todoArray;
    [todoArray release];
    // The database is stored in the application bundle.
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];
    NSString *path = [documentsDirectory stringByAppendingPathComponent:@"todo.sqlite"];
    // Open the database. The database was prepared outside the application.
    if (sqlite3_open([path UTF8String], &database) == SQLITE_OK) {
        // Get the primary key for all books.
        const char *sql = "SELECT pk FROM todo";
        sqlite3_stmt *statement;
        // Preparing a statement compiles the SQL query into a byte-code program in the SQLite library.
        // The third parameter is either the length of the SQL string or -1 to read up to the first null terminator.       
        if (sqlite3_prepare_v2(database, sql, -1, &statement, NULL) == SQLITE_OK) {
            // We "step" through the results - once for each row.
            while (sqlite3_step(statement) == SQLITE_ROW) {
                // The second parameter indicates the column index into the result set.
                int primaryKey = sqlite3_column_int(statement, 0);
                // We avoid the alloc-init-autorelease pattern here because we are in a tight loop and
                // autorelease is slightly more expensive than release. This design choice has nothing to do with
                // actual memory management - at the end of this block of code, all the book objects allocated
                // here will be in memory regardless of whether we use autorelease or release, because they are
                // retained by the books array.
                Todo *td = [[Todo alloc] initWithPrimaryKey:primaryKey database:database];
                [todos addObject:td];
                [td release];
        // "Finalize" the statement - releases the resources associated with the statement.
    } else {
        // Even though the open failed, call close to properly clean up resources.
        NSAssert1(0, @"Failed to open database with message '%s'.", sqlite3_errmsg(database));
        // Additional error handling, as appropriate...

Now it’s just that:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	NSMutableArray *todoArray = [[NSMutableArray alloc] init];
	self.todos = todoArray;
	[todoArray release];
	[self.todos addObjectsFromArray:[Todo allObjects]];
	// Configure and show the window
	[window addSubview:[navigationController view]];
	[window makeKeyAndVisible];

And this is just one example. All the CRUD operations are so much simpler. And I didn’t even need to create the SQLite database. It’s almost a shame Apple didn’t include such a framework in the SDK. For your curiosity, you can download the project here.

I love it! Now I should be able to get my hands dirty with my real project. More on that later ;o)

MobiMap First Release Candidate is Out

We needed a reusable mapping component for TagSpot development, and we wanted it to be Open Source so that everyone can reuse it and improve it for the general interest. There was no such library available on the environment we’re working on so… we made it!

And here comes MobiMap. MobiMap is a library that offers a reusable and customizable mapping component for several mobile platforms. Today, we’re releasing the first release candidate for version 1.0 of the JavaME version. We’re still working on porting this library to Windows Mobile and iPhone environments, and we’ll release the final version of all three libraries at the same time. Until then, we need feedback from mobile developers and we need help to improve the library.

The project website is on
Out support forum is on
Our issue tracker is here:
MobiMap’s Subversion repository is here:

Special Thanks go to…

First I would like to thank developers of Pyx4Me and Microemulator, thanks to which we could develop this library on the Mac.

I would like to thank Romain Guy, Richard Bair and the whole SwingLabs Team: MobiMap component is heavily inspired from JXMapViewer Swing component.

Special thanks also go to Antoine Jacquet, aka Royale, whose blog article about tile providers really helped me a lot in understanding all the tile APIs.

And last but not least, thanks to the whole TagSpot team for their help and support.

Finally, if you want to see what MobiMap can do on your phone, you can type the following URL on your phone: Or if you’re just too lazy to type this URL and you know how to use a QRCode, you can use the one on the right.

Be careful though, as MobiMap will download quite a bit of map data over your mobile connection so…