Does Google really have tablet woes?

There seems to be much discussion concerning Google and its apparent failure in the tablet market.  If I understand, the suggestion is that Google has failed to execute correctly; it simply hasn’t put enough effort into pushing the idea of an Android tablet so much as it has pushed the idea of Android mobile devices. The Nexus 7 is widely regarded as Google’s first (and only) success in the tablet space, despite being preceded by a number of retail devices and one major OS revision.

And it would seem that time isn’t on Google’s side either, what with the impending release of Microsoft’s Windows 8 RT tablets.  Microsoft has been courting the tablet space for a number of years now, and their inability to make deep inroads was as much due to Windows itself as it was to a lackluster consumer demand.

But with Apple proving that tablets are now in demand, and Microsoft having an established user base on the desktop that seems primed to jump into mobile, is Google destined to be a distant third in the tablet space?  Have they gotten it wrong while Apple has run with the crown and Microsoft has finally gotten it right

I think there’s more at play here.  I’ve talked about it here, and others have talked about it too – that is, the question of whether people really need a tablet.  Tablets have – and still do – sit somewhere between the uber-personal smartphone and the uber-productive laptop/desktop.  They’re an interesting media consumption device, and Apple successfully capitalized on its existing media ecosystem by introducing another client that was less personal, less presumptuous and more convenient than the existing alternatives.

And yet we’re seeing a shift in the tablet space.  Like it or not, tablets are approaching the smartphone in size and – crucially – in importance.  They’re becoming more personal.  The shift from 10″ to 7″ has obvious implications re: productivity, and the combination of lower price and smaller screen suddenly makes the device more personal again – probably because it’s more mobile.  Microsoft will likely find success with Windows 8 RT, but it won’t be iPad-level success.  Rather, they’ll have nothing more than a viable slate alternative to a Windows desktop/laptop at best, and a larger version of a Windows Phone 8 smartphone at worst – complete with the market traction that they’ve enjoyed for the past year with Windows Phone 7.

Personally, I think that the relative success of the Kindle Fire and the Nexus 7 are harbingers of the future of consumer tablets.  Curated experiences.  Portals to the ecosystem.  Unquestionable media-consumption devices that can run mobile apps on a larger, more comfortable screen than a smartphone.  And presently, the only real contenders in this space seem to be – yes, Kindle Fire and Nexus 7.  But there’s more to the story.  Google is probably better positioned than any other company at present to lead the next tablet wave.  Why?  Simply, Amazon has no interest in tablets for tablet’s sake.  Google, with the unvieiling of the Play brand, has a competitor to Amazon and they have an app store to compete with Apple.  And… they have a slew of online resources that cater to social and productivity – the latter of which has been Microsoft’s strong suit.

They’re the only company that has a 7″ tablet, a mature media store, a mature app store, and mature cloud-based social and productivity offerings.  If they were to use the 7″ tablet as a curated experience, they could immediately offer the end-user a solution to every usage case there is for a mobile device that’s not a smartphone and doesn’t have a hardware keyboard.

Stop treating Drive/Docs, Gmail, Google+ etc. as mere apps.  They need to be integrated.  Google needs to own the experience.  Sure, a user can still run the Kindle app, but there would be an obvious and clear distinction between an “app” and the ecosystem.  Stop treating the tablet as an app launcher and start treating it as an extension of your brand.

This is something that Google could do without alienating the notion of “openness”.  Again, they’re well-positioned – they have the hardware “Nexus” brand.  Rather than have a Nexus phone and a larger Nexus phone as they do now (ie, the Google Nexus and the Nexus 7), have a Nexus phone with stock Android and a Nexus tablet with “Google Experience” – the curated experience.  And if they want to continue to pursue the 10″ space (which they should), then get serious about tablet apps.  Distinguish them in the Play store, and work with developers to take advantage of the recent app guidelines.

Google still has time to figure this out.  Word is that an iPad Mini will be released soon, but unless Apple changes the staid iOS experience then we’re really only talking about the same old iPad in a smaller form factor.  It will challenge the Kindle Fire and existing Nexus 7 simply because it’s an Apple product.  If Google were to redefine (or evolve) the 7″ tablet space then they could compete with an iPad Mini on the same basis – it would become a bonafied Google product, not just an Android tablet.

What have I been up to? (“Home Automation” edition)

Apologies for the dearth of updates.  The silent masses have been wailing my name incessantly as a result.  I hear you, your screams are defeaning.

