I’ve been really busy with some new and exciting stuff for a while now. This year I saw my frist child, a daughter born, around that same time I shifted from being an Electrical Design Engineer, to an Engineering Supervisor at Veeco. And then, in September, I was offered a Software Engineering position at Trane in their commercial Climate Solutions division.

In all this time I haven’t had much of an opportunity to get back to my hobby project, ModbusDroid. I’ve had ideas for a while on how to improve it, and I even started working some on a fragment API (Android 3.0+ UI guidelines), but never got very far with it because of all the craziness with life this year.

So, I’ve decided it is time to get back on the wagon and start back to it – but with some caveats and a few notes.

1) In all the computer transition, and a minor server hard drive glitch, I lost the key files to the original ModBus Droid, so I currently can’t upload any updates to the Google Play store. Also, a while ago, I started working on a re-name of the project for porting the app to the BlackBerry playbook, and I’ve decided I like the somewhat more generic naming – Mobile Modbus. So for the time being, the app is going to be a brand new app, not a 2.0 of ModBus Droid. Mobile Modbus might stick as a name, it might not – I’m open to suggestions so send them my way.

2) Very early on, after I layout some rough frame-work and UI for the app, I’m going to do the development out in the open on GitHub. A lot of this is going to be re-written from scratch or heavily refactored. So, to all my friends who have been telling me that they were thinking about getting into Android development – get your github accounts set up – and follow me there. Install git on your PC, and the Android SDK, and import the old version of modbusdroid from github so you know you are set up and good to go. There has never been a better time – they even started bundling eclipse with the android SDK to make it easier to get started – and github has great GUI git clients for both windows and mac.

3) Part of this refactor is about being a better open source citizen. We make heavy use of the Modbus4J library in the app – a pretty great library that does batching (which we don’t currently use), and I made some non-trivial, but not major either, changes and additions the library. Rather than being awesome and contributing patches back to the main repository, I just dropped a rev of the source code right into the projects source and never really looked back. This time I’m going to clone the CVS and convert it to Git (done actually) and publish that to github with links back to the original project. I would contribute right back to the sourceforge page, but honestly – CVS… in 2012/2013… I hate CVS, not gonna happen any time soon. Call me lazy, but at least I’m going to make it easier to seperate out what I did vs what was from the original project. I plan on tracking it better too.

We’re also going to be using the ActionBarSherlock and SlidingMenu libraries, and I’ll make a fork of those on github if we need to change anything in them.

4) I really really want to get a few features into this 1.0 release of this app that weren’t in the original Modbus Droid. First off, I want to get Modbus RTU over TCP in there, and lay the groundwork for eventual bluetooth serial port adapters (SPP) with straight ModbusRTU. I also want at least lay in the foundations for saving some favorites in terms of configurations / IP addresses, and the possibility of giving registers names. Finally, I also want to get in something that could write out updates to a file for data logging. I’m contemplating some of the more advanced features would be in and ‘advanced mode’ in the settings or something like that to keep from cluttering the simple interface for people who just want to get in and out quickly while/after monitoring some registers. Only when the advanced mode was on would we expose some of these UI elements to enable these features. To see some of the design patterns for the new versions of android, and some neat extensions to them, check out Android Views.

So anyway, this is where I’m taking things. Hopefully over the next few weeks during the holidays I can get a few commits into github and you can all start to see where this is going. And if you are feeling adventurous, read up on Modbus, the Modbus4J library, and Android development – and feel free to jump in by forking the project on Github once it is on there (I will tweet/G+/blog about it when it is up).

All work on ModbusDroid, the modbus scanner/polling client app I wrote for android, will now take place using the GitHub.

The last released version – 1.0 – will remain available on launchpad.net, but will not be maintained there anymore. When I have a minute I’ll update the blog posts and pages with this info. But there are probably like 2 or 3 people in the world who care that I’m starting to hack away on a tablet/Android 3.0/4.0+ version that uses fragments and the action bar APIs, and I thought you precious few, my beloved audience, might be interested in this change.

Again, just as before – PLEASE – do not post questions on my blog about the app, post them on github so I can better answer them for all people who might be interested in the answers.

After working on another app for a start-up and some half-written project ideas, I decided to return to my original app ModbusDroid and finally clean up some stuff that was obnoxious about my first go at it.

