Tag Archives: Smartphone

Standard

Posted by

Posted on

August 2, 2013

Posted under

Home Automation, Software Development

Latitude is (almost-)dead – how do I go on?

I’ve espoused the virtues of Latitude as it relates to my Home Automation obsession.  While Google’s Location service once provided a critical means to validate home/way state, it was always critical in the determination of “occupant prediction” – that is, setting up a home-automation posture in anticipation of homeward-bound residents.

It’s no news anymore that Google is shuttering Latitude on August 9th.  It’s something that I predicted on my twitter feed, and I wasn’t alone in feeling that the end was near.

Google attempted to placate the masses by adding a Location feature to Google+, but from a developer perspective it was the retirement of the Latitude API that hurt the most – never mind the giveth/taketh soreness that has come out of Google’s decision to maintain Location History but close it off to 3rd-party developers going forward.

Whatever.  That ship has sailed (or soon will).  The bigger question for me was – how the heck do I keep location-awareness as a staple in my home-automation system?

I was pretty sure that 3rd-party solutions would crop up, ala the Google Reader debacle.  But unlike RSS feeds, there’s something very personal about location data.  Obviously I was (am) placing a large amount of trust in Google to hand over my location data to them, but I was very loathe to do the same for any other entity on the face of the planet.

So I enlisted my go-to man Tasker to fill the void.

Tasker always had a close relationship with Latify on my smartphone.  Tasker would determine which of three Latify profiles were most suitable at any given time.  So it wasn’t a huge stretch to rip out Latify and have Tasker poll location itself, sending that information to my home server so it could Do Something(tm).

And in a nutshell… that’s all there is to it.  With the help of the Tasker App Factory, I’ve produced an .apk that’s been installed on the wifey’s phone and – voila – the home automation system will remain location-aware after August 9.

So that’s part one.  And a very important part it is.

Part two encompasses what to do about sharing location information with friends, whcih is what one traditionally thinks of when they think of Google Latitude.  And in all honesty, I’ve only ever really seen that as valuable in the context of family, where each member probably wants to know where the other is for safety reasons.  To that end I whipped together a page on my intranet which takes Tasker’s reported location data and puts it on a lovely map.  As with all things intranet, this page is accessible from the Internet at large – for authorized users – and works on a laptop as well as it does on a smartphone.  It uses the Google Maps API for all the map-py stuff, AJAX so that locations update dynamically, and it’s generally Very Cool(tm).

So there it is – I’m quite happy with the current solution.  So a heartfelt “Thanks!” to Google for $crewing developers the world over once again.

Standard

Posted by

Posted on

February 2, 2013

Posted under

Digital Lifestyle

Blackberry will be a strong 3rd, and it won’t matter

So the company once known as “Research in Motion” has finally played its hand, and the reviews are mixed.

Personally, I side with Goldman Sachs and I’ve tweeted as much – I truly believe that Blackberry will be a strong 3rd in the smartphone market.  And I’m going to attempt to explain why.

When people think of RIM and its long slide from #1 in its industry, they instinctively think of Nortel – another Canadian tech darling that rode at the top of its industry, but now exists as a small part of a larger patent portfolio.  Management issues aside, both companies found themselves in a position of increased competition and eventually lost much of their perceived relevance.

Yet, I still believe strongly in Blackberry’s prospects – on the mobility side at least.  Part of that is of their own doing, the rest is a function of their industry.

Industry first.  Blackberry’s competition consists of Android, iPhone and Windows Phone.  And while you can argue the finer points of who has executed most impressively with respect to O/S, ecosystem and application offerings, you can’t deny that each company manufacturers a smartphone experience that is starkly different from the others.  Apple’s iOS devices offer a curated, walled garden.  Windows Phone, a less-curated walled garden but a very polarizing user interface with strict design guidelines.  Android represents the wild-west of the smartphone industry; no restrictions, and vendor-specific customizations.

Each platform offers a modern version of a smartphone operating system.  Each platform is supported by an application and media ecosystem – arguably of differing sizes and content quality, but the infrastructure is there.  So on the face of it, you have four competing products and solutions, all of which represent the state of the art in the smartphone space, all of which offer distinctive user experiences.

