Ramblings on Technology, Gaming, and Life in General

Menu

We’re closing in on the home stretch! The past week has seen me with a bit more time for development, and I’ve made a good dent in the tasks list. Let’s take a look at the one from last week and see how we’re doing:

The add subscriptions page (Done!)

A proper list for feeds and folders with refreshing and delete buttons (In progress)

A proper list for articles with swipe to star and mark read/unread (Next on deck)

OAuth (although it looks like Firefox OS will support this nicely – it’s just not a cross-platform solution) (Done, and source code posted)

Notifications (toast-style) (Done, source code also posted)

Various bug-fixes and cleanups (such as figuring out why the sharing menu won’t refresh properly) (Always in progress)

And there’s one to add that I forgot about last week: The recurring notification system that will alert you of unread feeds when the app is closed. The plumbing is there for this within the app, but I need to wire it into the OS. It looks like I’ll be able to use the Alarm API and the Notification API to make this work.

So, here’s the recap:

OAuth (my old nemesis). Fortunately, this was easier on Firefox OS than I expected. I was originally expecting to use a Cordova InAppBrowser, but, in Firefox OS, those don’t offer all of the features that I need. Namely, one can’t hook any of the event handlers. Fortunately, Firefox OS offers a better native solution using iframes and the Browser API, which I was clued into thanks to Peter Rukavina’s article. And, since I’m using Enyo, I can wrap the iframe in a Kind to set up the specific parameters that it needs to function properly on Firefox OS, and catch the nonstandard mozbrowserlocationchange event that it throws.

The only real weirdness that I ran into is that due to the way that Firefox OS browser sessions handle credentials, simply calling purgeHistory() on the iframe will not clear logged on sessions to Google, Twitter, Facebook, etc. I was unable to find a way to do this inside the Browser API (bug?).

So I needed to clear the logged on session manually. I handle this by navigating to the supported provider’s logout page after the OAuth session is complete and the iframe has (hopefully) been made invisible. We don’t need the logged in session after we’ve received the OAuth code anyways. And, if we don’t log out, there is no way to log in using a different account of the same type.

I thought that this would be a useful kind for the Enyo and Firefox OS developer communities, so I open-sourced it here.

Toast Notifications. The one type of notification missing from the Notification API is a toast notification. You know, the type that pops up from the bottom and stays there a few seconds to let you know that something has happened. It’s odd, because I know that this is in the OS. When an app is installed, this is exactly what happens. It must just not be publicly accessible.

Fortunately, there is an Enyo implementation of notifications by MacFJA. He doesn’t include toast notifications either, but he does provide a flexible, extendable framework, so I rolled my own, mimicking the Firefox OS style. I got a couple of requests for the theme, so I have made it available here.

The only weirdness that I ran into with this one is that it does not like being having the notification object inside a panel. So I had to add another layer and wrap my panels and the notification object inside a new Kind. Fortunately, with Enyo, this works very nicely. It’s turtles all the way down.

The add subscriptions page. Not much to tell here. It’s a bit different than the old FeedSpider, but its simpler. I think that it will actually work a bit better. Pictures will be below.

Converting things to use lists. When I first started this project, I was afraid that I would have to roll my own list type to handle the headers and dividers that I needed. This, I knew would be quite complex, so I’ve been putting it off. The “lists” that I’ve been showing in the screenshots are very fragile and don’t properly survive a refresh.

Now, I’ve gotten to the point in the project where I can’t put it off any longer, and have to actually deal with it. Fortunately, I’ve had a pleasant surprise. New to Enyo 2.4 (I’m pretty sure) is the AroundList, which will let you do headers and dividers like I need, as well as supporting swiping and re-ordering. This means that all the functionality that I need is available natively and I don’t have to stress about doing a custom kind anymore. I’ve done some initial work on implementing these lists, and this looks to be my project for the beginning of next week.

I’m hoping to have the app in a beta-able form by next Friday, and have it submitted to the Marketplace by the end of the following week (well inside my deadline). Then, I can start work on the versions for other platforms, including making sure that the app runs nicely on a Firefox OS tablet.

So, what’s left to do?

A proper list for feeds and folders with refreshing and delete buttons

A proper list for articles with swipe to star and mark read/unread

Recurring notifications

Various bug-fixes and cleanups (off the top of my head: mark all articles in a feed as read, proper handling of orientation lock, mark read as you scroll, auto close feeds/folders when all items are read. – all minor things).

