Algolia Search Offline SDK now supports Cocoapods

We have great news for our iOS and OS X users: our Offline SDK is now available as a CocoaPods dependency.

Cocoapods is a popular dependency management tool that lets you specify the libraries (dependencies) you want to use for your project in an easy-to-edit text file (Podfile). It then fetches all the required libraries and sets up your Xcode workspace.

You can now set up Algolia Search Offline in your iOS project with this line in your Podfile:
pod 'AlgoliaSearchOffline-iOS-SDK'

You can also set up Algolia Search Offline in your OS X project with this line:
pod 'AlgoliaSearchOffline-OSX-SDK'

Once you’re done, simply use the “pod install” command to set up Algolia Search Offline in your project. Now it’s easy to manage library dependencies for iOS and OS X projects!

Search on OS X: Search Kit vs Algolia

I recently read Mattt Thompson’s post about Apple Search Kit and he’s right about it being rather unknown, at least I had never heard of it before. So my very first thought was “how does it compare to our own SDK for OS X?” I immediately asked Julien if he could perform a few tests. Here are our findings.

Scope of use

Before examining the technical differences, it is important to stress the different intents behind the creation of both tools.

Why Android APK Format is a Mistake

When I started to develop for Android it appeared to me that an APK file was just an archive, a simple approach that you can find in many systems today. Files are extracted from the archive at installation and you can access them via the file-system.

This seemed even more reasonable since Android uses Linux which is very good in respect to POSIX standards.

But I was completely wrong! An APK is not a mere archive: the application starts from and uses the APK at runtime! This is a horrible decision that will probably hurt Android for a long time…

[Edit 28-Jan-2013] The goal of this post was to express my point of view about the bad properties of using directly the APK file at runtime versus relying on the file system. I used memory-mapped file to illustrate this but the post is incorrect on that topic. There is in fact a way to memory-map a file directly from the APK: you can use an extension for which files are stored uncompressed inside the APK (mp3, jpg, …) and use the AssetManager.openFD() or Resources.openRawResourceFD() to have offset/length inside the APK file.

All my thanks to Jay Freeman for his excellent feedback. His comments helped me to understand my mistake and to improve our Android integration!
[/Edit]
Continue reading…

Android NDK: How to Reduce Binaries Size

When we started Algolia Development for Android, binary size optimization was not one of our main concerns. In fact we even started to develop in JAVA before switching to C/C++ for reasons of performance.

We were reminded of the importance of binary size by Cyril Mottier who informed us that it would be difficult to integrate our lib in AVelov Android Application because its size. AVelov is 638KB and Algolia was 850KB, which would mean that AVelov would more than double in size with Algolia Search embedded.

To address this problem we managed to reduce Algolia binary size from 850KB to 307KB. In this post we share how we did it.
Continue reading…

C/C++ is still the only way to have high performance on Mobiles

[Edit 15-Nov-2012] I had questions on reddit about the data-structures and algorithms we used. We develop an embedded search engine for mobiles and tests were done on our own data-structure that is far more efficient than SQLite or other platform options for this use-case. [/Edit]

When it comes to programming languages and performance, you can read all and its opposite on the web. It’s definitely a very controversial topic!

For Algolia the story started when researching an instant suggest algorithm and I used Java for two reasons:

Main reason: our first client was using Java on Google App Engine
Secondary: at that stage, I was doing a lots of refactoring and Eclipse is very efficient for these tasks

Once our algorithm was designed, I started to optimize performance on a desktop computer (core I7 950). For this, I indexed all titles of the english version of wikipedia (4 millions titles) and I optimized the Java code mainly by reducing the number of allocations. All instant suggest queries were then faster than 10ms.
Continue reading…

iOS: When ARC is a bad idea

I started developing for iOS in 2009 by learning about Objective-C language. At that time ARC (Automatic Reference Counting) was not yet available and developers were responsible for alloc/release/autorelease. I found it pretty straightforward as it was very similar to C++ and the resulting code was very self-explanatory.

When ARC was released at the end of 2011 it made a great impression on me and looked like the perfect feature for any programmer coming from the Java world who was not familiar with memory management. I started using ARC and discovered a major flaw that completely changed my mind. Here is an example :

[Edit 28-Jan-2013] This post describes a bug in ARC that was fixed in Xcode 4.4.[/Edit]
Continue reading…

Why develop our own Unicode Library?

Unicode Logo from Wikipedia

At a time or another, most developers come across bugs or problems with Unicode (about 3,720,000 results on google for the request unicode bug developer at the time of this writing). Let me tell you about my experience in the last decade and why we have now implemented our own unicode Library to produce exactly the same result across devices/languages.

I first started to use Unicode in 2004 when I was developing a Text Mining software specialized on information extraction. This software was fully implemented in C++ and I used IBM ICU library to be Unicode compliant (all strings were stored in UTF16). I also used some normalization functions of ICU based on decomposition but I did not notice any major problem at that time. I started to understand the dark side of Unicode later when I used it in other languages like in Java, Python and later in Objective-C. My first surprise was when I understood that a simple isAlpha(unicodechar c) method can return different results!