That being said, Blackberry no longer needs to compete on specifications alone, or price alone.  They’ve differentiated sufficiently on standout, unique features – Blackberry Hub, Blackberry Balance, Blackberry Peek, an interesting take on the homescreen – that they have a compelling offering in BB10.  Note that I’m not saying that these are good features; just different.

That’s the industry that Blackberry is playing in.  And it’s fortunate that they’re not aiming to take on iPhone or Android, because they honestly have no chance of gaining any signficant market share from those competitors.  However I do believe that they stand a very strong chance of stealing market share from Windows Phone – and that comes down to the Blackberry name and legacy.

My evidence is subjective.  iPhone and Android are considered the gold standards when it comes to smartphones and app stores, yet I’m still surprised that I continue to see people clinging to their older Blackberry devices.  Meanwhile, Microsoft has a 1 1/2 year head-start on Blackberry yet they’ve failed to establish themselves as a bona-fide 3rd.

What is it about Blackberry that inspires so much loyalty?

I don’t have the answer, and while I’m under no allusion that the suggestion of loyalty  is enough to bring the masses flocking, I can’t deny that there’s something compelling about the Waterloo-based company’s iconic products.  I never see a Windows Mobile phone in public – why so many BB7 (and older) devices?

But the real question is – is it enough to convert BB7 (and older) users to BB10?  Will that be enough to pull Blackberry out of its slump?  Will users that have eschewed iOS and Android for Windows Phone, instead jump ship again to BB10?

Realistically, the long-term prospects for the company are still questionable.  And unfortunately, it does appear to be a result of the amount of time that it took for RIM to finally get its act together.  While I have no doubt that BB10 can trounce Windows Phone in the smartphone marketplace, the real truth is that Microsoft is quite happy to lose money on Windows Phone if necessary in order to push its presence in that space – with the intention of promoting its vertically-integrated solutions.  Blackberry, meanwhile, has no worthwhile consumer business outside of Blackberry mobile phones – in that respect it’s truly make-or-break on BB10.  Meanwhile, their enterprise business is not the behemoth it once was:

  • It has come under intense competitive pressure due to the BYOD movement
  • It has been scrutinized due to recent service outages
  • It doesn’t have the same brand loyalty that exists in the consumer market

Consider the news of changes to service fees, and it becomes more obvious that Blackberry’s traditional revenue streams are drying up as a result of the industry shifting more towards generic, data-centric service plans.  I imagine they’ll even have an increasingly-tough time hocking their BES software, despite the ability to manage iPhone and Android devices, as any potential customer must realize the obvious conflict of interest: that Blackberry would rather you use their software to manage their devices while they also collect on BES service plans.  Why go with Blackberry’s enterprise software if alternatives exist from vendors with no vested interest in the end-user devices they purport to manage?  Who wants to hitch their wagon to the horse that left them behind the pack for such a long time?

Okay, so why is Blackberry a “buy”?  And why do I agree with Goldman Sachs?

Because the company still has value.  And having brought their consumer side out of the doldrums, they have arguably more value than they did 12 months ago.  They’ll probably see mildy-impressive sales of BB10 devices after launch.  They will inevitably report strong earnings for a quarter or two, perhaps longer.  They’ll beat expectations.  And around the same time they’ll plateau as they struggle to gain more market share.  They may divest Enterprise.  There may be more layoffs.  And their rating will change to “sell”, and investors will make their quick buck.  What of Blackberry after that?  Who Knows(tm).

Which brings us to the second part of this article’s title.  Blackberry will be a strong 3rd, but they’ll either maintain that position as a smaller, more streamlined version of their current selves or – more likely – they will attain that position and then find themselves in the same boat as Palm in the not-too-distant future.  There simply isn’t enough market share to support their continued existence as the RIM we’ve always known.  Even if Apple releases a new iPhone with the same stale iOS, it will only take them one product cycle to rectify that problem.  Microsoft will not go away and will not concede significant market share.  Android will not cede market share, particularly as Google continues to push its software and hardware agenda.

