I have spent the last couple days working on my Practice Log application. I make the website for downloading the application nicer looking, wrote some documentation, created a simple web application and added a couple features to the android app.
The website: weissoft.com/practicelog looked pretty bad and may have been discouraging people from downloading the software. The new look is better:
I am not a web designer, so it is still lacking some polish. I used some of the css from the wordpress theme that this blog is using and the free icon that the application itself uses.
The PracticeLog application has been released as freeware and the Android version is available on the Marketplace!
After using the program and app for a week and really enjoying the convenience, I have decided to make it available to the public. In the unlikely scenario where this application becomes popular, I am worried that it may cause too much load on my web server. So I wanted to have some kind of potential revenue stream to offset this risk, but didn’t want to try to sell the software. So I have gone over to the dark side and added an ad to my Android App.
My first attempt to add the ad was a failure. I thought that I would use the Webkit GUI element to display an ad from my website. To that end I tried to setup Google AdWords but was rejected because the PracticeLog page had insufficient content. (At the time it wasn’t linked to the rest of my site). I know now that this isn’t the right way to put a Google ad in an Android App. The right way is AdMob. This is a free an painless system and they have an SDK that you add to the android app. (Note that you do have to be building the app with the latest version of the Android SDK to use AdMob.)
Putting the app onto the Android Marketplace was a bit of a pain. First you have to pay Google $25 for the privilege. This is a one-time fee to register as a developer, but it did make me hesitate, since I doubt I will ever make enough in ad revenue to pay for it. Then the app has to be digitally signed and you have to have perfectly sized screen shots and icons. This was all a hassle, especially through the slightly buggy VirtualBox VM.
Publishing the C# application was a little easier, the main hassle being adding it to various freeware sites. Fortunately, several of them accept .PAD files. This is a file that describes an application and the developer that the freeware sites can read to fill in their submission forms. It had been a long time since I had visited some of these sites, so I also took the time to let them know about the latest version of the MediaDB program.
So far I have 9 downloads and 7 users, 39 ad views, 0 ad clicks and so $0 in revenue. Of course it is still early and I am not really expecting this program to be very popular. Most people who are keeping a practice log are children who don’t have Android phones.
If it does become popular, I will add a “teacher” mode so that a teacher can have access to the practice logs of their students. The teacher could track their practice time and use the notes to assign tasks for the week.
The changes to the PracticeLog application and the associated android app are completed. They both access the database on my website through the php interface.
I have created a simple user system:
When you create a new user, I store the username and email along with an encrypted password and generated GUID in my user table.
When a user logs in, the given password is encrypted and compared to the stored password. If correct, the GUID is returned.
The other tables are accessed by the users GUID.
The C# changes were fairly simple. I created a login/new-user dialog and left the local database code so that someone could use the program in a offline mode if they didn’t like the idea of logging into my website.
The Android app was a much bigger job. I was able to use all built-in GUI elements, but the life-cycle issues were much more serious than they were in my first Android application. I didn’t want the user to have to log in every time, so I store the users GUID in the application’s configuration data. I also needed to preserve both the timer’s start time and the entered but unsaved practice time when the application is killed. I learned how to prevent the screen rotation from happening and learned how to store the downloaded data from the web during a screen rotation.
Testing the app was a hassle because my phone loses its connection to eclipse after a few seconds. This is probably a problem with the virtual machine that I am using to do the development with. If I had it to do over, I would go ahead and install java and eclipse on my main machine.
I am still considering releasing this application and app, but would like to figure out the ad model for the android app.
I have been using the PracticeLog for a little over a year now and have found it to be very useful. However, there are several features that I never use:
The list of pieces that I am practicing. This would be nice to keep up to date, but even with the “Same as Yesterday” button, I just don’t have the motivation to keep entering the data.
The stopwatch and countdown. I haven’t been practicing in the same room as the computer, so it is not handy to have to turn on the computer both before and after practice time. Instead I have been using a stopwatch on my phone, or just my watch to time the practice and then separately enter the time.
I would like to use my Android phone, which I usually have on me, to record the practice time. To do that, I am going to create a web database and php accessors so that I can load and update practice time from the phone or computer. While doing this conversion, I am going to make a few changes:
Remove the list of pieces practiced per day. It would make the database more complex and I never use the feature.
Make the database multi-user. This will allow me to publish the application and Android app. I am not sure if that will ever happen, but the software has been useful for me, so it might be appreciated by others too.
This will be the first time I have made a multi-user web database, so I am debating how to handle security. I want each user to only have access to their own data, but don’t want the overhead of encrypting all the data.
After my experience with the DurationAlarm application, I suspect that the Android app will take most of the time. But all of the GUI elements that I will need are built in.
I have finished the PracticeLog software. Here is what it looks like:
I am happy with the software. I created countdown and stopwatch timer modes so that the program will time my practice and automatically update the log for today. I added the “Same as Yesterday” button since I practice a particular set of pieces for at least a week at a time.
I also put in a “10000 hours date” field. This is the date when I will have practiced 10000 hours. I have recently read Outliers by Malcolm Gladwell and am intrigued by the notion that, while talent matters, becoming an expert is mostly a matter of putting in the time practicing.
I am staring work on a new application for my own use. It is called the Practice log and I plan to use it to keep track of the time that I spend practicing violin. When I started violin, the first book contained a paper log where you would fill in your practice time each day and it had a column for your parents to sign off on the entries. When I switched over to the Suzuki books, the books no longer included a paper log. I kept using the paper system for a while, but now I would like to computerize it. I will be able to collect statistics and keep a running total of my hours.
I will keep the paper log format and have a way to add a note and a list of pieces practiced to each day.
I am going to develop this in C# using their DataGridView and a SQLite back end database.