Yesterday, I took the Journey into Mobile course over at Code School, an online training program with a handful of web technology courses. I just started a large mobile project for Paper Source, so this was good timing. Because a paid membership to Code School is required to participating in the training, I won't share too many of the course details here. But I'll share a few tidbits that will hopefully interest you in taking the course or learning more about mobile development.

The course was divided into 5 high level lessons (or levels):

• Relative Font Size
• Fluid Layouts
• Adaptive Design
• Responsiveness Adventures
• Responsive Media

The first two topics covered working with proportional font sizes and content regions, and how to convert your existing layout to proportions (percentage or ems) to create a fluid layout which included proportional font sizes. In the Adaptive Design lesson, the CSS3 supported @media query was introduced. I've used the media query on the responsive design for The Best Game Apps and will be using it for Paper Source. Some examples of @media queries include:

@media (min-width: 655px) and (max-width: 1006px) {
  # styles specific to browser width 655-1006 pixels
}
@media only screen and (device-width: 768px) {
  # styles specific to browser width 768 pixels
}
@media (min-device-width: 320px) and (max-device-width: 655px) {
  # styles specific to browser width 320-655 pixels
}
@media (min-device-width: 450px) and (orientation:landscape) {
  # styles specific to browser width 450 pixels and landscape orientation
}

For each of the above @media queries, specific "break points" are determined to adjust styles as certain elements break as the browser width changes. For example, if elements begin to overlap as the screen narrows, the browser width at which this begins to happen is one break point, and new styles are defined for that width.

The last two levels of the training course covered Responsiveness Adventures and Responsiveness Media. Responsive design also leverages the @media query to design responsively for changing browser widths. One interesting topic covered in the Responsive Media lesson was how Retina Images are addressed on devices where the pixel density is 1.5-2 times regular pixel density. This was a topic I hadn't come across in mobile development. The lesson presented a couple of options for dealing with Retina images, including use of the @media query and picture HTML tag.

Overall, it was a decent course with a good overview. I would recommend it to anyone planning to get involved in mobile development.

Comments

In our last lightning talk of the conference, Brian Dillon and Adam Vollrath shared some of their favorite mobile apps. Brian queried the room to see the phone type divide in the room. Here was our split: 33% - iPhones, 33% - Androids, 33% - unsmart phones.

Brian likes pure simplicity for iPhone apps:

• Dropkick, categorization, syncing, require account creation
• Simplenote: same thing, but for notes

Adam has an Android "because Google owns him":

• Google Googles: Rumored Google technology is integrated into this. Google tries to ad-hoc identify logos, book covers, automatic translation of images, images, QR codes.
• K9 Mail: email client
• Andchat: IRC client
• WiFi Analyzer: provides site survey on network traffic
• SpeedTest

Comments

The Short Story

For those who don't care about why, just how...

1. Create a new Gmail account
2. Setup Mail Fetcher
3. Setup send email from another account;and make it your default
4. Verify you send and receive as your corporate address by default using the web client
5. Setup your mobile
6. From your mobile go to m.google.com/sync and Enable "Send Mail As" for this device (tested only on iOS)
7. Verify you send and receive as your corporate address by default using your mobile client

The Long Story

Here at End Point there are a lot of opinions about email clients. Our hardcore folks like Alpine while for most people Evolution, Thunderbird, or Outlook will do. As a Gmail user since September 2004, I found I needed to figure out how get our corporate email system to work with my preferred client.

My first reaction was to have Gmail act as an IMAP client. I found (as many others had) that Gmail does not support IMAP integration with other accounts. However, Gmail does have a POP email client known as Mail Fetcher. I found that Gmail does support encrypted connections via POP, so use them if your email server supports them. When combined with the HTTPS by default, access to the Gmail web client seemed sufficiently secure.

I now needed to send email not as my Gmail address, but as my End Point address. Google has well documented how to send email from another account. Again encrypted SMTP is supported and is strongly recommended. Also be sure to make your corporate email account the default account so you will always use your corporate email address and not the Gmail address.

After verifying I was sending and receiving email properly, I needed to get my mobile setup. There are a variety of options available for all the mobile platforms. On my iPhone, I had several other accounts already setup and found the native client to be acceptable. I decided I would configure the native iPhone email app to access Gmail, as well as Contacts and Calendar using Google's support for Microsoft's ActiveSync protocol, which Google has licensed and rebranded as Google Sync.

I had used Google Sync for other Exchange accounts at my previous job and found it worked very well. However, there are some known issues, like not being able to accept event invitations recieved via POP. It's worth checking these issues out to see if there are any blockers for you.

After setting up "Google Sync" on my iPhone, I tested again, and found that by default, it would use my Gmail account as my default outgoing email account, despite the setting in the Gmail web client. I needed to use my corporate address here at End Point for sending mail from mobile; I thought I was sunk!

