C and C++ Callbacks with SQLite

Everything is data. Occasionally, when programming day-to-day objects and functions, you get a reminder that everything from the keys you press to the code it makes to the bits it reads is data.

But enough, say you want to use C++ with SQLite in a sane, object-oriented way. More specifically, you want to use sqlite3_exec to execute a SQL query. Here’s an example:

int rc = sqlite3_exec(db, sql, callback, data, &errMsg);

What is each one of these parameters? The first, db, is your opened database, sql is a const char * query you want to run, callback is a static function pointer, data is a peice of data you want to send to callback, and errMsg is what it sounds like. Okay, all’s well, lets define that callback.

static int callback(void *param, int argc, char **argv, char **azColName)
    return 0;

Damnit. This is going to be called once for every row, I don’t know when it’s going to end, and it’s static, throwing any hope for object-orientation out the window.

Or does it? Switch gears for a moment: What’s one of the hallmarks of object-oriented programming? I’m talking about the keyword this or self. What this is is difficult to describe to others because you’ll often find yourself saying something like, “this is this, like you know, this is this”. But this can be thought of as a hidden parameter passed along with every message sent to an object which can access the object that the message was sent to.

Well if this is what we’re after, this is a hidden parameter, and we’ve got a void * we can put whatever we want in, how about we just reconstruct our instance of an object using C++ casting?

First, make your request:

char* customer::getPerson(int id)
    rc = sqlite3_exec(db, sql, callback, this, &errMsg);

Then, define your C callback with C++ casting to turn person into this:

static int callback(void *param, int argc, char **argv, char **azColName)
    Person * person = reinterpret_cast<Person *>(param);
    return person->cppCallback(argc, argv, azColName);

Finally, profit:

int Person::cppCallback(int argc, char **argv, char **azColName)

Thanks to this StackOverflow post for the insight.

Developer Journal: MVC and Interoperability

The desire for code re-use is a strong one among considerations of how to design a program or application. This competes with the desire to implement applications in their native, and oftentimes proprietary, framework.

Arguably the most important part of a mobile application to be developed natively is the view code. Non-native views on any sufficiently complex data-centered app are almost always immediately identified by users: web views and non-standard behavior almost always give it away. Furthermore, perhaps the least important part of an application to be native is the model. The storing, manipulation, and retrieval of data is oftentimes very similar across languages and frameworks: a linked-list is a linked-list no matter what language it’s in.

Perhaps we can use this dichotomy to best satisfy the competing desires of code re-use and native implementations: keep your views and controllers in native code, but implement your data model in shared code. Specifically, I’m wondering if I can move an application’s model to C++ on iOS, Android, and Windows Phone and only implement views and minimal controllers in native code.

In fact, ideally, all data-related tasks would be handy to have in shared code: anything involving databases, making requests to servers, and parsing responses are the taks which come to my mind. I think that in order to achieve this, I’m going to need to compile a framework for manipulating a database, a framework for making network connections, and a way to have native code request and receive data.

I think a design like this at least works, but it could even be desirable. Maybe the best way for me to find out would be to try it.

iPhone 6 Plus First Impressions

I was a holdout. For three years, I used the magnificent iPhone 4S as my trusty telephone. When I upgraded from a feature-phone Nokia handset to an iPhone 4S, all the things I could do made me forget how I did without a smartphone: get all your emails on-the-go, use the decent web-browser to do tasks if a computer wasn’t around, keep yourself completely amused in all idle moments.

A week ago, I picked up the Ridiculously Big iPhone® and it is also one of those products that I already can’t remember how I did without.

My 4S really complimented an iPad well for some tasks: where the phone could send a quick message, the tablet could comfortably guide you through a book.

This 6 Plus, on the other hand, does not play so well with an iPad. It demands use, because as big as it is, it does fit in your pocket … barely, it has a screen that is just shorter than the iPad is wide, and it always has Internet connection (and to connect your iPad to 4G is quite pricey). It’ll send your quick message and then guide you through that book as you quickly switch to your train-ticket app, or whatever else it is you do.

Any media shines on the 6 Plus: it’s in your pocket, so you can play music; it has a massive screen, so you can play games or browse the web or read a book; the portrait keyboard is well-suited to two-handed use, so you needn’t shy from heavy-input use …

But there’s one thing that totally sucks about the 6 Plus.

Checking the time.

Oh I know, the humanity, you’re walking somewhere to do some lovely fun activity or something and you want to check if you’re late and you have to pull out a 5.5 inch telephone to find out. How hard.

But seriously, this device isn’t great for glance-able information, using it demands attention.

But Apple has no need to create the need for a product category which involves glance-able information.

Right guys?