Martin Sonc

Android VerticalViewPager

2013-04-23T14:42:00.000-07:00

I've spent the last couple of months working on a project that required an implementation of the native +Android ViewPager that would support vertical paging. And since Google went blind I've decided to simply update the native ViewPager code. Naturally it wasn't that simple.

Fortunately, I am able to share the final code with the world this time, so head over to GitHub and check it out. The implementation is completely the same as for the native ViewPager, so no surprises there.

There's one bug I've managed to find. I can't for the life of me get the bottom EdgeEffectCompat (the blueish edge effect when reaching the last page) to render, so, +Android Developers, feel free to fix the damn thing :)

To see the problematic code check out lines 2155-2168 in VerticalViewPager.java.

If you manage to fix the bug or would like to recommend (or even better, implement) some improvements just leave a comment or find me on G+.

Android bug reports on the go

2012-12-08T21:04:00.000-08:00

We're all usually testing our applications all the time and discover the weirdest bugs while being far away from our computer with no real way to see what happened. All we can do is hope that we'll be able to reproduce the issue when we get to the computer.

Not any more!

With Android 4.2 an amazing option called Power menu bug report was added. Simply turn on the option in the Developer options menu and long-press the power button when you encounter an issue. A new option called Bug report will appear. The system will generate a report (it really can take a while and there is no progress indicator, so just be patient). When complete you will be presented with the Complete action using dialog where you should select the Gmail option for best results.

When the email arrives to your inbox there will be two files attached - the screenshot (really good idea!) and a bugreport-*.txt file containing one of the most complete system dumps I've ever seen. Most of you will probably be looking for the section labeled

------ SYSTEM LOG (logcat -v threadtime -d *:v) ------

Happy debugging! :)

Running ADB over WiFi

2012-12-02T16:55:00.002-08:00

Just a quick hint for everyone that would like to get rid of all the USB cables between your computer and the Android device you're testing your applications on. There's a simple way to persuade the ADB to run over WiFi without having to have root access to your device.

connect the device to your computer using the USB cable
launch the terminal and locate your adb file (android-sdk/platform-tools/)
figure out the IP address that's assigned to your device

settings / Wi-Fi / advanced

