Jason Antman’s Blog

So, I updated my Droid to Android 2.0.1 today. I’ll be honest that it didn’t work the way I’d hoped. When I woke up this morning (December 10^th 2009) I had an alert dialog on screen telling me that an update was ready. It gave me three options: “Install Now”, “Install Later” and “More Info”. The More Info screen didn’t show me anything useful. Well, I clicked the “Later” option, figuring that when I got home tonight I’d turn on WiFi, do a packet capture on the router, and save all of the traffic (specifically including the name of the update server). Well, it kept reminding me all day at annoyingly short intervals – probably about every 10 minutes or so. Finally, when I was home and had the WiFi setup, I went to try it again and… yup… when I clicked on the “System Update” button in Settings, the only option I had was “Reboot and Install”.

So… first big bitch about the Droid… Verizon pushed out the update without my consent. I kept hitting “Later” because that was the only way to get the popup to go away. Apparently. after X times of hitting Later (and each time your only real options are Later or Now) it will download the update by itself. Once the update is downloaded, I’m assuming that it *may* just automatically install on the next reboot. That would be a bitch thing to do.

Anyway, the “More Info” screen, which provides (as far as I can tell) the only release notes for the update, states:

This software update includes enhancements to your DROID by Motorola. Approximate install time: 6-10 Mins. You will be unable to use your device or make emergency calls for the duration of the install. The software updates automatically, and your DROID will power off and on as part of this software update. For more information please visit: www.verizonwireless.com/droidsupport

Not too helpful. And pretty cryptic.

Immediately when the phone turned back on, the first thing I noticed is that the spin-style unlock button has been replaced with an iPhone-style slide button, and the same for the mute feature. Maybe it’s just me, but I also noticed that the on screen keyboard seems to react better to quick keypresses – perhaps they’ve enabled multitouch for this?

Unfortunately, I wasn’t able to find much release documentation from Google other than the API changes – no full release notes or changelog like I’d like. And not even a summary of changes that I could find.

At the VZW droid support site, I found a link to a PDF of “Why to Update” (local copy). This sheet lists the enhancements made by the update (”AP:ESD56/BP:C_01.3E.01P”, build ESD56) as:

• OS stability is improved.
• Battery life is improved.
• Camera auto focus functionality is improved, and time between shots is reduced.
• Enhancements for three-way calling.
• Audio for incoming calls is improved.
• When receiving a call on call waiting, the speakerphone now remains on.
• Bluetooth functionality is improved; background echo is eliminated.
• Improved Bluetooth phone book transfer of contacts to in-vehicle Bluetooth solutions.
• After closing a GPS application, the GPS icon will now automatically be removed from the notification panel.
• Users can now receive SMS and MMS messages after an EMS message is received.
• SMS and MMS may now be sent to seven-digit addresses.
• Google contact merging has been updated to accommodate seven-digit numbers.
• Visual Voice Mail notices now arrive instantaneously.
• The corporate calendar widget user interface is updated.

This tiny one-page (and very styish – looks like and in-store advertising piece) sheet obviously isn’t anything that could pass for release notes, especially from Google. It doesn’t even mention anything about the changed unlock button!

I’ll keep looking around to find a real feature summary/release notes/changelog, but here’s my running list (I’ll update) of what I’ve found:

• Changed the unlock slider to a straight line.
• On screen keyboard typing seems faster.
• Photo taking is considerably faster, though it’s still painfully slow – it used to take about 10 seconds from shutter button to ready to capture next image, it’s now about 5 seconds.
• The UI seems to be a bit more responsive overall.
• I haven’t checked yet, but I’ve seen some forum posts about lost contacts and Facebook sync issues.

android android, droid, google, motorola, verizon

This is a follow-up to my Making maps from GIS data with Inkscape post. After playing around with Inkscape for quite a while, and coming up with the dismal results seen in that post, I decided there has to be an easier way. A little Googling turned up this video tutorial on how to print large scale maps from Google Maps. It turns out that the Google Maps API will honor almost any pixel resolution that it’s passed. The Screengrab add-on for Firefox has the wonderful capability of being able to capture a screengrab of page content, at actual resolution, regardless of screen resolution. So load up a 5000×5000 pixel Google Map, use the Screengrab addon, and end up with a full 5000×5000 pixel image file.

