Wow. What ... sloth!

It's Feb 26th, 2011 and I'm trying to get back on the wagon for Android programming. Once again hitting the Android Wireless Application Development book. This time around I have a Nook Color to play around with.

I ran into some issues getting Eclipse 3.6 installed on my Win7 x64 machine. Turns out it's looking for the JDK in a spot different than where the x64 Java installer puts it. Yay. Found a workaround on the 'net where you export your Java node and put in references to Wow6432 or some sort. That worked. However, Eclipse 3.6 has issues with Content Assist... in that it takes upward to 30 seconds when you are typing something before it will show any methods. Not nice. Downgraded to Eclipse 3.5.1 and that cured that problem.

The plan is to hit B&N tomorrow and get together with a buddy to discuss an Android app we can work on. I'm thinking a port of an open source SNES would be a good candidate.

That's it for now.

Restarting

Well, it's been a while since I've done ANYTHING. So, I'm going back to square one to get a better foundation of how to program in Java. I picked up a 8lb, umpteen page book entitled Java How to Program by two Deitel guys.

Chapter 1 gives the reader a basic background in computers, programming and so on and covers setting Java up on your machine. One notable thing is the "politically-correctedness" of some of the example programs which I find particularly aggrivating: calculating your carbon footprint (if you are part of the Global Warming, ooops, I mean Climate Change cult), calculating the BMI (bogus and unscientific way of determing whether or not you are obese), and an app for Gender Neutrality (claiming that gender based words are above all things SEXIST - adored by metrosexuals and psycho-feminist freaks). Really? Wear your politics on your sleeves much, guys?

Notwithstanding the PC BS, Chapter 1 has been ok and I like the presentation of the information. Looking forward to chapter 2.

The road goes ever on and on...

I'm going to bail on getting the Chrono thing working to my satisfaction. I think what I might end up doing is going with some sort of OS tick listener (or however they are called in Android) and give it an update rate of 500ms.

For now, though, I really would like to get an analog clock thing going. Anti-clockwise even. We'll see how it goes!

Favorite Android Apps

...and now for something unrelated to programming: favorite Android Apps. As I mentioned in my First Post!, I've had my HTC Eris since a little bit before Christmas. I can't say I've sampled a TON of apps, but I have a few that I really like. In no particular order here they are:

- NewsRob. Man oh man I like this app. It's an RSS app that connects to Google Reader. I find myself surfing news sites less and less and allowing this app to grab the stuff I'm interested in. I can quickly scan headlines and read only the things I'm interested in. Surfing typically means I'm skimming headlines and content so this makes that kind of activity even quicker.

- Craignotifica. This app allows you to get Craigslist updates on your handheld. I've got several filters set up for For Sale: books, electronics, etc. Very handy to have!

- Dolphin Browser. This is a web browser. I like it in that it is able to load things in the background and it implements tabbed browsing. A few peculiarities it has is: the method for bringing up your favorite links isn't very intuitive; I haven't found the way to alphabetize my favorite links; it lacks Flash support that the built-in web browser has. That last one is a good and bad thing -- I normally don't like to visit Flash heavy sites, but when I do, it's annoying that I can't view them in Dolphin.

- Locale. This is a neat little program that sets up various properties on the phone based on your location. I have a default setting, and then a "At Home" setting and "At Work". At Home, I have it turn on Wi-Fi and crank the volume. At Work, I have Wi-Fi turned offer and have the volume subdued. It has other features too. Neat!

- Aldiko. This is a reader program for .EPUB files. I've got a ton of e-Books and this will essentially replace Stanza that I was using on the iPhone. On a related note, the Calibre program is compatible with the Android (at least, it recognized it the other day when I had it running and connected my Android up). I need to play with Calibre & Android a bit more to get the full power of that setup.

- ASTRO. This is file explorer for your phone. It can cruise through the SD card and allow you to do things that you'd otherwise need to be hooked up to a PC to do. Very cool!

- WifiScanner. Handy for sniffing around for nearby Wi-Fi networks.

- Advanced Task Kill. Nukes applications on contact. Nice for regaining memory and nuking apps that otherwise could be sucking down battery power.

- Honorable Mention: Barcode Scanner. Reads in barcodes via the camera and allows you to search the net for lowest prices.

Chronometer class

I've been messing around with the Chronometer class. It's a weird little beast. It only has one direction of timing -- and that's "up". It also continuously updates even when stopped. Stopping just affects the text field updates -- the timer keeps on running in the background. So, if you stop it and then start it, you'll see a jump in displayed time as the thing takes off again.

To get around these idiosyncrasies, I created a derived class that I named ChronoRelative. I gave it the option to count up or down, and stopping the object halts accumulation. It works. Meh, sort of. Running it on the emulator, I've noticed that occasionally it likes to skip over a second. We're talking about once or twice a minute. Ugh. Very annoying.