I simply don’t see the version of reality playing out that has Blackberry being a content, distant third in the smartphone space, gaining no significant market share while giving investors a continuing return on their investment.  And that’s a shame, because I truly believe that Blackberry is an innovative company with a compelling legacy and the technical know-how to create good devices.

Ultimately, we’ll see if I’m wrong.  Considering that I’m no expert in this field, I can naively hope that I will be wrong.

Standard

Posted by

Posted on

October 12, 2012

Posted under

Digital Lifestyle, Home Automation

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!

Standard

Posted by

Posted on

July 31, 2012

Posted under

Digital Lifestyle

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 🙂

Standard

Posted by

Posted on

April 19, 2012

Posted under

Digital Lifestyle

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.

Standard

Posted by

Posted on

April 19, 2011

Posted under

Digital Lifestyle

Comments

2 Comments

RIM Blackberry Playbook: a solution to the multi-user conundrum?

Not too long ago I wrote about one of my perceived issues with today’s variety of tablets; that is, the lack of multi-user solutions to such things as native email access and other personal information.

To recap – I don’t want guests to pick up my tablet and have unfettered access to my email.  This may not be an issue with web-based email, where you can make a point of signing off after each email session, but it’s definitely an issue with native apps and their cached credentials.

But a strange thing happened today.  RIM launched the Blackberry Playbook, and it just dawned on me that one of its most-maligned “features” could actually serve to solve the multi-user conundrum.

I’m talking about the Blackberry Bridge method of pairing to your (Blackberry-)smartphone and gaining immediate, seamless access to the email and calendar stored therein.  I use “stored” loosely, since there’s no requirement that the data actually resides on your smartphone, but rather that your smartphone is configured to access that data around the clock.

So there it is – you can sit your tablet on the coffee table and nobody can access your email because they can’t pair it to your smartphone.

Would that feature be enough to reverse a recent tweet I made, decrying the Playbook as an also-ran? (at least, for the short-term – which can easily become a very-long-term in the technology industry)

No – since you won’t see me sporting a Blackberry anytime soon.  And for the larger audience of tablet-yearning consumers, I still say “no” – since I’m not aware of many consumers who share my particular brand of concern.

Now, all hope is not lost.  Some time ago BMW and RIM announced a hook for the iDrive interface allowing you to access text messages and emails on your Blackberry through iDrive.  This interested me – mildly – since I like iDrive and I like technology.  But I don’t love it enough to require my car to link to my text and email messages on my phone, particularly when those two things are at the bottom rung of today’s legions of socially-connected solutions (ie, Twitter, Facebook (ugh), and myriad BBM-competing freeware).

But the point is that it’s within RIM’s ability to extend Blackberry Bridge to non-Blackberry devices – and perhaps there would be more consumers willing to emerge from the dark and confess that they, too, seek some sort of user-partitioning when it comes to personal, private data on their tablets.  Perhaps this could be RIM’s great differentiator re: Playbook vs. iPad and co.

Hrmm.

Standard

Posted by

Posted on

April 1, 2011

Posted under

Digital Lifestyle

Frustrations with Gmail

Not every relationship is all rosy…

(man, I never thought I’d say this, but the on-screen keyboard is actually faster and easier to use than the hardware keyboard!!!)

Anyhow… when I switched to Android I switched my email notifications from SMS to Gmail. A little background:

I run my own personal email server, and while it supports IMAP Push, I’ve never found a client implementation of that protocol that had acceptable battery usage. Regardless, while it’s nice to get your emails immediately and be able to perform some action on them immediately, I’ve always wanted to maintain strict control over which emails generate a “new mail” alert.

There are a number of ways around that triage problem. But then you get into complexities over how you want your mail organized vs. what you want to be notified about… Long story short, I opted to create an out-of-band notification system specifically for the emails I was interested in. This has the added bonus of being extensible, so that I can define times of day that notifications are active, complex state tables that affect notification eligibility, and things like remote awareness.

