StokerX 0.5 progress


 
J

Joe Keenan

TVWBB Fan
I've been working on the next release of StokerX, and I thought people might like an update. Here's what's significant so far:

1. Rewrote a major chunk of the app, so there might be regressions in some areas. Test carefully.

2. I've spent a lot of time reworking things so that preference changes go live without a restart. Please report any inconsistencies.

3. Blower activity metrics are completely new, with a popup to specify the time period for recent activity vs activity since start of logging.

4. I have a good chunk of the open lid detection done, and that will be available in the next release.

5. Rudimentary Twitter integration complete. It uses the new OAuth authentication, which requires each user to specifically authorize the application to send tweets on your behalf. I have it working now sending from my account, but I have not implemented the mechanism for a user to do the authentication yet. That's going to be tricky, but I have some sample code I can look at. I'd like some feedback on when to send tweets.

6. I've been thinking about alarms, and I'm probably going to roll audible, visual, email, and twitter all into one "Notifications" system before it's final. Inputs for conditions that should generate Notifications would be welcome.

7. As requested, HTTP interaction with the Stoker via an alternate port can be specified in Preferences. If an alternate telnet port is needed, please let me know.

At this point, I'm still building for OS X 10.6.X and up. I'll probably stick with that for at least a few more months. I'd like to move some of the UI controls from the Preferences panel to the main screen, but when I do that I'm probably going to use the new Auto-Layout stuff that's only available in Lion (10.7). Trying to keep the UI laid out properly without it is a major pain.

joe
 
Joe: That sounds really excellent. I will be glad to put it through it's paces once its available. Your efforts are greatly appreciated by the MAC community.
 
Well, that was painful...

I got Twitter authentication working today. And saving the credentials in the user defaults so you should only have to do it once. But I do need to add a way to revoke the credentials so you can switch accounts if necessary.

Unfortunately, due to either a bug in Twitter's API, or a bug in the OAuth library I'm using, or some other weirdness, I was not able to get the "transparent" authentication working. Which means that when you get redirected to your browser to log in to Twitter and authorize StokerX, you'll need to copy a PIN number from the browser page and enter it into an alert panel in StokerX. It should have been possible to do that transparently to the user, but I couldn't get the redirection from the browser page back to the application to work. Or, to be precise, I couldn't figure out how to tell twitter the correct URL to use to get the info back to StokerX.

It's possible I'll get an answer on how to do this from someone before 0.5 goes out for users, but I'm not counting on it.

What I still really need from users is a list of Stoker related events that should cause a tweet to go out.

joe
 
Joe: I would say:

An alarm conditions
- Fire too high/low
- Food at temperature

Incremental tweets, say once every x hours.

Murray
 
Progress report:

Open Lid detection complete, pending testing to see if it actually does what it needs to.
icon_wink.gif


Twitter integration complete, pending Notification system implementation to actually generate the tweets. Authentication with OAuth works, as does deauthentication (so you can specify a different Twitter ID).

Here's where I'm at with Notifications. I can either do a very limited system that only allows specific notifications for specific events, or I can define a list of events and a different list of notifications, and let users mix and match as they wish. For each sensor individually.

I'm leaning towards the latter if I can figure out a good UI to set it up.

As I'm thinking about it now, what I'm looking for the conditions:

1. Sensor over-temp. Should this be a fixed amount or a percentage?

2. Sensor under-temp. Ditto.

3. Sensor at target temp. No qualifier.

4. Periodic notification, interval flexible.

And the following types of notifications:

1. Email to address specified.

2. Tweet from authorized account.

3. Audible alarm (system sounds). User specified repeat interval.

4. Visual alarm - dock icon bounce.

Does that cover it? Is there any condition or notification type I'm missing?

joe
 
OK, I'm working on the Notifications system.

First, I'm going to use Growl for the "Visual" notifications. I can either use the simple framework, which assumes you already have Growl installed on your system, or I can use the jumbo one which will install Growl if you don't have it (after asking if you want it, that is). Preferences?

Second, for the non-Periodic notifications (which have an interval already defined), how often should I repeat the notifications? For example, if you have an "over temp" notification to do a visual alert, how often should it display? Or how often should it send an email?

joe
 
I decided to stick with the simple Growl framework, since the installer version would have almost doubled the size of the app. Which is only another 2Meg, so I reserve the right to revisit this another time.
icon_wink.gif


Most of the Notifications work is done, but I've revisiting the data structures I'm using to maintain the data. I'm not happy with the complexity. I see some restructuring happening very soon.

I'm still looking for some input on the repeat interval for non-period notifications.

Oh yeah - just for grins I grabbed the Sparkle framework and integrated it into the app. Once you have 0.5 installed, the app will check and auto-update itself when you let it.
icon_biggrin.gif


joe

PS - 0.5 will be out in time for Labor Day Weekend cooking. Probably this week some time.
 
You must log in or register to reply here.

 

Back
Top