Passing An Account Object Around

Here’s a scenario I have both in Glassboard and the current client project I am working on.

Everything you do in the app requires that you have an account to authenticate. You’re hit with a brick wall when you launch the app asking you to sign in. Otherwise, the app is 1 star, useless to me.

In a variety of different view controllers I need to reference the user’s account information to be able to display information. A few scenarios:

  • The compose screen needs to know which account you are posting from and whether you have enabled or disabled location.
  • A profile screen needs your personal information such as the user name, password and avatar.
  • An upsell screen needs to know which account is getting upgraded.

Right now I am storing a strongly held GBAccount object in my app delegate controller. I then have a weakly held GBAccount object on each of my view controllers. that I pass whenever I instantiate a new view controller.

This works, but it feels kind of cheesy having to set an account object for each of my view controllers so that it knows about it. On the other hand, referencing [[UIApplication sharedApplication] delegate] account] feels like a mortal sin.

How would you implement this?

Update: I posted this to Twitter and the responses were great.

General consensus seems to have a currentAccount singleton on GBAccount that I can then reference globally. It won’t help if I ever need to support multiple accounts, but in both scenarios (Glassboard and client gig) that shouldn’t ever be a requirement, so no sense in implementing something more complex for an unlikely scenario.

Wearing Android

I’m a gadget addict. I can’t help it. I have two rules when it comes to buying some new tech gadget:

  1. Does it seem like a cool idea?
  2. Is it relatively inexpensive that I won’t be too mad if it totally sucks.

Passing those two tests, a $229 watch that runs Android was a pretty easy decision to pick up and see what Google envisions as the future of my wrist.

I’m naturally fascinated by this area having backed a few different Kickstarter projects (of which only the Pebble has actually shipped). I wear my orange Pebble a few days a year, but ultimately its utility leaves much to be desired. Do I really need to see what song is playing on my wrist? Do I care that you just replied to my tweet? Not really.

Android Wear doesn’t do much to change that scenario for me, but it takes it to another level that shows at least some of where this stuff should theoretically go.

The key feature of my LG G Watch is being able to get notifications on my wrist rather than having to constantly futz with my Nexus 5. From there, I can do a few different actions.

  • My music app shows me the song and band playing (with album art). I can then pause or play the music.
  • Twitter lets me see my replies and even favorite or retweet them.
  • The Hangouts app, which I use both for internet messaging and SMS lets me also reply to messages by talking to my wrist.

And that’s where we get to the utility that I think is the nut of all this wrist candy.

Sensors, Not Notifications

Being able to tell my phone to do something by speaking commands at it has been a neat parlor trick since Siri and Google Now were introduced. The watch makes it easier to do that since you always have a microphone an arms length away. I rarely use Siri or Google Now to talk to my phone. It’s awkward and I feel almost as sleezy as the business guy who is talking loudly into his Bluetooth.

Having said that, there are some small conveniences such as “Set a Timer for 10 minutes” that I’ll occassionally do because it is truly faster than opening the Clock app, navigating to the right pain, and jimmying a bunch of different buttons.

Enough utility to make me want to always wear the unsexiest watch hardware ever made? Not really.

What does get me excited is having a ridiculous amount of sensors broadcasting and gathering data on me without having to always carry my phone around with me.

I wear a Fitbit to track my daily activity. I don’t have any sort of goals beyond wanting to get somewhere between 12,000 and 15,000 steps a day to help remind myself that I’m not as big of a sloth as I sometimes think.

Android Wear has a step counter on it.

When I run or bike, I use Strava to track my mileage and paths so that I can measure my improvement over a period of time. When I’m actually running though, carrying my phone is a bit of a chore.

A wearable with a tiny GPS sensor? Sign me up.

I’ve had little luck with TouchID working. I’m convinced my thumb prints are so unreadable that I can commit crimes without worry of being caught. One of the new features in Android L is the ability to unlock your phone without any sort of passcode or fingerprint or whatever just by wearing the Android Wear watch. If the phone and watch are connected together, it assumes you are the one actually messing with the phone.

Sign me up for this.

Now extend that so that I can open my coworking office’s door without an HID card, adjust my Nest at home when I pull into the drive way, or start/stop my music when I leave the house.

There Is No Screen

To do pretty much all of the things I actually want to do with this thing on my wrist, I don’t need a big honking screen. I just need a lot of sensors. The same sensors that are in your phone, just crammed into a tiny bracelet.