After testing this a bit, I decided to go the Google Maps route. This also has a lot of other added bonuses – I can store my overlay data in simple XML files, add and remove layers on-the-fly, and also make it available online (and, theoretically, to any Google Maps-equipped device used by responders). This even opens up the possibility of using paper maps as a last resort, and providing the Fire Department with live hydrant maps on GPS-enabled handheld devices and phones.

The quirks, however, may need some serious photoshopping (err, rather, gimping) to fix:

1. With all of the background color, how will this look when printed?
2. How do I make the town borders easily defined? It would be a lot of raster editing to remove the background color of areas outside of town.
3. How do I overlay a grid for a street name index?

The first step was to setup a large Google Map to develop with. I used PHP and Monte Ohrt’s GoogleMapAPI PHP wrapper class. It was simple enough to setup a big (3300×5100px) map, zoom out in Firefox, and start adding some stuff. My examples and development pages, if you want to take a peek at the code, are here.

The first step was to draw a polygon for the outline of the town. I found some very detailed information on how to get zip code boundary lines on Matt Cutts’ blog. Apparently, he’s a Google software engineer, heading up their webspam team. I grabbed the files from the Census, as described, and came up with the boundary for my zip code looking like:

        60      -0.741427638843858E+02       0.409963180802469E+02
      -0.741375870000000E+02       0.410075970000000E+02
      -0.741308870000000E+02       0.410061970000000E+02
      -0.741308870000000E+02       0.410061970000000E+02
      -0.741307260000000E+02       0.410032600000000E+02
      -0.741326870000000E+02       0.409955970000000E+02
      -0.741278870000000E+02       0.409943970000000E+02
      -0.741280870000000E+02       0.409938970000000E+02
      -0.741327870000000E+02       0.409853970000000E+02
      -0.741352870000000E+02       0.409830970000000E+02
      -0.741369600000000E+02       0.409818620000000E+02
      -0.741410520000000E+02       0.409821940000000E+02
      -0.741412870000000E+02       0.409826970000000E+02
      -0.741412870000000E+02       0.409826970000000E+02
      -0.741417870000000E+02       0.409847970000000E+02
      -0.741427870000000E+02       0.409863970000000E+02
      -0.741482870000000E+02       0.409868970000000E+02
      -0.741536880000000E+02       0.409899970000000E+02
      -0.741510880000000E+02       0.409929970000000E+02
      -0.741531880000000E+02       0.409965970000000E+02
      -0.741571880000000E+02       0.409988970000000E+02
      -0.741557880000000E+02       0.410013970000000E+02
      -0.741461870000000E+02       0.410018970000000E+02
      -0.741400870000000E+02       0.410065970000000E+02
 
      -0.741375870000000E+02       0.410075970000000E+02
END

As per Matt’s instructions, I stripped off the first and last lines, converted everything to normal decimal notation, and built it into a PHP array:

$MP_boundary = array();
$MP_boundary[] = array(-74.137587, 41.007597);
$MP_boundary[] = array(-74.130887, 41.006197);
$MP_boundary[] = array(-74.130887, 41.006197);
$MP_boundary[] = array(-74.130726, 41.003260);
$MP_boundary[] = array(-74.132687, 40.995597);
$MP_boundary[] = array(-74.127887, 40.994397);
$MP_boundary[] = array(-74.128087, 40.993897);
$MP_boundary[] = array(-74.132787, 40.985397);
$MP_boundary[] = array(-74.135287, 40.983097);
$MP_boundary[] = array(-74.136960, 40.981862);
$MP_boundary[] = array(-74.141052, 40.982194);
$MP_boundary[] = array(-74.141287, 40.982697);
$MP_boundary[] = array(-74.141287, 40.982697);
$MP_boundary[] = array(-74.141787, 40.984797);
$MP_boundary[] = array(-74.142787, 40.986397);
$MP_boundary[] = array(-74.148287, 40.986897);
$MP_boundary[] = array(-74.153688, 40.989997);
$MP_boundary[] = array(-74.151088, 40.992997);
$MP_boundary[] = array(-74.153188, 40.996597);
$MP_boundary[] = array(-74.157188, 40.998897);
$MP_boundary[] = array(-74.155788, 41.001397);
$MP_boundary[] = array(-74.146187, 41.001897);
$MP_boundary[] = array(-74.140087, 41.006597);
$MP_boundary[] = array(-74.137587, 41.007597);

