Saturday, May 22, 2010


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.

Tuesday, January 12, 2010

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!

Sunday, January 10, 2010

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 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.

Saturday, January 9, 2010

Who's a widget?

There are currently two concepts that relate to the term "Widgets" in the Android world. First, there are the basic, elementary elements (did I just say that?) These are your buttons, text fields, etc.

Second, the "AppWidget" was introduced in Android SDK 1.5. If you use Vista or Windows 7, and AppWidget is a lot like the "Gadget". An application that runs on your phone that gives you a quick and easy interface. Examples I've got installed on my phone would be tip calculator, calendar, live newsfeed, and "This day in history". Think of it as an app that is running that you don't necessarily have to "run" to interact with.

It looks like AWAD Chapter 7 deals with AppWidget. I'm looking forward to that. Need to learn the basic widgets first which is the meat of Chapter 6.

Language dependent resources

Language dependent resources (think: Text strings, but it applies to other data as well) are handled very simply and independently of anything you have to program. It goes like this: all of the strings that your program is going to reference are defined in a strings.xml file. Each entry in this file consists of an element that defines the string's name, and value that defines the actual string.

From a program standpoint, you don't directly access the string value. Instead, you work with a reference to that string. To support multiple languages, you define a sub-directory in your /res directory that reflects the language selection, and then maintain a separate strings.xml file in THAT directory using the SAME string name. It's probably a good idea to have /res/values/strings.xml defined for your defaults. Then, to localize, add /res/values-es if you want to support Spanish (for instance). The extensions on that directory are based on whichever language you elect to support. The extension go further down into specific regions. For example, /res/values-en-rGB references English, Great Britain (to prevent heavy weeping over "center" vs. "centre", and "trunk" vs. "boot", I guess.)

If you had the following defined in your /res/values/strings.xml file:

<string name="WaterStr">Water</string>

...and you wanted to display the equivalent for Spanish users, you would define the following in /res/values-es/strings.xml:

<string name="WaterStr">Agua</string>

The one area I'm not entirely certain about is whether the file name needs to be the same. If I have multiple files defined, couldn't I just combine them into a single file rather than creating multiples in each directory for each language? I don't think the aapt tool cares how things are defined -- just that they are and are located in the correct sub-directory.

Further, I'm guessing if you don't have something defined in a language specific file, it will simply default to whatever value is given in /res/values. In the example above, if I failed to define the Spanish version of WaterStr, the default WaterStr would simply be used.

Next chapter in the AWAD book deals with Exploring User Interface Screen Elements. Finally getting to some good stuff. Wahoo.

Default System Resource definitions

Found what appears to be an error (or maybe just an outdated reference) in the Android Wireless Application Development book. Default System resource definitions, such as certain system colors, animations, etc are found in:


The book mentions they are found in /tools/lib/res/default. That's not the case for me... I don't even have that directory appear in my install.

Eclipse: Well duh

I'm a SlickEdit person at my job. But, since everything is packaged so nicely for Android into Eclipse I figured I might as well try to go native. Eclipse has got some really cool features - auto-completion, live updates, etc. Couldn't figure out how to open and VIEW multiple source files at once until now. It's so simple.

Open up both files in Eclipse. You should have a couple of tabbed items. Normally, you just click on either/or and that's what you see. To give one of the tabs its own window, simply left-click and drag it down. You'll see your icon transition to an arrow. When you let go when this happens, that file will open up in its own window. You now have multiple windows going. You can configure a side by side or above/below configuration. Woot. Not as quick to configure as my Brief emulation under SlickEdit, but it works.

Now.... where's my second monitor to really take advantage of this? :)

Emulator surprises

Discovered that when you create an emulator configuration and define SD emulation, an image of the SD contents is created at the size you specify. I specified an 8GB SD. AVD used my C: drive to store the configuration. My C: drive had < 8GB of free space and promptly locked up Eclipse. Ooops!

The plot so far

Picked up an HTC Eris from Go Wireless in Fargo, ND about a week and a half before Christmas 2009. Had a lot of fun playing with it and figured that I really *need* to start making my own stuff for it. Did some Googling and found out Java is the language of choice for this Android based platform. So, I picked Head First Java from Barnes & Noble and ordered two Android-specific books off of Pro Android (PA) and Android Wireless Application Development (AWAD).

Spent the majority of the Christmas break diving into Java. I've got prior C++ experience and found a lot of the concepts and syntax to be very familiar. That was definitely cool.

When the two Amazon books arrived after Christmas, I decided to hit Pro Android first. I had read a review that the book's price was worth just the OpenGL ES chapter alone. It may be, but I abandoned it after hitting the Content Provider chapter. Either the chapter order is borked or they just figured too many assumptions for the Android newb. I'm sure I'll revisit it as I get more experience, but it's not a very good book for those starting out.

So, I switched over to Android Wireless Application Development. Excellent book! I'm currently at Chapter 5 and am learning a great deal. Chapter 5 deals with resources and describes how to build the XML files that comprise your resources and also how to do things programmatically from the Java side of things. Very useful and very helpful examples. I'm pretty stoked about what I'm learning.

First post!

All right. This is my first post. I've tried to maintain blogs before, but they never really got off the ground. We'll see how this one goes as I post my thoughts, ideas, and discoveries as I venture off into the land of Java and Android. I'm pretty excited so I think this will be worth the effort.

Who am I? I'm a developer that works for a large agricultural equipment manufacturer (think of the color green and you'll be on the right track.) I've been working for this company since I graduated from North Dakota State University in 1995 with a degree in Electrical Engineering (Computer Option).... aka: Computer Engineering. I've been doing embedded work since that time until now. My work has focused on real-time systems with applications of Assembly and C/C++ to things like displays, engine controllers, transmission controllers, body controllers, etc. Have a lot of experience dealing with various RTOSes, communication protocols (CANopen, SAE J1939, SAE J1587, etc.) I've dabbled into robotics which has been really cool.

Lately my job has been less technically oriented so I'm looking to keep my nerd cred going by learning Java and programming mobile applications on my own time. I live in an area not served by AT&T so the iPhone is out (and there's only so much you can do with an iPod). Verizon on the other hand seems to serve everywhere. I picked up an HTC Eris before Christmas 2009 and have been excited to start developing for it ever since.

So, yeah, I'm looking forward to learning a lot and posting my trials and tribulations here.