I came across lots of problems when the glass updated to XE12, long ago. Today I found out this article which I thought I would like to share with you all.
My Glass was automatically updated with the monthly update XE12. This update included a new version of GDK implementation, known as Sneak Peek Rev. 2.
Since the update, I could not run any of my GDK sample apps. I was getting errors like: java.lang.NoSuchMethodError: com.google.android.glass.timeline.TimelineManager.getLiveCard.
As it turned out, this new GDK revision included some non-backward compatible API changes. Clearly, names like “Sneak Peak” or “Preview” edition imply they are not stable releases, and APIs can change any time. But, I was caught a bit off-guard, and a bit disappointed since it happened “without warnings”. (Or, maybe there was a pre-announcement, and I may have missed it because I’m off-line most of the time these days.) I mentioned the importance of “backward compatibility” in software engineering a few times before. Even more importantly, I believe that software engineers should strive for “forward compatibility”. This is a difficult goal to attain because, in many cases, developers do not know what product features they will need to support in the future. In most organizations, they come down from “PM’s” or people from “higher up”. Nonetheless, I think it is possible, and it is worth pursuing.
Anyways, I went through all my sample apps on GDK Demo and updated the code based on the new API. I’ll include the list of API changes here. This is only a partial list since the GDK Demo apps use only a subset of the GDK APIs.
First, you’ll need to update your GDK using Android SDK Manager. Since the original GDK release about a month ago, there seems to have been no other Android updates. When I opened the SDK Manager last night, it found only one update, GDK rev. 2. You can copy the updated gdk.jar file into your project dir and include it in your build path, or you can just set your
compileSdkVersion to a GDK-specific string. I personally prefer the first approach because there are some benefits of using a higher version for
compileSdkVersion than that of
targetSdkVersion (which should be 15 at this point). If you plan to do any “cross-platform” development (e.g., your app targeting both Android phones and Google Glass), then you probably have no choice but to use the Jar file.
So, here’s the list of API changes in GDK (as relevant to the currently “released” GDK Demo apps).
TimelineManager: Method name change from
createLiveCard(cardTag). (I’m only presuming that these are the same method, and the API change entails only the name change.)
LiveCard: It appears that the method
setNonSilent(boolean)has been removed. Instead, this “nonsllent” flag is set during publishing. The signature of the method
setNonSilent(true)has been changed to
publish(LiveCard.PublishMode.REVEAL). If you used
setNonSilent(false)for your livecard, then you now need to call
LiveCard.enableDirectRendering(boolean)has been changed to
com.google.android.glass.media.Camerahas been, it appears, renamed to
- The surface rendering callback interface,
LiveCardCallbackseems to have been renamed as
DirectRenderingCallback. My existing code just compiled fine (haven’t tried running them all though) after only changing the interface name.
That’s about it. Again, this is only a partial list of API changes in the new “Revision 2” version of GDK (as relevant to the “GDK Demo” sample Glassware). I haven’t done any comprehensive comparison of old vs. new GDK jar files or anything like that (which is probably easy to do). Google might have posted some kind of “release note” or “change log” at this point (which I haven’t seen yet though).
Meanwhile, I hope other GDK developers find my list useful, for now.
PS 1: BTW, interface name changes like
DirectRenderingCallback possibly imply that there might be something coming in the future that are in some way equivalent/similar to
DeadCard? :)). This is known as “breaking backward compatibility for forward compatibility”. We developers do this all the time, whether we realize it or not. We create, say, a class for certain purpose (with a certain name), and later realize that we have chosen too specific a name because the class can be more broadly applicable than initially planned.
Link to the GDK Release note – The GDK release note page.