Fortunately, it seems I over looked a section in the Google Sync setup documentation, labeled "Enable Send Mail As feature". This feature solved my problem by having me go to m.google.com/sync from my iOS device and check Enable "Send Mail As" for this device. This would tell Google Sync to use the default outgoing account I had specified in the web client.

One requirement here at End Point which this configuration does not meet is support for PGP encryption/decryption of messages. There is a Chrome plugin that claims to offer support, but as the authors from this post highlight:

There may also be resistance from crypto users ? who already are a security-conscious lot ? to trusting private keys and confidential messages to a set of PGP functions folded inside some JavaScript running inside a browser.

I'd have to say I agree. After following the instructions to install the plugin, I balked when it asked for my private key; I just didn't feel comfortable. Despite this shortfall, most End Point email isn't encrypted end-to-end. However, I can feel good knowing that my "last mile" connection to End Point's servers are encrypted, end-to-end using encrypted POP, SMTP, and HTTPS.

Comments

Took a bit of a break today to get one of those perennial activities out of the way, the great Christmas tree shop. Much hasn't changed about this time honored tradition, don the hats and gloves (well, at least until global warming takes over), pile the family in the car, and hit the ATM to get a bundle of cash to pass "under the table." Not so fast, this is 2011 and Christmas tree lots aren't what they used to be.

Rest assured much of the experience hasn't changed, you still get to wade up and down aisles of freshly cut firs. Trying to select just the right balance of fat vs. thin, tall vs. short, density vs. ornament hanging potential, and there is still some haggling over price (if you are lucky) and the inevitable chainsawing, bundling, and twining to the top of the old station wagon (well, SUV). But today did have a big difference, and one that our e-commerce clients and more so our bricks and mortar clients should be particularly mindful, the "cash box" with the flip up lid and stacks of tens and twenties had been replaced by an iPad with a card reader. This Christmas tree lot has gone high tech, all the way. The iPad totaled the order, and with card reader attached, took my payment, allowed me to sign the screen with a finger, and e-mailed me my receipt.

As much as I appreciated the simplicity and convenience of paying it is a tough argument to make that it is that much better from the consumer side, paying in cash was pretty simple before too, but the secret here is for the vendor. This particular vendor (not exactly Apple) has eight tree lots around town, but what the iPad has done for this little, short lived merchant is provide real time inventory tracking, supply management, resource management, and the underpinnings of customer relationship management. In an instant they are able to see which lots are having the most foot traffic, which lots trend at which times, which are running low on a particular sort of tree, and make adjustments to stock and resourcing accordingly. I will be quite surprised if I don't receive an e-mail from them next year reminding me just where their lot is located, and that it is time to buy the centerpiece of holiday decorations.

Of course next year it will be 2012, and credit card mag strips are really so 2011, so if I need to bring anything other than my cellphone I'll be just a little disappointed. (Did I mention they provide delivery? I guess in case you drive a smart car.)

@Happy_Holidays!

Comments

Many programming library APIs come with several levels of functionality, including the low-level but flexible way, and the high-level and simpler but limited way. I recently came across a textbook case of this in Android's Java audio API, in the MediaPlayer class.

We needed to play one of several custom Ogg Vorbis audio files in the Locate Express Android app to alert the user to various situations.

Getting this going initially was fairly straightforward:

In this simplified version of our PlaySound class we pass in the app resource ID of the sound file, and using the MediaPlayer.create() method is about as simple as can be.

We keep a map of playing sound files so that external events can stop all playing sounds at once in a single call.

We set an OnCompletionListener to clean up after ourselves if the sound plays to its end without interruption.

Everything worked fine. Except for a pesky volume problem in real-world use. MediaPlayer uses Android's default audio stream, which seemed to be STREAM_MUSIC. That plays the audio files fine, but has an interesting consequence during the actual playing: You can't turn the volume down or up because the volume control outside of any specific media-playing contexts affects the STREAM_RING volume, not the one we're playing on. Practically speaking, that's a big problem because if the music stream was turned up all the way and the alert goes off at full volume in a public place, you have no way to turn it down! (Not a hypothetical situation, as you may guess ...)

Switching to STREAM_RING would be the obvious and hopefully simple thing to do, but calling the MediaPlayer.setAudioStreamType() method must be done before the MediaPlayer state machine enters the prepared state, which the MediaPlayer.create() does automatically. The convenience is our undoing!

Switching over to the low-level way of doing things turns out to be a bit of a pain because:

1. There's no interface to pass an Android resource ID to one of the setDataSource() methods. Instead, we have to use a file path, file descriptor, or URI.
2. The easiest of those options seemed to be a URI, and doing a little research, the format comes to light: android.resource://package.name/resource_id
3. We have to handle IOException which wasn't throwable using the higher-level MediaPlayer.create() invocation.