Though this data doesn’t seem exactly 100% accurate (at least by my knowledge of the town, and every map I can find) it’s quite close and a very good start.

I’ll update later this week when I have some more done…

Tech HowTos catrography, emergency, EMS, google, maps, PHP

If you’ve used Google search from an Android device to search for a business, you’ve probably noticed the two interesting “buttons” to the right of the search listing – “Get Directions” and a button for the phone number. It turns out, these are pretty easy to implement.

The “Get Directions” link is a simple link to Google Maps like This One. The links are actually pretty simple:

<a href="http://maps.google.com/maps?daddr=42+Pierce+Ave%2C+Midland+Park%2C+NJ+07432">Get Directions</a>

It just uses a regular Google Maps URL, with the destination address encoded. When the link is clicked in the Android browser, a dialog pops up asking the user whether he wants to open it with the browser or the Maps application. If Maps is selected, it automatically opens with the address from the URL in the destination input box, the phone’s current location as the start input, and gives easy access to directions and navigation.

The telephone links are a bit more interesting. Apparently, the Android browser uses the Phone app to handle the “tel” scheme, as defined by RFC 3966.Therefore, clicking a link like:

<a href="tel:2015555555">201-555-5555</a>

on Android will bring up the Phone app and pre-enter the digits for 2015555555. Luckily, it doesn’t automatically dial the number. If you want to give it a try and are using Android: 201-555-5555.

The final step is how to implement this. I don’t know if most mobile browsers (Blackberry? iPhone?) also support the “tel” URI scheme, or how they’ll handle Google Maps links. But if you’re looking to include Android-specific content, the user agent string from my Motorola Droid (Android 2.0) looks like:

Mozilla/5.0 (Linux; U;Android 2.0; en-us; Droid Build/ESD20) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

I know that there are a number of PHP classes out there to detect browsers (like Chris Schuld’s browser.php) and some things to detect mobile device capabilities (like WURFL or Tera WURFL, both using the WURFL data). However, if you just need to know whether your user is on Android or not, I’d personally recommend just checking the user agent string for “Linux”, “Android” and “WebKit” until a better browser identification system is found, as these are not likely to change in the near future.

Uncategorized android, google, html

The Droid is here (literally, sitting in my pocket), and I have the next two days off of work – plus the weekend. Minus personal commitments, that’s about two full (call it 16 hour) days to get some work done. While I have lots of things that could use my attention – a number of neglected projects, my big new PHPsa project, and some server consolidation at home – I’ve decided to dedicate the time to Android development.

I’ve got the ADK installed and running, and the emulator is wonderful (especially with the Droid skin). And I know it’s wrong, but I think I’m going to be developing the first app for Android 2.0 (especially given the new ContactsContract API in 5).

I’m having a few issues with Subclipse, even on the latest OpenSuSE 11.1, and still have a few things I want to do on the phone… but hopefully I’ll have a beta build of the app by the end of the weekend. I’ve already done most of the data modeling and sketched out the storyboard.

I’m not going to say much about what the app is until it’s ready, but it’s something targeted at people like me – SysAdmins with way too many things on their plate for their number of waking hours.

android android, google

I don’t like writing posts with a low useful content quotient, but here goes.

After having only one new (i.e. not used) phone in eight years – and the one new one was a Treo 700p, obsolete when I bought it – I decided to bite the bullet. I bought a Droid! While I was almost dead-set on it before I even held it in the store, my feelings of love at first sight were even more clear when I started to play around with it.

So, here’s a little overview of what I did first, what my plans/questions are, and what’s next.

