Review: Verizon Galaxy Nexus

So first my initial impressions from the day after I first took it home from the Verizon store:

First impressions:

• Light (I'mm afraid im going to break it compared to my DroidX)


• Fast internet (4G is crazy. 22mb down, 19mb up on my last test)


• Fast performance, but still some of the classic android lag, such as coming back to the homescreen from an app - widgets take .3 seconds to reload (vs several seconds on my DX on occasion)


• The auto brightness kinda sucks, its really bright outside, but SUPER dim inside.


• Battery life sucked hard yesterday. Lasted about 4 hours, but I had done some video chatting via gtalk and about an hour worth of navigation - and lots of app installing. Today I am going to leave it connected to the wifi at work and see if its any improvement (vs using 4G)


• Uses the same power cables as the DX!


• I have seen only a handful of app compatibility problems, which I am sure will be fixed in time. Some apps crash unexpectedly, or their graphics look a little fuzzy because they weren't designed for such a high res screen.


• Camera is super crazy fast, and the pictures seem to be okay so far. Better than my DX, but certainly not on par with a standard point and shoot camera.

So what's changed after 5 days?

So the battery life isn't fantastic- with lite to moderate I am seeing about 9/10 hours of battery life. Lite for me is:

• Lives in my pocket for most of the day.


• Take it out every once and awhile to check email, Twitter, Facebook.


• Take it out when-ever it vibrates due to a notification (maybe once every hour?).

Moderate for me is (differences underlined):

• Lives in my pocket for most of the day.


• Take it out every once and awhile to check email, Twitter, Facebook.


• Take it out when-ever it vibrates due to a notification (maybe once every hour?).


• Google Reader browsing in the morning while walking the dog (30 minutes).


• A couple 15 minute internet surfing sessions.


• One or two 30 minute phone calls.


• 1-3 photos taken.


• A few Google Talk conversations throughout the day.


• One or two Google Maps lookups.

Unfortunately I decided to watch Netflix while at the gym this morning - the battery dropped about 20% in 40 minutes.  (Outlined in green below - note that I left it off the charger all night long, and started using it around 60% charge.). Granted, I have auto-brightness disabled and the screen is set to about 60% brightness.  (I find that the auto-brightness setting really sucks, tending to make the screen too dark).

Issues that I am currently having...

The speaker volume

The speaker volume on this thing is horrible. On the scale of 1 to 10, its max volume seems to be stuck on 2. There are various threads on the internet discussing this, and it seems that installing Volume+ seem's to help a great deal (albeit still not perfect).

I purchased Volume+ - but there's a free version available to try it out. The free version is limited to +4 for amplification, but you can still tell the difference (its difficult).

Here's what I did: start playing an mp3 in music player, open Volume+ and slowly increment the speaker volume setting... you will notice that +4 is quite a bit louder than the default max volume of the device. The paid version let's you tweak the max volume a lot more, but anything above +9 seems to have no effect.

You can get Volume+ here. (FYI: You can get the paid version for free from the author's website)

Application crashes / compatibility

For the most part, applications designed for Gingerbread (2.3) seem to be running fine on ICS - but I have encountered a few apps that don't.

• Facebook. Love it or hate it, it's still an important application for the platform to have.  Works most of the time on ICS, but sometimes crashes with a black screen when resuming from the background.


• Calendar Snooze.  I think the calendar reminders in Android leave a lot to be desired, thankfully Calendar Snooze exists - but its not compatible.  I have reached out to the author, an ICS beta is available and an update is coming soon.  (The beta seems to work perfectly on my Nexus)

Battery life: How about 3G only?

I tried disabling LTE and using only 3G for a day - but its hard to get an accurate usage graph since my phone gets plugged in often throughout the course of a day for development.

So instead I have a graph of the phone mostly idle sitting on my kitchen counter over night unplugged. Outlined in green is approximately the time during which I was sleeping. Notice the dip in battery life right when I got up in the morning?

I took this screenshot about 2 hours ago - the battery is at roughly 20% now.

So what do I have running in the background?

I do have 3 email accounts, TweetDeck (every 15-30 minutes), Facebook, and a weather widget (Beautiful Widgets) running. GMail is the only one making the battery usage list (not shown), at a hefty 2%

Note: This is the standard battery, but I do have the extended battery on order.

In summary..

Android 4.0 (Ice Cream Sandwich) is simply amazing. I don't think I could ever go back to a pre-4.0 build of Android.

There are so many nice touches, simple things like it "knowing" that I really like to upload pictures from the gallery to Dropbox, so Dropbox is one of two choices available immediately. (You can get to the others by touching the tripple colon).

The phone isn't that bad either, and I havent had any of the 4G issues on Verizon that others are reporting. Sure the battery life could be better, but thats the case with any smart phone.

My biggest issue is definitely the volume - fingers crossed that a software fix can remedy this.

Introducing: Color Dots for Android

Color Dots is a colorful visual tracking game that will hold a child’s attention. A Simple and clean interface puts fun first.

My friend Erik makes iOS games for his daughter Ellie to play - Color Dots is the first one to come to Android!







FEATURES:
● Vibrant, Visually Stimulating Colors
● Popping Sounds
● Pop Vibration (iPhone)
● Smooth Animations
● Tablet and Phone Compatible
● No Ads! Perfect for infants!

Ellie's Games combines vivid colors and simple game functions to help your child grow while having fun. Color Dots is a bright, vivid color based game that helps expand a child's growing mind. Simple themes and a user friendly interface make all of Ellies Games simple and fun for children of all ages.
Ellies Games: Using vivid colors for a brighter tomorrow.
Have a great suggestion for Ellie's Games? Please send it to Erik@ElliesGames.com
Check out Ellie's other games on iOS:
- Rain Dots
- Color Squares
- Color Sliders

DoublePost 2.0 on Android Ice Cream Sandwich

In my spare time after work I have been working on updating DoublePost, fixing some bugs, and improving the UI.

Tonight I had the chance to install and test on Ice Cream Sandwich (Android 4.0) - here are some screenshots for your enjoyment!

[gallery orderby="title"]

Actionscript: Finding orphan image files

For the last month or so I have been working on an Adobe AIR for Mobile project, I won't talk about the over all experience (it wasn't positive) - but I would like to share a quick bash script I threw together to find unused/orphaned images in my code base.

When it came time to submit that apps to the Apple AppStore, we found that they were far too large to meet the under 20Mb requirement to download over 3G.

The following script is pretty straight forward to use and supports only a few options. Most usage should simply be:



By default it scans the "src" folder at the current level the command is run from. It will scan any of the popular Adobe AIR file types for references to any of the files that are in the directory you specify (src/assets/backgrounds/ in the above example)

Here's what it looks like when it finds a potential orphaned file:



(If you tack on the -d argument it will automatically delete files that it thinks are orphaned*)

*Orphaned for me, is a file that is not explicitly referenced in code or XML. This script will not find files that are linked dynamically

[bash]
#!/bin/bash
DELETE=false
TRACE=false
filelist=
FOUND=0
MISSING=0
SOURCE_DIR="./src"

until [ -z "$1" ]; do
# use a case statement to test vars. we always test
# test $1 and shift at the end of the for block.
case $1 in
-d )
DELETE=true
echo "Will delete orphaned files"
;;
-t )
TRACE=true
;;
-s )
shift
SOURCE_DIR=$1
;;
-* )
echo "Unrecognized option: $1"
exit 1
;;
* )
filelist=$1
;;
esac