Putting it all together, we end up with:

It's not so hard, but it's not the one-line addition of MediaPlayer.setAudioStreamType() that I expected. This is an example of how the API lacking a MediaPlayer.setDataSource(Context, int) for the resource ID makes a simple change a lot more painful than it really needs to be -- especially since the URI variation could easily be handled behind the scenes by MediaPlayer.

I later took a look at the Android MediaPlayer class source to see how the create() method does its work:

Instead of creating a URI, the authors chose to go the file descriptor route, and they check for exceptions just like I had to. It seems more cumbersome to have to open the file, get the descriptor, and manually call getStartOffset() and getLength() in the call to setDataSource, but perhaps there's some benefit there.

This gap between low-level and high-level interfaces is another small lesson I'll remember both when using and creating APIs.

There's one final unanswered question I had earlier: Was STREAM_MUSIC really the default output stream? Empirically that seemed to be the case, but I didn't see it stated explicitly anywhere in the documentation. To find out for sure we have to delve into the native C++ code that backs MediaPlayer, in libmedia/mediaplayer.cpp, and sure enough, in the constructor the default is set:

mStreamType = AudioSystem::MUSIC;

My experience with Android so far has been that it's well documented, but it's been very nice to be able to read the source and see how the core libraries are implemented when needed.

Comments

I got a Motorola DROID 2 phone a couple of months ago and have assembled here my notes about how it's worked out so far. First, some background.

This is my second Android phone. My first was the Google Ion, basically the same as the HTC Magic. That was running standard Android 1.5 (Cupcake), while the DROID 2 runs Android 2.2 (Froyo) tweaked somewhat by Motorola. I've used several other Android phones belonging to friends and relatives.

Overall I like the Android operating system fairly well. Like everything, it can be improved. It's been advancing at a fairly quick pace. It's mostly free software. Too many phones are locked down and have to be broken into to change the operating system, but Android's still a freer computing environment than most phones have and I hope the situation will improve over time.

I take for granted much of Android's feature set: The excellent system-wide notification bar that many apps hook into and which is always easy to get to. The solid multitasking. Automatic screen adjustment for using the phone in landscape vs. portrait mode. The ability to mount the normal filesystem on the SD card from another computer via USB or by removing the SD card. The freedom to run any applications I want, downloaded from wherever, not just the Android Market.

For one of our clients, I'm currently developing an Android application in Java that uses geolocation, JSON web services, and Urban Airship's AirMail Push for push notifications. So I'm using the phone both as my main mobile phone and as an app developer.

Keyboard

This is the first phone I've had with a full slide-out QWERTY keyboard. I wasn't sure if I'd use it often or just stick with the touchscreen keyboard. So far I use the real keyboard most of the time. But it's nice to be able to use either the hard keyboard or touchscreen keyboard, whichever's more convenient.

I like the keyboard a lot, especially that its rows are offset like a normal keyboard and not a straight aligned grid:

The real keyboard makes using ssh (via the ConnectBot app) on the phone much easier than with the touchscreen keyboard, because the real keyboard doesn't use up any screen real estate.

The biggest annoyance for me has been the keyboard's microphone key which launches the voice commands function. I don't use voice commands, so this has never been what I've wanted and is highly annoying when accidentally pressed.

Third-party alternative touchscreen keyboards for European languages, Hebrew, Arabic, and others work pretty well too.

Touchscreen

I really miss having physical buttons for menu, home, back, and search, as I had on the HTC Magic:

On the DROID 2 they're touchscreen buttons and it's annoying and error-prone to have to look at the phone and carefully press one. Much better to have real buttons for those core functions used by all apps.

However, good riddance to the trackball.

The DROID 2 screen itself is higher resolution, bright, and responds well to touch, swipe, and multitouch, as you'd expect.

Battery

Battery life on the DROID 2 is not great, especially when using GPS heavily. But that's a problem on most phones.

I later got the optional extended-life battery. It isn't much bigger or heavier, and does add a lot more life to the phone. It wouldn't be necessary if I weren't doing heavy GPS & web service interaction with my own Android app under development.

Audio

The DROID 2 has a normal 1/8" stereo headphone jack, which is nice. The HTC Magic needed a special adapter to use normal headphones, which was a pain.

Audio playback is usually fine, though on a couple of occasions it's stuttered, presumably while contending with other apps for CPU. Audio playback when the screen is off doesn't drain the battery much at all.

Calling and Contacts

There have been a few isolated incidents, perhaps involving switching off Bluetooth, where I couldn't turn down the call volume in the middle of the call. That could've been either a generic Android problem, or the Motorola Android build; I'm not sure.

I didn't much like the special Motorola apps that shipped on the phone, but simply not using them has made them no problem.