First minutes/day:

1. Unpack everything and start to figure things out. Test phone, SMS, data.
2. Setup IMAP email for my personal account (need to look into IMAP-IDLE).
3. Go through the entire Settings menu and try to set things up. Find out that the default apps can’t be removed. The app screen, by default, is pretty full…
4. Export my contacts from my Palm (no sync cable, had to use php-pdb to export a CSV, then manually edit ALL of them in Gmail.

So after having the phone for about 12 hours, here’s what I’ve installed on it:

• Listen (Google Labs) – Great podcatcher app. The speaker is a bit too quiet for easy listening on the drive to work, so I’ll need to get one of those FM radio interfaces.
• AnyCut – allows creation of arbitrary shortcuts on the desktop, including direct dial.
• ConnectBot – full-featured SSH client including key-based auth and storage of multiple user/host settings.
• Meebo IM – IM client. It does AIM, which is nice, but doesn’t do IRC.
• Android Battery Dog – App that graphs battery voltage, temperature, capacity over time and also stores a simple CSV log (which I intend to parse out later for historical data).
• Bookmarking for Delicious – Allows saving of bookmarks to del.icio.us (but not retrieval).
• To Do List – A very simple To Do list app, until I find something that works with Google Tasks. No syncing.
• VoiceMemo (JavaCodeLand.com) – A really simple voice memo app.
• WiFinder (PGMsoft) – Pretty much useless. Shows a scan of WiFi networks, but only shows encryption, channel number, and signal strength in bars.

The few problems I’ve noticed so far:

• The touch-sensitive buttons along the bottom row (specifically the search button) seem to be right where my thumb wants to rest when holding the phone in landscape mode.
• As others have mentioned, the camera quality isn’t great, but it’s much better than my Treo 700p.

My list for future research/development:

• WAP pages for my web-based personal finance app, fuel log, etc.
• IMAP IDLE
• Tasks/to do app that syncs with Google Tasks.
• A Cycle System app.
• How to quickly mute all sounds on the phone.
• How to do tones by person or group for not only ringtones (phone) but also SMS, Email, etc. Also, a way to set certain hours of the day when audible alerts will be disabled, other than a specified whitelist (email, SMS, etc.)
• Verizon Visual Voicemail
• Do some development with the geolocation JS API.
• Console on the phone?
• SCP/SFTP program.
• TV listings (perhaps a WAP version of my script that pulls from SchedulesDirect (unfortunately, due to their redistribution policy, this is a private, authenticated page).
• Nagios checker/notifier
• RSS reader
• WAP page for PHP EMS Tools callin.
• How to handle IMAP folders?
• Script to backup Gmail contacts, other data stored with Google.
• Thunderbird Gmail contact sync.
• A wifi scanner/survey software that shows all of the important stuff like signal strength in dbm, noise floor, etc.
• Something like kismet that integrates the GPS and wifi scanning.

android android, droid, google

Well, I wanted to call this a $#!^storm, but I don’t think it’s grown to those proportions yet. But any new platform will have its hiccups, and Google is relatively new to the OS world.

So, here’s the news. Google issued a legal Cease and Desist order to a developer Steve Kondik (known as Cyanogen). The story goes something like this… Steve is an active Android developer, doing a lot of work on the lower-level stuff (lower level than apps), including multi-touch and more home screens. His changes are essentially at the OS-level, and Android doesn’t have a full-fledged package management/patching mechanism like Linux distros, so making use of them requires recompiling stuff and re-flashing the device with a new ROM image (since the installation apps can’t handle stuff this low-level). Here’s the rub: in order to work on a device, the ROM image needs to include both closed-source Google apps and proprietary (device manufacturer) drivers. While these apps and drivers are available for download, the license terms prohibit redistribution. But in order for Steve to create a fully-functional ROM image, he has to include the closed code.

There are some writeups on this at Linux Magazine and a good, timely analysis at Linux Insider.

There’s also a clarification by Google’s Dan Morrill on the Android Developers blog.

So, what’s my take on all this (not that another guy taking about this is needed)?

Firstly, I think this is relatively minor. The community will work around it, whether with Google’s blessing or not. The bigger issue that’s coming to light is the fact that Google isn’t simply altruistic, they’re a for-profit entity. They have every right to be, and they have every right to exercise some amount of control over Android. The community needs to realize that Android isn’t a silver bullet, and isn’t even the Linux of the phone world. On the other hand, Google needs to realize two important facts: 1) the openness of Android is what’s driving developers to it, and they need to do all they can to continue that, and 2) most of those developers are flat-out used to running Linux with an all-GPL system, and aren’t used to the concept of not being able to roll their own distribution.