I think this stems from a couple of issues. The emulator is just that -- an emulator. It's not going to operate as fast (slow?) as the real device. My host machine is a beefy Intel Quad-core Q6600 running close to 3GHz. Still, depending on the emulator, even this may not be fast enough. The other issue might be due to the code that I implemented in my derived class. When the timer changes, it calls OnChronometerTickListener. I use this to insert a check when the chronometer is configured to count down. There are some multiply and (worse) division operations going on as well as some parsing of text fields. All of this could be inducing a time delay to cause the problem.

I tested my derived class in a "count-up" configuration. This has minimal code in the listener method. I still see the problem of skipping a second, but it is not nearly as frequent as when I have it in the "count-down" configuration.

I need to explore a few options first. First and foremost -- can I minimize the amount of calculations that my listener performs. Will this have an effect? Second, and maybe more importantly, how does the code behave on the actual device? If the 'real' device doesn't have any problems, maybe this is a problem that I can just ignore.

Time to attach my HTC Eris...

Chess Clock, Step 1: Begin at the beginning

The first thing I wanted to figure out was how the chronometer worked. I expected to find a method that allowed it to either count up or count down. Such is not the case. Using Google, I was led to the awesome site StackOverflow.com. I've used this site before with programming questions I've had in the past. It's got a great user base and a very slick interface for sharing information.

Anyhow, I came across this post right here. It turns out that a little bit more Magic is involved to get things going. Not that it was overly complicated, but I wanted to lead up to getting the timer going so I opted to take a look at how to implement a simple paired set of buttons. The toggle button fits in quite nicely here. It takes care of its internal state (checked / not-checked). All I needed to do was extend the functionality a bit so that each button toggles the other button.

I fired up Eclipse and started a new project named ChessClock01 (expecting multiple iterations as I develop the app). I used the main.xml layout to establish a very simple interface - the exact layout is the least of my concerns at this point... I just wanted to get the basic element operation going. The layout consists of two Chronometer fields and two ToggleButtons. Further, I updated strings.xml to include textual definitions so I've got a one stop-shop for text definitions. That also allows me to re-use definitions that propagate throughout the whole project.

The ToggleButton is derived from CompoundButton which is derived from Button. The important methods I care about are: isChecked(), setChecked(boolean checked), and setOnClickListener(OnClickListener I).

isChecked allows you to determine the current state of the button. setChecked lets you set the state of the button. setOnClickListener allows you to do something when the button is clicked.

The chess clock has two buttons. When both buttons are off, the first button press will start the associated timer to countdown. When a button is on and is pressed, it will stop that timer and start the other timer. When a button is off and is pressed, nothing should happen. This is behavior is achieved via the listener that is configured with setOnClickListener.

Observations: on the emulator, it appears that the listener is executed before any of the UI graphics are updated. In the listener, when I detect that a button isChecked, I look to see what the state of the other button is. If it is off, I let it stay active and have a TODO: that will start the associated timer. If it is on, I force the clicked button to go back off. Doing this "just works". I half-expected to see the off button to "flash" On briefly before being turned back off. That didn't happen so I'm happy that no further action really needs to be taken.

SIDE NOTE: I discovered that if you go into the DDMS view in Eclipse with the emulator running, there is the option of taking a screen capture of the emulator:


Here is the current incarnation of my app. I've got button toggling operation defined and working. Chronometer isn't happening yet. Not much to look at but it's a start!

And now, for my first trick

Rather than dryly read through AWAD Chapter 6, I think I'll come up with an example that applies some of the concepts contained therein. As I was flipping through the pages, I noticed the Chronometer and toggle button widgets. That gave me the idea to develop a simple chess clock. I've got two things going against me at the moment -- I've never written a single program in Java and this is my first non-trivial (to me!) Android app.

With that in mind, let's get the requirements out of the way:

1. The Chess Clock will be set up for two players.
2. It will have two analog clock graphics that count-down in time as well as textural or similar digital counterparts. Want 3 hands on the clock: hour, minute, and seconds.
   
3. There will be two buttons displayed underneath each analog clock.
4. When a button is on, the corresponding clock will count-down.
5. A button can go from on -> off state, but not the other way. This simulates player 1 hitting "done!" on his button and automatically activating player 2's clock. The button itself should say "done!" or "stop!" to indicate the activity that occurs when the player presses it (exact text TBD).
   
6. Overall game time should be displayed in digital form, defaulting to 30 minutes but configurable through some means (changing game time method is TBD). Each player will then have game time / 2 assigned to them at the beginning of the game (therefore 30 minutes = 15 minutes a piece).
   
7. Display a graphic next to each clock giving another indicator of which player is active: use a green circle indicating that player is "active" and a red circle if that player is "inactive". Alternately, use a button that indicates this. Exact method TBD.
8. Make provisions that allow for sound alerts to be activated when 5 minutes, 1 minute, 30 seconds, and 10,9,8,... 1 countdown.
9. Need a method to reset the clocks, but also need to prevent reset from accidentally being hit.
10. Clock should somehow override the power-saving / blanking feature of the phone.
11. Verify interrupted operation. Clocks should suspend when this occurs.