(WTF?)

Things have been… different… this year.  That’s about as much as I can say at the moment.  The lack of a stable “all systems OK” comfort zone has basically meant that I’m in maintenance mode more than anything else.  Hence – little in the way of blog updates and other reckless indulgences 🙂

Anyhoo, on to the subject of this particular post.  And this will likely be quick.

You may recall that, to-date, the home automation system consists primarily of surveillance, hvac, and music.  Much hasn’t changed in that respect, but I have been able to make some changes that have increased the reliability, efficiency and usefulness of the system.

Surveillance first.  The most notable change here has been the inclusion of HTML5-compatible transcoded video.  For some time I’ve relied on Flash to allow for remote viewing of archived surveillance video – but having upgraded my phone to Jelly Bean and settled on Chrome as my browser of choice, Flash is no longer an option on that particular device.  To that end, the backend transcodes video into both Flash and x264 formats.  The format available to you is in the browser is determined automagically.

Other small changes have been the regular code cleaning that occurs when you realize that the way you did something a year ago makes absolutely no sense and – there – this makes much more sense.  For now.

The next notable change/improvement actually touches on HVAC as well, so it’s a good segue.  You may recall (but probably don’t) that the automation system is occupant-aware.  When we’re home, certain things happen – like telling the thermostat to target a comfortable temperature, or telling the surviellance system not to pepper me with event notifications.  Previously, occupant detection relied on Bluetooth and its rather short range.  And while I had dreams of hacking unsightly 2.4Ghz antennas onto cheap USB Bluetooth adapters, I woke up recently and decided to use WiFi for the same purpose – which also makes sense since our phones are connected to WiFi whenever we’re home.  Well, Shelly’s Nokia wasn’t always connected, by her loaner phone (my Desire Z) is as is my Galaxy S III.  It was just a matter of course before – no changes in usage or increased battery consumption.

This has simplified matters greatly, in addition to greatly increasing the reliability of the detection code.  The method is actually straightforward – check the wireless access point’s association table to see if particular MAC addresses are connected.  C’est tout.

Also within the spherical roundness of occupant-detection (???) is the news that the system can now get updates from the alarm system.  This is very useful, as it leads to very dependable home/away information that is actually more reliable (in some cases) than the wireless detection method.  The automation system is also configured to simulate motion/audio events on all cameras if the alarm notifies it of a perimeter breach.

Now over to HVAC.

Again – more code cleaning.  I spent a little bit of time thinking I could simplify the “Smart Logic” – the stuff that determines if the system should be off or on and what mode and when to run the fan and blah blah blah – but that turned out to be more painful than just leaving it the way it was so left it I did.  However, the system now has the ability to pre-condition the house if the next program calls for it.  This is one end of a multi-month effort that involved the automated collection of efficiency information.  The system keeps track of how long it takes to heat/cool the house – and currently maintains these statistics seperately for various absolute inside temperatures as well as inside/outside temperature differences – and if the next program calls for more heating or cooling, the system will start doing just that so that we hit the desired temperature just as the next program becomes active.

Admittedly this is not a novel concept.  Some thermostats have been doing this for years.  Something they can’t do is take the efficiency data and determine when to start pre-conditioning the house once it has been determined that occupants are on the way home.  And in the name of openness – my system can’t do this either.  But presently that has more to do with niggling concerns rather than a dearth of information or ability.  Any claims to the contrary would be blasphemy – you’ve been warned.

???

Anyhoo, the reality is that the current pre-conditioning only happens once a day – and perhaps twice a day in the cooling season.  Mostly this is due do the fact that I’ve “flattened” my thermostat’s programs, so that we basically have an overnight setpoint and a not-overnight setpoint (like I talked about here).  I’ve been able to do this because:

  1. the HVAC is much more efficient now than it was before (since we’ve moved)
  2. occupant detection can lower/raise the setpoint appropriately
  3. occupant prediction can target the “home” setpoint before we get home

We tend to keep a “cool” house when we’re asleep, but it absolutely sucks to wake up in the morning to cold floors and cold everything-else-too.  Otherwise, there’s really no need to program the thermostat when the pieces are in place to make more effective decisions automatically.

So ya, that’s HVAC.  Last (and perhaps least?), Music.

Admittedly there hasn’t been much development there.  Not to say that I/we don’t use the system – in fact I used it this past Thanksgiving when we entertained family.  I just haven’t had occassion to spend oodles of time on it.  As it is now, it Just Works(tm).

