~ or ~
Development Considerations Reconsidered
~ an Adventure in Too Many Parts ~
Well, calling it an AAR would certainly be optimistic, because I was about two weeks behind schedule when it came time to actually use Cygnipede v2 (C2). Why? Well, you know the phrase, “a good worker doesn’t blame her tools”? I’m about to do some of that.
- I missed the ship date (City To The Sea)
- Learned a *lot* about the [lack of] stability in BB dev tools and platforms
- Am continuing to upgrade C1 to C2, especially as regards the CygNet Enterprise Gateway
There is no question in my mind that, left to my own devices, I will slip schedules in order to add “one last feature”. In that regard, I’m no different than most software developers. In this case, though, I didn’t get to the features we wanted, and a big part of it was some mistaken assumptions on my part about both the execution environment (i.e. the phones) and the development tools.
Given that the BlackBerry is a mature platform as mobile platforms go, I assumed (implicitly) that time would further stabilize both of these, cleverly failing to note an entire year of errors like, “Cygnipede won’t run,” and “Cygnipede can’t find the GPS,” from all and sundry, including YC. Familiarity breeds contempt, so I should have noticed I’d managed to generate an entire flock.
Our initial goals
- decreased power consumption
- more (ok, *any) status information for the mobile user
- work out issues with “push” installations
- demo booth at City To The Sea
- and the late addition – use the new Cygnipede Enterprise Gateway
The core of the C1 application is a markedly modified version of one of a sample GPS application from the SDK. As demo applications go, it was ok, but was both too complicated and not really aimed at our purposes. It was monolithic and multi-threaded, and this on a platform that does not reward complex architecture.
Development on the BB can be done in three ways:
- BlackBerry JDE (Java Development Environment) from RIM – essentially this is the simplest possible IDE you could have and still do work.
- Eclipse with RIM plug-in – open-source IDE from IBM with an extensive set of tools
- NetBeans from SUN + JME (Java Mobile) add-ins – notable because it’s the only one of the three that offers a drag-n-drop GUI for UI design, although only for applets and not straight-up Java applications.
- Trying to make the client UI a MIDLET. The limitations in control layout alone are enough to make me say, “Never again.” I thought having a GUI designer/code-gen tool would save time, but I was wrong.
- In general, trying too many things. Next time: break one thing at a time.
- Let myself get distracted. In such a chaotic environment, i.e. mobile development, there are lots and lots of really interesting things. Just concentrate on making one phone do one thing with one server at a time.
- I can’t decide if this was a mistake, but using a sample application as the basis might have been wrong. I spent time trying to make someone else’s code do things it wasn’t really designed for. If I’d spent the same time writing two separate applications from the ground up, I imagine I wouldn’t have spent any more time, and would have ended up with something that involved fewer kluges.
- The Storm caused the most problems – I ended up having to wipe mine every few days when it would get to the point that attempting to update via the BB-DesktopManager would result in a ‘fatal error’ message (in BB-DM, with no further explanation).
Eventually I figured out that the DM was trying to update the OS and update applications. Once I made it do those tasks separately, it got a little better.
- “GPS services are not available on this device” – eventually diagnosed as being the result of running an application that tries to use location services with an external GPS, then fails and switches the entire device to the internal GPS without telling the user. Next time Cygnipede starts up, this happens. Pull the battery and reboot. Switch back to the external GPS. Now it will work.
- Simulators don’t – in theory it’s faster to use the simulators, but even the RIM JDE has problems connecting to them and I discovered that at least in the case of the 8330 (Curve), the emulator and actual device behave different, even with both of them running the same firmware version. Things that worked on the emulator wouldn’t work on the physical device, although the reverse didn’t seem to be true. Had to abandon using the emulators due to the uncertainty surrounding reliability.
- Running the battery completely down results in unpredictable behavior when the device reboots, although this is anecdotal and (I suspect) not actually the case. The problem is that when problems stack in this fashion, the superstitious part of one’s brain tends to run a bit wild in the speculation department.
- JavaDocs – While Visual Studio is at the point where there’s almost too much documentation, the documentation for the Java tools consist of:
- An outline of the classes (API)
- No examples to speak of along – this is just whining, frankly, because I’m used to having functional and non-trivial examples to work from, a la Visual Studio
- Oddly, the IntelliSense-like auto-completion feature in Eclipse is arguably better than VS, because it allows what I find to be a more natural navigation to relevant docs/help.
- BlackBerry Desktop Manager – as suggested, I used v5, but it was no more stable than v4.7. The typical problem was that after re-plugging a device about 10 times, the BB Device Manager (different software from the Desktop Manager), would stop being able to see it. The Windows Device Manager would see it, though.
This would be bad enough, but apparently the charging circuit doesn’t work if the driver on the PC doesn’t see it, so to all appearances, the device batteries had failed, since plugging them in wouldn’t result in them charging. The solution was to reboot the PC, remove the BB Desktop and Device Managers, reboot, install the BB Desktop and Device Managers, shutdown (power off), and then upon booting the devices would be visible.
Lest you think this was a machine-specific problem, I was experiencing these on both a Dell XPS laptop (Windows 7) and my home-built dev box (Vista Ultimate).
- In general, the RIM-recommended approach to problems seems to be, remove, reboot, and re-install software. We are not amused.
- Vast numbers of devices and versions – this isn’t anyone’s fault, it’s just that there are a dozen BBs, and a half-dozen carriers each with their own restrictions on the APIs. Our solution was to just say, “If it can’t do v 4.5, we’re going to ignore it.” We should probably actually say, “If it can’t do 4.7 or maybe 5.0, we’re not going to support it,” since these versions of the BB OS have reasonably comprehensive APIs that support the interesting parts of modern devices (e.g. accelerometers, faster location services, better UI suport).
- Safari books subscription – can’t say enough good things about this, and not just for Java, but for *anything* having to do with digital technologies. I was about to go out and buy a book about 3D lighting (for rendering) when I checked Safari on a whim. OMG! It was there, and I saved myself $40.
- RIM BlackBerry discussion forum – almost any question one might have is likely to have been answered in some form
- Eclipse – the only drawback is that the RIM plug-in requires an older version (3.2 – Ganymede)
- Sun Java stuff
- Split the application into 2 (or more) sub-applications:
- User Interface – set options and view status
- Location listener
- Fix feeder (transmit feeds to CygNet and report on status)
The existing C1 has been updated to about v1.5, I’d say. It includes the following changes
- Client now transmits altitude, heading, speed, and a user-defined text message
- Client shows extensive status information in a scrollable window
I’m currently working on posting to the Enterprise Gateway.
What I learned (I hope)
Once you have a working dev environment, DON’T CHANGE IT. Since VM-Ware (in theory) supports USB connections, I’m considering building a VM just for this purpose.
On your dev box, try to avoid plugging any non-BB mobile device into your USB ports. Plugging in my Windows Mobile phone seemed to be one of the things that would cause the BB Desktop Manager software to just wander off and never come back until a reboot. Don’t plug in more than one BB at a time.
Use the ‘javaloader’ application instead of the BB-DM when possible, since it seemed more reliable. Load the ‘.jad’ file instead of the ‘.cod’ file if you want it to appear in the menu somewhere
NetBeans, while superficially attractive due to the GUI builder offers no real advantages over Eclipse except for MIDLETs.
Mobile platforms are far more finicky about things being Just So. I knew this, but had on some Happy Ears.
What about next year?
Not really. It was enjoyable, and we’ve learned some interesting things about…mmm…not limitations in CygNet so much as possible way to increase the richness of the architecture. I’m specifically thinking of the fact that GPS fixes are compound entities which are nearly always accessed en toto, rather than in parts. A latitude or a timestamp aren’t generally useful, except as part of the whole piece of information.
As it stands, we represent the fix as several different points of the form
That’s not a problem, but I’m thinking about whether it would be useful for fixes to either have their own service, or for points to be able to define a collection of attributes as representing a “type”, in the computer science sense. Basically a point that’s a collection of points. It’s all too easy for this approach to cascade until you find yourself with an actual OODB, with bad performance and complexity too high for anyone to actually use.
I’m not suggesting a general type system, just that we can currently only represent scalars, and in only canonical mathematical types. I know we do composites, but I’m specifically referring to points of enduring business interest, to quote a colleague. I’m specifically referring to tuples as a possible way to create 2nd-generation SCADA objects, and GPS fixes are an exquisitely good example, in my opinion, of something we don’t/can’t currently do well.
I just heard that 3 people died during the Detroit Half-Marathon and found myself wondering if Cygnipede could help. A Bluetooth-enabled health monitor broadcasting runner stats might have allowed a centralized system to identify people who were approaching some kind of crisis point. I need to go talk to some doctors about this.
Cygnipede walks on, and I’m hoping we find some more uses for it. My current plan is to keep working on it as a very-low priority background task, unlike last year when it got dropped until we needed it again.