Time to move EngineDriver to Android Development Studio?

[jmri]

Time to move EngineDriver to Android Development Studio?

[mstevetodd]

Changing dev environments for a mature product is usually a bad idea, unless the new tool provides some critical function that the old tool does not. High risk for small reward.

What are you wanting to add to EngineDriver?

[pabender]

On Wed, Feb 10, 2016 at 8:49 AM, SteveT [email protected] wrote:

Changing dev environments for a mature product is usually a bad idea,
unless the new tool provides some critical function that the old tool does
not. High risk for small reward.

We change environments to keep up with technology. Yes, sometimes that
means we have to learn something new to make that happen.

Android indicates the eclipse plugin is no longer supported:

http://developer.android.com/tools/help/adt.html

At some point we will be forced to change or development will need to stop,
and I don't think any of us want to see that happen.

What are you wanting to add to EngineDriver?

I want to improve the interaction of EngineDriver and the operations code
on the server.

Paul

[n3ix]

Paul and Steve,

Hi. I love new technology but I would not support changing to Studio for a
dot release. Just way too risky. In my many years of product development
experience we would never change dev tools on an established product unless
we absolutely had to, and then it would be considered a major release and
require lots of testing.

(To illustrate the point, we are still using Visual Studio 2005 and Visual
Studio 2008 to support a long line of very successful existing industrial
instrumentation products. Those tools have not been supported for ages but
the tools function acceptably and there is really no need for support.)

In the EngineDriver case Eclipse continues to function acceptably for the
current product generation. Since the practice has been only to include
features in ED that are backward compatible to fairly ancient versions of
Android (to permit use of cheap, surplus phones), I don't see a technical
justification for changing the environment on the current product.

If we are talking about a next gen product, with different backward
compatibility requirements, then by all means let's look at our choices for
dev environment. Since by choice ED has a tough backward compatibility
limitation, if the new features that are desired are going to require the
latest Android then to me that seems like this would be a new product with a
clean sheet?

Just my 2 cents worth.

Robin

[mstevetodd]

Paul,

You're wanting to put something related to JMRI Operations inside EngineDriver itself?
The current interfaces to Operations (Trains, Manifest, Conductor) are in the web server code, and I highly recommend they stay there, accessible from any browsers including those embedded into the ED and WiThrottle apps.
Please describe further what you are proposing to add to EngineDriver itself.

I agree with Robin that the current ED does not benefit from the work required to move it to Android Studio and retest all functionality. Certainly, if the time comes that the code can no longer be maintained in Eclipse, that changes the equation.

Regarding future development, ED is long past the need for a rewrite (the initial framework code was Android 1.2 or earlier). Any rewrite should certainly use the latest tools, and set a new minimum OS level based on required functionality.
I started a rewrite (called EngineDriver3) a while ago with exactly that goal in mind. Unfortunately, development has stalled on that project.

[pabender]

On Wed, Feb 10, 2016 at 11:40 AM, SteveT [email protected] wrote:

You're wanting to put something related to JMRI Operations inside
EngineDriver itself?

The current interfaces to Operations (Trains, Manifest, Conductor) are in
the web server code, and I highly recommend they stay there, accessible
from any browsers including those embedded into the ED and WiThrottle apps.
Please describe further what you are proposing to add to EngineDriver
itself.

I'm not going to remove any of the existing features, but they don't feel
integrated with the software. They are what they are, they are web pages
displayed within the app.

What I want is better control over how the information is presented. One
option that I really want to put into place is the ability to have a
waybill stack stack that we can flip through and mark off completed work on
individual cars in the order in which they are in the train. That's a
different way of looking at the information than is currently available.

This ties into the RFID updated car ordering positioning in the operations
code and some other work I've been doing on the SimpleServer.

I agree with Robin that the current ED does not benefit from the work
required to move it to Android Studio and retest all functionality.
Certainly, if the time comes that the code can no longer be maintained in
Eclipse, that changes the equation.

Regarding future development, ED is long past the need for a rewrite (the
initial framework code was Android 1.2 or earlier).

What API version is currently targeted?

Any rewrite should certainly use the latest tools, and set a new minimum
OS level based on required functionality.
I started a rewrite (called EngineDriver3) a while ago with exactly that
goal in mind. Unfortunately, development has stalled on that project.

It would certainly be a good reason to restart that project.

Paul

[rhwood]

Is there any reason not to make these changes in the web server so other than EngineDriver users can benefit from them?

Randall Wood
Alexandria Software
[email protected]
http://alexandriasoftware.com

On Feb 10, 2016, at 13:34, Paul Bender [email protected] wrote:

On Wed, Feb 10, 2016 at 11:40 AM, SteveT [email protected] wrote:

You're wanting to put something related to JMRI Operations inside
EngineDriver itself?

The current interfaces to Operations (Trains, Manifest, Conductor) are in
the web server code, and I highly recommend they stay there, accessible
from any browsers including those embedded into the ED and WiThrottle apps.
Please describe further what you are proposing to add to EngineDriver
itself.

I'm not going to remove any of the existing features, but they don't feel
integrated with the software. They are what they are, they are web pages
displayed within the app.

What I want is better control over how the information is presented. One
option that I really want to put into place is the ability to have a
waybill stack stack that we can flip through and mark off completed work on
individual cars in the order in which they are in the train. That's a
different way of looking at the information than is currently available.

This ties into the RFID updated car ordering positioning in the operations
code and some other work I've been doing on the SimpleServer.

I agree with Robin that the current ED does not benefit from the work
required to move it to Android Studio and retest all functionality.
Certainly, if the time comes that the code can no longer be maintained in
Eclipse, that changes the equation.

Regarding future development, ED is long past the need for a rewrite (the
initial framework code was Android 1.2 or earlier).

What API version is currently targeted?

Any rewrite should certainly use the latest tools, and set a new minimum
OS level based on required functionality.
I started a rewrite (called EngineDriver3) a while ago with exactly that
goal in mind. Unfortunately, development has stalled on that project.

It would certainly be a good reason to restart that project.

Paul
—
Reply to this email directly or view it on GitHub.

[pabender]

On Feb 10, 2016 5:45 PM, "Randall Wood" [email protected] wrote:

Is there any reason not to make these changes in the web server so other
than EngineDriver users can benefit from them?

That is always an option, but that isn't the path I want to take this. This
is at least partly about integrating this into the look and feel of the
application, and we don't get that (at least not completely ) with a web
based interface.

The web interface for all this has always felt clunky to me, and it could
certainly use some refinement.

Paul

[mstevetodd]

I have completed the move of EngineDriver 2.x to Android Studio. Closing this issue.