What I have done, though, is to bring some HTML5 usefulness to the streaming aspect of the system.  As with video in the surviellance system, there has been a browser-embedded solution for some time to stream music via a Flash player.  Got the job done, but again – Flash’s days seem numbered and are basically done and done in the mobile world.

To that end I added HTML5 Audio, and it gets regular use when I’m at work.  Not so much in the car (also known as “not at all in the car”) but that’s because Chrome (and perhaps others) will not allow for background HTML5 audio.  If the screen turns off or the browser is pushed to the background: sayonara streaming audio.  So I still rely on a bonafied SHOUTcast client for streaming in the car, and truthfully I’d love to be able to run the browser-only solution as it requires much less in the way of security concessions.

Aaaaaaand….

….that’s it!

Is that a superphone by your face, or just happy to see me?

I have a troubled history when it comes to any combination involving PDA/smartphone and Shelly.

First it started with a Compaq iPAQ that was left behind in a cab at the St. Thomas port-of-call of a Caribbean cruise.  That particular PDA was a Christmas present from Shelly, and suffice it to say that I was incredibly upset for the remainder of the trip.  Not that I had lost data (I hadn’t, really) – but that I had lost something that Shelly had given to me.  It felt like a betrayal of trust.

Fortunately, the iPAQ made its way back to me.  That’s a feel-good story by itself, but ultimately the PDA was a “marked man” – it unceremoniously slipped from my grasp while I was opening my car trunk.  Yes, the screen cracked, with the digitizer beyond repair.

Next in the story line – the Desire Z.  Shelly didn’t buy this smartphone outright, but she did lend a financial assist.  And yes, it too suffered an ignominious fate – dropped, again, in close proximity to my car.  Dropped, again, while my hands were entirely overburdened.

And while I did manage to stick a foot out and deflect the phone before it landed at a perpendicular angle, the resultant slide left a fair number of gouges and scratches in the body.  With the phone face down I hoped for the best – I picked it up, and observed a crack at the top-right.  The digitizer was saved, and the crack didn’t obstruct anything too badly.  But there it was – two high-tech devices, two assists from Shelly, two undeserving ends.

I suppose it’s good that the Desire Z is still functional – blemished though it may be.   But I can’t understand how the Palm Pilot (that preceded the Compaq iPAQ) and the HP iPAQ (that followed the Compaq iPAQ) as well as the HTC TyTN (that followed the HP iPAQ) all managed to survive without incident.

At some point I believe that Shelly decided she was done buying me high-tech devices.  That particular decision came before the Desire Z, and apparently she relented to my obvious technology bias as she subsequently offered to subsidize the Desire Z’s full face value.  But I refused; I agreed with the spirit of her initial resolve, in part because it was based on the realization that consumer technology is a fickle beast, where relentless technological advancements cause devices to be put to pasture well in advance of their time.  I did not want her to continue to invest in such a selfish ideal.

That may have been fortuitous on my part, because I believe that around the time I dropped the Desire Z I was also starting to look around heavily for the Next Thing(tm).  Not necessarily the next phone, but rather a refreshed user experience.  Back in the WinMo/TyTN world the next thing was the move from stock-WM5 to WM5-with-customizations; fTouchSL and a different launcher, if memory serves.  While I was content initially to run the HTC Sense version of Android 2.2 on the Z, I came to realize that I was two major versions behind the current trend.  I felt nothing compelling me to upgrade to 2.3, but 3.0 had come and gone, and 4.0 was the talk of the day.  Fortunately many applications still listed 2.2 as the minimum required Android version, but when Google itself is pushing a 4.0 release you can bet that they’re also pushing the envelope when it comes to the 1st-party apps.  The likes of Gmail, Maps, etc all worked fine on 2.2, but the experience was designed to be something else entirely with 4.0 afoot – both in appearance and functionality.

Additionally, the bru-ha-ha over the HTC One X flagship’s sub-par multitasking performance caused me to sour on the sub-par multitasking performance that my own Z had always exhibited.  It was becoming noticeable, and it was noticeably negative – a harbinger of change, that is.

So I had been researching Cyanogen-based ROMs for the Z prior to the fateful drop, and the day after the drop I proceeded to load a CM9 derivative.  Never looked back, despite some noticeable lag.

