Using the proper data type

How to represent datatypes? For example in a JSON output.

Dates

Don’t do things like:

2014-01-17T18:01:30+01:00

Seriously. Do you have any idea how difficult and computationally intensive this is to parse? And I’m not even talking about the variants with timezones like GMT, PST, Z, +- offsets and so on.

Instead, do the following:

1389978090000

This is the number of milliseconds since the beginning of times, that is 1st January 1970 with an UTC time zone. It’s easy to parse and there’s no room for interpretation. Every library understands that format.

Durations

Don’t do

3111.44

This uses floats. Not only it can give rounding errors but it’s slower than integers. Instead do:

3111044

which is the number of milliseconds. Again easy to parse and every timer related library understands integer milliseconds, not necessarily floats.

Keep it simple and efficient.

MediaCodec: Android’s half-assed codec API

Android’s media playing capabilites have always been an annoying issue. Either you use the high level MediaPlayer API where most of the control is about supplying an URL to play, or you use JNI to write low level C code to do all the work (as of 2014-01-20, Android Studio doesn’t support the NDK). Since Android 4.1 (API 16), there’s a MediaCodec API which gives access to the decoding process using java code. The concept is as follows:

  • use MediaExtractor to demux the stream
  • decode the buffers using MediaCodec
  • render into the surface

This sounds great… until you start using it. Unfortunately, there are several shortcomings to that API:

  1. no control over the buffers. MediaCodec has both getInputBuffers() and getOutputBuffers() methods which give pointers to buffers whose sizes cannot be chosen. On a Nexus 5, the former is 4 and the later is 19. The only option when one needs bigger buffering would be to copy them around, which incurs a performance drop.
  2. MediaExtractor has no way to get access to the data-only portion of the stream. It’s basically designed to feed its output to MediaCodec. Feeding a stream composed of multiple parts (as in the case of HTTP Live Streaming) is impossible and you need your own custom parser.
  3. There’s no control over the rendering. You cannot touch the buffers but just render them into a surface.

It looks like this API was mostly designed for encoding media and the decoding was added as a bonus. It should work fine for decoding a file. For network sources you’ll probably run into streaming issues. Anything more advanced requires diving into the complexities of the NDK and OpenMAX API.

On a related note, this blog post has a good history of Android’s video decoding.

Also it seems that Google is still making improvements on that area so it might not stay half-assed forever.

New version of I’m sleeping

I'm sleeping

A new version of I’m sleeping has been released!
Changes in this version:

- automatically puts the phone in silent mode when set in the UI and the time is within the sleeping range
- likewise for unsilencing
- added a "call through" mode which allows repeated calls to reach you

Head over to Google Play to find it.

Crysis 2 QuickSave Mod

Crysis 2 is a great game. Outstanding graphics, fast dynamic rendering, good sound effects, advanced AI, etc.. Then someone at Crytek decided to remove quick saving at the last minute before releasing the game, making it annoying to play.

Which is why I did a quicksave mod. You can download the Crysis 2 quicksave mod.

To install, simply unpack the .zip into your Crysis 2\Mods folder.

Apple’s “inventions”

Tim Crook

So let’s see what Apple copied from Android invented with the iPhone 5:

  • Shared Photo Streams (Google+ Events Party Mode)
  • Panorama photo mode
  • taking photos while shooting a video
  • Points of Interests in Maps
  • Turn navigation
  • Satellite imagery in Maps
  • 3D Maps
  • changing camera angle in Maps with 2 fingers
  • iCloud tabs (Google Tabs Sync)
  • Sports team scores in Siri
  • Movies recommendations in Siri

And I’m not talking about 5 GHz WiFi, 16:9 screen aspect ratio, 1080p video support, and backside illuminated camera sensor which were available on the Galaxy Nexus which was released almost a year ago.

Now I suppose they can sue everyone else.

Apple’s Do Not Disturb feature already on Android

I was pretty amused to discover that Apple’s Do Not Disturb feature in iOS 6 is pretty close to my Android application I’m sleeping, which was available long before their version.

Android doesn’t offer such feature by default (but some ROMs do). At first, I was puzzled by that lack. I searched on Google Play but didn’t find anything that suited me, namely:

  • simple and intuitive user interface
  • intelligent design, with separate settings for week days and week ends
  • white list, allowing close friends or family to call you at all times
  • manual mode for naps or out-of-schedule sleeps without having to reconfigure everything

So I wrote it myself. Apple’s version is similar except it uses favorites instead of a white list. It also has a “go through” mode if the caller insists but doesn’t feature a manual mode (Apple still didn’t “invent” widgets).

Screenshots below:

Apple’s version
My version

Available on Google Play for free and without ads.

Android, WiFi and power consumption

Android is not very well documented when it comes to power consumption. Most user manuals tell you that, in order to save power, you have to turn off the features you don’t need. While these advice have their merits, they often involve a significant trade off. For this article, we’ll focus on wifi usage.

Wifi versus mobile data

When it comes to power usage, wifi behaves quite differently than 2G/3G mobile data. To keep things short, wifi is more power efficient when doing actual data transfer but less when staying on doing nothing, at least that’s the case with simple implementations. For example, my Sony Ericsson Xperia X10 Mini Pro (Android 2.1) will barely last a day when wifi is turned on and connected to an access point (AP) and there’s a reason for that:

contrary to what happens with mobile data, Android cannot sleep while a wifi link is active, even idle

Well. At least that statement was true until fairly recently.

Wifi powersaving mode

Since recent versions of Android, a power saving mode (PS-Poll) was implemented and many phones use it. It works in the following way and is only active when the screen of the mobile device is off:

  • the AP will keep packets for the phone buffered
  • the phone will periodically (typically every few seconds) poll the AP and asking if there are new packets
  • if there are, the AP will send them in a burst

It’s like if the phone was taking a dive, surfacing each few seconds to ask if there are packets. This decreases greatly power usage. The drawback is that it increases latency significantly and some APs don’t handle power save mode properly and simply disconnect the device. This is fine for “background data” usage though (syncing, email checking and so on).

Here’s how to test if your phone supports PS-Poll:

  • connect to your AP
  • on the phone, go to Settings / About phone / Status and look the IP address field
  • on a terminal on your computer, type:
  • ping -t <ip_address> (note: on Linux/Unix, drop the -t)

You should get some output like:

Reply from 192.168.1.71: bytes=32 time=452ms TTL=64
Reply from 192.168.1.71: bytes=32 time=200ms TTL=64
Reply from 192.168.1.71: bytes=32 time=1512ms TTL=64
Reply from 192.168.1.71: bytes=32 time=762ms TTL=64
Reply from 192.168.1.71: bytes=32 time=1768ms TTL=64

Anything bigger than 1000ms indicates that PS-Poll is active. Turn on the screen and notice how the timing become smaller because then PS-Poll is disabled, bringing better latency.

Sleeping is the key

While PS-Poll helps a lot, it still doesn’t solve the main issue. Phones’ greatest power saving strategy is to put the processor (CPU) to sleep mode, basically the same that happens when you put your laptop to “sleep”. You close the lid, the machine stops but the memory content stays intact so that you can quickly wake up again to resume work.

And this is also what recent phones are able to do. For example the Samsung Galaxy S II and the Galaxy Nexus have a dedicated ARM Cortex-M3 chip (a full blown CPU) and dedicated memory in their wifi subsystem. This allows the phone to be put to sleep while the wifi link stays active.

Android 4.0 and default wifi sleep policy

This is probably why the default sleep policy in Android 4 (ICS) was changed from “sleep when screen turn off” to “never”. I was actually surprised to see the change and had to do some research to find out why this was done.

Now not all phones implement this but if your phone is recent, chances are it does.

How to stop multicast packets flooding the wireless interface in dd-wrt

For some reasons, they don’t provide a simple GUI switch for this and their wiki page doesn’t have the correct commands.

Anyway, the way to do it is this:

Check what is your wifi interface. Go to status/Wireless and check the Interface field below (you need to connect at least one client). In the following example, we assume it’s eth1.

Go to Administration/Commands

Type the following (assuming your LAN is on the 192.168.1.x range):

insmod ebtables
insmod ebtable_filter
insmod ebt_pkttype
insmod ebt_ip
ebtables -A FORWARD -o eth1 -p ipv4 --pkttype-type multicast --ip-source ! 192.168.1.0/255.255.255.0 -j DROP

Press Save Firewall and reboot.

Voilà! No more multicast flooding of the wireless interface! This is handy if you’re using IPTV. As a bonus, normal multicasting on your LAN will still work (Samba, Homegroups, etc…)

The joke called DVB-T

DVB Logo

You can’t stop progress. When TV switched from Black & White to Color it was amazing. Now that the TVs are switching from analogic to digital transmission, a major step is done. See the following comparison:

Analog DVB-T
Resolution 720×576 720×576
Digital sound yes yes
Progressive (no interlacing) no no
Works with all antennas yes no
Reception with low signal yes no
Free MPEG image artifacts no yes
Channel switching delay none 2 seconds
Station transmission delay none 5 seconds

As you can see, DVB-T is clearly superior. You can’t stop progress.