Round table at Microsoft TechDays 2013

I had the pleasure to be invited by David Catuhe to participate in a round table about Windows8 development during Microsoft TechDays 2013!

I was joined by Christopher Maneu from Deezer and Guillaume Leborgne from MCNext, both deeply involved in Windows development. David (cropped from the photo) led the discussion with Jean Ferré, who leads the developers, platform and ecosystem division at Microsoft France.

The discussion was very interesting and openly addressed the late start of Microsoft on mobile. They seem to have spared no effort to ease the work of developers, for example by opening the platform to development in HTML5/Javascript. I confess I initially thought it was a strange choice for native apps but it seems to have attracted quite a few web developers.

This round table was a great opportunity to meet smart people and gain insight into the Microsoft platform! Thanks also to the journalists in attendance who covered Algolia in the IT press.

Meet us at the Mobile World Congress! - The Algolia Blog

We’ll be in Barcelona next week for the Mobile World Congress! Last year, more than 67,000 attendees participated in the event.

We will use this opportunity to launch our new website along with a brand new offer… Algolia for FREE! Stay tuned!

If you happen to be attending MWC too, ping me if you’d like to discuss over a coffee :) (@dessaigne on twitter, or nicolas at algolia dot com).

We ranked Second at Start In Paris!

Start In Paris is a monthly event where 5 startups have the opportunity to pitch their service to the Paris startup community. After a first selection and then a public vote, we were selected as one of 5 finalists of the #22 edition that took place yesterday, January the 28th!

Start In Paris

Algolia has greatly evolved over the last few months, so it was an excellent occasion for us to test a new pitch! And the response has truly exceeded our expectations. After a 5 minute pitch we received a rush of questions, displaying interest and insight from the 400-strong audience!

While we were the only tech startup to pitch to an audience including only a few developers, we ranked second in votes, just behind Kitchen Trotter, our fellow Seedcamp finalist from last December. Congrat to them, they were truly excellent!

[Edit 03-Feb-2013] Check out Alexis Niki great feedback about the event on Rude Baguette [/Edit]

Nicolas at Start In Paris

Sharypic benefits from Algolia Search!

Demonstrating how Algolia Search functions in the wild, in this post we will discuss a recent integration with sharypic, another Paris-based startup focussed on photo sharing at events.

Sharypic is a web and mobile app dedicated to collaborative photo sharing, focused on enabling users to easily gather photos from attendees during and after an event. The platform allows users to collect and share photos from all devices, including mobiles (via Twitter and Instagram), cameras, and computers, and from already existing albums on Facebook, Picassa, and Flickr. One of their killer features is the ability to stream photos to a live PhotoWall at the venue and to an embeddable slideshow widget. This increases engagement both with event attendees and with an online audience. On sharypic one of the primary ways that users discover events is via a search bar, in addition to pages highlighting recent and popular events.

SharypicThe existing mobile search function relied on users accurately typing an event’s name into the search field, which limited the results (especially on smartphones where typos are common). By integrating Algolia Search into the mobile app, sharypic users can now type just a few letters of a search term, or enter it incorrectly (‘pqris’ instead of ‘Paris’), and the results will display the corrected term within event names, locations, descriptions, or hashtags.

Martin Fourcade, one of sharypic’s co-founders, said “For our users, it’s exactly what we needed. They can show the best photos of their events to friends without bugging their smartphone and whining about the internet connection. I’m lazy when it comes to typing on my smartphone, impatient when it comes to waiting for server responses… now everything is done with a few keystrokes!”

Sharypic’s other co-founder François-Joseph Grimault hopes that this new intelligent search will enable users to find specific content more easily, possibly leading to increased exploration on the platform. Time will tell how the new search feature affects user behaviour, but reducing user frustration through quick and efficient search is a step in the right direction.

Download the latest version of the sharypic app, including integrated Algolia Search, and have fun with photo sharing at your next event!

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]

What is the Problem with the APK format?

Let’s look at our own example. At Algolia, we have designed an efficient binary data-structure that is able to answer instant-search queries in just a few milliseconds, even with a very big data set (for example with all the world cities’ names from Geonames: 3M+ entries). This data-structure is designed to be used directly on disk without being copied in memory. To obtain optimal performance, we use a memory-mapped file which is standard on all platforms, especially on Linux.

We have been able to use memory-mapped files on all platforms, except on Android!  In fact you can only retrieve an InputStream from a file packaged in an APK. So the only solution to use a memory-mapped file is to copy the resource from the APK on disk and then to use the file-system. This seems like re-implementing an installer in each application.

Is the APK so bad? Why did they design it this way?

I imagine that Android developers chose this approach to solve some pitfalls of file-systems. I can think for example about solving performance problems when you have a lot of small files in one folder, or reducing the size of applications on the device (resources are compressed in the APK and decompressed only when the application uses them, which actually contributes to the sluggish image of Android).

I may of course be wrong, there may be other more important reasons for this approach. But if not, Android should have thought more about the consequences of their choice: in the long term, the APK constraints are more serious than those small pitfalls that could have been solved in other ways.

But wait… Android applications can contain dynamic libraries (.so files) via NDK. Isn’t it the principle of dynamic libraries to be memory-mapped? In fact I am pretty sure they discovered this problem when working on NDK since dynamic libraries are automatically extracted from APK file at installation and stored in an application directory in ‘/data/data’. I am wondering why they decided to implement this hack instead of fixing the problem…

Conclusion

Developing an API, a SDK or worse, a whole platform, is extremely difficult. Let’s face it, it’s unavoidable to ship some badly designed components or inconsistent APIs. We definitely need to listen to developers’ feedback even when it hurts. Actually, the real difficulty comes when it’s time to put things right without alienating existing users!

By the way, if you know more about APK design choices, I’m interested to hear from you!

Search