shift

if [ "$#" = "0" ]; then
break
fi
done


if [ -z "$filelist" ]; then
echo "Usage: countImages.sh path [-d] [-t] [-s dir]"
echo "Specify -d if you wish to remove orphaned files."
echo "Specify -t if you wish to show found files"
echo "Specify -s dir if you wish to specify a specific source directory to scan. Default is ./src"
echo "If you wish to find all source files a particular image is referenced in, simple specify a path to a file"
echo "instead of a directory for path."
exit 1
fi



echo "Scanning $SOURCE_DIR for images from $filelist"

for file in $filelist*
do
SHORT_FILE=`basename $file`

RET=`find $SOURCE_DIR -type f \( -name "*.xml" -o -name "*.mxml" -o -name "*.as" \) -exec grep $SHORT_FILE {} \; -print | grep -c "$SHORT_FILE"`
if [ $RET -eq "0" ]
then
echo "$file has no occurences"
MISSING=$[$MISSING+1]

if $DELETE
then
rm $file

if [ $? = 0 ]
then
echo "... removed"
fi
fi


else
if $TRACE; then
echo "Found: $SHORT_FILE ($RET)"
RET2=`find $SOURCE_DIR -type f \( -name "*.xml" -o -name "*.mxml" -o -name "*.as" \) -exec grep $SHORT_FILE {} \; -print `
echo $RET2
fi
FOUND=$[$FOUND+1]
fi