An exception to that is the Contacts app that integrates with Facebook and Twitter. That's a lot more helpful than I imagined it would be, though when you have many contacts it can sometime slow down on opening an individual contact, when I imagine it tries to fetch the latest details from social networks.

The in-call screen's "Mute" button is small and way too close to the "End call" button:

That's led to me accidentally hanging up during conference calls a couple of times. The stock open source Android call screen is arguably less pretty, but equally-sized buttons makes it easier to use:

Because I'm using Verizon for the first time with this phone, I've been introduced to the sad problem of not being able to use voice and data at the same time on CDMA. I used to laugh about that when I was using AT&T because it seemed silly. Now I find it really does get in the way fairly often.

The normal Skype app doesn't allow using a Bluetooth headset or using the cell network for calls (in the US). The special Verizon Skype app burns voice minutes and won't let you use wifi for calling (in the US). The combination of proprietary software plus controlling phone carriers is bad for users! Because of the limitations I use Skype mostly for text chat on my phone.

GPS

As I mentioned, the GPS uses a lot of battery. But it works well. The GPS on my HTC Magic sometimes took a very long time to get a location fix, but on the DROID 2 it's fast and works very well. Given the location-aware app I'm working on, I've had more opportunity to notice this than I otherwise might have.

There was one funny problem with the GPS, though. Once when the battery got down to 5% or so, the GPS started to report hilariously wrong data to my app, and thus to the web service it reported to. For example, it reported every second that my phone, which was sitting on my nightstand, was traveling at 121 m/s (270 mph), and the point in latitude and longitude moved quickly. This continued even after I'd plugged the phone back in. I haven't seen it happen since, but it was strange.

Useful apps

I don't spend a lot of time trying out new apps, but I've found several to be very useful: K-9 Mail for multiple mail accounts (reviewed yesterday on Ars Technica), Yaaic (an IRC client), 3G Watchdog (bandwidth monitor), TweetsRide (Twitter client), Google Sky Map, and My Tracks. I haven't found a great music player yet, but the built-in Android Music app and Winamp are both fine.

Security

I've long used crypto filesystems on desktop and laptop computers, and feel the lack on Android. A phone needs a solid cryptofs option more than normal computers even, and I hope that'll be available soon.

The end (for now)

I'm probably forgetting lots of things, but this is already longer than I'd expected, so I'll stop now and put any afterthoughts in the comments. In short, I like the phone, but it's hard to avoid looking forward to a brighter future when it comes to mobile devices.

Comments

As I mentioned previously, I recently got a Google Ion phone running Android. I recently began using it as my main mobile phone, and thus needed to finally migrate the contacts from my Nokia 6126 phone to Android.

This is apparently easy to do by first copying all the contacts from the Nokia 6126 internal memory to the SIM card, then moving the SIM card to the Ion and importing the contacts. But that only works if all your contacts fit on the SIM card. If not, they're truncated, and you have to delete many contacts on the Nokia to fit more, which would be a nonreversable move.

Several posts describe ways to do the export and import, such as this one that didn't really apply to my phone, and this one that involves VCF export & import which I didn't see a way to do.

Ultimately I found an article that described Nokia's PC Suite software that I'd never heard of before, which I downloaded on an old Windows machine and used to download the contacts from the phone via Bluetooth, then export to a CSV file and import into Gmail. So far, so good.

Except as this post and another post describe, then all the contact data showed up in a single Notes field, useless for dialing or emailing.

I decided it would be easiest to convert the Notes data into normal phone fields since I already had some contact information in the phone and couldn't find any other reasonable way.

I came up with this Gmail Contacts Notes Converter script to solve the problem. It takes Gmail-exported CSV as input, converts any Notes field data into standard Work or Personal contacts, and outputs CSV that can be re-imported into Gmail. It requires Perl 5.10.0 and I've only tested it on Linux. (It could be modified to work with earlier Perl versions fairly easily.)

Perhaps it will be useful to someone else as well.

Comments

Eugenia released a little web-let called "MobileQuo" the other day, and it caught my eye. I downloaded it and hacked it up and made some changes.

1. This version is more secure - it won't let the content of the feed break your HTML.
2. This version outputs friendly errors. The 1.0 version can fail if your php.ini isn't set up right, or output a blank page if there are certain errors.
3. This version is more portable and doesn't rely on a particular PHP configuration.
4. Most differently, this version can cache the results. This way, each reload won't hammer an RSS feed. Rather, the results can be cached for a perdiod and fed from cache, and then when the cache expires, it reloads the cache.

The source code is here: MobileQuo. Note that you will need to upload a blank WRITABLE file in your MobileQuo directory. Then just use the rest of the code from Eugenia here.

Tags: MobileQuo, Programming, PHP, Eugenia
Comments