Anyhow, these out-of-band notifications were traditionally delivered via SMS, and in the WinMo world I had coded a solution whereby a second, specially-formatted SMS would tell Pocket Outlook to sync email. The result was a poor-man’s push solution – perfectly functional, if not the most efficient.

So that’s the background. Since I place great value on the flexibility of this notification system, it was paramount that I could carry over its core intent to my Android smartphone. And I opted to ditch SMS and go with Gmail as the delivery mechanism.

So that’s the background then.

What I’ve been finding, much to my dismay, is that I’ve been missing notifications. In the SMS world it was possible that a notification would get delayed, or lost altogether – but I didn’t expect that from Gmail’s push notification system running on Android 2.2.

After some digging I came to realize that quite a few of these missed notifications were indeed making it to my phone, but they were ending up in the trash and hence no alert was being generated by the Gmail app.

Gosh darnit! Chock it up to Gmail’s “conversatons”, where your emails are grouped (ie., “threaded”) by subject. So if you decide to delete a single message in a conversation (which is something you can’t do in the mobile app – more on that in a minute) then the whole conversation would have a “trash” label applied to it.

And it seems that when a conversation has the trash label applied, the mobile Gmail app removes it from the inbox view. Critically, it won’t alert because the new message is part of a “deleted” conversation.

Now, I haven’t tested this, but it’s possible that things would work differently if you delete a single message in the Gmail web app. But on the Android app no such option exists – it’s the conversation or nothing at all.

Now I have to imagine that this is of the utmost frustration to people who use Gmail (and the Gmail mobile app) as their primary mail client. Fortunately I’m not one of those people, so I’m testing a solution (and it may be that this can apply to the aforementioned group of people too – unless they’ve figured it out already).

Basically, you don’t delete anything.

This is something that Gmail originally trumpeted – that you now had so much space that you’d never to delete an email again. And because you need some way to manage a huge inbox with email that’s never deleted, and people generally pout if they can’t permanentky delete their own email, Google acquiesced and added some trash “label” and other what-not to appease the masses.

But in my case those solutions don’t work. I can get by without deleting because I only care about new emails – or more accurately, new notifications of new emails.

So my solution is not to delete, but also, to only sync 1 day worth of email out of my inbox. That way, the old undeleted stuff will fall out of view in the mobile Gmail app. I’m also syncing “all” starred items, so if something is of interest and I need it to stick around for a few days – like a URL that I’ve emailed myself – then I can star it and it will remain in view.

That’s the theory. I’ve only just now made all the changes, so you’ll need to follow tradition and give me a few days to deal with the (inevitable?) fallout.

Standard

Posted by

Posted on

March 22, 2011

Posted under

Home Automation, Software Development

Comments

2 Comments

More location awareness

Having gotten my feet wet with occupant detection for the home surveillance system, I recently decided to tackle a similar scenario for another application.

This one was bought to the fore courtesy of two seemingly unrelated occurances.  First, was the move to Android from Windows Mobile.  My Touch Pro had a handy menu setup whereby I could easily send automated messages to my home network, and have it Do Things(tm) – notably, whether to notify me on my phone of received work emails.  So far I’ve found no easy solution to do this in Android, save the laborious method of writing and sending the actual emails which command my home network.

But I was willing to let it slide.  Until the second occurence – an apparent increase in the frequency of impromptu meetings at work.  With the need to be away from my desk, but still being at work, I would find myself often penning the emails to my home system telling it to direct work emails to my phone.

The obvious question here is – why not send work emails to my phone all the time?  And the answer should be equally obvious to the (non-existent) masses who read my blog missives; basically, I prefer to exercise a modicum of control over a series of repeating notifications for things that may not be of interest to me at the time.  For personal emails there’s a set of rules that determine what fires a notification and what gets summarized at some point in the future.  For work, I don’t see a point in being notified – by my phone – of a new email if I’m sitting at my desk staring at Outlook.

