Archive for the ‘Android’ Category

Google Latitude UX adjustments

Tuesday, April 24th, 2012

I use Google Latitude quite a bit with roughly three to four checkins a day. I remember when you could get free things at Arbys with a checkin – though, I never took advantage of that. Even the manager at our local Arbys had no idea it was available, nor did they have a way to track it in their Point of Sale system. Likewise, our local Walgreens didn’t know how to handle a coupon on a phone that they couldn’t collect, though, did offer to give the discount if we bought the product.

However, the one thing that is very annoying is the amount of data that must be transferred for a checkin. I run a T-Mobile phone on AT&T’s network which means I’m limited to 2G which maxes at 512kb/sec. A first checkin after a phone restart will take two or three minutes transferring data.

When I do a checkin, rather than wait for the fine GPS location, I should be presented with a screen using the coarse lookup with all of the checkins that I have been to. That first screen would usually have the place I’m checking into. Granted I could go to a different store or restaurant, 95% of the time, that first list is going to contain a very short list of the places I’m likely to check in to.

While that list is being presented and GPS is getting a better position lock, I could opt for the refresh once I see GPS has locked in, or, hit search. Hitting search while it is loading results takes me into Maps rather than searching checking locations, then I have to go to the location, click on it, then click checkin. Cumbersome on 3G speeds, irritating at 2G speeds.

However, once I have done that, the amount of data for a checkin must be incredible as it will normally take 10-15 seconds to get to the next page that shows the leaderboard. Even at 2G speeds, I can’t imagine how much data needs to be sent that ties up the phone that long. I can upload a 115k image in less time than it takes to get the leaderboard after checking in. I know it isn’t a lookup time problem as both the send/receive data indicators are solid during the leaderboard download.

It has made me seriously consider bringing in an unlocked HTC Desire Z from Canada so I could have a keyboard phone on AT&T. I tried TMobile for 47 hours and missed text messages and several phone calls even though I can see their antenna from my backyard.

Watching several apps, the amount of data transmitted is sometimes quite scary.

Android App Graphics

Monday, February 6th, 2012

While writing an Android App, I found no list anywhere that talked about the numerous graphic items that would be needed.

* Two Screenshots – one of 320 x 480, 480 x 800, 480 x 854, 1280 x 720, 1280 x 800
* High Res Icon – 512 x 512
* Promo Graphic – 180w x 120h
* Feature Graphic – 1024 x 500
* Launcher Graphic 72×72, 48×48, 36×36

The screenshots are relatively easy to take from ddms. The rest of the graphic items need to be created in addition to the graphics used within the application itself.

* Android Brand Guidelines
* Icon Design Guidelines
* Launcher Design Icon Guidelines
* Graphic Assets for your application

Apple Guidelines

* Icons/Images

A few days of Android development – Java

Tuesday, January 24th, 2012

My latest project is written entirely in Java* (Java and JavaScript). While they aren’t the same by any stretch of the imagination, the project has been quite a learning experience.

From concept inception on Jan 11, 2012 and the first byte of code written that evening, I dreaded the Android App. Matthew Housden wrote a quick framework of it that had some bare functionality used for testing and I spent the last three days doing a headfirst dive into Java which I haven’t used in 9+ years.

The first problem I encountered was the tutorials on the Android SDK site don’t work in a 2.2 or 2.3 emulator nor on my phone. The documentation is littered with half-truths, but, when you read it carefully, you can tell that the person that wrote it was a programmer and not a technical documentation writer.

The application is quite simple – three screens, two of which POST to a remote server. However, I spent a ton of time debugging an issue where sending extra data to an Intent causes the OnActivity callback to have a null intent. I can see the security implications behind this, but, the documentation doesn’t allude to this.

Roughly 700 lines of Java (most are try/catch autogenerated blocks, declarations, etc) to get an app which is 22k until packaged for the market which balloons it to 290k. Dealing with the Camera was by far the heaviest code, dealing with the fact that the context isn’t available globally, I had to pass a number of parameters around rather than have a method that could be called.

It really didn’t take long to sink back into Java as it is just OOP and language is mostly syntax. Since I had been working heavily with Async Javascript with node.js, the event driven code structures required by Android weren’t that difficult to transition to.

Overall impressions: I was quite pleased how quickly I could write an app to do a few things and interact with my Node.js app. I really regret not doing more Android development with a few other projects I had in mind, but, there are only so many hours in the day. This weekend I’ve got a live beta test planned for the entire project – 17 days from inception to a real test.

Then we’ll see if this thing is worth launching.

Entries (RSS) and Comments (RSS).
Cluster host: li