This week we are happy to present writer and developer John Xenakis’s independent review of our developer documentation and SDK. John created an in-depth review which we want to share with our readers.

Over the years I’ve worked on over 100 different software applications and I’ve used many development tools (such as Mobilengine). As a part-time technology journalist, particularly for ten years as Technology Editor of CFO Magazine, I’ve written over a thousand articles; I’ve also interviewed thousands of CEOs, CFOs, CIOs, software development managers, and programmers. In addition, as a personal project, I’ve been developing an Android app called “Professional Debt Calculator”. One question that went through my mind as I started is whether your documentation provides me with enough information so that I could implement ProDebtCalc using Mobilengine.

There’s a lot of sophisticated material in this tutorial manual. One thing that should be considered is converting it to a couple of in-class courses, one introductory course, and one advanced course.

CONTENTS:
Tutorial – “Sandbox View”
Tutorial – Advanced Capabilities
Scripting and Computations
The Big Picture

Tutorial – “Sandbox View”

The tutorial puts you right into the sandbox, where you start playing with the tools and creating simple applications. I found the explanations clear and easy to follow. The pattern consistently followed in the document was, “Here’s what we’ve done; next, you’ll want to do that; here’s how you do that.” That worked very well throughout the document.

An issue is that you’re starting out right in the sandbox, and you’re always in the sandbox. The reader never has an opportunity to get out of the sandbox and get the big picture. I’ll suggest several possibilities as I go along. As I was reading through the manual, I was thinking about my ProDebtCalc program, and wondering how much of it I could implement using Mobilengine. As I developed my program, the UI evolved into a three-level infrastructure: dataItems (interest rate, start date, interest assessment rule, etc.), dataBlocks (collections of related dataItems), and tabData (collections of dataBlocks on a single tab, allowing the user to select different tabs).

Tutorial – Advanced Capabilities

One of the problems of writing a tutorial manual for Mobilengine is that Mobilengine itself violates the Principle of Least Astonishment in some ways, especially for a newbie who may have never seen anything like this before. I’m going to suggest additional some additional explanatory material that you may wish to consider.

I mentioned that I’ve taught programming courses in procedural languages like Java, but I’ve never done so for a language that’s XML-based, so I don’t know how difficult it would be, but I think many newbies approaching this tutorial manual will be confused because they’ve never seen anything like this before.

I think some introductory material on the pros and cons for procedural vs xml-based languages would be very helpful for the “big picture,” because otherwise when you’re just thrown into the sandbox, it takes a while to figure out what’s going on. This is where a user story will be extremely useful – a user explaining how he sees the differences, the pros and cons, between a procedural language and an xml-based language. Actually, several user stories explaining it in different ways would be most credible.

I taught programming courses over three decades in different procedural languages, and I discovered something that really surprised me, once I figured out what was going on. Students could understand assignment statements like “a=5; b=6; x=a+b;” and know what’s going on. In addition, when the variables were changed from numeric to string, and the operator was concatenation, they had no trouble dealing with that as well.

However, when the value of the variable was a pointer to another variable, as in “p=addr(x); p->x = p->x + 1;”, I would lose about 1/3 of the class, no matter how many times I explained. My conclusion was that pointers were simply too abstract a concept for many programmers. This is similar to the situation where a student in geometry class might be able to apply the formula to compute the area of an isosceles triangle, but could not even begin to understand how to prove something, such as that a triangle with two equal sides has two equal angles.

In advanced programming courses, where I described in class how to implement a linked list, sorting a linked list, adding a new element to a linked list, or removing an element, even programmers who had years of programming experience were simply unable to understand this example, or solve the homework problems related to it. Once again, my conclusion was that even for experienced programmers, use of pointers was simply too abstract to understand. This is similar to a calculus student who can mechanically apply the formula to differentiate a function, but has no understanding of how to derive that formula.

In languages like C++, Java, C#, Python, etc., this problem is simplified by providing a collection of data structures (linked lists, maps, adjustable arrays, hash tables, sorted sets, etc.) The programmer can mechanically use the APIs for these data structures, even if he’s incapable of understanding how any of them are implemented.