It was just too much of a sweet upgrade going from Froyo (2.2) to Ice Cream Sandwich (4.0.x)  I was definitely feeling Google’s design philosophy, and even after playing with the latest HTC and Samsung flagship phones in the store I still felt that “stock” ICS was the way to go.  At one point in time I felt that Sense was where it was at, but the advances that Google put forth in ICS quickly erased that (unhealthy) dependency.

So there it was that I was digging ICS on the Z.  Well, I was digging ICS anyway.  Either it was the beta state of the ROM or the limitations of the Z’s hardware, but the lag was killing me.  And for whatever reason, the screen was starting to feel cramped…?!?  So I started looking at a hardware upgrade to go along with that software.

Understand that – thankfully – no impulse decisions were made.  I had a carrier hardware upgrade waiting in the wings for about 2 years so I figured I might as well put it to good use and get the latest and greatest for a really good price.  Except that each of the latest and greatest somehow had undesirable qualities of their own.

The HTC One X was a looker, no doubt, but having done my fair share of battery pulls – and even having replaced my battery for one with more capacity – I couldn’t stomach the non-replaceable battery.  Lack of expandable memory was also a minus, though one I could stomach but would rather not (in the name of disaster recovery).  On the software side I discovered that Sense 4.0 wasn’t that bad, really, but there was that awful multitasking.  Would it get sorted?

The Samsung Galaxy S III surely would continue the GSII’s reign on top of the Android heap, but TouchWiz almost made me throw up.  I mean… I was speechless.  Ya, the phone itself had replaceable everything and a nice camera and screen (the latter not as good as the One X though) but the s/w was a no-go.

That left the Galaxy Nexus – which had the benefit of being a Google-supported device.  Except that the Rogers version was behind the times by three minor Android versions (4.0.1 vs. 4.0.4) and there was talk of signal drop issues in 4.0.4???

Ultimately, my time with the CM9-derived Andromadus Audacity ROM lead me to decide that, regardless of the hardware, I would likely be running a CM ROM in the future.  It had the best of both worlds – a stock Android feel, subtle but welcome improvements, and relentless developer support across many devices.  And once I came to that realization, the upgrade decision came down to hardware alone.

But first I sat on the decision for a while.  Because… Jelly Bean (4.1) came out.  And while Google provided an official version for the Nexus, I was still of the mind that CM10 would be the ROM for me.  But CM10 didn’t exist yet.

That gave me time to decide if I would wait for a fall Nexus device or go with the current Nexus.  Thing is, the current Nexus wasn’t the best hardware that was currently available.  It was eclipsed by the One X and the GS3.  The One X wasn’t a contender, which left the GS3.  So really it came down to: GS3 or fall Nexus?

In the smartphone world, it’s always the case that there will be something newer and better within months.  Does that mean that you should wait perpetually?  A consequence of wedding oneself to a CyanogenMod ROM is that there’s a delay between Google’s official unveiling of a major Android release and the subsequent CM release.  This is a hardware-independent fact.  At which point, the focus shifts from getting the best hardware to getting the best CM release.

And it just so happened that CM10 preview builds got to the point that: 1) they were stable, and (2) they showed an obvious commitment on the part of the Cyanogen team to support the hardware. Tipping point was reached – I sprung for a Samsung Galaxy S III.

So yes, I went from a 3.7″ QWERTY slider with a trackpad to a 4.8″ slate with a single physical button.  And that last point is noteworthy, because I absolutely adored the trackpad-wake feature of the Z, which made it a cinch to turn on the screen when the phone is docked in its vehicle mount.  In fact, this is one of the features that made the GS3 win out over the Nexus (in addition to the faster hardware, bigger battery, better camera and 2x the RAM).  Might a quad-core Nexus come out in the fall?  Sure.  Is the GS3 mighty fast with its dual-core?  Yes.  Does Project Butter make insane core count a non-issue to anybody but the hardcore gamer?  YES.

So ya, I’m rocking a “Pebble Blue” SGSIII.  What do I have to say about my previous tirades (sic) re: device longevity?  Admittedly, dropping my Z didn’t help.  And buying into 2.2 may have been the wrong decision too, as I believe it was already a 6-month old OS at the time.  But you know, I have no doubt that a 4.1 version of Andromadus will be available for the Z (there’s a working CM10-build out right now) however…

…as I said earlier, the screen was starting to feel cramped.  And, believe it or not, I used the hardware keyboard no more than 10 times in the 1.5 years of actively using the phone.  That meant that I was carrying around the size and weight of the keyboard (and its perpetual on-the-verge-of-opening state) for no good reason.  I realized early on that my primary reason for having a hardware keyboard – that is, text entry in remote desktop sessions – was a non-starter.  Pinch-to-zoom and finger-panning make a virtual keyboard work very well during remote desktop sessions.

