Mangling data with sqlite on Android

Oof! I still haven’t recovered from the holidays.

I nearly have LogMyLife in a presentable state, but I just have this one last nit to pick: numbers don’t seem to get recorded the way I expect. I’m using a numerical column (with the intention of using the DB to manipulate numerical values later) but they weren’t storing with the precision I expected.

To explore this, I created a demo project on github. It’s a simple Android app that lets you try out storing values in different ways. It’s interesting for exploring edge cases. I’d like to say more about this but it’s late… maybe later. One answer I was looking for: when you store the value 1.23456789 into a numeric column, if you retrieve it as a String, you get 1.23457; as a Float, 1.2345679; if you retrieve it as a Double you get the full precision. When retrieved as a String it’s getting truncated with only six digits of precision – why?


Android packaging and publishing

I’m giving a lightning talk on LogMyLife and other Android-y stuff this Friday at SplatSpace. I thought it’d be nice to allow people to download the app and try it out if they so desire, even though it’s still pre-release at this point. So I looked around on github and found where I could create downloads (in addition to the source download that’s automatic).

On a different machine from what I usually develop on, I created a new LogMyLife package. Actually, it wasn’t quite that simple, because I discovered my SDK debug keystore cert had expired. Which wasn’t quite that simple either, as I had to track down the error message (which I forget at this point). But, congrats me, I’ve been at this for a year now! Or not congrats so much, as I still don’t have a complete app on the market to show for it. But I have my excuses.

Anyway, I deleted the existing keystore and the Eclipse ADT plugin kindly made another one behind the scenes, and I carried on. I uploaded the package and got an error, but it seemed to have succeeded. The cool thing was when I found github automatically pulls a QRcode from a Google service for the uploaded APK:

So I can just include that in my slide and people can use their Android device’s barcode reader to scan it and download if they so desire. So can you while you’re looking at this.

Of course I tried this, and I tried it on my phone, where I already had LogMyLife installed. It downloaded and nicely showed me the permissions it needed and notified me it would replace the current app. Then it proceeded to fail to install. There wasn’t really an informative message, but I think I know what happened.

That key I was talking about earlier? Well, it was of course different on my two dev machines. I’m pretty sure the phone refused to install the app because the key had changed from what was previously installed. I would have to un-install the app in order to install the version signed with a different key. Which leads me to wonder whether I’ll have the same problem once I sign it with my official market signing key for release? I don’t want to lose what data I already have been collecting on my phone, so if that’s the way it will be, I’m gonna be prioritizing the “Export/import data” feature way up.

I went ahead and signed up for an Android Market account finally. I’ll probably post something for beginners about the process on my neglected “Android from scratch” blog at some point. It’s pretty simple, but you don’t know what your $25 gets you to start with. Strangely enough, there doesn’t seem to be anything about signing your app on the market site. There is on the dev site, of course. It seems somewhat complicated to do by hand, but pretty simple from the Eclipse plugin. Nothing seems to mention what happens when you change keys – what the practical consequences of doing that would be. I’ll find out soon enough. Just for fun I tried uploading my dev LogMyLife.apk, and received only the error message “Upload a valid APK.” I guess if you don’t know about this stuff they’re not gonna help you find it!