So here you have it, I added a landscape layout that moves the Modbus controls to the left in their own column, and the data has its own column to the right. And I fixed the issue that disconnected from the server when rotated from portrait to landscape (or vice-versa), but it still disconnects if you exit the app to avoid doing any unnecessary draining of your battery. A few other nagging bugs – there seemed to be a few exceptions from bad inputs in the settings or register offset or lengths. So I set all the text-boxes to be numeric-only keyboards and inputs. Please report a bug on launchpad if you are able to enter any alpha characters into any of those boxes with any keyboards I don’t have installed (like swiftkey – I only have the stock keyboard and swype installed, and I don’t have a physical keyboard). I also fixed some annoying bug reports that came in from the market – for the record on those, if you put “crash” in the description that is not helpful at all – if you put what you were doing, that helps WAAAYYY more, and I’ll fix it as soon as I see it and can reproduce it.

Unfortunately I didn’t clean up everything I would like to (still have the stupid “JAVA: Socket Exception, timeout while trying to make a connection” error messages instead of a more friendly message). But maybe as time allows I’ll circle back to that.

All that being said, let me know what you think about the final 1.0 release, and I hope you find the minor tweaks I made an improvement.

Going beyond 1.0

I learned a lot about android, and real application development during this project as well as when I was working on Whooznear (the prototype App I put together w/ my friend Alec for the startup now named Primmo Apps). And in all that learning, as well as everything I’ve read and learned since then I’ve realized I could do a lot better at making this app a little more friendly, and easier to maintain and extend w/ new features.

Also, since then android 3.0 came out and brought w/ it the new fragment and action bar APIs, and just a few weeks ago android 4.0 brought those features to phones. And I got to thinking there were some usability improvements that could be had on this app if I leveraged those.

So I’m thinking re-write w/ new APIs when I can find the time (who knows when that will be – I’m having a kid early next year – but here’s to hoping anyway!). Something to expand a little nicer to a tablet layout – especially in layout mode. I’m thinking something more like a grid layout, where each column would have a register number and the value in it, and the number of columns would be screen size dependent (i.e. portrait on a phone would be 1 column, portrait on a tablet would be 2, layout on a tablet would be 2 or 3 – depending on the font). And maybe I’ll cook up some other niceties – if you have suggestions feel free to post them here, or to put them into launchpad (or github – read on for more info on that).

Besides that, I’ve gotten some requests for these features (or dreamed them up after some request made me think of them):

• Data recording to a file
• Real tested Slave support – for some TCP to RTU bridge devices you can have multiple slave IDs, so that might be useful for some people
• RTU support for devices that can connect to your phone or tablet that have a COM port
• RTU over TCP – this is a use-case for some people. Might be worth looking into
• Modbus4J library changes to be posted separately – not a feature per-se, but still a request I think is worth doing
• The ability to put ‘names’ at certain register locations instead of the register number

Now, I’m probably not going to be able to tackle all of these requests, but I’m hoping to re-architect how I did the app (again, if I can find time) for android 3.0+ devices to include some of these. And I definitely want to separate out my changes to the Modbus4J library so that I can more easily contribute back to the community that developed it originally, and so I can more easily track upstream changes as well. Right now when people ask me about it I’m forced to say “uhhhh…yeah, I just dumped the source code into my project folder for ModbusDroid and started hacking – I couldn’t tell you what I changed.” Since then I’ve gotten a lot better about knowing how to keep projects separated and yet connected, and use these new fan-dangled DVCS features like ‘branches’ to keep my changes separate from the upstream changes.

Switching source-code management and hosting
Finally – I keep pushing everyone to launchpad.net for the hosting of the project, and there are a lot of awesome things about Bzr and launchpad, but to be honest, since then I’ve kinda fallen in love w/ Git. And GitHub seems to have a better community and UX vibe going on (“Fork This” is a great banner). And, bazaar apparently messes w/ some of my work software (ePDM from Solidworks), and crashes that when I right-click on stuff inside of our company vault, so I had to uninstall it for now – making it a pain every time I want to upload changes in my source code to launchpad. So as soon as I commit the 1.0 release branch to launchpad (after I finish this blog post and upload the APK to the market), I’m going to switch the project to Git – the first commit will be the 1.0 branch – and then upload to github for my hosting. Look for an announcement about that sometime later this week, and I hope for a lot of you this will make it simpler to follow the project as I think Git (and to a lesser degree Mercurial) is gaining more and more traction all the time, and I hear less and less about Bazaar outside of Ubuntu.

Thanks for your feedback so far, and keep it coming so we can make this a great piece of software for the other android faithful out there in the controls industry.

Ben