My excursions into the Bluetooth-powered occupant awareness solution at home have yielded favourable results, and ever since then I’ve sought to automate more tasks.  Many years ago I had written a Win32 program that interfaced with my personal mail server at home, displaying new emails as one-liners in a window that lived in the system tray icon.  The program would determine if I was at my desk based on the screensaver; an active screensaver meant that I was away, and no screensaver meant I was there – much the same way that IM applications determine your away status.  I decided that something similar was required for this new project.

What I ended up with was a combination of a Win32 console application and a WinLogon Notification DLL.  The Win32 console application can poll for the state of the screensaver, but the DLL receives events every time the screensaver starts/stops, or a logon/logoff occurs, or a the workstation is locked/unlocked.  Obviously the DLL has a richer set of conditions available to it than the console app, plus there’s definitely something to be said for event-driven processes vs. polling processes.

But both have their place.  In my implementation, the console app sits on a socket waiting for somebody to connect and tell it that my away state has changed.  This can be the DLL, or it can be a polling thread which is launched by the console app itself – the thread wakes up every x minutes, checks the screensaver, and also pings the main thread with the current state.  The main thread then sends an HTTP request to my home server, which then does all the work required to setup my mail server to notify my phone (or not to notify my phone) when a work email is received.

So long story short – it works.  I’m sure there will be some bugs to work out, but I’m just loving the feeling of having busy little tech bees working behind the scenes, Making Things Happen(tm), without any direction on my part. <g>

Standard

Posted by

Posted on

January 23, 2011

Posted under

Digital Lifestyle

The Ultimate smartphone?

No, I’m not talking about my month-old HTC Desire Z.

I’m thinking of the new (and as yet unreleased) Motorola Atrix 4G.  Besides the dual-core silicon running under the hood – something that seems destined for all new high-end smartphones btw – the big news for the Atrix is the “webtop” app and docking abilities. Said abilities allow your little pocket burner split personalities, shedding its smartphone skin for a laptop visage or home multimedia center duty.

Certainly sounds cool, and brings new weight to the notion of a converged device. But the problem, as I see it, is that you can’t deal with all of these persona at the same time.

Here’s the skinny.

Right now I’m in Starbucks, and I was thinking to myself; “Man, it would be nice if I had my laptop with me.” Then I thought to myself; “Hey, if I had a Moto Atrix I’d be set!”

But I wouldn’t.

For the Atrix to be useful in this situation, I’d need the laptop dock. And if I’m going to carry the dock around with me, then how is that any better or worse than carrying my netbook with me? Without the laptop dock the Atrix is no more useable than my Z.

Wait, it gets worse.

With the laptop dock, and running the webtop app, I can’t do cool things like run a Java-based SSL tunneling client to connect to my home network. And that’s just one example. What about running a development IDE?

Sure, you can run Google Docs and do any number of other cool web-based thingamijigs. But a real laptop the Atrix is not.  It’s somewhere between a netbook and a tablet, in my humble estimation.

Then there’s the multimedia dock. And again, you’ve got to look at it for what it really is. Today’s tech push into your living room is all about net-connectedness. Watch Netflix on your TV. Watch Hulu. Do it fullscreen, in full HD, at 24 to 30 FPS.

Now, you may be able to get close to some of that using the Atrix’s web-browser in webtop mode, but the jury’s still out on fullscreen performance. And that’s crucial.

You can get the fullscreen, full HD, full FPS experience using the media player in webtop mode, but my research leads me to believe that that’s for local content only. No Hulu, no Netflix, no vids from your Windows Home Server or other DLNA-graced devices.

So again – what’s the point?

Don’t get me wrong; the Atrix is a great example of pushing the boundaries when it comes to smartphone design and use. But I fear that the implementation, while abounding in gee-whiziness, doesn’t really give us anything that we can’t already get (better) by carrying the same amount of hardware. Factor in efforts like Firefox’s Weave or Opera’s Link, and the lines between your desktop and your mobile are already being blurred (I’m thinking along the lines of the vaunted Connected Client effort).

I have no doubt that people will drop large dollar bills to get an Atrix and its assorted docks. But I truly wonder if their digital lifestyles will be improved as a result of it.