android – The Industrious Squirrel

Experimenting with Bluetooth

One of the challenges writing games for the touch-table is handling hidden information. So far we have used two solutions: Physical blinds that rest above the sensor and block the view of the other players, and a touch-to-reveal system where the player blocks the view with their hand and touches the screen to reveal their cards.

Many of our users have smartphones, and I thought that it would make sense to let them use their smartphone for the display of the hidden information. In the past, have experimented with a web based system where the game is hosted on a webpage and played on browsers. This works, but when the game is written in C++ for the touch-table, the game has to send data to the web-server so that the clients can display it. This creates extra overhead and lag.

Instead, I thought it would work better to send the hidden information directly to the phones over bluetooth. So I set out to write a C++ server that would use bluetooth to broadcast data to Android clients. This ended up being more difficult than I expected, but I did get it to work and wanted to post what I have done.

Continue reading “Experimenting with Bluetooth”

Rooting my Android phone

This morning I rooted my android G2x. The main motivation was curiosity, but there were a few things that I wanted to improve about my phone. T-Mobile didn’t pre-load too much junk onto the phone, but there was the T-Mobile app-pack and Mall, Nova and Tegra game stores, and the lite version of TeleNav. Also, to get a good ad-blocker you need to have root access.

So I took the plunge and rooted the phone. There was a point when I thought the phone was bricked, but it all worked out in the end.

Even without the mistakes that I made, I would say that the benefits do not justify the effort (at least for my phone). I am glad that I did it, but more for the experience than the end result.

Continue reading “Rooting my Android phone”

Practice Log Webapp

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.

Continue reading “Practice Log Webapp”

Practice Log published

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.

You can get the C# application on my site: http://chadweisshaar.com/weissoft/practicelog and the Android app from the Marketplace.

Practice Log – Android+MultiUser completed

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.

Here is what the app looks like:

Practice Log – Android version

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.

Duration Alarm

I have had an Android phone for a while now, and one of the reasons that I picked that particular phone was so that I could create my own applications without going through a central marketplace. Until now, I have never actually done it. The Android marketplace has had all the utilities and apps that I have wanted. But I’ve decided that I want to learn how to write software for Android and there is an app that I have always vaguely wanted and haven’t found.

The app is a duration based alarm. This is a common way to set an alarm for a nap, but I would like to use the same system for an over-night alarm. Since I don’t have a day job, I don’t have to get up at any particular time, but I’d like to limit my sleep to the amount of time I need.

The application is simple enough to be a good problem to learn Android development with.

I have had bad experiences with Java and eclipse in the past, so I’ve decided to do all my Android development in a virtual machine. I used Oracle’s Virtual Box and an old copy of windows XP. While the Virtual Box software is nice (especially since it is free), this took a lot longer than I had expected. I had forgotten how old windows XP is and I spent hours installing updates. Installing eclipse and the android SDK went fairly smoothly and once installed, I was able to hook up my phone and run a sample app through the VM.

The Android SDK documentation is good, and the sample apps provide a lot of examples to follow and I was able to make quick progress on my program. The GUI builder is not bad, but I spent half the time editing the XML directly anyway. The hardest part was the lifecycle. It takes a while to get used to the idea that your program can be killed and re-started with very little notification.

The app took about three days of me working on and off. I was impressed by the Intent system which allowed me to easily use the built in alarm software to handle the alarm part while my app just does alarm scheduling. I was least impressed with the resource ID system and java in general. I have always disliked java and this project reminded me of all the ways that java makes my code ugly and my coding sloppy. There may be a better way to do this, but the default mode for the resource ID system makes all the GUI elements into global variables.

I used the local database to save off the user’s last alarm duration. Once I got used to it, that is a very convenient system. Much like what is built into C#.

I have no plans to put the completed app on the Android Market. It works fine, but I have no desire to test it on other phone models.