philkmills: Phil and guitar (Default)
2012-03-15 11:30 am
Entry tags:

Testing Metadata

There are properties associated with messages. Some of them would be nice to keep in the backup and some probably irrelevant. Here I am discovering how they are transmitted.
philkmills: Phil and guitar (Default)
2012-03-07 02:49 pm
Entry tags:


When I started this, I was handling background database updates by keeping control of which thread was allowed access at any one time. This worked fine for simple cases but was starting to look top-heavy. The recommended method is to have each thread maintain its own "scratchpad" of modified objects and, when there's a commit, merge the changes into any other affected threads.

It took a bit of a rewrite compared to the simple template code for Core Data that Apple provides but it looks as if it will be easy to work with from here on.

Bug score: Open 13, Fixed: 75.
philkmills: Icon for AutoSongbook (iPad)
2012-02-29 10:55 am
Entry tags:

Testing (still)

Attempting to post with a user icon that's selected according to a keyword. Since I now have more than one image associated with this account, there's a better chance of it happening. :-)

Bug score: Open 15, Fixed 73.
philkmills: Phil and guitar (Playing)
2012-02-27 11:00 am
Entry tags:

New Test

Posting with selected metadata. At this point posting mostly works except for some oddities with pending messages saved from earlier sessions.
philkmills: Phil and guitar (Default)
2012-02-10 04:58 pm
Entry tags:

Numbers Game

Yesterday I had a friend coming over and, while waiting for him, I put the iPad version of the program through some tests. As usual, sitting down and using the application rather than just following my planned-out steps reveals a number of bugs.

The thing that makes iPad development a little more difficult that iPhone is that the iPhone UI usually only has one thing happening at any time. For the iPad there are extra sanity checks concerning synchronized display of data.

Bug score: Open 20, Fixed 63.
philkmills: Phil and guitar (Default)
2012-02-09 10:04 am
Entry tags:

More UI Fixes

The most recent bugs to be fixed were fairly resistant. In one case, improper re-flowing of text when the display size changes, turned out to be an Apple problem and has been reported to them. I have a workaround that's OK for what I'm doing but would be really annoying in other cases.

Another pair of bugs, related to how things on the display are resized to make room for a keyboard, turned out to be problems in code I had taken from samples in Apple's own documentation for how to handle the situation.

And I fixed a few of *my* bugs too. :)

Bug score: Open 20, Fixed 57.
philkmills: Phil and guitar (Default)
2012-02-03 05:01 pm
Entry tags:

Some Progress

New things that work are, using index controls to navigate through word lists, making toolbars disappear or not depending on the screen being displayed, improvements (more detail) for error objects being generated because of server errors, and consistent behavior concerning remembering selections when returning to parent table views.

Bug score: Open 24, Fixed 51.
philkmills: Phil and guitar (Default)
2012-02-02 04:52 pm
Entry tags:

UI Fixes

The one major piece of the program I haven't done much on yet is the ability to post a new message to the user's journal. As strange as it seems, that's not a core function of the program but one that -- like viewing a reading list -- seems like it should be there for convenience. If someone *really* wants to post messages and replies, Safari does that quite well.

Most of today's fixes related to cleaning up the post code that I'd written as a semi-functional placeholder so that it will be easier to make it do what I really want.

Bug score: Open 25, Fixed 47.
philkmills: Phil and guitar (Default)
2012-01-31 12:25 pm
Entry tags:

Taking Time

Creating an interface for managing stopwords turned out to be a bit more time-consuming than I'd expected. Partly that was getting the database access right but mostly it was spent figuring out a couple of oddities within the development kit.

There is a controller class which one can use as a caching interface to the database. It tracks DB changes and updates query results accordingly. Optionally, it informs a delegate that changes have happened. However, if you give it a delegate and it detects that the changes aren't being processed, it invalidates its own cache. This causes havoc if the programmer's strategy is to defer such processing to a more appropriate time.

The other weirdness was the product of the visual interface editor. The task was to put a sub-view inside a scrolling view which, itself, was inside a primary view. The tool decided to apply positive x/y offsets to the sub-view and compensating negative offsets to the scroller. It looked great until the user tried to make anything scroll...then, confusion in the form of objects wandering aimlessly across the screen.