So what’s my advice?

1. Google should further decouple their Apps from the Android platform. Specifically, instead of requiring users to back things up, they should provide a redistributable application that installs their other apps. Allow a user to flash a bare-bones community ROM image, and then pull whatever else they want from Google. If Google intends on toeing the line that Android is Free but the (Google) Apps aren’t, then Google should provide an acceptable means for users of community ROM images to easily and painlessly re-install the closed Google apps on that image.
2. Google should require that handset manufacturers do the same. Create a redistributable application that can be part of community ROM images, which will (via tethering or whatever) download and install any proprietary device-specific drivers that are needed.

Bottom line of my opinion – it’s fine if Google exercises their full control over their own closed apps. But they should provide an avenue for non-technical end-users to easily upgrade a community (i.e. Free) ROM image with the expected Google Apps and device manufacturer software.

Tech News android, google

In terms of ongoing projects, I should be updating RackMan sometime soon, and also adding the demo site.

I’ve begun to move DNS for all of my domains in-house, mostly because since everything is behind NAT, it’s a real pain to manage DNS entries in two places (one of them being GoDaddy’s web interface). Because of the NAT issue, I’m also writing my own BIND configuration tool, currently named MultiBIND Admin. In addition to managing multiple zones in a sane way, it stores all configuration in MySQL. Among other things, it can store different IP addresses for A records for the inside and outside views. Zone files can either be pulled by a script on the name server (push capability is being worked on) or downloaded (for uploading to a DNS hosting provider like GoDaddy).

For my final project for my XML web design class, I’m going to be making some “mashup” with RackMan, Google Maps, Google Visualizer, Nagios, and a few other tools…

Stay tuned…

PHPsa, Projects bind, dns, google, PHPsa, rackman

So… what’s the deal? Will anyone come out and definitively say what the fate of VoIP is?

From what I’ve read, there are two distinct issues:

1. The ease of developing VoIP applications on Android, given the lack of a SIP stack.
2. T-Mobile’s shunning of VoIP over their 3G network.

Android – obviously, if we want to see VoIP apps on the G1, Android needs to support SIP. And the best way to do this is with real, native OS support. Even if VoIP possibilities are limited to WiFi, still, it would be nice to have SIP support and let my cell double as a WiFi VoIP phone… even if handoffs between APs are still nearly impossible. The next question that begs to be asked is how well such a third-party app can integrate with the phone. Will the user experience of receiving a VoIP call be substantially similar to that of receiving a normal phone call?

T-Mobile 3G – I’ve read, so far, that T-Mobile “does not support” VoIP over their 3G network. What’s this whole “does not support” thing? I’m still a bit confused about how their 3G network works… do they actively block 3G, or just not enable it? If the latter, doe this mean that other “non-standard” things, such as SSHing to a non-standard port, won’t work? Does this mean that there will be other heavy restrictions on what types of data are sent over the network?

What about tunneling SIP/IAX/whatever else over SSH? Will the G1 be capable of handling that at a relatively good speed?

I’ve read that the G1 “can’t” be tethered. WTF? Firstly, what is this “can’t” thing? Couldn’t a developer just write an app that’s essentially a proxy server, that proxies from some sort of USB-based wired connection to 3G?

Unfortunately, as has been written many times already, less than a week from the G1’s release, it seems that the openness touted by Google and T-Mobile is much less than that. With all their claims of openness, I’d expect a phone that will do anything – especially not be locked to one carrier, given Google’s history of opposing that (their bid for 700Mhz) – and a data plan that would allow anything over the air that my home ISP will allow over the wire.