And now, to close the post, the screenshots:

The completed OAuth screen, with border and back button. The OAuth Kind doesn’t provide any browser chrome, just the iframe. You can plug it in anywhere you want.

Functioning toaster notifications!

The completed add subscription screen.

The main page re-implemented using an Enyo.AroundList. (This works in Firefox OS too, but I use Safari for my UI testing because it is much quicker to iterate).

Last week, I was fairly busy due to other commitments and did not have much time to work on FeedSpider, but last Wednesday, I got a bit of exciting news – I had been accepted to the Firefox OS Apps on a Flame program!

In exchange for me committing to have an app ported and in the Firefox Marketplace within 30 days of receiving the device, they sent me a Flame developer phone to do hardware testing on. So, with that time limit in place, that moves Firefox OS up to be the priority development target! Fortunately, Enyo (with a little bit of Cordova to fill in the gaps) and Firefox OS play very nicely together, so I have had a productive week.

Since the Firefox OS UI is HTML5 based, I have only had to make minor tweaks to FeedSpider’s core (so far) to make it work. The big thing is that it doesn’t like cross-domain Ajax calls using JSON (instead of JSONP). Unfortunately, that is 99% of what FeedSpider does.

That being said, it’s not impossible. You just need to know the magic words, and ask for the right permissions for your app. In my case, the app needs to be privileged, and ask for the systemXHR permission, as described here.

The tricky part is that you also need to pass the parameter {mozSystem: true} to the XMLHTTPRequest when you create it. In Enyo, that is a little challenging, as you would typically call enyo,Ajax, which doesn’t appear to pass the parameters all the way down to XMLHTTPRequest. For another app that I was working on, I wound up having to call XMLHTTPRequest directly, rather than using enyo.Ajax. For FeedSpider, however, since I am using the prototype.js library to handle my AJAX calls, I just had to change prototype.js’s call to include the {mozSystem: true} parameter, and then everything worked. Now, I just have a couple of places to update where I have implemented my own XMLHTTPRequest handlers to work around webOS not handling puts and deletes properly.

The other bit is that it doesn’t allow you to use exec statements, so I had to toss out the JSON parser that I added in to parse articles after some characters were causing the default webOS parser to choke. On Firefox OS, this is an even simpler fix. The XMLHTTPRequest response object returns a pre-parsed responseJSON object, so I don’t even need to add the overhead of parsing the JSON. (Gecko FTW!)

As of right now, I only have a handful of things to still get working properly before the app is ready:

The add subscriptions page

A proper list for feeds and folders with refreshing and delete buttons

A proper list for articles with swipe to star and mark read/unread

OAuth (although it looks like Firefox OS will support this nicely – it’s just not a cross-platform solution)

Notifications (toast-style)

Various bug-fixes and cleanups (such as figuring out why the sharing menu won’t refresh properly)

Parts of this are a bit of a tall order, but I think that I can do it. And the Flame arrived yesterday, so the clock is ticking.

First boot on the emulator. At this point, the list of feeds and folders are loading correctly, but the articles aren’t due to the problematic JSON parser being blocked by the system.

A few small tweaks later, and we can load articles.

A bit of work on the sharing menu, and we can now share links via Email and Twitter using the Mozilla Web Activities API.

I got a box yesterday! The Flame looks and feels very nice, and I look forward to working with it. (I might even write a review later).

And this morning when I got back into the office, I tried it out. FeedSpider running on Firefox OS on real hardware. It looks great!

The past two and a half weeks have been very busy, FeedSpider-wise. The app now successfully allows you to go all the way from login to pulling up an article! I even got it running on a Touchpad to celebrate webOS’s birthday on the 6th.

In addition, most of the preferences are now wired in, and you can move between folders, feeds, and articles, and mark articles read and unread, starred and unstarred. Next is a matter of filling in all of the gaps and wiring a bunch of stuff in, and adding a few odds and ends that I haven’t gotten to yet, such as adding subscriptions, and handling sharing.

My earlier prediction panned out and much of my time has gone into building the UI. The core logic has continued to port relatively easily. I don’t think that I’ve touched the API layer at all. So far, much of the work has been fiddly and time consuming (in the sense of make minor UI change, refresh, check, repeat until satisfied), but not that difficult.

