Category: android

Canvas game tweaks

A few weeks ago I threw together a quick demo HTML canvas game ‘FlatRoller’; I’ve updated it this weekend to add a few things:

  • touch controls now work on IE 10 in Windows 8 Developer Preview on a multitouch device. Microsoft is adding yet another touch event model alongside the classic mouse & iOS-style touch events. Urgh!
  • full window is now used for the canvas; the directions and touch controls overlay it
  • visual feedback on the touch controls
  • the directions switch from showing ‘left/right’ to showing ‘jump’ as appropriate when another touch would trigger jump

It’s a little sluggish on my first-gen iPad, but runs very nice in Metro IE 10 on my Dell Inspiron Duo tablet/notebook convertible. Yay!

20111120-144301.jpg

I’ve also tried it out on my Android phone (Nexus One) and tablet (Kindle Fire), both running Android 2.3. Unfortunately both run pretty slow in both the stock browsers and Firefox, and only appear to pick up a single finger’s worth of touch events so the jump control doesn’t work.

Find source on github or play the game in browser.

 

Android USB debugging and screenshots on Amazon Kindle Fire

Got your shiny new Amazon Kindle Fire tablet in the mail today? Desperate to check out rendering & app compatibility issues but taking “screen shots” with your cameraphone is getting old?

  1. Enable third-party app installation in settings
  2. Tweak your ~/.android/adb_usb.ini to include an entry for Labs 126’s USB ID (0x1949)
  3. If necessary (eg on Linux) tweak permissions for the device again using the hex ID 1949
  4. adb kill-server

Plug the Kindle Fire in to your computer with any micro-USB cable, and ‘adb’ and ‘ddms’ etc will work. Yay!

Note that screenshots taken from ddms appear to come out in landscape orientation, regardless of the actual orientation of the device.

Already noticed some layout issues with some of Wikimedia’s fundraising banners in the browser. :)

Weekly whinge: offline feed reader for Android?

Google Reader for android is great… if you’re always online. If you have a subway commute, fly a lot, or otherwise like to catch up on your blogoverse when the rest of the world isn’t talking to your phone, you’ll quickly discover that the app’s offline sync feature is poor enough to be more frustrating than not having it at all.

They seem to have done a lot of things right; starring or marking things read works just fine while offline and queues the server updates transparently for later.  And when an article is available offline it fetches it cleanly and quickly.

There are basically three problems:

First, there’s no way to tell what feeds will actually be pre-downloaded. It claims to fetch your “most read feeds” but it gives no indication which those are. After several weeks of use I’m still getting confused by what is or isn’t being fetched.

The second problem is that the list displays do not distinguish between new feed entries *that have been reported to exist by the server* and those that have already been downloaded. You can see a clear count of entries and be faced with a “no network; retry” screen. Worse, if the connection is intermittent it’ll try to connect for a few seconds before telling you there’s nothing to see.

And to add insult to injury, images are not prefetched, consigning subway warriors to a pure-text life devoid of photos, screenshots, charts, icons, diagrams, maps, etc.

I could probably whip something up that does what I want, but polishing it won’t be trivial and I’m sure there are other tools out there that would suit my needs; anybody know a good offline-friendly feed reader of Android, preferably with Google Reader sync or import?

Apple’s pricing still winning the tablet war, mostly

Apple’s long had a reputation for high prices, and certainly there have been times and product lines where that’s very true. But there are a lot of places where Apple’s prices are actually quite competitive, especially where they have a huge lead in market share.

Everybody and their brother have been gearing up for the last year to launch their “iPad-killers”; so far Apple’s iPad is pretty much the only tablet-factor computer to ever sell well in the mass market (despite — or perhaps in part because of — the iOS platform’s many odd limitations). The only one to actually reach market yet with a tablet-optimized operating system is Motorola’s Xoom which recently launched running Android 3.0 “Honeycomb”; tech specs of this and another upcoming tablets are pretty similar to Apple’s just-announced iPad 2, available March 11 at the same pricing as last year’s models.