Google: Have you forsaken all of your stated ideals at the prospect of making some cash off of a phone?

Ideas and Rants cell, g1, google, phone, t-mobile, voip

It’s been a long month and a half or so. A bunch of new projects at work (and interviewing for a full-time position) and lots of school stuff, all on top of having my truck stolen, dealing with insurance and the police, and then recovering it, and dealing with insurance again. It’s a long long story, which I posted as a Note on facebook.

PHP EMS Tools is due for a major revision, and hopefully this will include, among other things, the following new features:

1. Support for i18n.
2. Install-time choice of using MySQL or LDAP as a roster and authentication storage system.
3. Some vastly more efficient changes to the database schema, specifically dealing with scheduling.

I’m still working on some other big projects, namely the migration of this blog to WordPress, the migration of JasonAntman.com to some real CMS (Joomla, Drupal, etc.), and migration of my home internet connection from residential FiOS to “business-grade” Optimum Online (cable) – which will probably see a slight decrease in reliability from the amazing levels of FiOS, but will give me five static IPs and no ports blocked.

On the other hand, there’s been a wrench thrown into all of my plans for big projects (not even mentioning the projects that have been cast aside – TuxTruck, tuxOstat which is now down, and a bunch of others. That wrench is the T-Mobile G1, the GooglePhone finally come to fruition. I was psyched about Android when I first heard about it, and the idea of finally having a phone that I can develop for without learning a new language sounds amazing. I’ll admit that at $180 with a 2-year contract, plus $80/month for service (split about 50/50 between the voice plan and the unlimited data plan) it doesn’t make the best financial sense for someone whose car was stolen and now has 2 vehicles – only one of which I can afford – but I’m really excited. I’ve heard some not-so-good things about the quality of the GPS, and some of the apps currently available, but within a few months, I’d assume that the effects of open development will cause it to greatly surpass the functionality of my current Treo 700p, running my beloved Palm OS (which I’ve been dedicated to for the better part of seven years).

While the all-around flexibility of Android and its’ apps is definitely one of the biggest selling points, my own interest is mainly in the ability to quickly develop Java apps that bring my already-existing web-based forms and data to the desktop of my phone. It’s the simplicity that is my biggest interest – even for simple purposes, like converting the web-based fuel log I keep for my car(s) to a dedicated Java-based form on my phone.

Stay tuned…

Projects android, g1, google

While I’ve often told mystified people that hosted services – the free ones – aren’t required to backup your data, and you should probably do it yourself, I usually didn’t worry about this very much – all of my web apps are on my own boxes, as well as my email. However, out of curiosity, I spent about 15 minutes the other day coding up a little hack of a PHP script to keep track of what applications I use a lot (specifically web-based ones that I can’t easily have my OS keep track of). After a day of trying to click the little “update” boxes on a simple page when I used something, I realized how much of my data is actually out of my own control. Maybe not anything critical, but convenience stuff like Google Reader, del.icio.us for *all* of my bookmarks, and occasionally Google Docs when I’m going to be hopping from place to place, or may be using a machine that I don’t trust to SFTP something back home.

So, I decided to go about backing up some of this. The solution I aimed for was simple – a BASH script that runs nightly via cron, and dumps the data into my home directory on my main storage/backup server.

Google Reader seemed to be one of the most difficult – no easy URL scheme, but I found a simple script that makes use of Perl CPAN’s WebService::Google::Reader module to grab a complete feed list. After seemingly an hour of CPAN updates and dependencies scrolling down my screen,

Google Calendar Backup:
Wonderfully simple. Go into Settings, copy the URLs to the private calendar links (I used iCal format), and wget them.

del.icio.us backup:

curl --user usernam:pass -o myDelicious.xml -O 'https://api.del.icio.us/v1/posts/all'

Google Reader Backup:
Still in the works – Perl problems on my backup machine.

Google Docs Backup:
Hopefully soon, though nothing important lives there.

Tech HowTos backups, del.icio.us, docs, google, reader