tag:blogger.com,1999:blog-91068229153080301652024-03-05T20:07:02.338-08:00devtcgAnonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-9106822915308030165.post-4008468079669169582012-10-07T20:53:00.000-07:002012-10-07T21:03:42.991-07:00wssh: Handy utility for WebSocket testing<a href="http://en.wikipedia.org/wiki/WebSocket" target="_blank">WebSockets</a> are a pretty darn cool evolution of the web, but with any new technology comes some challenges providing adequate tools for testing and exploration. For HTTP, we have curl. For plain sockets, we have netcat. WebSockets now have <a href="https://github.com/progrium/wssh" target="_blank">wssh</a>. I stumbled upon this very useful tool recently in starting up my own advanced WebSocket project.<br />
<div>
<br /></div>
<div>
Unfortunately, there were some glaring bugs and annoyances, in particular in the area of automation and general netcat compliance. So, I brushed off my Python skills and I'm happy to report that after the weekend was over, the tool had matured quite a lot and was ready for some test automation.</div>
<div>
<br /></div>
<div>
Hoping to move the project to some QA folks for automation, I decided to whip up a quick recipe that demonstrates how the tool can be used to verify both client and server behaviour with minimal headache:</div>
<div>
<br /></div>
<div>
<b>A simple echo server test</b></div>
<div>
<br /></div>
<pre class="prettyprint"><code class="language-bash">#!/bin/bash
set -e
(echo foo; echo bar; echo baz) > testinput
cat <(cat testinput | while read a; do echo $a; sleep 1; done) | wssh -q 0 ws://echo.websocket.org/ > testoutput
cmp testinput testoutput
rm -f testinput testoutput
</code></pre>
<div>
<br /></div>
<div>
This script tests ws://echo.websocket.org under "real-world" usage simulating a 1 second delay between each line of input. This concept can be extended much further with some basic bash-fu, creating some fairly sophisticated unit tests.</div>
Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-62326927336001607292012-09-17T22:32:00.000-07:002012-09-17T22:32:40.770-07:00Significant keep-alive performance flaw in iOS' NSURLConnection<b>The problem</b><br />
<br />
I've recently done a lot of research to understand a perplexing performance problem haunting the iOS port of a commercial component I maintain at work (originally developed for Android). Specifically, the problem presents itself when the user navigates repeatedly to a specific screen in the application which issues an HTTP HEAD request (via HTTPS) to determine if a particular static resource has been modified. Normally, you would think, a quick and light-weight operation.<br />
<br />
However, the performance penalties we were seeing in this simple usage of NSURLConnection was a measurable delay of approximately 600ms, despite a round-trip time to our servers of only ~80ms over our local Wi-Fi network. Now I'm sure at this point a well informed reader is going to exclaim: but wait, this is HTTPS, there's a <a href="http://www.semicomplete.com/blog/geekery/ssl-latency.html" target="_blank">well known and significant handshaking penalty</a> versus HTTP! Of course, this same penalty exists for our Android version of the application, however this workflow on Android does not present any significant delay.<br />
<br />
<b>So, what's going on?</b><br />
<br />
The short answer: the connection has been closed. While NSURLConnection does support HTTP keep-alive, it has a client-imposed timeout of just 12 seconds <i>even for HTTPS</i>. This may seem like a reasonable timeout when you look at the problem with <a href="http://research.microsoft.com/en-us/um/people/padmanab/cse561/papers/pm94.pdf" target="_blank">1995 goggles</a>: loading a complete web page efficiently without requiring a separate<i> </i>connection for each resource on the page. However, in today's world the model is much richer. Web services dominate the landscape of mobile applications (even when the browser is the client), using the web for more discrete data exchange where appropriate and moving the rest client-side. <br />
<br />
And this data exchange frequently happens over HTTPS. Borrowing from Google's own <a href="http://dev.chromium.org/spdy/spdy-whitepaper" target="_blank">SPDY proposal</a>: the future of the web depends on a secure network connection. SPDY requires SSL and yet is designed for efficiency. A paradox only if you don't embrace long keep-alive timeouts.<br />
<br />
<b>Does it matter?</b><br />
<br />
The practical implication of NSURLConnection's short timeouts for users is a noticeable but not immediately reproducible delay experienced within applications that utilize web services over HTTPS. A common user scenario making for an easy repro case on a large number of mobile apps out there (go ahead, try yours) is the login screen. Logging in implies a secure connection, and often users are expected to take some time to awkwardly type their cat's name: Mr!Cuddl3s. I timed myself with this exercise: 13 seconds. In this amount of time, any HTTPS connections already opened to your application's domain have been closed and so here comes the 600ms+ SSL connection penalty before the user sees a frustrating message: "Your username or password does not match". Returning to the input field, you recheck your username, delete the password, and start again. If you were fast enough, you're quickly ushered off to the main screen for the application. If, however, you took more than 12 seconds again to retype things, you will see that penalty one more time. This is likely to repeat many times in the user's interaction with your application: idling on various screens reading content, setting the phone down for just a moment, etc.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><span style="margin-left: auto; margin-right: auto;"><a href="http://www.youtube.com/watch?v=ZbMVJmKcUO0" target="_blank"><img alt="" border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCtS2n2KyU07gH-mad_2Wlza_gec-4ewEe455vF0zM0HYcVyXJCvcq2SC0Df6kqXfeXnjy1DfqxTXCFeXgLerprwVQTBHhqI6yC7wvIjJ2ciBgWtwka2snh9NWwZ-0JE2cfcvEa3xvO_uF/s320/ssl-handshake-overhead.png" title="Practical demonstration of HTTPS connection re-use performance" width="320" /></a></span></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://www.youtube.com/watch?v=ZbMVJmKcUO0" target="_blank">TCP/SSL handshaking overhead shown in the Amazon Mobile app (Android left, iOS right)</a></td></tr>
</tbody></table>
The above image and linked YouTube video demonstrates the impact from the user's perspective of the 12 second connection timeout. As you see, the first request is much slower on iOS because Android has re-used the previously established HTTPS connection set-up through prior interaction with the app. Subsequent requests are identical in performance until after the user idles for 12 seconds again, bringing the favor back to Android once again.<br />
<i><br /></i>
<b>But what about optimization best practices?</b><br />
<i><br /></i>
There is significant precedence on the web suggesting that this is not a reasonable default. A variety of libraries that I sampled do not exhibit this behaviour (Apache HttpClient, Android's implementation of HttpURLConnection, and serf). None had such a short timeout, let alone even a client-initiated shutdown at all. The same conclusion holds true for HTTPS servers in production: a sampling of Google, Facebook, and Amazon servers suggest they are all willing to let HTTPS connections linger for minutes, not seconds.<br />
<br />
Surely there is some reasoned thinking behind this behaviour, right? Well, perhaps. I can find little material publicly available except a <a href="http://lists.apple.com/archives/macnetworkprog/2011/Mar/msg00016.html" target="_blank">brief thread</a> on Apple's Mac Network Programming mailing list where an Apple engineer draws the conclusion that the closure is to support the radio's ability to enter an idle state. While it is true that cellular radios have complex power saving state management (searching the web for material on Radio Resource Control [RRC] or Fast Dormancy has no shortage of white papers), I question the argument that the connection closure truly is in alignment with the details of the radio.<br />
<br />
The first piece of evidence against this comes from the nature of RRC's lack of specificity or standard on timing windows. Apple simply cannot know whether the network would ask the device to enter this idle state in 2 seconds, 10 seconds, or 15 seconds. So a naive, hardcoded timeout of 12 seconds is seemingly just as likely to incur the worst possible performance as it is the best.<br />
<br />
Furthermore, the hardcoded timeout is consistent between 3G and Wi-Fi connections which of course have very different radio stacks and performance optimizations. In the case of Wi-Fi, this appears to have even changed significantly from iOS 4 to iOS 5, with no change to NSURLConnection's behaviour. In my extremely informal testing on iOS 5, I found that the radio entered a low power state in just a few seconds, indicating that the radio is to resume normal operation to handle the connection closure if the user switches off the screen just a few seconds after an HTTP request. Hardly an edge case.<br />
<br />
Admittedly, we're getting into white paper territory ourselves here to properly and convincingly prove that this timeout harms battery life (let alone carrier network performance!). I'm not prepared to go through that much rigor just yet. Instead, I'd like to simply make a call to Apple to reconsider this behaviour and re-evaluate their own internal research. And, if you're reading Apple, please feel free to reach out to me if there is interest in a thorough and more academic study on this topic. I'd be happy to help.<br />
<br />
<b>What next?</b><br />
<b><br /></b>
NSURLConnection is intentionally opaque, offering no features to customize the underlying mechanics, making it easy for Apple to adjust them without fear of breaking backward compatibility. Unfortunately this means that there's no convenient way to work around the problem if your app uses NSURLConnection. While it is possible to switch to a third party such as ASIHTTPRequest, I don't personally recommend this approach as this transition makes it more difficult for Apple to implement or enforce reasonable connection management policies.<br />
<br />
The API is designed for Apple to implement best practices, so let's ask that they do exactly that.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-62840793610241406572010-04-13T15:02:00.001-07:002010-04-13T15:48:00.192-07:00Logcat, Improved.Logcat is a staple for most Android developers out there and I'm certainly no exception. I often have at least one terminal dedicated to logcat with sometimes many more with various combinations of options to control how I'm filtering the output.<br /><br />Recently it occurred to me that most of this work is designed to separate my program from the noise of the entire platform. The numeric argument printed after the tag in the logcat output is the pid responsible for that log line which I had used in the past to do this sort of filtering but it was a pain when the app crashed or was reinstalled because the pid would change.<br /><br />Enter my <a href="http://github.com/jasta/android-dev-tools/blob/master/proclogcat">proclogcat</a> script. This script tracks the pid as the process is killed and restarted and takes care of automating the <code>adb shell ps | grep <process></code> logic on first launch. The best part is the script can be combined with Jeffrey Sharkey's excellent <a href="http://jsharkey.org/blog/2009/04/22/modifying-the-android-logcat-stream-for-full-color-debugging/">coloredlogcat</a> script (or my <a href="http://github.com/jasta/android-dev-tools/blob/master/coloredlogcat.py">modified version</a> of it) for beautiful results.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv1kazubwgYxu2IBUsH7DTMukXmyM5B-3X6-ndEqavs5Mz3jxPoLyZBVKIS5TNMZYJifWCw36511V26fxCNjgZ13g_2M1zztJPL9c3626SDR3fUvnEEr122ElP-knjNghC6oMhrHyQ16PO/s1600/proclogcat-small.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 129px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv1kazubwgYxu2IBUsH7DTMukXmyM5B-3X6-ndEqavs5Mz3jxPoLyZBVKIS5TNMZYJifWCw36511V26fxCNjgZ13g_2M1zztJPL9c3626SDR3fUvnEEr122ElP-knjNghC6oMhrHyQ16PO/s400/proclogcat-small.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5459755330049553602" /></a><br /><br /><span style="font-weight:bold;">Download:</span> <a href="http://github.com/jasta/android-dev-tools/blob/master/proclogcat">proclogcat</a><br /><br />To use, simply copy it somewhere in your <code>PATH</code> and invoke either manually as <code>adb logcat | proclogcat <process></code> or in a function as is discussed in the script source code.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com5tag:blogger.com,1999:blog-9106822915308030165.post-35506500977491633602009-12-15T07:29:00.000-08:002009-12-15T07:29:26.519-08:00Gracefully supporting multiple Android platform versions in a single releaseThe Android platform has been aggressively updating since version 1.0 and now we're starting to a see a much more interesting mix of device types, manufacturers, and even platform versions out in the wild. Unfortunately sometimes this can be frustrating for developers wanting to look forward to support new features and conveniences, but to still support devices that are on longer update cycles (like with the G1).<br /><br />The pattern shown here will deal with multiple platform versions although can easily be applied in other situations. First of all, let's start with a preface about <a href="http://developer.android.com/guide/topics/manifest/uses-sdk-element.html">minSdkVersion</a>, <a href="http://developer.android.com/guide/topics/manifest/uses-sdk-element.html">targetSdkVersion</a>, and the Eclipse target platform. The *SdkVersion attributes are defined in the manifest <a href="http://developer.android.com/guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a> tag and define the minimum platform version your app can be installed onto (and tested on!), and the highest version that you tested to and were aware of during development. It is important that you test your application on all versions between and including min and target. The Eclipse target platform is the specific version that Eclipse will be compiling against, this is what permits us to compile code that actually does link specifically against the newer platform features. This is usually set the same as your targetSdkVersion.<br /><br />Now let's consider a practical example of a music player application which needs to implement a service in the foreground state during playback. Prior to API level 5, this was done with the <a href="http://developer.android.com/reference/android/app/Service.html#setForeground(boolean)">Service.setForeground</a> call, but level 5 and beyond deprecated this method due to widespread abuse. Instead, a new method was introduced (<a href="http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)">Service.startForeground</a>) which can be used to achieve this affect as well as setting an ongoing notification in the status bar. In many ways this is handy as the notification and foreground state were naturally already tied together, now there's an API combining them. But problems start when you try to test new code using this method on platform versions below 2.0 (API level 5). Specifically, Dalvik will throw a VerifyError when attempting to initialize the class containing the call to startForeground for the first time, even if the call is in a conditional statement. This method does not exist on pre-2.0 devices, and so cannot be included in your code in this way.<br /><br />A naive approach would be to simply use reflection to test for and execute startForeground, but thankfully Java offers a much more elegant design pattern for just this sort of thing. The basic idea is to create an abstract API that the rest of your application can access which hides the specific implementation of what's being performed, and does so in such a way that prevents the VM from initializing an unsupported class on an older platform. So you might try defining something like this:<br /><br /><pre class="prettyprint java-html"><code><br />public abstract class PlayerNotification {<br /> public static PlayerNotification getInstance() {<br /> if (Integer.parseInt(Build.VERSION.SDK) <= 4)<br /> return PreEclair.Holder.sInstance;<br /> else<br /> return EclairAndBeyond.Holder.sInstance;<br /> }<br /> <br /> public abstract void showNotification(Service context, int id, Notification notification);<br /> public abstract void hideNotification(Service context, int id);<br /><br /> private static class PreEclair extends PlayerNotification {<br /> ...<br /> }<br /><br /> private static class EclairAndBeyond extends PlayerNotification {<br /> ...<br /> }<br />}<br /></code></pre><br /><br />Now your service could be modified to make use of this new abstract API as such:<br /><br /><pre class="prettyprint java-html"><code><br />public MyService extends Service {<br /> private static final int NOTIF_PLAYING = 1;<br /> private final PlayerNotification mNotification =<br /> PlayerNotification.getInstance();<br /><br /> ...<br /> <br /> public void setForegroundAndShowNotification(Notification n) {<br /> mNotification.showNotification(this, NOTIF_PLAYING, n);<br /> }<br /><br /> public void stopForegroundAndHideNotification() {<br /> mNotification.hideNotification(this, NOTIF_PLAYING);<br /> }<br />}<br /></code></pre><br /><br />Great, this sounds very simple and easy to follow. Let's return to the full implementation of PlayerNotification:<br /><br /><pre class="prettyprint java-html"><code><br /> private static class PreEclair extends PlayerNotification {<br /> private static class Holder {<br /> private static final PreEclair sInstance = new PreEclair();<br /> }<br /> private NotificationManager getNotificationManager(Context context) {<br /> return (NotificationManager)context.getSystemService(Context.NOTIFICATION_SERVICE);<br /> }<br /> public void showNotification(Service context, int id, Notification n) {<br /> context.setForeground(true);<br /> getNotificationManager(context).notify(id, n);<br /> }<br /> public void hideNotification(Service context, int id) {<br /> context.setForeground(false);<br /> getNotificationManager(context).cancel(id);<br /> }<br /> }<br /><br /> private static class EclairAndBeyond extends PlayerNotification {<br /> private static class Holder {<br /> private static final EclairAndBeyond sInstance = new EclairAndBeyond();<br /> }<br /> public void showNotification(Service context, int id, Notification n) {<br /> context.startForeground(id, n);<br /> }<br /> public void hideNotification(Service context, int id) {<br /> context.stopForeground(id);<br /> }<br /> }<br /></code></pre><br /><br />And that's it as far as code goes! Assuming that you have already updated your AndroidManifest.xml to include the appropriate <a href="http://developer.android.com/guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a> attributes, you're ready to start testing. Use the Android SDK tools to create AVDs for each of the major platform releases from your minimum supported version to your current target and deploy your app on each to make sure you have not made any mistakes.<br /><br />For further reading about how Java guarantees this approach, read about the <a href="http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom">initialization on demand holder idiom</a>. This is what allows us to prevent the wrong implementing class from initializing in the VM (and thus causing verification errors).<br /><br />You can find two working examples of this pattern in my <a href="http://five.googlecode.com">Five</a> app: <a href="http://github.com/jasta/five-android/blob/master/src/org/devtcg/five/provider/util/AcquireProvider.java">one using reflection</a> and <a href="http://github.com/jasta/five-android/blob/master/src/org/devtcg/five/service/PlayerNotification.java">one matching the explained example</a>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com4tag:blogger.com,1999:blog-9106822915308030165.post-37322907668897027772009-03-17T20:40:00.000-07:002009-07-24T12:36:38.186-07:00Building, running, and debugging Android sourceThere is a lot of confusion surrounding the work flow in the Android source tree, so allow me to simplify:<br /><ol><li>Follow the initial instructions for downloading the source at:<br /><br /><a href="http://source.android.com/download">http://source.android.com/download</a><br /><br /></li><li>Set up your environment to build the engineering build for the generic device and generic product. This is similar to the SDK, but with a few pieces missing.<br /><code><br />$ source build/envsetup.sh<br />$ lunch 1<br /><br /></code></li><li>To build for the first time:<code><br /><br />$ make<br /></code><br />If you have a multi-core system, you can build with <code>make -jN</code> where N is twice the number of cores on your machine. This should speed up the first build considerably.<br /><br /></li><li>To launch the emulator from your build<span style="font-family:monospace;">:</span><code><br /><br />$ ./out/host/<your-machine-type>/bin/emulator<br /></code><br />On my system <code><your-machine-type></code> is <code>linux-x86</code>.<br /><br /><span style="font-weight: bold;">NOTE:</span> The emulator knows where to find system and data images as a result of running <code>lunch 1</code> above. This sets the environment variable <code>ANDROID_PRODUCT_OUT</code> to point to the target directory. For this example, it should be <code>out/target/product/generic/</code>.<br /><br /></li><li>If you wish to make changes to the source code, there are handy utilities that have been exposed to your environment by <code>source build/envsetup.sh</code> above. For example, if you modify the Email app and just want to rebuild it:<br /><br /><code>$ mmm packages/apps/Email</code><br /><br /></li><li>To see your changes in the emulator you can run:<br /><br /><code>$ adb remount<br />$ adb sync</code><br /><br />Which will copy the regenerated <code>Email.apk</code> file into the emulator's <code>/system/app</code> folder, triggering the <code>PackageManager</code> to automatically reinstall it.<br /><br /></li><li>Or if you change framework resources in <code>frameworks/base/core/res/res/</code> you could regenerate <code>framework-res.apk</code> with:<br /><br /><code>$ mmm frameworks/base/core/res</code><br /><br />Or if you modified even the framework itself you could run:<br /><br /><code>$ mmm frameworks/base</code><br /><br />To sync these changes you must restart the running framework and sync, as with this handy sequence:<br /><br /><code>$ adb remount<br />$ adb shell stop<br />$ adb sync<br />$ adb shell start<br /><br /></code></li><li>Finally, to debug your changes you can use the DDMS tool to select a process for debug and then attach Eclipse to it. If you have the Eclipse Android Development plugin installed, there is a special DDMS perspective which you can use to choose the process for debug. To attach Eclipse to it, see these instructions:<br /><br /><a href="http://source.android.com/using-eclipse">http://source.android.com/using-eclipse</a><br /><br />This document also describes how to use Eclipse for development. Any IDE should work with the proper finagling though. Just note that the IDE won't really be an integrated environment: the final output of APKs, <code>system.img</code>, and even the generation of <code>R.java</code> files will have to be done by <code>make</code>!<br /><br />A note about the processes in Android:<br /><br /><ul><li><code>system_process</code> houses all things under <code>frameworks/base/services</code>. This includes the PackageManagerService, StatusBarService, etc. It has many, many threads (one for each service, and then one main UI thread), so be wary when debugging.</li><li><code>com.android.acore</code> hosts Launcher (home), Contacts, etc. You can determine the apps/providers that run here by looking for <code>android:process="android.process.acore"</code> in the various <code>AndroidManifest.xml</code> files in packages/.<br /></li></ul><br />Also remember that the "framework" (under <code>frameworks/base/core/java</code>) is not hosted by any one process. It is a library used by most processes, so to debug code there you can usually use a simple demo app that takes advantage of whatever you changed and debug that app's process. A useful trick for setting up your debug connection is to call <code>Debug.waitForDebugger()</code> during some startup part of an application or system service.<br /></li></ol><br /><strong>UPDATE 2009-07-24: </strong>The original <code>ONE_SHOT_MAKEFILE</code> line I gave for rebuilding the framework has been deprecated. <code>mmm frameworks/base</code> is now the recommended way to rebuild the framework code.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com21tag:blogger.com,1999:blog-9106822915308030165.post-11725528689950464562009-01-07T18:00:00.000-08:002009-03-17T16:03:36.198-07:00Push services: Implementing persistent mobile TCP connectionsAs a result of my work on IMAP IDLE support in Android's default mail application, I have been experimenting with various strategies for implementing long-lived services and persistent connections that operate efficiently in a variety of circumstances. Several quirks about Android and mobile devices in general arose that could be of value to anyone implementing similar services.<br /><br />For most protocols, you will need to implement some type of client-initiated keep alive at the application layer. For my purposes with IMAP I simply complied with the RFC and elected to leave IDLE mode then re-enter after 28 minutes of inactivity. On Android, you must use the <a href="http://code.google.com/android/reference/android/app/AlarmManager.html">AlarmManager</a> service to wake the CPU for this task. You might be tempted to use a <a href="http://code.google.com/android/reference/android/os/Handler.html">Handler</a> for timing or even a simple thread with a looped sleep() however it should be noted that unless your application otherwise holds a <a href="http://code.google.com/android/reference/android/os/PowerManager.WakeLock.html">WakeLock</a> you cannot rely on any timing mechanism other than the <a href="http://code.google.com/android/reference/android/app/AlarmManager.html">AlarmManager</a>. Once the screen goes blank, the CPU may sleep and once it does other timing mechanisms will block until the CPU wakes up again, regardless of any timeout paramters you supply.<br /><br />After running my test for several days I noticed Android was mysteriously killing processes, claiming that the services implemented in them have "died", then restarting them just a few minutes later. No call to the service's <a href="http://code.google.com/android/reference/android/app/Service.html#onDestroy%28%29">onDestroy</a> method will occur, and even on service restart you will only see a call to <a href="http://code.google.com/android/reference/android/app/Service.html#onCreate%28%29">onCreate</a> and not <a href="http://code.google.com/android/reference/android/app/Service.html#onStart%28android.content.Intent,%20int%29">onStart</a>. In order to compensate for this you are expected to store your state persistently and check for a discrepency during onCreate and then invoke <a href="http://code.google.com/android/reference/android/content/Context.html#startService%28android.content.Intent%29">startService</a> for yourself if necessary. The <a href="http://code.google.com/android/reference/android/content/SharedPreferences.html">SharedPreferences</a> system can be handy for this.<br /><br />Source code for a functional demonstration on this topic can be found at my <a href="http://android-random.googlecode.com/">android-random project</a> page, under the module <a href="http://code.google.com/p/android-random/source/browse/#svn/trunk/TestKeepAlive">TestKeepAlive</a>.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com15tag:blogger.com,1999:blog-9106822915308030165.post-90313811404381494722008-10-23T21:12:00.000-07:002008-10-23T21:24:54.084-07:00Working on IMAP IDLE support for Android's Email appFor all those screaming about the lack of push e-mail updates for regular IMAP accounts with the basic Email app in Android, I have been digging into the code for the past few days and am preparing a patch for IMAP IDLE support. For those that do not know, IMAP IDLE allows a client to maintain a persistent, light connection to the server that is then notified of new messages as they arrive. Many IMAP servers support this extension, including Microsoft Exchange which would thus allow push e-mail for those that need corporate e-mail options on the G1.<br /><br />I will post an APK for folks to try once I have the support working well. Stay tuned...Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com9tag:blogger.com,1999:blog-9106822915308030165.post-51088143803452264682008-08-27T12:24:00.000-07:002008-08-27T12:36:11.297-07:00Generate Callback Listener Helpers from AIDLAs I redesign <a href="http://five.googlecode.com/">Five</a> I find myself tweaking/expanding the callback listeners in my interface which are handled through the RemoteCallbackList class in the service implementation. This class is great, however for each call code must be written similar to:<br /><pre class="prettyprint java-html"><code><br />int N = mCallbacks.beginBroadcast();<br /><br />for (int i = 0; i < N; i++) {<br /> try {<br /> mCallbacks.getBroadcastItem(i).onSomeEvent();<br /> } catch (RemoteException e) {}<br />}<br /><br />mCallbacks.finishBroadcast();<br /></code></pre><br />This can quickly pollute the service implementation, and even if you factor these calls out to a separate class it can be a pain to create and maintain them. So, I came up with a solution in the form of a Perl script which takes as input an AIDL file defining the callback interface and outputs a class implementing the extended RemoteCallbackList. To use, simply type:<br /><code><br />$ ./aidl-cbliststub.pl < IFooListener.aidl > IFooListenerCallbackList.java<br /></code><br /><span style="font-weight: bold;">Download: </span><a href="http://android-random.googlecode.com/svn/trunk/aidl-cblistsub/aidl-cbliststub.pl">aidl-cblistsub.pl</a>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com1tag:blogger.com,1999:blog-9106822915308030165.post-3973620071858131552008-08-25T06:57:00.000-07:002008-08-25T06:57:14.946-07:00Android Instrumentation ExampleAs Android approaches maturity with its recent <code>0.9r1</code> release, I began to think its time that my main project updates to match. I decided to take another look at Android's instrumentation and unit testing features to build robust tests for my critical services and activities. Unfortunately, there isn't anything new in the way of documentation however there is now is an example we can use in ApiDemos.<br /><br />Looking at the new ApiDemos we see that there is a new <code>tests</code> directory which contains a second <code>AndroidManifest.xml</code> with no user activities defined. This is important as this structure allows us to have two separate APKs, one for production and one for testing, so our main distribution and build doesn't need to be polluted. Unfortunately, this approach is not compatible with the Eclipse plugin, and so we must define everything in an external build environment.<br /><br />For convenience, I packaged the complete ApiDemos project with my Ant build environment here: <a href="http://android-random.googlecode.com/files/ApiDemos-instrumentation-build.tar.gz">ApiDemos-instrumentation-build.tar.gz</a>. To build, start the emulator and run the following commands:<br /><code><br />$ adb shell rm /data/app/ApiDemos.apk<br />$ ant install<br />$ cd tests && ant install<br /></code><br />It is essential above that you remove the old ApiDemos.apk as the instrumentation APK must be signed with the same key as the package it tests.<br /><br />Once we've got both APKs installed we can begin running our unit tests. There is no UI in Android for this, however it can be invoked more conveniently through adb as such:<br /><code><br />$ adb shell am instrument -w com.android.samples.tests/android.test.InstrumentationTestRunner<br /></code><br />This will run all defined tests and print a dot character for each successful test, F for failure, or E for invocation error. See the javadoc in <code>tests/src/com/android/samples/AllTests.java</code> for more sample command lines to run individual test cases or specific tests within them.<br /><br />My main project, <a href="http://five.googlecode.com">Five</a>, has recently been updated to include unit tests in the five-client component, with more test coverage to follow in the next few weeks. For a non-trivial test case, see my <a href="http://code.google.com/p/five/source/browse/trunk/five-client/tests/src/org/devtcg/five/service/CacheServiceTest.java">CacheServiceTest</a>.<br /><br /><span style="font-weight: bold;">NOTE: </span>Previously, I was using the <a href="http://masa.googlecode.com">masa Android plugin</a> for Maven, however it has not yet been updated to support <code>0.9r1</code>. I feel that using Maven for this would have been cleaner, but the Ant approach is sufficient for this simple demonstration. Once updated, I will return here and finish this example with a more sophisticated build environment to automate testing.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com5tag:blogger.com,1999:blog-9106822915308030165.post-37146967146889149732008-08-07T00:27:00.000-07:002008-08-07T00:42:38.440-07:00Android on the HTC VogueAs many of you know, the Vogue can run Android quite nicely with support for sending/reciving SMS, incoming and outgoing calls, GPRS, touch screen, etc thanks to dzo over at Xda-Developers. See his posts and materials here: <a href="http://it029000.massey.ac.nz/vogue/">http://it029000.massey.ac.nz/vogue/</a>.<br /><br />Several folks from freenode/#android have access to this device, myself included, and have been developing tools and applications to further explore the platform on real hardware. Those tools are being hosted at the <a href="http://android-random.googlecode.com/">android-random project page</a>. There is a simple file manager (Glance), a much-improved threaded text messaging app (Messages), and perhaps most importantly of all a RemoteLogcat tool that allows us to observe the running devices logcat (normally accessible through <code>adb logcat</code>) by piping it to a server on the public Internet.<br /><br />Recently, I created an emulator skin that can be used to simulate this device's resolution during development. Simply download <a href="http://android-random.googlecode.com/files/vogue-skin.tar">vogue-skin.tar</a> and unpack it into <code>$ANDROID_SDK/tools/lib/images/skins</code> along with the other default skins. Then fire up the emulator as:<br /><code><br />$ emulator -skin vogue<br /></code><br />The skin has no decorations, just a simple 240x320px layout, but this should give you a pretty good idea how different Android can be on this device.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com1tag:blogger.com,1999:blog-9106822915308030165.post-21282896685709370472008-07-31T18:00:00.000-07:002008-07-31T21:59:01.635-07:00Interruptible I/O example using HttpClientRecently I found myself considering some of the gotchas of threaded, blocking I/O as I've been using it on Android. Specifically, how do we gracefully handle interruptions demanded by the user or the system to free resources? After some thought there seems to be three basic strategies with Java:<br /><ul><li>1. Use non-blocking I/O, which is generally clumsy and unintuitive for most Java engineers.<br /></li><li>2. Cancel blocking I/O threads by simply setting a stop flag and discarding the reference to the thread. The thread will clean itself up after an arbitrary length of time up to its transmit or connect timeout.</li><li>3. Close the socket owning the input stream on which the blocking thread is waiting.</li></ul>It seems that #2 is the most popular choice on Android however I would like to make a case for #3 as a cleaner method of tidying resources on user request. With this approach, we can be certain to quickly close any open files, relinquish database, object, or file locks, and allow the thread to clean up its resources quickly. As it turns out, using HttpClient makes this approach relatively painless, but there are a few gotchas in this pattern that we must watch out for.<br /><br />So, to get started we need to create our <code>StoppableDownloadThread</code> class which allows us to encapsulate our interrupt logic.<br /><pre class="prettyprint java-html">public class StoppableDownloadThread extends Thread<br />{<br /> private String mURL;<br /> <br /> private HttpGet mMethod = null;<br /> <br /> /* Volatile stop flag used to coordinate state between the two<br /> * threads involved in this example. */<br /> protected volatile boolean mStopped = false;<br /> <br /> /* Synchronizes access to mMethod to prevent an unlikely race<br /> * condition when stopDownload() is called before mMethod has<br /> been committed. */<br /> private Object lock = new Object();<br /> <br /> public StoppableDownloadThread(String url)<br /> {<br /> mURL = url;<br /> }<br />}<br /></pre>This simply outlines our basic strategy for stopping and synchronization. A simple volatile boolean flag and a monitor lock to share the HttpGet handle should do just fine. Now let's continue with the implementation of the run() method:<br /><pre class="prettyprint java-html">public void run()<br />{<br /> HttpClient cli = new DefaultHttpClient();<br /> HttpGet method;<br /> <br /> try {<br /> method = new HttpGet(mURL);<br /> } catch (URISyntaxException e) {<br /> e.printStackTrace();<br /> return;<br /> }<br /> <br /> /* It's important that we pause here to check if we've been stopped<br /> * already. Otherwise, we would happily progress, seemingly ignoring<br /> * the stop request. */<br /> if (mStopped == true)<br /> return;<br /> <br /> synchronized(lock) {<br /> mMethod = method;<br /> }<br /> <br /> HttpResponse resp = null;<br /> HttpEntity ent = null;<br /> InputStream in = null;<br /> <br /> try {<br /> resp = cli.execute(mMethod);<br /> <br /> if (mStopped == true)<br /> return;<br /> <br /> StatusLine status = resp.getStatusLine();<br /> <br /> if ((ent = resp.getEntity()) != null)<br /> {<br /> long len;<br /> if ((len = ent.getContentLength()) >= 0)<br /> mHandler.sendSetLength(len);<br /> <br /> in = ent.getContent();<br /> <br /> byte[] b = new byte[2048];<br /> int n;<br /> long bytes = 0;<br /> <br /> /* Note that for most applications, sending a handler message<br /> * after each read() would be unnecessary. Instead, a timed<br /> * approach should be utilized to send a message at most every<br /> * x seconds. */<br /> while ((n = in.read(b)) >= 0)<br /> {<br /> bytes += n;<br /> System.out.println("Read " + bytes + " bytes...");<br /> }<br /> }<br /> } catch (Exception e) {<br /> /* We expect a SocketException on cancellation. Any other type of<br /> * exception that occurs during cancellation is ignored regardless<br /> * as there would be no need to handle it. */<br /> if (mStopped == false)<br /> e.printStackTrace();<br /> } finally {<br /> if (in != null)<br /> try { in.close(); } catch (IOException e) {}<br /> <br /> synchronized(lock) {<br /> mMethod = null;<br /> }<br /> <br /> /* Close the socket (if it's still open) and cleanup. */<br /> cli.getConnectionManager().shutdown();<br /> }<br />}<br /></pre>This is a pretty standard example of an HTTP GET using HttpClient4, however do note that we have strategically placed checks against our stop flag to avoid leaving the download thread in an inconsistent state when it's being cancelled. We're not done yet though as we still need to implement the stop part of the interface so that our main thread (or any other thread) can abort the download thread:<br /><pre class="prettyprint java-html"><code>public void stopDownload()<br />{<br /></code> <code>if (mStopped == true)<br /></code> <code> return;<br /></code><br /><code> /* Flag to instruct the downloading thread to halt at the next<br /></code> <code> * opportunity. */<br /></code> <code>mStopped = true;<br /></code><br /> <code>/* Interrupt the blocking thread. This won't break out of a blocking<br /></code> <code> * I/O request, but will break out of a wait or sleep call. While in<br /></code> <code> * this case we know that no such condition is possible, it is always a<br /></code> <code> * good idea to include an interrupt to avoid assumptions about the<br /></code> <code> * thread in question. */<br /></code> <code>interrupt();<br /></code><br /> <code>/* A synchronized lock is necessary to avoid catching mMethod in<br /></code> <code> * an uncommitted state from the download thread. */<br /></code> <code>synchronized(lock) {<br /></code> <code> /* This closes the socket handling our blocking I/O, which will<br /></code> <code> * interrupt the request immediately. This is not the same as<br /></code> <code> * closing the InputStream yieled by HttpEntity#getContent, as the<br /></code> <code> * stream is synchronized in such a way that would starve our main<br /></code> <code> * thread. */<br /></code> <code> if (mMethod != null)<br /></code> <code> mMethod.abort();<br /></code> <code>}<br /></code><code>}<br /></code></pre>This completes our basic interface, but we still don't have a usable example here. There's no communication between our download thread back to the user in any meaningful way as would be required for an Android application. For that I have modified the above code slightly and introduced an Android layer in the form of a working demo. Source code for the full example: <a href="http://android-random.googlecode.com/files/CancelHttpGet.tar.gz">CancelHttpGet.tar.gz</a>.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com4tag:blogger.com,1999:blog-9106822915308030165.post-20095360284113903432008-05-30T10:22:00.000-07:002008-05-30T12:56:24.405-07:00Details on the next public SDKI had hoped to reserve judgment until after an official announcement from Google, however after speaking with Dan Morrill and Jason Chen at Google I/O, it seemed clear that the OHA, up the corporate chain, has not taken the development community seriously. I have confirmed that the ADC winners have now received an updated version of the SDK which they are bound by NDA to keep private. These projects are thus forced to be closed until the NDA restrictions are lifted, which include no source release, performance benchmarking, discussion of new features, screenshots, etc. These restrictions are expected to last until the next public SDK is dropped.<br /><br />So, when is the next public release? Surely after over 3 months since M5 and only a few major releases so far it should be close, perhaps landing after round 2 of the ADC is over? Not so. The SDK is not expected until either shortly before handset launch later this year, or perhaps on or after that date. We can rest assured that there will be significant changes in this release: modified and new APIs, new core SDK features (like Wi-Fi, bluetooth, etc), modified UI, and of course many important bug fixes. As a result, our applications will require substantial revision to work [well] on this new version, reducing the likelihood that losing ADC entries will be able to "compete" for visibility on the handsets as they launch. Not to mention, generally stressing the larger development community with excessive unnecessary work and "wandering" development with no clear indication of what's coming and when.<br /><br />I see this as a serious problem, running directly counter to the claims of openness and developer support, however Google and the OHA apparently do not feel that a commitment to openness is binding in the face of proprietary inconvenience.<br /><br />So, I feel there is no choice but to suspend my development on the current platform and await the launch of handsets. Hopefully I will be able to catch up quickly and still offer a stable and feature-rich application within the first few months of handset availability. That said, I will now be starting on the desktop client for my <a href="http://five.googlecode.com/">media streaming system</a>. If anyone is interested, my project is currently open source and I am actively interested in contributors, even if you want to work on the Android component using M5 *grin*.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-18520370598199693202008-04-15T08:31:00.000-07:002008-04-15T13:08:47.605-07:00My ADC Submission: Five, a media distribution technique<div id="inbdy">I have created a system by which your music can be accessed anytime on the go using your cell phone's wireless data connection. Simply install the server software onto your home PC and configure the phone to connect to it. Initially, the meta database will be downloaded and then from there only changes will be synced to the phone. The media itself is retrieved on demand and cached to the storage card. In my real-world tests with a remote server and simulating GPRS or EDGE data throughput has been very promising, requiring only 3 - 8 seconds of buffer time before most content can be played.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoLYlJDaQDNoeeQfetstH6c2VuMDNa1X84Yg1pl7kfg0r-Wg7WwQuEp8SqrBwkxQ6vFLNpDbCVf6bXcXMPsWZ9gvCEXpNerW1d9VQwNFq03nqt_-bXzvfBnQM6UQDKCi0x1lU4pJeWg_h4/s1600-h/buffering.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoLYlJDaQDNoeeQfetstH6c2VuMDNa1X84Yg1pl7kfg0r-Wg7WwQuEp8SqrBwkxQ6vFLNpDbCVf6bXcXMPsWZ9gvCEXpNerW1d9VQwNFq03nqt_-bXzvfBnQM6UQDKCi0x1lU4pJeWg_h4/s320/buffering.png" alt="" id="BLOGGER_PHOTO_ID_5189500436070088402" border="0" /></a><p>For more screenshots and info, see <a target="_blank" rel="nofollow" href="http://android-five.googlecode.com/">http://android-five.googlecode.com</a>. The system, though currently closed, will be opened under the terms of the GPL after the first round challenge winners are announced, regardless of outcome.<br /></p><p>I will also be posting a video this week, showing my system in action. Stay tuned. </p></div>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com3tag:blogger.com,1999:blog-9106822915308030165.post-37148307122002046592008-04-10T10:00:00.000-07:002008-04-10T10:06:59.607-07:00Obligatory Google I/O PostingSeems like <a href="http://code.google.com/events/io">Google I/O</a> is all the rage these days, so I decided I'd officially mention that I will be attending. I live in Seattle so airfare was cheap, plus I have <a href="http://www.loopt.com">friends</a> in the area who want to go too.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-48913993420786018032008-03-23T21:29:00.000-07:002008-03-24T16:29:11.410-07:00Advanced Tab Activity DemoI was inspired by the simple TabHost/TabWidget demonstration by <a href="http://www.jsharkey.org/blog/2008/02/14/android-tabhost-in-the-m5-sdk/">Jeffrey Sharkey</a>, and decided to expand upon it significantly. In my demo, I have replaced all the default drawables and layouts, created my own custom <a href="http://code.google.com/android/reference/android/graphics/ColorStateList.html">ColorStateList</a>, and even utilized TabActivity for greater isolation.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0U-oP29dic-jEIAkUbKyJsex8iEOUXTUY6gCqhfgTTj9U97gAlvXxV_-9vv0DABk91EfHHK311hyqVnFTeCgg8pTUQR2JpFZHsNHc8HUHts9JWOZk2tzTykyGWiNx93G6sf2ZOlHQncCl/s1600-h/TabActivityDemo.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0U-oP29dic-jEIAkUbKyJsex8iEOUXTUY6gCqhfgTTj9U97gAlvXxV_-9vv0DABk91EfHHK311hyqVnFTeCgg8pTUQR2JpFZHsNHc8HUHts9JWOZk2tzTykyGWiNx93G6sf2ZOlHQncCl/s320/TabActivityDemo.png" alt="" id="BLOGGER_PHOTO_ID_5181162380684860338" border="0" /></a><br /><span style="font-weight: bold;">Download:</span> <a href="http://android-random.googlecode.com/files/TabActivityDemo.tar.gz">TabActivityDemo.tar.gz</a><br /><br />The code and images for this demo are in the public domain, so please feel free to use and modify as you wish.<br /><br /><span style="font-weight: bold;">NOTE:</span> TabActivity is currently marked as deprecated, but according to <a href="http://groups.google.com/group/android-developers/browse_thread/thread/61976a6a2d86673d">this post</a>, I believe that may be in error.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com13tag:blogger.com,1999:blog-9106822915308030165.post-38365368294236124862008-03-05T15:54:00.000-08:002012-08-22T18:10:05.699-07:00Tool to read Android binary XML filesI have successfully reverse engineered a good portion of the Android binary XML file format that is found inside of Android package files (.apk). With this tool, you can explore the XML layout, drawable, and animation files used in the applications distributed with the SDK (phone, browser, contacts, etc). My primary motivation for doing this was to simply observe some of the common practices and get a sense for what Google is doing internally that isn't necessarily available through their API demos and samples. Below you can find two links to download either the stand-alone convertor or the collected output as run over every APK file found in the phone's /system directory:<br />
<br />
<strong>Download:</strong> <a href="http://android-random.googlecode.com/files/axml2xml.pl">axml2xml.pl</a><br />
<strong>Download:</strong> <a href="http://android-random.googlecode.com/files/android-xmldump.tar.gz">android-xmldump.tar.gz</a><br />
<br />
Please note that this tool was a very quick hack and some of the XML files I found failed to parse. Not many, and the only ones I found were raw XML documents (not Android resources) so I didn't bother to explore any further incompatibilities. If you find any resources that fail to parse or have any insight into the format, feel free to leave a comment and I will investigate when I have time.<br />
<br />
<b>EDIT 2012-08-22:</b> Android's come a long way since this post. It's now possible to use the aapt tool to read the contents of XML documents (and a whole lot more) of APK files. For example:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">android dump xmltree foo.apk AndroidManifest.xml</span>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com15tag:blogger.com,1999:blog-9106822915308030165.post-45221021249417891612008-03-02T20:20:00.000-08:002012-08-22T17:43:40.123-07:00Custom Android list widget to access large sorted lists on touch devicesI have developed a custom Android widget for <code>m5-rc14</code> that automatically (and efficiently) sections a sorted list by alphabet letters and offers a side-bar widget for quickly jumping to each section. This widget could be very useful for any project offering an extremely large list to the user, such as a music player showing artists or albums.<br />
<br />
Some things left out with this widget are a smooth scroll to the selected position as well as a finer control for sections that have large item counts themselves. More to come later :)<br />
<br />
Here's a screenshot using dummy data:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkt_ljcMjtFtPiN6f7VCtx974wV-T8b7PlvJBMMKy8548K-CmrnWY_oh0occ0AXnbMNuhJyzh8VxSMErb089Rs6FFR95fRg1wA66UXQFouNps42mus8n_rC1Npoaact0bRBrerFF7MvCg9/s1600-h/alphabet-list-test.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5173367622603267410" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkt_ljcMjtFtPiN6f7VCtx974wV-T8b7PlvJBMMKy8548K-CmrnWY_oh0occ0AXnbMNuhJyzh8VxSMErb089Rs6FFR95fRg1wA66UXQFouNps42mus8n_rC1Npoaact0bRBrerFF7MvCg9/s320/alphabet-list-test.png" style="cursor: pointer; display: block; margin: 0px auto 10px; text-align: center;" /></a><br />
<br />
<span style="font-weight: bold;">Download:</span> <a href="http://android-random.googlecode.com/files/AlphabetListView.tar.gz">AlphabetListView.tar.gz</a><br />
<br />
Licensed under the GPLv2.<br />
<br />
<b>EDIT 2012-08-22: </b>This approach represents very old design patterns for Android and has been broadly replaced by upstream components such as the <a href="http://developer.android.com/intl/zh-TW/reference/android/widget/AbsListView.html#setFastScrollEnabled(boolean)" target="">fast scroll mode</a> of ListView.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com5tag:blogger.com,1999:blog-9106822915308030165.post-42268237348541097912008-02-10T21:41:00.000-08:002008-02-21T02:09:26.474-08:00Android Eclipse Plugin / AIDL bugs<span style="font-weight: bold;">UPDATE: </span>This work-around is no longer necessary since <code>m5-rc14</code> fixed the aidl bugs.<br /><br />The current Android SDK (<code>m3-rc37a</code>) has numerous bugs surrounding the aidl parser, the most annoying of which makes it very difficult to work with a project utilizing aidl imports and the Eclipse Android plugin. In order to ease some frustrations, I have created a wrapper around the aidl tool which tries to guess certain usage parameters and automatically inject the necessary <code>-I</code> switch.<br /><br />To use the script, enter your Android SDK tools directory and issue the following:<br /><br /><code>mv aidl aidl.google</code><br /><code></code><br />Then save the following script as <code>aidl</code>:<br /><br /><code>#!/usr/bin/perl<br /><br />my @aidl = split /[\/\\]/, [ grep { /\.aidl$/ } @ARGV ]->[-1];<br /><br />foreach (reverse @aidl)<br />{<br />last if $_ eq 'src';<br />undef $_;<br />}<br /><br />my $I = join('/', map { $_ if $_ } @aidl);<br /><br />my @args;<br /><br />push @args, "-I$I" if $I;<br />push @args, @ARGV;<br /><br />system("$0.google", @args);<br /><br /></code>And finally, set the script executable:<br /><br /><code></code><code>chmod +x aidl</code>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-37326786048245743772008-01-09T00:50:00.000-08:002008-02-29T23:17:41.925-08:00Asynchronous Service ExampleMany folks have been asking about asynchronous services (using the Binder) in Android and I decided to whip up a quick example showing how this is intended to work with the current SDK (m3-rc37a). There are rumors from Google that they will be improving things soon and providing a better example, but in the mean time this example should clear up a lot of the confusion:<br /><br /><a href="http://android-random.googlecode.com/files/AsyncService.tar.gz">AsyncService.tar.gz</a><br /><br /><span style="font-weight: bold;">UPDATE:</span> The project must be built using ant (not Eclipse) because of an SDK bug regarding the invocation of the aidl tool. There are also reports that even ant won't work on Windows due to yet more bugs in aidl. The code does work as Google intended, though, and in the next SDK release they are committed to having these issues resolved.<br /><br /><span style="font-weight: bold;">UPDATE2:</span> Google released m5-rc14 and, as promised, the bugs are fixed and their included RemoteService example has been updated to show similar functionality.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-38964937115831686912007-12-28T20:37:00.000-08:002007-12-28T21:43:32.165-08:00Android VNC, Part DeuxI decided to create <a href="http://android-vnc.googlecode.com">my own VNC implementation</a> and have posted code and binaries over at Google Code. There, you'll find instructions for installing and using the VNC server with a Windows Mobile device using <a href="http://dotnetvnc.sourceforge.net/">.NET VNC Viewer</a>. Here's a low-quality photo I snapped to get you interested:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtY-t0cVsWDlkt6Bm9HUQigJFRTbpe_glbKwhHElLuTIjLRUdTAF0INjqhXV2_GZAt9Z9pFMuIwdXlQaqyvbmfVSVT7L4ccvE98WlLk2poVCHdw8lzH9RG2AAUuj0kYRUSqiSL1y-ckV5Q/s1600-h/CIMG0359.JPG.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtY-t0cVsWDlkt6Bm9HUQigJFRTbpe_glbKwhHElLuTIjLRUdTAF0INjqhXV2_GZAt9Z9pFMuIwdXlQaqyvbmfVSVT7L4ccvE98WlLk2poVCHdw8lzH9RG2AAUuj0kYRUSqiSL1y-ckV5Q/s200/CIMG0359.JPG.jpg" alt="" id="BLOGGER_PHOTO_ID_5149265151501914674" border="0" /></a><br />The application running is my <a href="http://android-rss.googlecode.com/">Android RSS reader</a>, also hosted by Google Code.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com3tag:blogger.com,1999:blog-9106822915308030165.post-38477882084635882332007-12-23T15:19:00.000-08:002008-01-08T10:53:16.657-08:00Android RFB / VNC implementationLooks like the Android team has created a functional VNC server implementation natively in their surfaceflinger library (/system/lib/libsurfaceflinger.so). After some further exploration, it is possible to actually connect to and use this VNC server, although there are very strict requirements of the client.<br /><br />First off, you will need to proxy the connection as it only permits connections on the local interface. For this, I have simply <a href="http://benno.id.au/blog/2007/11/13/android-native-apps">cross-compiled</a> a <a href="http://www.life-gone-hazy.com/src/simple-tcp-proxy/">simple TCP proxy</a> and invoked it on the emulator:<br /><br /><code>arm-none-linux-gnueabi-gcc -static -o proxy simple-tcp-proxy.c<br />adb push proxy /data/proxy<br />adb shell /data/proxy 0.0.0.0 5901 127.0.0.1 5900</code><br /><br />Then you must redirect port 5901 on the local machine using the Android telnet interface:<br /><br /><code>$ telnet localhost 5554<br />Trying 127.0.0.1...<br />Connected to localhost.localdomain.<br />Escape character is '^]'.<br />Android Console: type 'help' for a list of commands<br />OK<br />redir add tcp:5900:5901<br />OK</code><br /><br />Now you can connect from your local workstation:<br /><br /><code>xvncviewer -noauto localhost</code><br /><br /><span style="font-weight: bold;">Note: </span>the VNC connection will fail if the client suggests any unsupported pixel format (bit depth, endianness(?), etc). So make sure you use -noauto to disable the initial 8bpp performance test and also use a 16bpp native display on your workstation. If your client requests 24 or 32bpp, the server will reject and hang indefinitely. See <code>adb logcat</code> to determine if you have triggered this behaviour.<br /><br />A few comments on this implementation:<br /><ul><li>You may only specify 16bpp pixel format, with the true colour flag on and a 565 bit pattern. This creates problems trying to use it from mobile devices with tools like <a href="http://dotnetvnc.sourceforge.net/">.NET VNC Viewer</a> which default specifies a 655 bit pattern when you force a 16bpp encoding. I wrote a very simple proxy that understands the RFB protocol and "fixes" some of this brokenness, but the experience is still less than desirable.</li></ul><ul><li>Only the raw encoding is supported, with no incremental updates. This causes atrocious performance problems on the client, making it impractical to use an existing mobile device to interact with the Android RFB server. I tried, it's bad. I think the only real option to proceed would be to extend my proxy to have a deeper understanding of the full RFB protocol, interpretting and re-encoding the data sent from the native Android RFB server. This seems like excessive work, and ultimately is work that should go into the native server. Perhaps I will still do it, though, just to prove it's possible.</li></ul>For reference and further reading, see my <a href="http://groups.google.com/group/android-developers/browse_thread/thread/b4fc2a71fa377baf/792d6afcee458b5a?lnk=gst&q=rfb#792d6afcee458b5a">android-developers post</a> on the subject.<br /><br /><span style="font-weight: bold;">UPDATE: </span>I have created <a href="http://devtcg.blogspot.com/2007/12/android-vnc-part-deux.html">my own VNC server</a> implementation on Android to work around these problems.Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-79267047325295093732007-12-01T19:53:00.000-08:002007-12-01T20:03:14.523-08:00Open to the public<span style="font-family:arial;">I've created a Google Code project at <a href="http://android-rss.googlecode.com/">http://android-rss.googlecode.com</a> to host the new Subversion repository for my RSS reader. I will be "releasing" version 0.1 in the near future with a better build environment (ant supported with meaningful dist targets) and a few default feeds preconfigured for easier testing. In the mean time, head on over to the <a href="http://android-rss.googlecode.com/">android-rss</a> project to access the code through SVN. Again, for now you must use Eclipse w/ the Android plugin installed or you will not be able to build the source.<br /></span>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com0tag:blogger.com,1999:blog-9106822915308030165.post-32063638234531293872007-11-20T15:48:00.000-08:002007-12-01T19:52:10.710-08:00Android RSS Reader<span style="font-family:arial;">I started an Android RSS reader project to help learn the new Google Android APIs in preparation for the Android Developer Challenge. The irony as I tested overwhelmed me:</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkMGmqYGxmClDAbEpdhOZ8yAlAG8VJIGXvbO33piJrz2X5EE_-j4xv5rXGLskyQhnUNp340eDMBoL9O6luITdHMuAQhoY4P5IFQNG6OpzDIHpGvv0Xp96PmLboNi1SZAsBolcXgDutqCQf/s1600-r/rss2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitcZkZT0EURaw5H68Be7PTCBV5GEU3nRQPL3TO4dgi3wPqMDQhV0Z386eB0ahUIjag2Fc0LRjMVgu8CI9Z887-PD3SbidN2TaHHmXL2uifJGd_rVwFtQltQHFJmmX7TwwEEMgYxrX7NkUK/s320/rss2.png" alt="" id="BLOGGER_PHOTO_ID_5139218334671087378" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvdd9-Fdtejc3RW48sE4Qb45266xgqRlz4aOIqtot2veijQMWYLBcczgz4FuXNY0sCPL3QHzwwQH9iW0wMxNJgiXmcZB6_xZDK7quEVBa8wZuJVVtfw592vOFnqU6j1UfG74ASmZ2wX70v/s1600-h/android-rss.jpg"><br /></a>Anonymoushttp://www.blogger.com/profile/02055635184861046754noreply@blogger.com2