Which means that, like the Touch Pro before it (and the TyTN before that), it was a hardware design decision – and an iconic one at that (vs. something like processor speed, which isn’t distinctive) – that forced the desire to move on.

I’ve attempted to future-proof this purchase (in as much as one can when talking about smartphones) by electing for the GS3’s 2GB of RAM (vs. industry-standard 1GB), large screen and relative newness (what, 1 month old?).  A HUP was critical, as I absolutely would not fork over full price for the “latest” model in fear of feeling that I’m just following a trend with hard-earned bucks.  But a subsidized phone?  Ya, I’ll do that every 5 years or so 🙂

Move over Latitude (client), enter Latify

I had a recent issue involving Latitude and my home automation “somebody-is-coming-home” logic.  What hurt the most is that, around the same time, I had made some significant changes to my Latitude polling code which would increase the polling frequency if it was determined that a Latitude user was in “rapid motion”.  I’ll refrain from posting details re: the exact definition of that term, but suffice it to say that the intent was to collect more information when a user is moving around so that we could determine their enroute in a more expedient manner.

So while I got that code working, I was subsequently stymied by an apparent inability to receive updates from the Latitude API at anything faster than 1 update per 10 minutes.  Given that my code needs at least 3 data points before it can make an “enroute” determination, the apparent limitation meant that the code wouldn’t know you were enroute until at least 30 minutes had passed in your current transit session.

Bummer.

So as evidenced in the link above, I took to the Latitude Google Group and after some time it was decided that the issue wasn’t with my code or the Latitude API, but rather the Latitude client on my phone.  Apparently some client update along the way had changed the upload behaviour, such the client was now batching updates.  In other words, the phone would hold on to a set of updates and upload them in one shot.  Which is great for battery saving, but not so great for real-time location reporting.

I heard about this Latify character amid other general rumblings about Latitude being battery hog.  I never did pay much attention to the third-party contender as I hadn’t noticed any particularly heinous battery drain myself with the official client.  But given this most recent development, I had no choice but to look elsewhere.

I’m either hugely  glad that I did or vaguely glad that I did.

In concert with Tasker, the premium version of Latify has been put to use on my handset to switch between rapid GPS-based updates (when driving) to less frequent cell/wifi-based updates otherwise.  I’ve created a Tasker profile that attempts to determine when the phone is moving (by determing if the connected cell tower has changed) and will switch Latify from a 1hr update period to a 5min update period if motion is occurring.

In general it seems to work well, and on some days I notice incredible battery prosperity.  If this is indeed due to Latify and my usage patterns, then I am indeed hugely glad for the Latify/Tasker combination.  If battery usage is not part of the equation, then I’m vaguely glad – yes, I’ve got more control over my Latitude updates and I seem able to track my movements at 5-min intervals if, say, the wifey is driving me around; but I’m also curiously dismayed by some of Tasker’s quirks and the hack-ish way I’m having to deduce cell-tower based movement.

Still bittersweet

This is actually old news, but one night I was given the kid-equivalent of a tongue lashing for committing what has become something of a cardinal sin.

Okay, so Andrew didn’t put the boots to me and cause me to tear up from a withering verbal assault, but he did adorn the house with his special breed of mannish wailing when I put him to sleep one night and turned on his mobile.

Now understand that his mobile has long had its moveable features removed, and given that he’s so comfortable in his “big bed”, the mobile is nothing more than a music player sitting on a chair in one corner of his room. And for some time, he seemed to enjoy requesting the “red” music before eventually falling asleep.

But not on that one night, and boy have I learned my lesson since. Apparently I had misstepped by turning on his music – he wanted no part of it.

And ever since, when asked, he’s adamant that he does not want the music to play when he lays his head on his pillow at night.

Okay, so I could accept that without much in the way of a teary eye. Certainly it was nothing more than a preference.

But somewhere along the line he also decided that he no longer wanted any of his daily comforts to accompany him to sleepy land. Not his various cars, not his teddy bears. On some nights they are even banished from taking up residence beside his bed, on the floor.

Which makes me wonder – what is he doing to fall asleep?

Certainly it’s great that he falls asleep every night with no fuss, but his refusal to do so with any childish aid of any sort? Admirable, but again, a little bittersweet. What will be the next youthful indulgence to get the axe in this little man’s quest to become something more?

