Android Shogi app with Bonanza engine

I updated an old Android Shogi (Japanese chess) app that uses the Bonanza engine to work better with newer devices (and I also simplified it a bit). I also added optional animal-themed pieces (like in Dobutsu Shogi in the Greenwood) as that's what I'm more used to from playing with my kids.

Google Play: https://play.google.com/store/apps/details?id=mobi.omegacentauri.shogi

APK: https://github.com/arpruss/AndroidShogi/tree/main/app/release

Source Code: https://github.com/arpruss/AndroidShogi

[Note: the Bonanza engine is for non-commercial use only]

Gamifying planking

There is research that some video games can relieve pain. And boredom saps endurance. So the Stealth board product which lets you play games on your smartphone while doing core exercise on a specially shaped balance board seems to be a rather fine idea. But it's too expensive for me. So instead I cut a foam overlay with a phone slot and put it on my home-made balance board (with grippy skateboard tape). And the two free games for the Stealth board work great with this (I haven't bought their premium games).

Trivial Instructable here.

Result: I can plank more time on this than I can endure ordinary planking. Admittedly, the fact that the games involve some motion make the exercise less static. But it's still probably good core exercise.

Wobble board, gamified

Last year, I made an adjustable wobble board for balance practice: a plywood disc with a 3D-printed plastic dome rocker. One thing that I always wanted was some sort of a device that would measure how long I was staying up on the board, detecting when the board edge hit the ground. I imagined things like switches under the board or even a camera trained on the board.

But what I forgot is that I already carry the electronics for the detection in my pocket. A smartphone has an accelerometer, and so if it’s placed on the board, it can measure the board angle and thus detect the edge’s approximately touching the ground. I adapted my stopwatch app to start and stop based on accelerometer values, and made this Android app. Now all I need to do is lay my phone on the board, and when the board straightens out the timer starts, going on until the board hits the ground. There are voice announcements as to how long I’ve been on the board, and a voice announcement of the final time.

Source code is here.

Instructions on building the wobble board and links to the 3D printable files are here.

One forgets how many things can be done with a phone.

I think my best time is just under a minute, with the board set to a 19 degree maximum angle.

Giant numerals stopwatch app

I do two activities where it is nice to have a stopwatch one can see from a distance: lap swimming and lap (indoor) rock climbing. I found one stopwatch app with large numerals, but they weren't large enough for my taste, so I ended up writing my own with the absolutely biggest digits I could (and lots of customizability and various extra features, like a start countdown).

For any Android users who want it, it's here. Source code is here. No ads, no in-app purchases. The app keeps track of the time even if it's navigated away from, and doesn't use any CPU time then. It should even continue keeping track of time if the device reboots or runs out of battery, though perhaps with some loss of precision. The lone permission in the app is to let it run on boot (to adjust the time in case it's running through a reboot).

