Version 2.3 was recently released.
The response thus far has been phenomenal! One of the biggest requests was for the addition of a timer. I've added this functionality, and I believe I've done it in style. If you don't have it yet, you should download it now.
You can also check out the screenshots of the new features here:
http://www.robbiehanson.com/alarmclock/screenShots.html
Tuesday, May 23, 2006
Thursday, May 18, 2006
Long time, no see
It's been over 2 weeks since I've offered an update for Alarm Clock, or posted to this blog. What have I been doing? Have I been relaxing at the pool, taking in the beginning of my summer vacation? Heck No! I've been hard at work on the Alarm Clock, adding features, and making it more stable. More to come soon...
Wednesday, May 03, 2006
Hebrew localization
I've just recieved the first draft of a Hebrew localization. It should be completed/approved very soon. This will be the 10th supported language for the app.
I'm always looking for more localizations! Is anyone out there interested in doing a Japanese translation? My website gets a lot of hits from Japan on a daily basis, and I still don't have a Japanese localization... If you're interested, email me at: robbiehanson15@gmail.com
I'm always looking for more localizations! Is anyone out there interested in doing a Japanese translation? My website gets a lot of hits from Japan on a daily basis, and I still don't have a Japanese localization... If you're interested, email me at: robbiehanson15@gmail.com
Monday, May 01, 2006
Version 2.2.6
A new version is available. Here's the low down.
Feature additions:
-Now automatically skips to the next song in between snoozes when using a playlist. I often use a playlist to wake up, but since I wake up rather fast, and hit snooze many times, what ends up happening is I hear a small section of the song many times in the morning. No matter how much you like a song, after it wakes you up 15 times in the morning, it starts to get really annoying! So with this addition, a single song won't constantly annoy you if you're using a playlist.
- You can also manually skip to the next track, or go back to a previous track with the apple remote. Several users requested this feature, and since I saw no reason not to implement it, I honored their request.
Bug fixes:
-Fixed bug where app would crash if it encountered a bad alias.
-Fixed bug where app would crash if you immediately hit stop before the background thread completed parsing the iTunes library. Depending on your computer, and the size of your iTunes library, the background thread lasted anywhere from 0.3 to 2.5 seconds. So yes, you had to act extremely fast if you wanted to catch this one.
-Fixed bug where app would crash if you tried to edit a one-time alarm after the alarm had already gone off. This was only possible if the alarm editor was open when the alarm went off.
-Fixed memory leak in iTunes player. It was possible for a few variables to not get released.
-Fixed bug where currently snoozing alarm doesn't wake up a battery powered MacBook Pro that goes to sleep between 30 and 45 seconds before snooze ending, or between 0 and 15 seconds before snooze ending. (Yes, it only affected intel Macs because they take much longer to go to sleep. At least it does on my roommates MBP) (Yes, it only affected the computer if it was on battery power.) (Yes it only affected the user if it happend approximately right in those ranges. So there was a 30 second window for trouble.) The precautions I had coded a long time ago didn't take into account the possibility of it taking over 20 seconds for a laptop to go to sleep. It should be safe now even if your computer takes 60 seconds to get to sleep.
-Fixed bug related to the alarm check timer firing early. This was a really odd bug that happend to me one time. Timers are supposed to fire at specific intervals. Sometimes they fire a bit late, but I had NEVER seen them fire early... until now. So the time was firing several milliseconds before the second hand got to zero. This meant the program thought it wasn't time for the alarm to go off. So it wouldn't check again until the next minute, and the end result was that the alarm went off a minute late. When this happened to me, it continually happened every time I ran the application. I was very perplexed. But when I restarted the computer, the problem completely went away, leading me to believe it was a freak bug in the OS or in the NSTimer API or something. But regardless I added code to allow for slight inaccuracies in the firing of the timer that will take care of the problem should it ever happen again.
I wasn't planning on releasing a 2.2.6 version, but when bugs pop up, especially any that would prevent an alarm from going off, I drop everything else, and get them patched immediately. Stability is the main focus. I'm not sure if these problems actually affected anyone, but the fact that they could have keeps me up late into the night working on it. I would rather lose several hours of sleep, then cause someone else to oversleep! My primary focus now is on version 2.3, but if anything serious comes up, a fix would be immediately offered.
Feature additions:
-Now automatically skips to the next song in between snoozes when using a playlist. I often use a playlist to wake up, but since I wake up rather fast, and hit snooze many times, what ends up happening is I hear a small section of the song many times in the morning. No matter how much you like a song, after it wakes you up 15 times in the morning, it starts to get really annoying! So with this addition, a single song won't constantly annoy you if you're using a playlist.
- You can also manually skip to the next track, or go back to a previous track with the apple remote. Several users requested this feature, and since I saw no reason not to implement it, I honored their request.
Bug fixes:
-Fixed bug where app would crash if it encountered a bad alias.
-Fixed bug where app would crash if you immediately hit stop before the background thread completed parsing the iTunes library. Depending on your computer, and the size of your iTunes library, the background thread lasted anywhere from 0.3 to 2.5 seconds. So yes, you had to act extremely fast if you wanted to catch this one.
-Fixed bug where app would crash if you tried to edit a one-time alarm after the alarm had already gone off. This was only possible if the alarm editor was open when the alarm went off.
-Fixed memory leak in iTunes player. It was possible for a few variables to not get released.
-Fixed bug where currently snoozing alarm doesn't wake up a battery powered MacBook Pro that goes to sleep between 30 and 45 seconds before snooze ending, or between 0 and 15 seconds before snooze ending. (Yes, it only affected intel Macs because they take much longer to go to sleep. At least it does on my roommates MBP) (Yes, it only affected the computer if it was on battery power.) (Yes it only affected the user if it happend approximately right in those ranges. So there was a 30 second window for trouble.) The precautions I had coded a long time ago didn't take into account the possibility of it taking over 20 seconds for a laptop to go to sleep. It should be safe now even if your computer takes 60 seconds to get to sleep.
-Fixed bug related to the alarm check timer firing early. This was a really odd bug that happend to me one time. Timers are supposed to fire at specific intervals. Sometimes they fire a bit late, but I had NEVER seen them fire early... until now. So the time was firing several milliseconds before the second hand got to zero. This meant the program thought it wasn't time for the alarm to go off. So it wouldn't check again until the next minute, and the end result was that the alarm went off a minute late. When this happened to me, it continually happened every time I ran the application. I was very perplexed. But when I restarted the computer, the problem completely went away, leading me to believe it was a freak bug in the OS or in the NSTimer API or something. But regardless I added code to allow for slight inaccuracies in the firing of the timer that will take care of the problem should it ever happen again.
I wasn't planning on releasing a 2.2.6 version, but when bugs pop up, especially any that would prevent an alarm from going off, I drop everything else, and get them patched immediately. Stability is the main focus. I'm not sure if these problems actually affected anyone, but the fact that they could have keeps me up late into the night working on it. I would rather lose several hours of sleep, then cause someone else to oversleep! My primary focus now is on version 2.3, but if anything serious comes up, a fix would be immediately offered.
Subscribe to:
Posts (Atom)