Server upgrade? [update: 2012-02-17]

Ah, the life of a consummate hardware tinkerer.

Blog devotees will know that my “Home” server is the guy whose job is to run the house – in-so-much as the house can be run by a computer, that is.  More commonly noted in these journals as “Home Automation”, the Home server is primarily responsible for surveillance, HVAC, Whole Home Audio, TV show transcoding, and a host of other support services.

Said server has had a long history of service, although the only original parts are probably the case, power supply, and some hard drives(!).  And after just over 3 years with its current hardware configuration, it would seem that a significant shift is about to occur.

So significant, in fact, that I’ve had to come up with a new “P”-prefixed name for said server.  Yes, *all* of my computers are named with a “P” as the first character…

Anyhoo, this started about a week ago when I noticed some “previous system shutdown was unexpected” messages in the event log.  And some quick investigating led me to conclude that hardware was – again – the cause of the problem.

I was left with three choices:

  1. Retire the Home server and move all functionality to the remaining (“Internet”) server.
  2. Troubleshoot the problem and replace the failing component.
  3. Start from scratch with a new server

My “best practices” principles ruled out option #1.  And with time at a premium these days – and given that the Home server is based on technology that’s over a decade old – I decided to take the $$$ plunge and build a new system utilizing modern(ish) technologies.  Some things I’ve wanted for some time – like RAID1 drive redundancy – and other things I’ve had no experience with and wanted to have at least some passing familiarity (like SATA… yes, *all* of my drives are PATA!!!)

I also decided that I wanted to go with an Intel motherboard and processor solution.  In all of my professional and personal years dealing with computer hardware, I can’t recall one time that an Intel product has failed (especially motherboards).  I may be unique in this experience, but I decided to pay the extra money and go Genuine Intel.

Unfortunately I may have been too presumptuous during my decision-making process, as I opted for any old Intel board that had the hardware features I wanted (among them, 3 PCI slots) and didn’t spend too much time worrying about the “***DESKTOP***” branding that graced the packaging and product designation.  So it was that I came home, spent an untold amount of time putting the hardware together, and found myself unable to install my server software due to driver issues – all of which were arbitrary on Intel’s part, wanting their DESKTOP boards to have no business running SERVER software.

So it took a few nights and early mornings to finally get Windows Server 2003 installed and recognizing the DZ68DB board’s many features.  Thanks to Google and these pages for the invaluable assistance.

That was the first hurdle, and I knew that the software setup would be a multi-day affair.  Unfortunately I’ve run into another (temporary) roadblock, which is that the act of promoting this Windows 2003 Server to a Domain Controller has been foiled by Exchange 2000-related issues in my Windows 2000 AD schema.  Argh.  And while I value the learning experience, at this point I just want to get to the point where I can start moving services to this new “Home” server from the old “Home” server.  I’m really looking forward to the significant increase in speed that this server should bring, particularly with respect to show transcoding and database operations.

So I’ll update this post when I have more to report.

[update 2012-02-17]

So I’ve surmounted most (all?) of my AD-related issues, and the server is chugging along quite happily.  Girder gave me some issues – particularly in the area of launching processes – but this was resolved by changing the window parameter from “hide” to “show”.  Had to do it for both the open process and kill process (this is more a note to myself for future reference…)  I was also pulling my hair out over mixer issues until it dawned on me that the references to the hardware on the old server were probably causing Girder to get mired in some thick mud.

Anyhow I can say that services are smoking fast; DivX transcoding is limited by the speed of the network transfer from the PVR machine (which is currently the Internet server but will soon become the Home server).  The responsiveness of the whole-home audio interface is likewise much improved, as is the whole set of intranet pages (particularly noticeable when looking at archived HVAC and surveillance data).

I’m still in the process of moving my network-stored movie images from a local disk on the old Home server to a local disk on the new server.  This task’s painfulness is exacerbated by the insistence of the old server to spontaneously reboot whenever I try to initiate such a file transfer over the network – which certainly would seem to mimic the original problem which started this whole process in the first place.  The question still remains as to why this causes a server reboot.

Anyhow, I’m using the external 1TB drive (thanks Mark!) to sneaker-net the files from the old server.  However, we’re talking about something like 40GB of data (or is it 80GB?), which is very slow to transfer using the old server’s USB 1.1 ports…

