RUPRecord now works offline

We published version 1.1.0 of RUP Record yesterday.

This version has the critical Outbox feature. You can now enter the details of a pesticide application and successfully hit Send out in a field where you have no cell service. With the Outbox feature (which we ported over from our SnapToMe Plus app), the record email is queued up and simply waits until you get back in cell phone range and then is sent.

Other, minor enhancements:

  • The app may be moved to the SD card.
  • Matt simplified and unified the various settings into a single preferences list, which should make the app easier to set up and maintain.

Three SnapTo’s and an ERG in the approval process

Matt published new versions of all three SnapTo Android products today, with small but significant usability improvements.

All three apps now show a progress dialog after the Capture button is pressed, while the phone is processing the image. Having the Send button dimmed until the Capture was complete was a bit subtle and led to some users to think they had sent the photo when they hadn’t, if they hit Send before it was activated.

All three can now allow themselves to be moved to an SD card to free up memory on-board the phone.

And SnapToMe Plus and SnapTo Scott Hininger now have Retry All and Resend All buttons to help manage the Outbox queue when connectivity is spotty.

Also exciting:  We submitted our very first Blackberry app to the BB markeplace today.  It is a new version of DOT Placards that we are calling, simply, ERG2008 since that is what it is.  This app is the product of one of our interns, Sara, who has just finished with us and is about to start a full-time job.  We wish her the best of luck and promise to nurse her product through the BB approval process as quickly as we can.

 

Installing an Android app from a web page link

For Sheridan Programmers Guild apps: 

We occasionally want to give one of our Android apps to a tester or reviewer without going through the Android Marketplace.  These can be alpha or beta copies of new apps or preview copies of updates.  There are several ways to distribute such apps.  The instructions here apply to our preferred technique of providing a download url that navigates to a copy of the app sitting on our own website. If you are looking for more general instructions, you may want to check out one of the links at the bottom of this post.

To install an app from a link on our web page, Continue Reading →

New SnapTo’s published today

Scott HiningerToday was a fun day.  Matt published version 1.2.6 of both SnapToMe and SnapToMe Plus — details below.  And he published the very first of our private label apps:  SnapTo Scott Hininger.

Scott’s the Sheridan County Extension Agent with responsibility for agriculture and horticulture.   People are always trying to describe pests and plants and plant diseases to him over the phone so he can help them figure out what to do. Now that his app is in the Android store, Continue Reading →

SnapToMe Plus Published

Porcupine quills in tire (cropped)

I tested the newest version of SnapToMe Plus all weekend while I was out of town and, mostly, out of cell phone range.   I captured a bunch of pictures and transmitted them as we drove home once we got cell phone service back.  I had a couple of usability tweaks that Hokan implemented today and then he republished the app.  Huzzah.

If you, or someone you know, just needs a super simple way to snap a photo and get it off the phone and share it via email, try one of the SnapToMe‘s in the Android Marketplace.  The free version sends the email in the foreground.   The paid version has a background service to do the Send, which allows you to quickly take another picture or close the app without waiting.  The same background service gives you the option of capturing pictures when you don’t have cell phone service at all and having them queue up till connectivity is restored.

Both versions include the date, time, and location when the picture was taken in the email so you have tracking info if you need a record of when/where you saw or did something.

SnapToMe progress

We published a quick update to the free SnapToMe today after fixing a crash reported by user Lnand — thank you!

We’re also making good progress on the paid version, SnapToMe Plus.  It made a brief preview appearance in the marketplace last week.  But when we found out that the background email sending technique we were using wasn’t really ready for primetime, we unpublished and went back to work on it.  I thought I had lost a couple of photos of my own (I didn’t — they were still safely on the phone but had to be harvested by hand) and wasn’t willing to risk that experience for users.  I’m testing the new version this weekend when I’ll have plenty of time out in the country with no cell service, so I should be able to give the background/queued-send feature a pretty good workout.

RUP Record published in the Android Marketplace

We’ve just published the very first version of RUP Record in the Android marketplace:  https://market.android.com/details?id=com.sherprog.rupware.ruprecord