For climbing, I leave my phone on the ground and easily read it from 50 feet up. For swimming, I put the phone in a freezer bag, and stand it up by the edge of the pool. In foggy dark goggles, I can read it from several yards away, which is good enough for pacing. (Our pool only has one analog wall clock which I can't read in foggy goggles.) Having time feedback as I swam encouraged me to improve two of my swim times (maybe it helped with pacing, too).

Curiously, in an early version I found that there is some bug in the font renderer on my phone: at maximum size, some digits were left blank on the screen (perhaps nobody anticipated drawing text so large that if it had descenders they wouldn't fit on the screen). So I wrote a python script that used a font library to convert digits, colons and minus signs to java code with the Android Path class.

The landscape screenshot shows it running in fullscreen mode with the classic German DIN 1451 highway sign font (and aspect ratio preservation turned off for even bigger digits). The second is with a standard Android Roboto font.

Vector display for Arduino-type boards

It's a nuisance to buy an LCD for each new Arduino project that requires a display, so I wrote an Android app that lets you use a tablet or phone as a display for an Arduino-type project. As a result, one can use a $2 board as a rudimentary oscilloscope with a phone or tablet providing the power, display and UI.

Instructions and links here.

Nostalgia: Use Palm infrared keyboard with Android phone

I am probably the only person interested in this sort of thing, but in case anybody has an old PalmOne infrared keyboard and for the sake of nostalgia or convenience or whatever wants to use it with a newer device, I wrote up instructions on how to interface the keyboard via Bluetooth.

Talking of nostalgia, doesn't the phenomenon suggest that there is something not quite ideal about our current relationship to the past? The past is really real. So why feel nostalgia, when our past actions and experiences are really real? In heaven, perhaps, our memory will be so vivid that our past lives--transformed in a hindsight illumined by the beatific vision--will be fully present to us.

My unkillable Treo 700P

I bought my Treo 700P phone second-hand on ebay in 2008, and it's served me faithfully.  I've written enough apps for it so it works very much like I want it to work.  I only really wish it had a better web browser, but it's good enough to check my email on.

At one point, maybe a year or two into its service to me, I had to use an app to turn on the microphone and speakers to make phone calls, but this was fixed when I blew out the headphone jack--I think it was stuck in thinking that there were headphones attached. Two or three times, I've had keys become less reliable, but that's an easy fix--I just disassemble the phone, peel back the keyboard, and clean the contacts (acetone works well).

Yesterday, I thought it had finally kicked the bucket.  We had an on-campus Fiesta event, and there was a small pool of bubble solution, and my son and I were making bubbles, and the Treo slid from my shirt pocket into the bubble solution.  I checked that it didn't work, removed the battery, disassembled and dried it at home, and it still didn't work.

I then spent several hours looking at what Android options Sprint had for me.  I wanted a large screen (4.3" is really the smallest I'd want, at least in wide-screen format) and a hardware keyboard (on-screen keyboards aren't very good for typing serious technical emails, especially if you need to use braces and the like--apparently a lot of people don't use them much).  Alas, nothing met my desiderata.  The Galaxy S II had an OK sized screen (4.5") but no keyboard, and the Galaxy S had a keyboard but the screen is little too small (4").  Granted, my Treo's screen is much smaller, and its keyboard symbol support isn't great (but I wrote an app that helps with that), but if I am going to upgrade, I'd like to upgrade to something that will satisfy me, rather than make me wish for something else.

I was planning to drive to the Sprint store and get a Galaxy S this morning, when I did the last check of my Treo and found that after drying out more fully overnight, it's now back to good working order.  I wonder how many more months or years it'll last me.

Update: It's finally dead--see comments.

Moon+ ebook reader for Android

In the summer, I tested ten ebook reader apps for Android, looking for something that worked well with large documents. My best choices were Moon+ and Mantano, but neither was ideal. Moon+ took 20 seconds to open the Summa epub, though it searched it in a speedy 20 seconds, and Mantano opened it almost instantly, though it took 80 seconds to search.

The Moon+ developer has just pointed me to his latest apk of Moon+ which improves the Moon+ loading speed significantly It can now load the Summa in 10 seconds on my Archos 43, and probably faster on faster devices. The search seems to be slightly slowed down, to about 23 seconds, but that's still quite decent. Moon+ is now clearly the best reader for large documents if you want searching, and is all-around an excellent reader. So I think I'm close to the point where I can start converting my large library from Plucker to epub.

I've accordingly updated my mini-reviews of epub readers.

Further update: On my new Epic 4G Touch (the Sprint version of the Galaxy S2, though a bit slower), it takes 4 seconds for the latest Moon+ to open the Summa, and 25 to search.

My search for an Android ebook reader

[Edit: I edited the Moon+ review to take into account the latest version as of January 5, 2012. -ARP]

Every couple of weeks, my Palm TX stops working, and the only way to get it working again is to short out its battery quickly in order to clear out the RAM (disconnecting the battery would work, too, but then I'd have to unsolder it and resolder it; hmm, maybe I could solder in a tiny switch?).  So I need a new home for my large ebook collection.  It looks like the current options are iOS and Android.  But iOS development requires a Mac, plus iOS is notoriously closed.  So Android.

I acquired an Archos 43.  I don't particularly recommend the device, but it has the advantage for me of not being a phone (so I don't have to switch from my grandfathered-in phone plan that gives me unlimited Internet on my Treo at a ridiculously low rate), plus a manufacturer who has a very open attitude.  A happy thing: PDF readers for Android are an order of magnitude better than PalmPDF (though PalmPDF was a great step forward from Adobe's reader for Palm), and the higher resolution screen is quite helpful.

But what about non-PDF ebooks?  It looks like the standard format of the future is epub.  So I converted my Plucker version of Aquinas's Summa Theologica to html.  This generated 626 html files (about one per article), total size 25 mb.  These html files use very simple formatting, which should make them easily convertible.  I then converted the html to epub with Calibre.  Options: 260K segments, don't split on page breaks.  Result: a 6.9mb epub file (the Plucker file was 5.6mb).  This is quite large as epubs go, since most epubs are novel-length, rather than Summa-length.

What would I like in an ebook reader?

1. Speed (I don't want to wait 30 seconds to open the Summa at a conference to look something up prior to asking a question). 
2. Good searching at a decent speed through large texts.
3. Multiple bookmarks/annotations.  
4. Good use of a small screen.
5. Scrolling rather than paging (this is a taste preference, but I think paging is a left-over from dead-tree technology;  why should one have to flip back and forth to see a difficult passage that is broken between pages--one should just be able to scroll to locate the passage conveniently).
6. Open source.

Item (1) and (2) are essential.  Item (3) is close to essential, but I find I don't use Plucker's bookmarks/annotations quite as much as I thought I would.

I tried: Moon+, FBReader, CoolReader, Aldiko, the Nook app, StarBooks, Foliant Beta, Mantano Trial and the Kindle app.  FBReaderJ and CoolReader are open source.  I don't know about Foliant and StarBooks.  The others are closed source.  All are free or have free or trial versions which is what I tested.

Summary: None of the readers was 100% satisfactory for my purposes.  Moon+ and Mantano are the best choices.  Moreover, both have very responsive developers who are interested in working with me on large text issues.  If you care more about searching than opening large documents very quickly, Moon+ is the choice.  If you care more about opening large documents very quickly, Mantano is the choice.  But this may change with future versions.

My main tests were just opening the Summa and searching through it for the nonsense word "trubbli".  As background for the speed tests, the Summa opens in two or three seconds in Plucker on my PalmTX, which is underclocked to 208mhz, and a search through the Summa takes 41 seconds.

The Archos has a 1000mhz CPU.  The epub format is basically zipped html files, each at most 260K long, with some additional meta-data.  It should be possible to extract a single file from an epub zip just about instantly, to open an epub file it shouldn't be necessary to do more than open some meta-data files and then load the correct html segment.  It takes the Archos 0.05seconds to unzip a 200K file (unrepresentatively large) from my summa2.epub file using busybox's unzip.  Unzipping all of the files in the Summa takes 17 seconds on the device, and then searching them with grep takes less than two seconds.

Moon+: This was the first reader I tried, after hearing really good things about it. This mini-review is edited as of January 5, 2012, and is of the version downloaded from the developer's site. It takes 10 seconds to load the document. That is slightly disappointing--I thought it would be like Plucker, namely almost instant.  Display options are great, scrolling is great.  I haven't tried the annotation features, but I've been told they're good.  Search took about 22 seconds, which is close to the best that one can expect given how long unzipping the epub takes.
The developer is great and responsive. For instance, the version I tried in the summer took an unacceptable 20 seconds to open the document, and the developer has worked on reducing this. Moreover, the summer's release had an annoying dialog each time you clicked on an intra-document link, but it's now gone.

Apart from the imperfect 10 second load time, Moon+ is great. You can scroll, you have a ton of display options, etc. It is the best choice right now for large ebooks as far as I can tell. And the 10 second load time is decent given some of the competition.

FBReader: This is open source, which means a lot to me as I don't expect any reader to have all the features I want, and so I expect to have to add features myself.  It took about 40 seconds to load the document, which is unacceptable.  Search time was a creditable 20 seconds.  Since the opening time was utterly unacceptable, further tests were unnecessary.

Coolreader: Another open source offering.  Took a minute to load.  Took three seconds to flip a page.  I couldn't click on any of the links.  Didn't try any more as it was not usable.

Aldiko: A pretty popular closed-source reader.  It loaded the file instantly, thereby showing that there is nothing intrinsic to the epub file structure that makes that impossible.  But the search was unacceptably slow at  about 74 seconds.  Moreover, it pages rather than scrolls, which is annoying.  I didn't try any more as the search speed killed it as an option.

Nook: Annoyingly, it wants epubs in its own directory, and doesn't let you browse the file system to get to them, like other readers let you.  It also loaded the file instantly.  However, it had really annoying large margins, showing too little text per screen.  Maybe it's optimized for larger screens (the Archos has a 4.3" screen), but such large margins should be adjustable in the app, and I couldn't find an adjustment for them.  The deal-killer was the search.  After two minutes it wasn't done, and I gave up and uninstalled it.

Starbooks: After about 20 seconds of first-time importing, it loads instantly.  Page-based model.  But no search!  So, that's that.

Foliant Beta: It took a while to scan the Summa, but it cached the scan, so next time it started instantly.  Developers whose model requires the epub to be all scanned (which I am guessing is what is behind the unacceptable startup times on otherwise good apps, such as Moon+ and FBReader) should take note.  Search speed was marginal at 35 seconds, too, and it scrolled fine.  The killer was that I couldn't click on intra-document links, and I couldn't change the absurdly large font size.  The inability to click on links makes books like the Summa which seem to have been written with hyperlinks in mind (wasn't St Thomas ahead of his time?) unusable.  However, it is a beta version, so it may improve.

Mantano: Starts the Summa instantly.  Unfortunately, like many readers, it's page based rather than allowing for continuous scrolling (why pages? most page breaks are an accidental division with no semantic value).  And as with a number of other readers that started the book instantly, searching the Summa was slow, about 80 seconds.  I was using the free seven day trial.  Unlike the other apps, Mantano has no permanent free version.  However, Mantano has an extremely responsive development team that collects suggestions, and it looks like they are quite interested in working on these issues.

Kindle: Unlike the other apps, this doesn't have epub support as far as I know.  Fortunately, Calibre can convert to Mobipocket format, too, so I put a Mobipocket conversion of the Summa, based on the same html files, in the Kindle directory (like some of the other apps, it only reads books in a special directory; my beloved Plucker on PalmOS does that, so I don't complain too much).  It opened in a second or less.  However, it is page-based, with no scrolling.  More seriously, the search.  The good news is that unlike most other apps, it has a progress bar for the search.  The other apps mostly just show you a spinner and so you don't know what percentage has been searched.  The bad news is that I started the search around the time I started writing this paragraph, and it's still going.  It's now about 3/4 done, and my timer says that it took 4 minutes to get there.  It's definitely one of the slower searchers.  Since Kindle is the big name in ebooks, I'm going to let the time get to the end.  Almost there.  Finally: "0 results for 'trubbli'."  I missed the exact time of finishing, but it was around 6 minutes.  Wow!  How did they manage it to be so slow? There is also a subpixel rendering bug, at least as January 5, 2012.

Conclusions: I have yet to find anything that works as well for my purposes as Plucker on my 5+ year old Palm TX, though the faster search speed of Moon+ almost compensates for the slower document opening speed.  Perhaps I should try readers that use other formats than epub, like Mobi.  Or perhaps I should just take Coolreader or FBReader and bang on the source until it does what I want it to do.  Or perhaps I should just wait until something comes along that is compelling better than Plucker on Palm.

Or maybe I should just keep on downloading epub apps.  I'll post comments with test results on other epub readers or update the post.

PDF Viewer for Android

I acquired an Android device, but haven't been too happy with any of the free PDF viewers I tried for ebook reading. E.g., some don't keep your place in the document when you exit. Anyway, the closest I found was the APV project, and it being open source, I joined and added most of the features I wanted. In case anybody else wants an acceptable and free PDF Viewer for Android, a pre-release version with a whole bunch of enhancements by me is here. Send me bug reports.