Other than that, I’ve finally got full data redundancy thanks to Second Copy (thanks Daniel!) and that very same 1TB drive.  NTBackup is backing up the system and data drives on both servers, saving said backups to the external drive; and Second Copy is doing one-way replication to the external drive of all media on a nightly basis.  To Centered Systems – the cheque will soon be in the mail 🙂

Making tech work for me (smartphone automation with Tasker)

I’ve made a few mentions of my fondness for MortScript during my time in the Windows Mobile world.  It was most useful when it came time to automate in-car tasks – resolve Bluetooth connectivity drops, dis/connect A2DP, keep the screen alive.  Other things were more general in nature, like emulating a Bluetooth “timed discoverable” feature and restoring the Normal ring profile after Silent had been active for a period of time.

All useful additions, features or fixes.  And I’m sure that I’ve given a shout-out to Tasker as my go-to-guy for giving me the same sort of hacking pleasure on Android.

Fortunately, my Tasker experience to-date has been more about adding functionality than fixing O/S problems.  And I’ve extended the functions I mentioned in this post to the point that I’m tickled pink (not literally, of course) over the added convenience that has been bestowed on my Android phone.

The aforementioned post has a section aptly named “Tasker” that basically talked about things which happen automagically when the phone is in the car.  Basically, when the car’s Bluetooth is detected, the phone can be in one of two states which we’ll call “Car In” and “Car Docked”.  It’s the latter which is of most interest, and it becomes active – as mentioned in that previous post – when external power is connected.

(it would be possible to sense the presence of an actual “car mode” cradle, but the Desire Z doesn’t have the requisite hardware.  I find it acceptable to consider the phone in a “car docked” mode if the car’s bluetooth is detected and the phone is plugged in – which pretty much means that the phone is sitting in a cradle)

Gone are the days of auto-launching Google Navigation – more on that later.  I definitely wanted a 3-foot user interface to come up when the phone entered Car Docked mode, but Google chose to deny access to the actual Car Home app on my phone.  So, I relied on Vlingo‘s “InCar” feature to emulate the Car Home app.  And this was… acceptable.  Vlingo’s usefulness as a Siri-like assistant was questionable, but I was digging the convenience of the InCar interface so I told Tasker to fire up this interface when Car Docked mode became active.  From there, I could launch Navigation or Maps or – if Vlingo was cooperative and background noise was low enough – speak a command to open any app of my choosing.

Vlingo’s usefulness fell significantly once it stopped being able to hear anything I tried to yell at it.  I think this happened shortly after I rooted the phone, but no matter; it was the kick in the pants that I needed to convince me that it was time to rid myself of this dysfunctional relationship with Vlingo.  Away it went.

It was subsequently replaced with a pure-Tasker solution, in which I could hold down the search key and up would pop a custom menu containing all of my useful in-car shortcuts.  So there was a link to Navigation, Opera Mobile, XiiaLive for streaming audio, and some other useful apps.  And this was… acceptable… but it was just wasn’t integrated enough.  What I really wanted was to hit the home key and have a real 3-ft interface appear.  What I really wanted was Google’s Car Home app.

My decision to root the phone was actually the ticket I needed to get Car Home installed, as it involves booting into recovery and installing a signed package file containing Car Home.  Anyhow, that was done, and so we arrive at the point where I am today – getting in the car and putting the phone in its cradle and connecting power automagically brings up the 3-ft interface of the Car Home app.

It may seem to you like I’ve spent a lot of time to get something going that’s trivial.  And on the face of it I’d agree with that perception.  But you have to keep in mind the how and why of it all.

The “how”, in this case, is Tasker.  And the “why”, in this case, is Tasker’s flexibility and power.  Car Home has the ability to launch itself whenever it detects a certain Bluetooth device – ie, the car – and that’s great.  But I want more to happen when my phone is “docked” in the car.  And this is why Tasker is important, and why I’d rather have Tasker launch Car Home at the appropriate time.  In actual fact, Tasker sets the phone’s “Car Mode” setting to true, which is a global setting which may have other (desired) ramifications.

Now… recall that I mentioned Tasker’s previous duty of starting Google Navigation whenever the Car Docked state became active.  I could tell you that it’s nice to have Navigation up when you’re driving, and to some extent that’s true, but my car has navigation built-in – and that screen is 2x the size of my phone’s screen.  I could tell you that Google Navigation shows semi-reliable traffic information, and that’s true too, but I don’t need that info for the entire drive.  Plus, I can always get there with two taps: one tap on the Home button to bring up the Car Home launcher, one tap on the Navigation icon to bring up navigation.