RUPRecord helps private pesticide applicators comply with the record keeping requirements of the U. S. federal regulations on restricted-use pesticides (RUP).  Failure to comply with these regulations can result in civil penalties of $500 or more.

RUPRecord remembers your name and applicator id, automatically records the date, time, and location,  and provides an easy-to-use form for entering application-specific data out in the field.  The resulting record, which meets the USDA requirements, is then emailed to you so it can be printed out and dropped into a file folder.  This makes it easy to comply with the regulation that the information be on file within 14 days and be kept for at least two years.

RUPRecord can be used for recording both spot and area applications.  It builds up a history of the names and ids of the restricted-use pesticides you apply, making it even easier to record additional applications from the same container.  If you don’t have cell phone service out where you are applying the pesticide, you can capture the location when you are in the field and enter/send the data once you get back in range.

RUPRecord joins the recently published SnapToMe as the first products in what we hope will be a long line of phone-based data collection and data distribution apps.

Marketing, research, publication, marketing, marketing, marketing

Cover of Frog and Toad Together

We’ve had a long, tiring, but remarkable, couple of weeks in our corner of the microISV universe. I feel as if I am buried in ToDo lists, beginning with that perpetual task: update ToDo lists.

Does anyone else have fond memories of reading Frog and Toad Together to your children or, since it’s been around long enough, having it read to you? All the Frog and Toad books were a treat. But Together’s story The List about Frog’s day being totally controlled by his ToDo list also had a sort of resonating bite for me.

Anyway, it’s too easy to get caught up in the un-done and the not-done-quite-well-enough, which will be always with us. I’m here this Friday afternoon, instead, to celebrate real accomplishment. The ToDo lists can wait till tomorrow.

The RNFamily of apps

Yesterday, Hokan and I finally published the Android version of PasswordRN. It had been hung up on little finishing touches: a bit more testing and tweaking, a few screenshots, getting the merchant account set up right so we can receive payments. There was really no reason not to push it out the door. And last night, in the middle of the night, the very first copy was purchased and downloaded. What a thrill. And a responsibility.

Continue Reading →

Programmers, mind your rat holes!

I’ve spent good chunks of the last week ‘throwing time down the rat hole’ as we say around my house.  But it wasn’t till this morning that I got a clear picture of which rat hole(s) I was actually diving down and managed to plug two of three.

I don’t have an easy relationship with Eclipse.  I’ve spent years cursing the Visual Studio IDE, as it slowly matured, and can’t claim even now that VS is better that Eclipse, only that a) it HAS gotten much better and b) I know it well.  I can navigate its gotchas just the way I avoid the gravel and ruts on the shoulder of the highway along which I ride my bike two or three times a week.  They are there, but not particularly in my way.

OTOH, whenever anything goes wrong with my Android development environment, I find myself reflexively blaming Eclipse and trying to find a way to whack it upside the head so it will tell me what’s going wrong.  Eclipse CAN be the problem, as I was assured by this nice little (old) article on how to clean the cruft out of your Eclipse environment.  But this time, Mercurial/BitBucket, Java, Eclipse, and I all had some share of the blame for the insanity that descended upon me.  I think I’ve resolved everything BUT the Eclipse issues, but once more I could be blaming the victim for my own stupidity.

Ever since I pushed Sara’s changes to PasswordRN up to our BitBucket repository, I’ve been trying to reliably execute on the following simple ‘new developer’ exercise:

  • Clone the respository to a new, fresh location on my harddrive.
  • Run Eclipse and ‘import’ the project, which Sara pointed out is best done using File/New/Project/Android Project and telling Eclipse you are creating the new project from existing sources.
  • Build and run the results.

What was particularly frustrating was that I was sure I saw this work correctly at least once but could never recreate that success.  And Sara reported ‘it worked fine for her’ but when Hokan and I tried it again the other day, we wasted two precious hours hacking around trying to get the project to build and never succeeded.  And each step I took along the path of trying to diagnose what was wrong and how to fix it just seemed to make less and less sense.  But, enough with the emoting, here’s some useful detail for posterity.