Bug score: Open 31, Fixed 40.
philkmills: Phil and guitar (Default)
2012-01-27 08:25 am
Entry tags:

Stopping By Words On A...

Yesterday's main task was getting the basics of a stop word list in place to support text search. (For those who haven't lived in the world of text indexing and retrieval, stop words are those that you don't care about, the ones that appear in just about every piece of text and therefore are useless for locating important information.)

I'm intending to supply a default list with the application but also allow its customization. This means that the provided list needs to be copied to a manageable location -- database -- when the application is installed. The app needs a screen that allows additions and deletions. An easy way to do additions is showing the user what has already been indexed and allowing those to be moved into the stop word list.

Removing a stop word is somewhat problematic in that it could only be effective for messages indexed after the removal. That means either re-indexing existing messages or living with inconsistency. There's an option of disallowing removal after any messages have been indexed...which might not be a bad thing.

At this point, database access for stop words is working; only the maintenance function is still to be done.
philkmills: Phil and guitar (Default)
2012-01-21 09:50 am
Entry tags:


Between last night and this morning I've removed one large item from the Bugzilla list of enhancements. (Aside: I'm not sure 'enhancement' is the right word for implementing a feature in the first version of an application...but it's an available category and it will do.)

My program is now capable of filtering downloaded messages according to the account or community where they were posted (or some combination of those) and applying a list of search terms to find messages containing 'any' or 'all' of those terms. It's using an indexed keyword search rather than full text so, at least with test accounts, it responds quite quickly.

(Note to self: Add another enhancement item for a method of modifying the supplied "stop word" list.)

Bug score: Open 31, Fixed 17.
philkmills: Phil and guitar (Default)
2012-01-20 11:13 am
Entry tags:


Wednesday was dedicated to fixing some user interface bugs. Yesterday was mostly a write-off for working on this project. Today, so far, I've got sorting working for filtered messages and for friends/reading list messages both from the UI point of view where sort order is selected and from the data side that responds to it.

Bug Score: Open 31, Fixed 16.
philkmills: Phil and guitar (Default)
2012-01-17 04:29 pm
Entry tags:

Network error handling

I've only found a few bugs and fixed a few in the past couple of days but one of the fixes was a big one. I now have a unified way of handling network errors within the application so that, whether they come from a problem with a connection or are returned as server text, they propagate through the application from the network layer to the top-level callers in the same way.

(Debugging asynchronous networking is the same kind of fun as swinging blindly at spontaneously-regenerating, rocket-powered pinatas.)

Bug score: Open 35, Fixed 11.
philkmills: Phil and guitar (Default)
2012-01-13 03:17 pm
Entry tags:

Friends/Reading List

The current score on the buglist front is: Open 37, Resolved 7.

Of the ones that got fixed today, most were small but the one exception was: Make the friends list (reading list) work. That involved parsing the return values, deciding which ones to keep, creating a UI for the list of them, another page for showing details, and the logic for navigation.
philkmills: Phil and guitar (Default)
2012-01-11 05:49 pm
Entry tags:

Risk Analysis

The main part of today's programming adventure was testing various ways of creating a custom 'skin' for an iOS application. This is connected to my previous post about things that the development kit doesn't want to let a developer do...but it's also something that's done repeatedly. The trick is not so much in finding a way as in finding a way that is less likely to break than others.

The nice thing about my current choice is that, if it breaks because of changes in a future iOS release, the failure will almost certainly show up as a user interface that looks like the non-customized one. Some of the other candidates could have failed in ways that affected functionality.

Since Dreamwidth now has the ability to send a user's reading list to a client in a similar format to LJ's friends list, I've started fixing the 'bug' related to that not being shown for a DW account.
philkmills: Phil and guitar (Default)
2012-01-10 09:41 pm
Entry tags:

Bug Hunting

I spent the evening at a local Cocoa developers' meeting in downtown Toronto. Since I got there by public transit I had time to spend and put most of it into exercising the application on my iPad while taking notes. This was the first version of it that I built to run on a device instead of a simulator and it behaved reasonably well -- only one crash in about 45 minutes of testing.