There’s been much hoopla about price, with no high-end competitor yet coming close to Apple’s entry-level pricing. The lowest-end iPad rocks in at $499, just under the $500 “wow that’s closer to $1000 than to free!” price point.

The Xoom so far has only a single 3G+Wifi-capable model, which retails for $799 standalone. This actually isn’t insanely awful — Apple’s 3G+Wifi models can run up to $729 or $829 with larger built-in storage, while the Xoom can have storage added with an SD card, so the gap is less than that initially visible $300 if you’re going for the beefier models.

Verizon also offers a $200 subsidy for a 2-year contract, making pricing more comparable to the unsubsidized $629 base 3G+Wifi iPad. But… let’s be honest, we all have phones with 3G or 4G data plans already. Do we really need to shell out for another cellular radio and another data plan?

Which tablet will actually cost you more will depend on which one you buy and on which data plan you get, if any. For those of us who want to pass on paying for a third (or fourth …) Internet connection every month when we can already use our phones as a wifi hotspot, any data plan is a huge expense, and subsidized pricing doesn’t make up for it:

  • iPad 2 Wifi-only: $499
  • Xoom 3G+Wifi w/ 2 years contracted data plan (sticker price only): $599 (pay extra $100, but you really pay more…)
  • iPad 2 3G+Wifi w/o data plan: $629 (pay extra $130)
  • Xoom 3G+Wifi w/o data plan: $799 (pay extra $300… but Best Buy ads say you actually need to buy a month of service to activate it…)
  • iPad 2 3G+Wifi w/ 2 years month-by-month $15/mo data plan: $989-$1229 depending on taxes/fees? (pay extra $400-$600):
  • Xoom 3G+Wifi w/ 2 years contracted $20/mo data plan: $1080-$1300 depending on taxes/fees? (pay extra $500-$700; plus another $350 if you terminate contract early)

Bigger badder data plans will let either brand leapfrog the other in price, depending on where you pick em… The cheapest thing is to buy a Wifi-only iPad and donate a few hundred bucks to your favorite Free Software-related charity. :P

The most important thing to remember is that for devices that incur a monthly data plan fee, the costs of the data plan can dwarf the original purchase price. This is why so many phones are insanely cheap or “free” — carriers have spent years playing an arms race to the bottom on your initial buy-in price to make way, way more money from you in the long term.

Update 2010-03-21: Motorola has announced a wifi-only Xoom model at $599; still above the iPad 2 entry price point but MUCH cheaper than getting anything with a data plan. I’ve placed a pre-order and hope to be trying it out by the end of the month!

Beta testers for StatusNet Mobile wanted soon…

A few weeks ago, we released the first public beta of StatusNet’s dedicated desktop client for Linux, Mac, and Windows.

We’re still working on bug fixes and improvements, but we’ve also been working on a mobile version, which runs on Android and iPhone/iOS platforms (Blackberry support isn’t ready yet in the Titanium cross-platform runtime we’re using, but it should come along in a few months). If you’re really brave you can dive into the source code, but we’re in the middle of major restructurings and UI design so it’s not really usable yet. :)

Once we get the UI polished up in the next week or so, we are going to need some testers to help make sure things work on different devices, different OS versions, at different screen sizes, with different servers, etc…

If you have an iPhone or iPod Touch and want to test without being a developer yourself, you’ll need to find your device’s UDID number and send it to us; due to the way Apple’s code signing works you won’t be able to install the beta distribution unless your device’s ID was included when building the signing key.

Android users will only need to ensure that “Unknown sources” is checked in Application settings, which allows installing apps from the web as well as from the Android Market. (Some models unfortunately don’t allow changing this setting, in which case you may need to root your phone to get the beta running. Sorry!)

Particular things we’re looking for…

  • older iPhone 2G, 3G devices still running iPhoneOS 3
  • Android phones running older OS versions (1.6 or later; 1.5 does not work with our runtime)
  • Android devices with unusual screen sizes:
    • small low-res screens (less than 320×480)
    • larger tablet devices