The two biggest remaining challenges that I have identified are working with OAuth, and figuring out a better way to handle the folder, feed, and article lists, so that I can do it properly using dividers. Based on the reading that I’ve been doing, I think that I may be stuck writing my own custom kind to add swipeable behaviours to an enyo.Repeater, as what I’m doing is a little complex for enyo.List.

If progress continues the way that it has been, I’m hoping to have something that I can begin testing on real hardware soon, and maybe a beta shortly after that.

Anyways, on to the screenshots. I typically find myself posting a new one almost every day on twitter, so if you want to keep up on the bleeding edge, check it out at twitter.com/feedspiderapp.

By June 5th, I had finished my re-design of the main page, and was successfully loading the list of feeds from the server, separating them into feeds and folders, and properly displaying their unread counts.

After a weekend away, I next worked on the preferences page. The Mojo-style groupbox does not exist in Enyo, and as I wasn’t too fond of the Enyo version, I rolled my own. This is the prototype.

By the next day, I had mostly finished wiring up the preferences page, except for dealing with a little UI bug, which I tackled the next afternoon. It caused my my custom picker headers to not have their width (100%) set correctly if they were invisible/hidden when the page was rendered. The calculation was made based on the width of the page rather than the width of the containing object, like it should have been. I wound up fixing it by manually setting the width when they were made visible, basing the calculation on the width of the other objects in the groupbox.

The next day, the Internet was out in the morning, so I finished up the help page – one of the few things available that didn’t need Internet access in order to fetch data.

When the Internet came back on, I got the list of feeds to notify the user about working, finally completing the Preferences page.

This week, I worked on getting the rest of the way from login to making an article available, getting the folder view working…

… and the Feed view, which required some new Kinds to represent the individual articles (as well as some more fiddling with the UI).

By Wednesday, I had the article view laid out and properly displaying (although at this point none of the buttons work on this page).

Yesterday saw the re-introduction of theming (which was a lot easier than I expected) as well as the ability to change the font size in the article view.

And today, I got the buttons in the article view wired up and working.

Next up, I need to get the sharing options working on the article page, and then on to dealing with the way that the folder, feed and article lists are handled. I also need to make a point of updating this blog more frequently. This is one big info dump!

With things quieting down going into the summer, I’ve found myself with some extra free time. So, I decided to start work on a project that has been at the back of my mind for a while now – porting FeedSpider to Enyo 2. This port solves a few problems for me:

Mojo, as a framework, is an evolutionary dead end. It has not received any updates since 2011, and, even then, had been superseded by Enyo. Enyo is the future, and is something that I need to improve my skills with.

There is currently no RSS reader client for Open webOS (which does not support Mojo). I might be able to help out there 🙂

Personally, I have switched back to an iPhone as my daily driver, (although I still love my touchpad), and I haven’t been able to find an RSS reader client that I like. So, I’ll do what I did before – roll my own.

The first goal of this project is to replicate the FeedSpider experience in Enyo (with a few tweaks), and to deliver a working RSS reader client for webOS (both open and legacy) and iOS. Further goals are to add support for Android, Windows Phone, and possibly even a Windows 8 (touch) app.

I’ve already had a fairly successful week, and have begun designing the new app and fleshing out some of the components. So far, I’ve ported over the login system, and have successfully pulled test data down from The Old Reader. I am working on the layout of the main page, and am starting to port the Mojo classes over to handle the static feeds (ie. All Items, Starred, Shared, etc.).

Fortunately, at the end of the day, it is all Javascript, so I can reuse much of the code and structure, thanks in no small part to Darrin Holst’s excellent architecture. In fact, it looks like I will be able to use many of the Prototype.js classes with few or no changes.

That being said, I forsee a couple of challenges. OAuth has reared it’s ugly head again, and while I might be able to use OAuth.io, I may need to come up with a more creative solution. That will require further research. I’m also sure that I will run into further pitfalls during the porting process that will slow me down a bit. But, with a little bit of creative thinking, and some reflection on the architecture before building, I’m sure that I can handle it.

To close off this inaugural post, here are a few screenshots of what I’ve completed already.

This is the initial layout test/mockup. These items are all statically generated.

Here is the new login screen. As of this screenshot, it actually works, and should be able to authenticate to any of the non-OAuth RSS readers.