So why did I ever have Tasker launch Navigation as soon as the phone was docked in the car?

One word: Latitude.  Click the link.  Honestly, do it.  Then you’ll know why Latitude is important for me.  With Navigation active, GPS is also active, and when GPS is active the phone is aware of movement with more precision than it is when using WiFi and/or cell towers.

So Navigation was a useful means to a GPS-enabled end.  And while I still find Navigation useful, it’s really the Latitude updates that I wanted to occur while the phone is docked in the car.

Most obvious solution: tell Tasker to turn on GPS, and Bob’s your uncle.  Well, not so fast – even if Tasker can just turn on the GPS module and leave it turned on (which I doubt), you get into trouble with the opposite action: turning GPS off.  Suppose somebody is trying to use GPS when Tasker turns it off?

So my solution is somewhat more creative.  And this goes back to the “how” and “why” of using Tasker at all when Car Home seems suited to fulfilling your 3ft-interface needs.

Something else that I’ve had Tasker do is adjust my phone’s brightness dynamically.  And yes, the phone has an auto-brightness setting, but believe me when I say that the lowest brightness setting is still way too bright when you’re driving in darkness.  When the phone is docked, Tasker runs a task that loops and constantly measures the light-sensor’s reported ambient light level.  Then, in conjunction with the Screen Filter plugin, it is able to dim the screen to levels that would be un-achievable otherwise.  It can even take sunset/sunrise times into account, as those tend to be the trickiest times of day when it comes to suitable lighting.  This logic recently underwent a rewrite, and it’s not as straightforward as following the sensor’s (somewhat finicky and fluctuating) reported level.

Anyhow, this task is great because it’s an active loop that I can use to call other tasks.  And the lastest task is… one which attempts to get a GPS fix.  So every 60 seconds or so, Tasker asks the Android system for the most accurate location info possible.  Android dutifully obliges by determing which location services are permitted – GPS and/or “net” – and uses the most accurate one to get the requested information.  The beauty here is that it’s now Android which is determining what needs to be done to get the location data.  If Navigation is active and using GPS, then the location data is known and returned to Tasker.  Okay, Tasker doesn’t actually do anything with that information.  BUT… if GPS is not active, then Android will turn on GPS, get a fix, return the location data to Tasker, then turn off GPS if nobody else is using it.  Which completely solves Tasker’s  problem of determining when/if GPS should be active.

This is good news, because Latitude seems to be hooked into a system event notification that goes something like this: “if the phone determines that its location has changed, let me know.”  Well, because Tasker is asking for updated location info every minute, and its asking for the most accurate location info available, it’s necessarily the case that Latitude will get notified every minute if the phone has moved.  Meaning…

…all of my Latitude-dependent services will have precise, up-to-date location info.

I know what you’re thinking – what happens if I’m moving around and I’m not driving?  This is entirely possible.  And the short-answer is – nothing.  We’ll get the same old imprecise Latitude info and it may not be terribly relevant either.  BUT… and this is important… everything I’ve done re: Tasker and the “Car Docked” mode means that the special use case of having the phone docked in the car will result in precise, relevant Latitude info.  Period.  Even if I only drive one day a week, it’s now the case that the driving scenario is handled in a seamless, extensible, straightforward manner.  It requires no special user intervention that wouldn’t occur otherwise.  It doesn’t even require that Navigation is active.

And that’s the design philosophy that I aim for.  Look at a problem, find an elegant and workable solution.  Refine the solution.  And hopefully, extend the solution to resolve related problems.  If you can extend the solution, then you know you’ve come up with a solid foundation or approach.

That’s why I’m tickled pink.  I love to solve worthwhile problems 🙂

Problems loading webpages with your HP TouchPad? Try this fix

I mentioned it in a previous post, now I’m making a separate post to satisfy any Googlers out there.

Ever since disabling TCP Window Scaling on my TouchPad, I’ve been able to enjoy problem-free web browsing – a far cry from the hit-or-miss affair I endured previously.

I won’t get into the nuances of why setting a scaling factor of 0 may resolve your problem, but suffice it to say that it comes down to your client believing that certain TCP options are set while the server does not. Blame your router – that’s where the problem lies, but in my case I also found my smartphone’s WiFi hotspot to suffer from the same problem.

So in the name of mobility, I offer a fix on the TouchPad itself. Hopefully it works as well for you as it has for me.

Continue reading