run the following commands (don't forget to replace [IP] with the IP you found in the previous step):

adb tcpip 5555
adb connect [IP]

unplug the device and enjoy the world of wireless
to enable USB debugging again just run the following command

adb usb

Android, Calendar and Time Zones

2012-09-17T18:40:00.001-07:00

Let's say you're building a time tracking app and want it to work for users that travel a lot. Simple, you say, just store the timezone value and move on.

Well, you might want to do some testing before that.

There are two ways to set the timezone in a Calendar object:

Both of them are supposed to work, but unfortunately the option one only works on Android versions up to 2.2 and option two only works on Android versions 2.2+. The simple solution is to simple set both values and voila - everything is working.

Oh, and another thing ... c.clear() does not clear the timezone value. Ever.

Android Calendar Madness.

Android Accelerometer Madness

2012-08-14T20:04:00.000-07:00

via wikispaces.com

I'm definitely willing to admit that we're not always using some mobile device's functionality as originally intended at Azumio, but we sure would appreciate some consistency across different Android devices. The previous sensor we decided to (ab)use was camera, which is still causing some sleepless nights with new and weird phone coming out quite regularly - you can read all about it in the Android Camera Madness post. This time we're trying to develop an app using the accelerometer, a really useful sensor embedded in every(?) Android device.

So, here's the story.

We need to monitor the movement during an extended period of time, which also means we need to get events in background. Which should not be problematic and easily solvable with a right combination of Services and WakeLocks. And, on some phones (for instance, GalaxyNexus can handle everything as expected). Unfortunately the other more popular Samsung devices are not that reliable. I've soon realized that we're gonna need some more black magic to make it work on Galaxy SII and Galaxy SIII that share a similar problem - when the screen is turned off accelerometer stops propagating the data.

Fortunately, the solution seems to be quite simple, all you need to do is listen to the ACTION_SCREEN_OFF broadcast and restart the accelerometer. Except, it's not that simple.

There are two more things that you need to be careful about:

allow some delay between the ACTION_SCREEN_OFF broadcast (1-2s seem to be just enough)
never do that on a phone that works as expected (so using, Service + Partial Wake Lock) when the screen is off

What we ended up doing is again, fairly simple when you figure it out:

listen for ACTION_SCREEN_OFF broadcast
check if you have the WakeLock and re-acquire it if needed
raise a sample counting flag and start counting samples
post a Runnable to a Handler via the postDelayed method that checks the counter (be careful, the Accelerometer might have sent some events after the screen was off - 5s timer and 100 samples seem to work)
check if you got any samples. If yes - you're good to go, just stop here
restart the algorithm
repeat 1-4 to confirm if it works

You need to be careful not to take any results as a guarantee that it will work the next time the screen is turned off, I've noticed that some phones are turning off the damn thing on random.

On some devices even that might not work, so the best you can do is display a warning and let the user decide if he wants to run the app with a full wake lock (you can dimm the screen, but never turn it off).

Android Camera Madness

2012-01-28T23:07:00.000-08:00

image: tested.com

Camera in Android works, and it works well - as long as you don't try to do something a bit more complicated than taking photos and shooting videos. Anything more soon reveals some flaws in the implementation.

In Instant Heart Rate we are doing some heavy processing of images taken by the camera and we would expect some consistency across Camera implementation across different devices and Android OS versions out there. Unfortunately, that's not the case.

Let's start with the flashlight

When user starts the measurement we turn on the flashlight to provide enough light to see "inside" your finger. We clearly tell them that the results might be lower in quality on devices without flash, and would provide a reliable result on the rest of devices. But, what do you tell the user when device has the flashlight, but the manufacturer decided (I would rather say forgot) not to allow the applications to turn on the flashlight when needed? We are seing this problems on a few new devices, that have a lower price that makes them easily affordable and do as such have a quite large number of users. Here comes the first round of one star reviews

Frame rate

We require a high frame rate to get the best results. We have even optimized the algorithm to handle lower frame rates (as a workaround for some older Motorola devices). But, what do we do when:

device ignores the frame rate that you set (even when the frame rate is one of the ones device reported as supported)
device crashes when you try to set the frame rate
device changes the frame rate during the measurement (again, without providing a way to retrieve the new value)

It gets even worst, when you combine it with the next issue.

Time stamps

When camera captures the frame it is sent to the application via a callback. Since the camera is not running on UI thread, there is a time difference between the actual capture time and the time the frame arrived to the application.

But, since we are expecting the UI thread to occasionally get blocked with animations, layout updates and all the other Android Layout nonsense (since nothing is rendered on GPU) we provide the camera a little buffer so we get all the captured frames for processing. The buffer size is calculated according to preview sizes available on the device since we do not have a big chunk of memory available for allocation (for instance and as some devices only provide 640x480 or even 800x600 preview sizes we can sometimes afford only one or two.

And since no time stamp is associated with the frame returned to the application, we have no obvious way of knowing, when the frame was taken - we can only make a fairly well educated assumption. Let me try to illustrate this with an example:

In this case, the camera has reported a frame rate of 30 fps and we can buffer max 3 frames.

T = difference in time when the frame was returned to the application from the previous frame

# = number of the frame

# | T | ? |

---|-----|-----|

1 | 0 | 0 |

2 | 30 | 0 |

3 | 30 | 0 | all okay, steady frame rate

4 | 40 | +10 | huh, what happened here?

5 | 50 | +20 | ok, UI thread is busy, the frames are delayed

6 | 50 | +20 | so, the delay is now 50ms, 1 buffer is taken

7 | 70 | +40 | the buffer is full. next lost frame is discarded

8 | 10 | -20 | huh, one buffer got processed, yay

9 | 50 | +20 |

10 | 40 | +10 |
11 | 60 | +30 | and here we are, we just lost a frame

So, we can be creative and put a modified timestamp to a frame using the logic illustrated above. And it works really good, as long as the camera maintains the frame rate. But, some cameras are being smart about it without providing any pointers to when it happened and what the black magic actually made. They detect dropped frames and modify the frame rate so the number of lost frames is as low as possible - and since the frame rate sent to the camera or the frame rate the camera is returning, that is only a hint. A hint!

Native access

It turns of that Android knows when the image was taken. It just gets lost with all the levels of abstraction. So, in theory we could just write the algorithm in C/C++ and get the native Camera interface. And the code would run much faster too! So, we have a solution to our problem. Oh, wait, no we don't. The native Camera implementation is considered a private API and the camera API has changed with every single major Android release and is different across the devices since manufacturers tend to write their own implementations. So, we would need to provide an implementation for all the major releases, all the devices and the code would most likely break with every new Android version or Android device.

Magical devices

Last but not least - there are some devices that are best described to be magical. Rooted devices and devices with custom ROMs are a majority, but are far from being the only devices that are a bit special.

Some custom ROMs do not have a Camera implemented, so it's a bit unrealistic expecting from us to support them. Fortunately, this seems to be limited only to devices with no access to Android market, so we don't really care.

Then there are devices, that throw a NullPointerException when you try to get the Camera object. Or others, that are throwing weird exception when you try to get a property from a Camera object:

"java.lang.NullPointerException",

"android.hardware.Camera$Parameters.getSupportedPictureFormats(Camera.java:1721)",

Or some, that can't even parse their own properties without choking on them:

"java.lang.NumberFormatException: unable to parse 'null' as integer",
"unable to parse 'null' as integer",
"java.lang.Integer.parseInt(Integer.java:347)",
"java.lang.Integer.parseInt(Integer.java:323)",
"android.hardware.Camera$Parameters.getInt(Camera.java:905)",                "android.hardware.Camera$Parameters.getJpegThumbnailQuality(Camera.java:979)",

Oh, and from time to time the Camera service simply dies and there's no other way to get it up and running but to restart your phone.

So do what we can, we are being as creative as possible and try to support every device out there, but sometimes our hands are just tied and we are stuck at a dead end.

"Now do the animations"

2011-10-24T23:42:00.000-07:00

(cc) tarabrown via Flickr

I made a mistake.

There was a new app to write, designs all ready, waiting for me to dig in. So, naturally I took a few hours to go trough the whole thing, pen and paper technique, trying to figure out how to translate the designer's idea to an actual product.

Ok, done, time to open Photoshop and enter the world of pain (no surprise here, I hate PS, I find it extremely counterintuitive and bloated). First screen done, supporting all the resolutions, yummy, now translate the whole thing to Android Layout XML, another pleasant process. A week or two later, there was a beautiful app just waiting to be shown to the world.

Here it comes, the 'I fail' part of the post.

"Nice job. Now do the animations."

And let me tell you, if your layout was not created to accomodate the animations from day one you're pretty much screwed. With all the relativity involved in the product I got a layout that can adopt to any Android phone's screen size, a must in the Android world, but it animation wise - a big no-go.

Let me just give you an example. Below the header part the application there is a fade to transparent part of the view, covering the top few pixels of the scrolling view under it. So, I did the following:

Simple enough. But try to animate the header and gradient to seamlessly slide of the top of the screen at the same time. No way!

I'm still working on it. And I have learned my lesson.

Fine Tuning Android Layouts

2011-10-03T23:53:00.000-07:00

One of the main differentiators in mobile app market is the final polish of the application. There are many applications available providing really awesome functionality but most of them are lacking the magic Final Polish.

Being a developer I have to constantly reming myself that I am not coding for fellow programmers, but for the end user, some John Doe that wants the application not only to work perfectly, but expects it to have good and easy user interface, just the appropriate amount of rich graphics and to top it off some nice animations that guide him trough the app. And Android is not much help with that.

One of the most recent projects I have been involved with, Instant Heart Rate, features a rather rich, circular interface positioned in the center of the screen. Being a bit different that most android applications, the code creating the layout is a bit of a ... well, mess.

The effort that was put into making this thing look and feel right was quite big, and I am sometimes wondering if it was worth it. Implementing a more linear, square-ish design would be much easier and would provide a similar experience. Similar, but not the same.

Some developers would argue that all the problems would go away if Android would have a proper WYSWYG editor, but I would agree that we don't really want one. Not only does this weird XML syntax encourages you to optimize the layout, it also forces you to think about all the different screen sizes Android has to offer. And after coding for Android for about three years now, RelativeLayout and NinePatch images have become two of my best friends. And I am quite surprised to have met several Android developers that have never herd of those. Oh, and yes, AbsoluteLayout is finally marked as deprecated!

Another poorly documented but really interesting option available in the LinearLayout is the weight parameter, enabling you to "assign an 'importance' value to a view".

If you are singing "A little less conversation" by now let me show you some code in action.

Simple Useless Example #1

Pretty simple, straight forward approach, working on all devices and on all orientations. As you can see, the first ImageView element has the weight parameter set to 1 and the second to 2, making the first one less important by 1 'point'. The TextView added later is positioned above the LinearLayout, producing the following result:

While this is a pretty trivial example it produces perfect results on every screen and orientation.

Simple Useless Example #2

If you are looking for a bit more complicated example there is one available in my GitHub repository:
https://github.com/LambergaR/layout_demo

Yes, it has 'rainbows' ... but hey, we're in San Francisco