done

echo "Found $FOUND files"
echo "There are $MISSING missing files that are potentially orphans."
[/bash]

Adobe AIR for Mobile: Adventures in Frustration

For work I am currently banging my head on an Adobe AIR project that will be deployed into iOS and Android phone/tablet apps.

There seem's to be an ever growing list of things that just "don't work right" in the language (at least compared to if I was writing things natively.).. and unfortunately the documentation/community is severely lacking.

Recently I was 100% stumped by a single build error for an entire weekend - it came out of no where, and it makes no sense at all. (I only found the solution by painstakingly merging changes from my current code into a 3 day old build, and building after each change).

The build issue:

When doing a release build of my AIR project in Flash Builder 4.5 I was receiving the strangest error ever:
Error occurred while packaging the application: Warning: 'function nextResult' contains a verify error at offset 757174. The body of this method will be replaced with 'throw VerifyError.

There was a nice long stack trace included as well, that pointed to absolutely nothing in my own code - (no way I am going to type this guy up!)



So what was the culprit? The code below (note, not even part of the referenced nextResult function!)

Bad Code (???)
[javascript]
switch(currentState)
{
case "Splash2":
{
// restart_clickHandler(null);
// break;
}
case "LangLoc":
{
restart_clickHandler(null);
break;
}
default:
{
break;
}
}
[/javascript]

After tweaking the case block below to have its own break (see below) statement, the Export Release Build worked perfectly (I think).

Good Code
[javascript]
switch(currentState)
{
case "Splash2":
{
restart_clickHandler(null);
break;
}
case "LangLoc":
{
restart_clickHandler(null);
break;
}
default:
{
break;
}
}
[/javascript]

Not cool Adobe. Not cool.

Android: Testing C2DM service from a shell

Recently I did some debugging of an existing Google C2DM infrastructure for an Android project. I wanted to test to see if the Android application was actually capable of receiving "messages" from the Google C2DM servers.

Android Cloud to Device Messaging (C2DM) is a service that helps developers send data from servers to their applications on Android devices. The service provides a simple, lightweight mechanism that servers can use to tell mobile applications to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queueing of messages and delivery to the target application running on the target device.

Basically the infrastructure is: Hosted servers (on your backend) send messages to Google C2DM service, and Google pushes those messages to the appropriately registered Android handsets.

I did not have access to the backend infrastructure, but wanted to send messages to my handset anyway.

The following is a bash script which you can use to push messages to Google's C2DM service, assuming you have the AUTH key for the backend server and the Registration ID of the receiving handset.

[shell]
#/bin/bash

REG_KEY=APA91bHuJQtqbrbkA......QFzpaJPuXY

AUTH_KEY_NPIKE=DQAAAO8........AC4P0

AUTH_KEY=$AUTH_KEY_NPIKE


#echo
echo Send Game Alert to Device
echo test_c2dm_sendGameAlert.sh [waitTime] [device_reg_key] [auth_key]
echo

# reg key
if [ ! -z $2 ];
then
REG_KEY=$2
echo Using user provided device registration key of: $REG_KEY
echo
fi

# auth key
if [ ! -z $3 ];
then
AUTH_KEY=$3
echo Using user provided auth key of: $AUTH_KEY
echo
fi

if [ ! -z $1 ];
then
WAIT=$1
echo Will wait for $WAIT seconds before sending C2DM message.

for (( c=1; c<=$WAIT; c++ ))
do
DELAY=$(($WAIT - $c))
echo -ne "$DELAY "

sleep 1
done
fi





