Actually, it came about a week ago, but I figured I'd wait for it to settle in before I posted an article about it. You can see it here (along with my guitar):
It arrived in great shape, except for one of the "pips" (the white things on the end of the tuning pegs) fell off. I had to fashion one out of the ball on the end of a push pin, but I think it looks rather nice.
It sounds amazing, looks amazing. I couldn't be more pleased.
I did break the high F string (called the chanterelle) on the second day. Lucky it came with an extra one. Apparently, there are a lot of works for the Baroque Lute that are labeled "Sans Chanterelle" (or "Without the Chanterelle") because in their day it was common for this string to break, and if it happened during a performance or something, they'd want to have something to play.
Anyway, perhaps when I've learned a song well enough that I'm comfortable with it, I'll record a video and post it on here.
The reason for this? I lost my signing key. Even if I wanted to make updates to it, I couldn’t upload it to the same project on the Android Market, at least, not without a lot of grief. So, I just avoided it… though it wasn’t a huge problem. Since I uploaded it, I haven’t gotten one error report in the market dashboard, so it must be working. However, during that time using it myself, I noticed a few features I’ve wanted here or there that would just make things easier.
So, over the weekend, I rewrote the entire app in Scala. Why a rewrite? I dunno, just because I wanted an excuse to learn Scala and Scala for Android. I’ve named this one “DupaCount”. “SupaCount” will remain on the market, but with a blurb that it’s been replaced. During the rewrite, I added the few features that I wanted:
- If you reboot the phone while a timer is running, it will still alert as expected. This one really is more of a bug, but people probably didn’t notice as most wouldn’t make a timer that runs longer than a few hours. I’ve run timers for up to 2 months before, and though they always kept counting down, they wouldn’t always alert if I had rebooted during that time.
- There is an easy to see & access button at the bottom of the main screen called “Add Timer”
- The “description” field in the Add Timer dialog has been made optional. If you leave it blank, it will default to a display of the timer time. This will make it much easier to add a timer.
Anyway, the app can be found here: https://market.android.com/details?id=com.synicworld.dupacount, and the sourcecode can be found here: http://bitbucket.org/synic/dupacount
Yeah, ok, this post is more of a rant that anything. I realize that people actually reading this article probably aren’t the ones that post my most unfavorite comments on the market, but I don’t care. I’m posting it anyway.
First and foremost:
The android market comments section is not a good place to post bug reports. There is no way for the author of the app to get in touch with you if they need more information about the bug, and no real reliable way for them to even respond to your post. Please please PLEASE try and find their bug tracker, if there is one.
With that in mind, it’s probably a better idea to use that same bug tracker to file feature requests. Especially if they are complicated. Sure, it’s fine for something short and obvious, like “I wish you could change the font size”, etc (though I’d prefer that no one ever use the market for any feature requests).
Do your research. I often see comments like the following:
“The latest update of this app starts up upon booting your phone, uninstalling”
Does this mean you just noticed that it requested boot permissions while installing it? Or you actually noticed it was running immediately after boot? The world will never know, because, as stated above, the developer cannot contact you based on your comment. Regardless, noticing that the app requires boot permissions or is running immediately after startup probably doesn’t mean what you think it means.
In the case of SupaCount, it starts on boot to reset the alarms that were wiped out during the reboot. This means it starts up, registers any alarms with the Android Alarm Manager, and then quits. However, because of the way Android memory management works, it’ll probably still show up in your Task Manager app (more on these evil things later), because the OS keeps it around for a while, just in case it’s needed again. If the OS needs this memory for something else before that happens, it’ll discard it, and that’s when it will stop showing up in your running tasks.
I imagine most apps are doing something similar to this. A lot of apps use the AlarmManager to wake the app up periodically so that it can perform some background task. For instance, the OkCupid app used to wake up every 15 minutes or so to check to see if you had any new messages. In order for the app to schedule these events with the AlarmManager, it needs to be started at boot, otherwise, those events will never get registered.
“One star. App is constantly running in the background hogging all my memory”
Likely the app is just waking up to check something periodically, like I mentioned above. Even if it is actually running in the background all the time, your memory is not what you need to be worried about. If the OS needs the memory and a certain app is hogging too much, that app will be killed. No exceptions. Giving an app a bad rating or uninstalling it all together just because you noticed it in your task manager is dumb.
What you should be worried about is your battery. If an app is doing something constantly in the background, it WILL eat away at your battery. You can find out what apps eat up the most battery by going to Settings->About Phone->Battery Usage.
For the reasons I just listed above, you should uninstall your task manager. There are countless articles out there about why they are bad (do a search if you don’t believe me), and the Android developers have stated themselves that they aren’t needed. Android memory management works differently than it does on your computer. An app in the foreground has priority over any app in the background. If the OS needs memory for the app in the foreground, it will kill apps in the background to get it. In order to improve response times, android may keep an app around in memory, even after you think you’ve exited, just in case you need to open it again. Like I said, though, if the OS needs that memory, the app will be removed.
So, if you see an app running in the task manager, it really has no meaning to you. There are several reasons it could be there, and you killing it is more likely to cause problems than anything else. If you’re worried about your battery, check your battery usage section, and if there’s an app behaving badly, uninstall it.
“I will give this app 5 stars if you enable installing to the SD card”
Uhg. It’s not as easy as that. There is a very specific set of criteria that determine if an app is installable to the SD card. You can see that list here: http://developer.android.com/guide/appendix/install-location.html#ShouldNot
A lot of it has to do with what happens when your SD card is unmounted (which happens when you attach your phone to your computer).
In the case of SupaCount, it can’t be installed to the SD card because the startup apps are run before the SD card is attached, so any apps that need to be run at startup cannot be installed on the SD card.
Don’t be an asshole. Especially if the app is free. The author does not owe you anything, and you freaking out the in comments is just going to get you ignored.
A lot of this stuff probably applies to the iPhone App Store as well. Just have some common sense. The rating and comment system is there simply so you can state what you thought of the app, and so that other people can tell if the app is worth installing. It’s not a place to report bugs or ask for features.
Yesterday, after many years of using Vim, I’ve finally realized what the purpose of Vim Tabs is. My friend asked me to post this article, because she was also stumped by their functionality.
When they first came out, I tried them. I didn’t understand why they’d even put tabs in, when there are far superior ways to navigate Vim buffers, but I soon found out that tabs in Vim don’t show buffers.
They show, in essence, separate instances of Vim. Buffers open in one tab will not show up in another tab. EDIT: As VimGuy points out, they do contain the same buffers. Tabs are more like separate layouts of your currently open buffers.
So what’s the point? With all the options to organize your buffers and manage your files (BufExplorer, NERDTree, split windows, etc, etc), what are the tabs useful for?
At my new job, there are 3 separate, large, codebases. Yesterday I was working in one system, coding away. Probably 20 buffers open, all related to the same project, when one of my coworkers asked me to help him in another one of our systems. I didn’t want to lose my place, or vim “state”, as it were, and intuitively I created a tab, opened up a new instance of NERDTree in this tab, and started opening new buffers related to the second system in this tab. In the first tab, all my open buffers and split windows were still there, waiting for me to get back to them.
A minute later, it suddenly occurred to me, “So THATS what Vim tabs are for.”
In December, 2007, I was watching the History Channel, like I often did at the time. I’m not sure what show was on, but the episode was, I think, about ancient instruments and early music.
This sparked a wikipedia session, where I looked up the origins of my own favorite instrument, the guitar. I found out about one of the guitar’s cousins, the Lute. I wondered if people still played it, and looked it up on…