FeedSpider Dev Blog: End to end (basic) functionality!

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.

feedspider-enyo4

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.

feedspider-enyo5

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.

feedspider-enyo6

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.

feedspider-enyo7

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.

feedspider-enyo8

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

feedspider-enyo9

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

feedspider-enyo10

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

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

feedspider-enyo12Yesterday 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.

feedspider-enyo13

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!

FeedSpider 2 Development Blog: FeedSpider goes Cross-platform

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:

  1. 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.
  2. There is currently no RSS reader client for Open webOS (which does not support Mojo). I might be able to help out there 🙂
  3. 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.

feedspider-enyo

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

feedspider-enyo2

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.

feedspider-enyo3

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.

An Ode to Source Control (or On The Importance of Backups)

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.

Spoiled by modern technology – Multiple Monitors

Jeff Atwood over at Coding Horror has been writing about the value of multiple monitors for years, and I have to say that I completely and totally agree with him, especially after the last week. You’ve seen what my desk at work looks like. (Although I’m thinking of getting rid of the 4th monitor. It’s a bit too much). At my previous job, I talked the boss into a dual monitor setup, and was ultimately responsible for getting dual monitor setups for everybody in the office. It’s amazing what a difference it makes for productivity.

Personally, I love the 3 monitor setup. My typical development environment is set up as follows:

  1. Left monitor: Emulator/Debugger/Logging tools, etc.
  2. Middle Monitor: Code – either a collection of text files, or IDE. Depends on what I am working on.
  3. Right Monitor: Reference Materials – usually one or more Firefox windows with a couple of dozen tabs open between them.

This allows me to quickly glance between windows without requiring a mental context switch. This is especially useful when referring to code and logging/debugging info at the same time or to code and reference material – without having to keep switching windows and risk dropping all of the variables that I am juggling in my head.

Over the past week or so for Christmas break, I’ve been home, so I’ve been developing on the laptop. I finished adding support for Tiny Tiny RSS to FeedSpider! (Now if HP would just release the thing to the app catalog…) But, it meant that I was stuck using the laptop’s tiny 17” inch screen. (Yes, I know, it’s a big laptop. But it’s a drastic change from dual 23” monitors.) I tried using Spaces and that is almost as good – at least the best experience that you’re going to get on a single screen. For my environment, it is very useful to be able to tie apps to individual spaces and switch between them with a keystroke. But, you’re still stuck mentally context switching.

So, I’m spoiled. While the laptop works, I don’t think that I could ever go back to a single monitor setup permanently. I’m looking forward to getting back to the office and getting some development done on a real setup.

The Joy of Creation

Nothing is quite as satisfying as finishing a project that you’ve been working on for some time, especially if its been sitting on your desk for a while – important but not urgent. For me, that has been adding Feedly integration to FeedSpider over the last week or so. That is now complete, and I am just waiting for the guys over at Feedly to push my new client id to production so that I can release the app. (As a bonus, I also added support for BazQux Reader. It only took about half an hour thanks to their very Google-like API.)

The biggest challenge was implementing OAuth support (detailed in my last post), but between a few false starts with AOL reader, which requires the same technology, and work piling up at my day job, I got it done. The rest of the project was merely tweaking the app to support Feedly’s API, which is Google-like, but just different enough to create it’s own challenges, especially on the platform that I’m working on. And now, that’s finished too.

While I can’t take credit for building the app from the ground up, (Darrin Holst did an excellent job of architecting it), I have done some significant tinkering under the hood, and am very proud of reworking the API and login/credential layers so that the app can properly and easily handle multiple providers with different requirements. This was aptly demonstrated by how easy is was to integrate BazQux Reader. I just had to drop in a new app API, and add the service to the service list. No other changes required.

One of the things that I love about programming is the feeling of having built something, even if it’s just a bunch of bits. It gives you a certain satisfaction and an energy that can’t be duplicated – make you feel like you can take on the world, and makes you feel ready to go energetically into the next project. That’s something that’s feels like its missing nowadays – and why I intend to keep programming and building computers and systems for many years to come.

Programming via clever hack

I picked up an HP Touchpad shortly after the firesale back in 2011, and have been using it as my daily driver ever since – I even picked up a Pre 3 a little later to replace my aging iPhone 4. Suffice it to say, I’m a big fan of the webOS operating system, even though it’s been a while since it was updated.

Of course, with no new hardware on the horizon, and no official updates coming down the pipe for these devices, (although LG is still working hard on developing Open webOS), developers have left for greener pastures, and apps and services have slowly stopped working. One of the main things that I use my devices for is consuming RSS feeds. Until it was shut down, I used Google reader, and one of the best Google Reader apps for webOS: Feeder. After it shut down, we were kind of in a bind, as many Google Reader alternatives sprang up, but no apps supported them, and the developer had left for greener pastures.

So, as a developer, what am I to do but roll my own? Fortunately, Feeder had been open sourced when the developer finished with it, so I forked it and have been working on “FeedSpider” ever since, adding support for The Old Reader and InoReader. But that’s not the clever hack. Both applications cloned the Google Reader API (mostly) and allowed support for simple authentication using ajax calls, so adding support was pretty easy.

Where the clever hack comes in is when dealing with Feedly. Feedly is the largest of the Google Reader successors, and just opened their API up to the public fairly recently. What makes this challenging is that Feedly uses OAuth for authentication, which webOS does not support very well. Fortunately, somebody else already came up with a clever hack for that, which, in short, captures the OAuth authorization code from the browser when it redirects to redirect uri and allows the app to use it. The library mostly works for Feedly, but not quite.

My contribution to the clever hacks list is two-fold. There is a bug in webOS on tablets that causes it not to pop up the keyboard when using a webview inside an app. (Works fine on phones, and I need to use this method to keep support for old devices) that I had to hack around by manually causing the keyboard to pop up then you go to the Twitter, WordPress and Google OAuth providers. I did that by watching for the urlChanged event and acting accordingly.

The more interesting part of the hack was that Feedly forces you to register your redirect URI with them, and will only let you use the one that you registered. Since I’m currently in sandbox mode, they gave me two options, http://localhost, or urn:ietf:wg:oauth:2.0:oob. Localhost won’t work on a webOS device. The browser will just time out. It never actually tries to do the redirect in a way such that I can catch it. The other one will try to do the redirect, but, it generates a “MIME type not supported error.” Here’s the fun bit – this raises a “Mojo.Event.webViewMimeNotSupported” event, which returns the URL that it is trying to redirect to. So, I catch the event, feed it to the filter and get the OAuth code, allowing me to log in, and we’re in business! (Yes this means that I am making good progress on Feedly support and hope to deliver it as a Christmas gift).

This is one of the fun parts for developing for poorly supported operating systems – there’s always a clever hack that will let you do what you want to do, even if the path is a little roundabout at times.