Nexus 1 + Froyo notes & iPhone 4

The Android 2.2 “Froyo” update finally came through over the last few days for Nexus 1 owners. After a few days of on-and-off usage, some notes to add to my initial review of the N1 running 2.1:

What’s new:

  • Speed: Things definitely feel snappier than they used to, but not really in a firmly quantifiable way. I’ll try another head-to-head scrolling test after a bit, but I can still expect to see the N1 way behind on that — scrolling still feels jerkier, and usually slower, than on an iPhone.
  • Tethering: For me, this was one of the main the killer features that pushed me to actually buy the N1, and I’m very happy to see it working! AT&T might finally have gotten around to enabling tethering for the iPhone, but they’ve shot themselves in the foot by making it cheaper to buy a new Android phone instead of the $20/month to not get a bandwidth limit increase on your iPhone. Over your 2-year contract, that comes to $480 wasted on AT&T… and it still wouldn’t power your Wifi iPad while the Android will! Sorry, guys. I know which features I want.
  • Screen: my background image is still pretty badly banded, but gradients in the web browser look smoother. There may be piecemeal improvements in how images get rendered and dithered for fullcolor output, but it’s still a bit inconsistent.

Otherwise, the OS isn’t mind-blowingly different, but definitely has a lot of nice little bumps. Ars Technica has a general review of Froyo on the N1 if you want to peek at a few other under-the-hood changes.

Update: There’s also a notification system that looks like a very flexible superset of what the iPhone platform has, which might be very nice for things like sending realtime updates to our upcoming mobile client without it having to poll in the background. That ain’t much useful to users yet, but we’re sure gonna use it in future!

Compared to the iPhone 4

Of course, Apple’s been moving as well. iOS 4 is out for the existing iPhone 3G and 3Gs, and the new iPhone 4 is available and busy fighting a reception issue scandal.

iOS 4 on my iPhone 3G feels like a very nice incremental improvement. Things aren’t radically different, but it’s definitely a bit nicer: folders have helped organize home screens by moving out rarely-used apps, background processing is a big help for a few apps (like Pandora!) and there are other niceties like threading in the mail reader.

I haven’t picked up an iPhone 4 for personal use yet, but I did swing through an Apple store the other day (when the crowds had died down a bit!) to check it out. There are only a couple of interesting user-visible hardware changes beyond the case change:

My favorite is the awesome, awesome high-resolution display. I am really looking forward to this pixel density being available on desktop-size screens… some day we can stop worrying about pixels and just have text and graphics that look good.

There’s some talk that HDTV has actually set display technology back for large formats; I’ve seen only a handful of commercially-available monitors that venture much beyond 1920×1080, and those are all to gain extra desktop space not to improve density/sharpness.

The screen on the Nexus 1 is visibly sharper than the iPhone 3Gs, but even with my slightly blurry vision is visible pixelated at smartphone-usage distances from my eye. The iPhone 4 really, literally, truly moves it into the realm where pixels no longer matter; as this level of display technology makes it out into the broader market, I think it’s going to make a big difference in what we’re comfortable reading on a small screen.

The front-facing camera & video calling support is the primary selling point in Apple’s current ad campaign; the nice saleslady demoed it for me, and the quality’s pretty good for what it is. But honestly I don’t see myself ever using it as more than a gimmick; I’ve had a webcam on my laptop for 5 years and have never been on a video chat that’s not about trying out the video chat feature. Perhaps Apple will prove me wrong — and like with video chats on computers, some people get a lot more mileage out of it than others. I can certainly see if I had a small child we’d probably be on with my parents a lot more often — my mom doesn’t need too many real-time updates on the cats. ;)

There’s also an improved main camera, which may be a nice extra but isn’t a killer feature for me — the current phone cameras are adequate (though not great) and aren’t main selling points for me.