1) Mind your empty folders.

1A) You push a working project to BitBucket, clone it to a new location, add the project to your Eclipse workspace, and try to run it.  Eclipse gives you a message box that says:  “Your project contains error(s), please fix them before running your application.”  In the Problems tab, you see an error message that says:  Project ‘PasswordRN’ is missing required source folder: ‘gen’. Ok.  Alright.  This is a known issue.  In fact it’s a perennial problem with source code control tools:  You don’t want to store your generated files in the repository.  But version control tools don’t like to store empty folders.  So when you clone, you get a folder structure that is missing folders under \gen and \bin Eclipse and Java expect to see ready for them.  This fix SHOULD be easy.  Add a ‘readme.txt’ or other small file to the bottom of each folder tree that you need to get back from source code control.  Check in that file and and keep ignoring the generated files.  Now, when you clone/pull, you’ll get the folder structure you need.  But, this time, watch out!

1B) The above worked great; I verified all the folders were in place after I cloned and before I imported the project into Eclipse.  But, then I imported the project into Eclipse and got the same message.  Huh?  After the looong detours represented by items 2 and 3 below, I finally figured this one out.  Either Eclipse or the Java compiler (doing a premature automatic build step, maybe?) ended up deleting some of the folders as I imported the project.  The fix is simple, just double clutch:  clone and get the full folder folder tree; import the project and the folder tree gets mangled; go out to DOS or Explorer and revert your file set to get the full folder tree back; refresh in Eclipse; and now everything builds just fine.  (I didn’t do telephone tech support for all those years without developing good hack-around skills, eh?)

2) Mind your classpaths. I know, I know; any Java developer worth her salt already knows this stuff.  But I’m just barely a Java developer.  (I can’t WAIT to see how much trouble I can make for myself tweaking the ObjectiveC/Xcode for my iThing version.  Sheesh.)  As it turns out, classpaths were NOT my problem at all, till I misunderstood the ‘buildpaths’ message above, did some dumb stuff, and made them into a problem.  OTOH, reading that article about them made me understand what a bad job I had done with constructing my original package name.  And, since it is often useful, while waiting for problem-solving enlightenment to strike,  to do something, anything, useful, I spent rather a lot of time today  cleaning up my package name and dealing with the source code, folder, and version control chaos that created.  So calming, sometimes, to deliberately break the code in a way that you think you understand and then bring it back to working again, step by step.  Gives you back that sense that you might actually know what you are doing.

3) Mind your Eclipse workspaces. Now we get to the embarrassing bit, the point at which I have to admit I have a problem I still don’t understand, don’t know how to understand, and have decided to just steer around for now.  It’s not as if I ever claimed to understand Eclipse workspaces; you can’t say I did.  But now I’m just plain confused and worn out. Ok, listen carefully.  If the empty folder problem is solved and I import the project into my original workspace, the one where I’ve already done Android development, using the double-clutch technique described above, the cloned project builds and runs fine.  Whether I delete my original project or not.  But, if I create a new Eclipse workspace and then do exactly the same thing, then every one of the classes in my project that implements an Android interface, as well as deriving from an Android base class, now has the error message:  “The method onClick(View) of type AddEntry must override a superclass method.”  At least now I know the difference between when importing works and when it doesn’t.

And I even think I know what the error message means — it means that the project isn’t handling its imports correctly. It’s as if I did NOT have the line:

import android.view.View.OnClickListener;

at the top of my source code file or as if the environment wasn’t set up to interpret it correctly.  But I do, of course.   And, weirdly, I can create a New little Hello World project, in the same workspace, and it implements OnClickListener and builds just fine.  So, you’d think, maybe, if NOW I delete my imported project, and re-import it, it would build.  I try that.  No joy; no build.

So I have a ‘healthy’ workspace and ‘unhealthy’ one.  And now I know which to use.  Duh.  But, what the heck is really going on here?

Time to get on with other stuff and wait for wisdom to filter in, from more experience, from someone telling me what is up, from ??  The rat holes have had their share of me this week.  Enough for coding and trying to do the fun technical stuff . . . time to write a business plan.