Re: [Orekit Developers] Status of the Android application -- 2

[Alexis ROBERT <alexis.robert@gmail.com>]

On Fri, Aug 12, 2011 at 4:58 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
> Events are meant here as Orekit events. This means classes that implement
> the EventDetector interface (in org.orekit.propagation.events package).
> There are several such events classes already defined, each with its own
> settings.

It was mostly how could I make a table for entering events in a clean
and extensible way, how could I pass the data to the compute activity
and other little things. But I'm almost ready to begin the
implementation :)

By the way, you told me a while ago :

"What could be done is to create some table with all spacecraft
passes. Each row would correspond to an interval during which the
satellite can be seen from one station. Each row would have 3 columns
: the station name or id (stations are often abbreviated with 3 or 4
letters mnemonic like KRU for Kourou, AUS for Aussaguel, HBK for
Harteebesthoek ...), the AOS (Acquisition Of Signal, or visibility
start) time and the LOS (Loss Of Signal, or visibility end) time. It
should be possible to have several stations in one run. Some
additional optional features could be to have also a visibility
duration (i.e. duration between AOS and LOS), to have the max
elevation during the pass, to have Doppler at AOS and LOS ..."

Does each event type need to show their own specific kind of data
(with each event type on their own tab, like a browser), or is the
list of data to show applies for other kind of events ? (and not only
visibility detection)

> Here are a few random comments from me, as I just succeeded in installing
> the application (I had to completely reinstall my tablet with a new ROM,
> this time with Android 3.0.1).
>
> When we leave go back to an input form after a computation, it is reset back
> to default values (i.e. all zeros for frame conversions). So if I want to do
> several conversions from the same parameters and change only the target
> frame, I have to retype everything again. Could the last entered values be
> remembered somehow ?

That's strange I don't have this problem here :/ When you go back to
the parameter forms, do you use the "back" button or do you go back to
Orekit's home menu ? The first way should normally keep the data --
although, it may be Android 3 related, I'll test.

> Is the layout of the UI final with the compute button at the top right ?

I was thinking of keeping it that way, as the "action bar" is one of
Android best practices -- I found the same pattern in the Google+
application when you create a new post --, but I understand that may
not look very natural, I could also be misinterpreting the best
practices. Do you want it to be in an other place ?

> About Pascal request about units, I am on the fence. On the one hand, Orekit
> needs SI unit and only SI units. However, entering angles in an end-user
> application in radians is awkward. Would it be possible to let the user
> specify the units he wants (SI by default, with m, m/s, m^3/s^2, rad) but
> allowing to use for example degrees for angles and converting to SI units
> underneath ?

I think the best way to enable entering data with units would be to
make our own widgets for entering data with the ability of changing
the unit with a dropdown list, like a AngleEditText, LengthEditText
and so on... The widget would be in charge of the conversion, because
supplying an unit along with all parameters through the IPC system
would not be really great.

Alexis