echo Sending C2DM message to Google..
echo
C2DM_RESPONSE=`curl "https://android.apis.google.com/c2dm/send" -d "registration_id=$REG_KEY" -d "collapse_key=1" -d "data.mediaActionKey=Go There" -d "data.alert=New England Patrios win the Superbowl!very long very long very long very long very long very long very long very long" -d "data.mediaId=2010090900" -H "Authorization: GoogleLogin auth=$AUTH_KEY" -s`

echo C2DM Response:
echo $C2DM_RESPONSE

echo
echo Complete.
[/shell]

You can either hardcode in the appropriate keys, or you can pass them as arguments.

./test_c2dm_sendGameAlert.s 0 myDeviceKey myServerAuthKey

The very first argument is a "delay" time - hand if you want to kick off the script, and then run into your manager's office to say: "Hey check out this notification from the Google C2DM service!"

./test_c2dm_sendGameAlert.s 30

Monitoring subversion repositories for commits

If your subversion repository doesn't have commit emails turned on - don't fret!  It's fairly simple to monitor commits yourself with a simple bash script ( and growl and a launch agent if your on OSX).

Below is my bash script, that monitors a list of repositories for revision changes:

[bash]
#/bin/bash

# SETUP
growlNotify=/usr/local/bin/growlnotify

if [ ! -f $growlNotify ];
then
echo "Cannot find growlnotify, script will abort."
exit 1
fi

# loop through watch_list
while read repo_url; do
# format SVN repo URL to clean name
# first, strip underscores
CLEAN=${repo_url//_/}
# next, replace spaces with underscores
CLEAN=${CLEAN// /_}
# now, clean out anything that's not alphanumeric or an underscore
CLEAN=${CLEAN//[^a-zA-Z0-9_]/}

# rename $CLEAN to $CLEAN_old
mv tmp/$CLEAN tmp/${CLEAN}_old > /dev/null 2>&1

# run svn info repo, save output to $CLEAN
svn info $repo_url > tmp/$CLEAN

# run diff on $CLEAN and $CLEAN_old
diff tmp/$CLEAN tmp/${CLEAN}_old > /dev/null 2>&1

# if difference, show growl
if [ $? = 1 ]
then
SVN_REV=`awk '/Last Changed Rev: ([0-9]*)/{print $4}' tmp/$CLEAN`
SVN_NAME=`awk '/Path: (.*)/{print $2}' tmp/$CLEAN`
SVN_LOG=`svn log $repo_url -r$SVN_REV`

$growlNotify -n SVNMonkey -m "$SVN_NAME $SVN_LOG"
fi
done < watch_list
[/bash]

For the OSX, I have a launch agent that runs every 300 seconds (5 min). You can either recreate it yourself (I recommend using the free version of Lingon), or you can modify the following plist and use the following commands to install it.

[xml]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>net.npike.svnmonkey</string>
<key>ProgramArguments</key>
<array>
<string>/Volumes/npike 1/phunware/Dropbox/android/tools/svn_monkey/svn_monkey.sh</string>
</array>
<key>StartInterval</key>
<integer>300</integer>
<key>WorkingDirectory</key>
<string>/Volumes/npike 1/phunware/Dropbox/android/tools/svn_monkey</string>
</dict>
</plist>
[/xml]

Notes:

• ProgramArguments - Should be the full path to the bash script.


• StartInterval - The amount of time in seconds you wish the script to re-run


• WorkingDirectory - The full path to the directory where the bash script lives

Once you have the script saved to your mac (in its own directory), follow these instructions:

1. Make sure growlnotify is installed (for all users). This in the "Extras" folder in the growl download zip


2. Make sure the plist reflects the correct paths/locations on your machine


3. Make sure you create a "tmp" folder in the same directory as the bash script.


4. Open a terminal window to the same directory as the bash script.


5. Install the launch agent:
   [shell]
   launchctl load net.npike.svnmonkey.plist
   [/shell]
   


6. Start the launch agent:
   [shell]launchctl start net.npike.svnmonkey[/shell]
   

For completeness, you can also download a zip file which contains:

• The bash script


• Example watch_list


• plist for running as a launchd script on OSX


• Readme for getting the launchd script running on OSX


• Expected directory structure (needs an empty tmp folder relative to the script)

Download svn_monkey.zip