Many readers of your manual are going to have similar difficulties trying to understand how data tables work. I noticed that you provided a link to an sqllite tutorial, but you might consider inserting a chapter on the use of tables in Mobilengine. This chapter doesn’t need to follow the pattern of adding one feature after another to the Rocky Jupiter application. It could be a chapter to help the newbie overcome his inability to understand the concept of a data table. The objective would be to provide enough examples so that the user can apply the examples mechanically, without needing to understand how the tables are implemented.

Another major issue has to do with synchronizing updates to the database in a multi-user environment. I know from a number of experiences that many long-time programmers really have no clue how large multi-threaded systems work, and how to synchronize multiple threads. This requires a level of abstraction that goes well beyond even pointers and data structures, and beyond the capabilities of perhaps 75+% of programmers. I noticed that you provided some excellent examples of data synchronization. I just want to make the point that a large number of your readers will not have a clue what’s going on, but probably what you’ve done is as good as can be done.

Scripting and Computations

When I was reading about the scripting language, I immediately wondered how much capability it had compared to, say, Perl or JavaScript. The documented examples seem to suggest that the capabilities are extremely limited, and I couldn’t find any additional documentation online. Whatever the capabilities, the scripting language needs at least a full reference summary.

My ProDebtCalc app performs brief computations in several places, and a very big computation at the end to do the amortization. I was wondering how I would do these computations in a Mobilengine implementation.

The scripting language does not seem capable of even simple computations, as would be required, for example, in an e-commerce app that needs computations to configure a product. So how, I wondered, would I implement the computations in my app, particularly the amortization computation, which currently runs on my mobile phone in 8000 lines of Java code?

The manual seemed to provide only one workaround: Do the computation on my own computational server somewhere, then request a computation from the app by going through the Mobilengine server:

App <> MBE-Server <> Endpoint My-Computational-Server

The computational server would provide the results as back to the Mobilengine server in the form of a series of tables. The above would work, but could take a long time for each request, and require two sets of large data transfers, since the amortization table can be thousands of lines long.

Perhaps there’s an “escape mechanism” in the scripting language that lets the app make a procedure call to a compiled program on the mobile device. Even then, the mortization table data apparently would have to be transmitted to the Mobilengine server, and then bring the data back again to display in the user interface. This is an important issue.

In other words, there are a lot of issues here having to do with computations. It may be that Mobilengine doesn’t support apps that do a lot of computations, or it may be that there are workarounds that I’m not aware of (or that I missed in my reading). In any case, there should be a chapter of the manual describing this whole subject.

The Big Picture

From what I’ve read on the internet, Mobilengine has a very good story to tell about the big picture, and some of that story should be included in the manual.

I’ve already discussed some of the issues that the developer is going to be concerned about, how an xml-based language works, how to do dynamic forms, and how to do computations.

There are also issues that the development manager / CIO / CFO should concern themselves with. I understand that Mobilengine has thousands of users in Europe, so there’s a positive story to tell. It would be great if the reader can be told this story in the introduction to the manual, and should be reminded of this in other places by referring to the large number of users. Another issue CIOs are concerned about is how well the tool is supported. This can also be handled with user stories.

Also, an issue for CIOs is “brick walls.” I’ve discussed a number of possible issues (doing computations, etc.), so the concern for the CIO will be whether something will need to be done, but it can’t be done using this tool, and there’s no workaround to get it done. I think that the best way to handle this issue is to be honest about it, and talk to your users about problems they’ve had.

Another issue is data security. This is a serious issue for a lot of companies, and in some cases (when health or financial information is involved), there may be strict regulatory requirements. The CIO needs to know that company data is protected, and the development programmer needs to know what he has to do in the code to make sure that data is protected.

Related to data security is malware and hacking. The entire security issue is very important, and should be thoroughly addressed in the documentation at all levels, from coder to CIO.

Visit our Developer Pages

Adam Dalnoki, Mobilengine’s CEO, brings IT and telecommunications expertise as an ex BCG consultant. He made a previous exit in a mobile payment start up and has held sales executive positions at Provimi and Kraft Foods.