Today’s update comes after I completed the port of the static feeds from Prototype.js classes to Enyo kinds. This was necessary since they mix layout and functionality. The Prototype classes that just handle functionality don’t needed to be converted into Enyo kinds.

For more information as the project continues, stay tuned to this blog and follow @FeedSpiderApp on Twitter.

While I’ve mostly switched away from Seagate hard drives after losing three hard drives to the firmware bug that hit the 500 GB models a few years back (although I was able to recover 2 of them after building one of these). I had to do a warranty return for one of my customers the other day, and had an excellent experience.

For $10, and a simple warranty validation check, Seagate shipped out a replacement drive with a return shipping label. The new drive shipped out right away and arrived earlier than expected. Since I’d already recovered the data from the old drive, all that I had to do was pop it in the box especially designed for the return, slap the return shipping label on and drop it of at the FedEx depot.

All in all, a very pleasant experience, and well worth the $10 – much cheaper than the shipping alone would have cost me.

Well, it’s finally happened. Google has dropped support in Gmail for the version of Gecko used by Mozilla Prism. This means that Gmail has to fall back on basic html mode. So, clicking on an email causes it to open up a new Firefox window for the email – rendering Prism completely unusable.

Of course, it was just a matter of time. Prism hasn’t been updated in almost 4 years – ever since Mozilla stopped developing an embeddable version of Gecko, and tied it into Firefox development. And, it seems like the idea of Site-Specific Browsers (SSBs) never took off.

Personally, I’m a huge fan of the concept. For rich web-apps like Gmail, it just makes so much sense! I love having a dedicated Gmail window that is sandboxed from the rest of my browsing environment, giving me the full power of the Gmail web client, without having to keep my main browser signed into Google. It also means that I can put it up on it’s own monitor!

Fortunately, while the concept hasn’t really taken off, there is still a solution, at least for the Mac. For $5, I picked up a copy of Fluid, which allows me to set up a sandboxed SSB using a modern version of WebKit, giving me my Gmail app back. There are still a couple of quirks that I need to get used to, but it’s nice to know that I’m not going to have to drastically change my workflow.

It’s amazing how the time slips away on you – it’s been almost a month since I’ve posted anything – and I meant to post this for World Backup Day on March 31st.

I almost lost the code for FeedSpider the other day – or at least I would have if I didn’t have a proper source control system set up. I was making some changes, and accidentally deleted the wrong file. This could have been disastrous, but fortunately, I had the changes committed to Git. But it got me to thinking…

I have what I like to think of as a robust backup system. My code is backed up to source control (separate from everything else), and all of the computers are backed up to the local server, which, in turn, is backed up to cloud based storage using CrashPlan so that I can still retrieve it in case of a catastrophic emergency.

This has saved me more than once – one time my laptop wouldn’t boot and the troubleshooting advice from Apple boiled down to “You’re screwed. Format and reinstall.” Fortunately, I had a time capsule backup from the previous night, so I did just that and went on with my day. In another situation, one of our guys accidentally clicked on a phishing link in an email, and got infected. He still had to change all of his stored passwords, but rather than try and “clean” his computer, I just stuck in the restore CD and restored it from the previous night’s backup.

It’s nice to be in a situation where I have enough redundancy where I don’t have to lose sleep at night worrying about something happening to my hardware. But many people don’t, and in my years of tech work, I’ve seen more data lost due to a lack of backups than I would care to remember. So, in the spirit of World Backup Day, I’m here to help. Let me know what your situation is, and I can help you come up with a backup solution that works for you.

Learned something new this week about (modern) cordless phones – they can interfere with wireless mice.

Customer had a problem with their wireless mouse (mouse + dongle, rather than Bluetooth). Whenever they were using it on their desk, it would act wonky, especially if a YouTube video was running, or the computer was under similar load.

Customer tried replacing both the mouse and the mousepad (in case something was screwing with the laser) with no luck, and the mouse worked fine on my workbench. So, I went over to take a look and check for sources of wireless interference. There was nothing obvious (no microwaves in the office, wireless router was on the other side of the room, etc.), but the customer had two cordless phone base stations on the desk. I couldn’t think of anything else, so I tried unplugging them, and all of a sudden the mouse started behaving properly.

Both phones were DECT 6.0, so *in theory* should not have affected the wireless mouse. That being said, most people only keep one on their desk, so perhaps something about the two being right next to each other was causing the interference? If anybody has any, I’d love to hear some theories on the phenomenon.