I want to believe this is where Apple will take their wearables project, especially given how ‘connected’ these platforms seem to become with the addition of Auto and TV to their arsenal.

Of course, no one outside of a select few in Cupertino know what Apple has in mind, but if they want me to get truly excited about the future of wearables, lose the screen. Give me the sensors.

CocoaRadio Sponsorship Openings

I’ve been remiss in announcing that I’ve opened up the next batch of CocoaRadio sponsorship slots from now through September. We’ve got slots open starting with next week’s show all the way through Episode 20.

If you’re interested in reaching a large, targeted audience of OS X and iOS developers, get in touch and I’ll help you reach a new audience of users for your product.

Glassboard Update - June 2014

Yes, I know we are eight days into July, but most of this is related to last month. I just got behind on writing.

Anyway, what’s been going on with Glassboard?

The Web

I pushed out a new version of the Glassboard web site right before WWDC. I worked with my pal Tory Hobson on it, and I’m really happy with how it turned out.

Other than that, most everything was under the hood. I’ve been working on converting the backend to use WebAPI and be asynchronous where possible. The new push notification architecture is the first to take advantage of both of these features. I’m going to write more about this once I have the iOS app update out (more down below).

Android

I’ve been carrying my Nexus 5 as my primary phone the last month or so, which has made me aware of how out of date the Android app was starting to look. Seeing the Android L release at I/O only helped solidify that.

I spent a few nights in June pushing out some fixes:

  • Added pull to refresh to the boards view.
  • Updated default font sizes, much to the chagrin of Play Store reviewers.
  • Rounded user avatars in board timelines. Finally.
  • Redesigned the action bar to look more KitKat than Honeycomb.
  • Set the minimum required SDK to 15 (Android 4.0.3+).

The next thing I want to tackle is redoing the drawer to use Android’s standard DrawerLayout. I’m handling all the design and development on Android, which is new for me. I’m an amateur designer at best, but I’m trying to save a few pennies, and there aren’t really that many people who specialize in Android available for design it seems.

iOS

I tried pretty hard to get a major update for Glassboard out before WWDC, but time got the best of me. It’s been nearly done now for the last few weeks. I just need to find the time to work on it outside of the full-time contract I’m working this month. Hopefully I can submit it this weekend. We’ll see.

The iOS app is focused on cleaning up a lot of the user expereince. I’m calling it a 3.1, but I’ve tweaked nearly every aspect of the app. The other thing I added is in-app subscriptions for monthly and yearly premium sales. We’ll see if Apple approves that. I think they should, but I’ve been wrong more than once about the App Store review process.

Tweaking Premium

A few months ago I got an email from a known developer who was filing a bug report with me on my business model ‘being broken’. Said developer was amazed he never hit any sort of limits to pay for the product

Story of my life.

The first half of this year was centered around fixing and stabilizing the apps and the under the hood stuff. Now, I’m able to start focusing on the actual future of Glassboard.

The first part of that is going to be fixing the business model.

In the short term, I’ve set the Glassboard iOS app to be 99 cents on the iOS App Store. I did this to see how many complained (yep!) and how it would impact downloads. My download numbers dropped well over 70%, but each one of those users is at least invested in the product right now.

I am leaning towards keeping this for the next few months mostly to slow growth. I’ve been bleeding cash on this thing for months now, and bringing on more free users isn’t going to fix that. Google’s Play Store unfortunately doesn’t let me convert a free app to paid without doing a new SKU, so I am deciding what to do for that.

As for Premium, the next step is to make email notifications a premium-only feature. My Sendgrid bill accounts for nearly half of my monthly costs for running Glassboard as the service sends over 150,000 emails a day. That’s not cheap. I admittedly should have done this six months ago, but live and learn.

CocoaRadio - Isaiah Carew on Parse

No CocoaRadio episode this week for the Fourth of July holiday, but I realized I forgot to mention the great episode I did last week with Isaiah Carew of YourHead Software. Isaiah and I talked about Parse, Facebook’s backend as a service platform that is popular with developers who don’t want to spend too much time and effort building and running their own server infrastructure. This episode is a wonderful complement to episode 1 where we talked about Azure Mobile Services.

Sponsored by:

  • SensorTower - the leading mobile app analytics platform, used by more than 40,000 companies and developers. Improve app downloads, analyze competitors, and stay on top.
  • AppCode - AppCode is an intelligent IDE for iOS/OS X development. It is designed to ease developers’ everyday routine and help them be more productive when creating apps for Apple devices.