It got me nine more functional/appearance bugs as well to add to my project list, however, so that's good. :-)
philkmills: Phil and guitar (Default)
2012-01-10 03:45 pm
Entry tags:

Programming 101 -- Refuted

While working on customization of the application's general appearance today I discovered some very annoying behavior in Apple's "Cocoa Touch" software development kit. A couple of commonly-accepted programming guidelines are: 1) in OOP, a subclass extends the behavior of its parent class; it doesn't restrict it, and 2) side-effects are bad; a routine should do what it claims and little else.

In this library, the class UIToolbar is a subclass of UIView, which leads to the expectation that a toolbar should do anything a view can plus whatever extra its designer thought necessary. Nope. For example, a view allows you to set its background color but a toolbar quietly ignores such a request. A Google search reveals a great number of people questioning their own code because of this breaking of a basic assumption.

While experimenting with this, I discovered the second problem: that of unexpected results having nothing to do with the documented purpose of various routines.
- Toolbars exist as a way of letting a user select actions relevant to some other information on a screen. Changing the translucency of one changes the *size* of the related content.
- Toolbars contain optional buttons as trigger points for these actions. Changing the alpha (transparency) of the toolbar changes it for all the embedded buttons.
- Setting a toolbar translucent and then changing its "tintColor" -- or vice versa -- cancels the translucency.

Some operating systems are designed to give access to computer features in a useful way. iOS, on the other hand, was designed to prevent access except in Apple-approved ways. Some days the difference really shows.
philkmills: Phil and guitar (Default)
2012-01-10 11:20 am
Entry tags:


Doing a complete review of the iPad-specific application screens this morning only added three items to my bug list. Two of those were obvious enough that I did the fixes first and then created the Bugzilla entries.

This is actually difficult for me...remembering that having entries in the list has value in itself. It serves as a reminder of what problems occur and, therefore, may occur again. It also is a guide for estimating amounts of work for future projects.

Also fixed was a potential problem of attempting to save search terms for a post that had none. This brings the current score of bugs to: Open 28, Resolved 3.
philkmills: Phil and guitar (Default)
2012-01-09 04:22 pm
Entry tags:

A Large Step Forward

After going through a few days of organizational wheel-spinning, I now have a configuration where Bugzilla running on Linux is available throughout my LAN. This inspired me to go through the eleven iPhone screens in my application prototype, try out all the controls, and enter a bug report for everything that wasn't how it should be. Current count: 28.

The level of granularity on these is all over the map, ranging from adding another field to a certain display to "Help...yes, there should be some". This, combined with the fact that the iPad side of things mostly consists of placeholders, means that the number of entries is likely to climb significantly in the near future. On the other hand, I'm happy to have an interactive product plan available.
philkmills: Phil and guitar (Default)
2012-01-06 07:44 am

A Server OS For Server Software

Partly because I'm stubborn and partly because I wanted to learn whether the previous day's installation problems were software issues or me(!) issues, I installed Bugzilla on Linux yesterday. Even this was not exactly simple, but that's because my PC's Linux partition was running an OS version that was four years old.

There are a couple of things about this that come as a bit of a nightmare to a -- by choice -- Mac user. One is that updating applications for that old a system is dicey and the second is that updating the OS becomes a case of replacing it rather than upgrading. After internalizing those ideas, I thought it might be interesting to install a Ubuntu version. I downloaded the ISO image, burned a CD, and started an install...which crashed. It asked if I'd like to send a crash report and I agreed to that. It said it couldn't gather enough information and would I please install some more software first. If I could do that, I wouldn't be sending this report, would I? Go away.

I went back to my old friend openSUSE which installed fine after the standard download, burn.... The PostgreSQL database installed fine and Apache and the massive number of Perl modules that Bugzilla needs and Bugzilla itself. With only a small amount of head-scratching, they all got configured to work together and by the end of the session I was starting to remember where they all hid their configuration files.

I'm not sure whether I'll actually use this installation or not but I feel better knowing that the previous day's failures weren't due to brain deterioration. Cross platform software is wonderful in theory but, in practice, use it on the system it was *really* designed for.