Mobile dev trade-offs: emulator vs simulator

Along with other projects at StatusNet, I’ve been poking at the mobile version of our open-source client reference implementation (still in pre-alpha but getting usable for desktop version). We’re building the client with Appcelerator Titanium, a JavaScript-based cross-platform toolset for development and packaging; the desktop version uses a WebKit-based HTML environment, while the mobile versions use a thin bridge between JS and native controls.

There are some differences between the JavaScript and native bridge implementations between the different target platforms, but cleanly-written backend code can be shared between all platforms, and we’re able to use a single codebase for the mobile UI on both iPhone and Android.

The fun part, though, is with testing and debugging. I’m doing most of the mobile development on my MacBook Pro since I can test both current mobile targets in their respective emulators or real devices from there.

The Android experience

There are several really nice things about the Android SDK setup. First off the download isn’t a bandwidth-shattering 2.3 gigabyte disk image. :) Once installed, I can create custom emulator images with particular combinations of screen resolution and API versions. And, of course, I don’t have to pay $99 and set up a bunch of code-signing keys just to run my test app on a real device!

Android’s SDK emulator is a real, honest-to-god emulator, built around the amazingly versatile QEMU. (I remember using QEMU to simulate an x86_64 system back before I could afford one! Oh the memories…) It runs a complete virtual ARM-based system, booting up a full Linux kernel and Android userland environment.

The good thing about this is that you’re going to be running the exact same real actual code that you’d load onto a real system.

The bad thing is that it takes fricking FOREVER to boot up. Even on a fast modern desktop CPU, emulation is a bit sluggish… booting and general UI actions feel much slower in the emulator than on my Nexus 1 with a 1GHz Snapdragon CPU. And if you accidentally close the emulator you have to wait for it to boot up before relaunching your app…

It’s actually faster in many cases to plug in an Android phone and launch it there. With USB debugging enabled, a native phone can be treated much like the emulator, and Titanium’s wrapper on the SDK can install and launch my app remotely just as quickly as on the emulator — but without waiting for it to boot.

The iPhone experience

Apple went another direction with their iPhone SDK, which has some pluses and minuses. Rather than a true system emulator, the SDK contains an “iPhone Simulator” application, which runs much of the iPhone OS userland as native Intel code on the host system.

The downsides are obvious: you have to compile separately for the simulator and the real, ARM-based devices. Subtle bugs can arise from differences between the systems at both high and low levels. Low-level optimizations such as assembler or vector code won’t even compile, much less run (though that at least isn’t an issue for our JS-based code! ;) An emulator wouldn’t have the same performance characteristics, but could help you confirm that  your math is right before sticking it on a real device.

But there are some upsides: most important to me, the simulator launches nearly instantly. This makes a big difference when you’re working in a rapid-development environment without a good debugging infrastructure; working in Titanium’s JavaScript involves a lot of ‘poke in this line of debug to find out wtf is going on, then fix it’ and I might have to restart the app over and over and over while working with it…

The thing that’s amusingly poor with the iPhone is launching the app  on a physical device. Thanks to Apple’s tight restrictions on app distribution, running your own program requires buying into Apple’s developer program ($99/year), setting up code-signing keys, an dropping a bunch of certs into iTunes so it’ll be willing to copy your stuff over. The Titanium developer tool can then recompile your app (this time for ARM) and shove it over to iTunes, which performs a sync of your phone to copy the app on. This is kind of annoying if you have a bunch of random crap on your phone and syncing takes forever!

What I’d like

Something in the middle might be nice… working with a real device is a lot easier without jumping through code-signing hoops, and the iTunes mediation seems like something that should be skippable if the toolchain’s better integrated, which could improve the iPhone experience.

Performance and boot time are the biggest issues with the Android emulator; making it boot within a couple seconds would be a huge improvement by itself. Cutting overhead by running a native i386 or x86_64 system image might be nice too, but might not be worth the trade-offs of being able to run native ARM code in the emulator.