[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Status of the Android application -- 2
Alexis ROBERT <alexis.robert@gmail.com> a écrit :
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 :)
Wow, this is great!
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)
The most important property for an event is its occurrence date, so
this is common to all event types. The second property is a boolean
one (named "increasing" in the eventOccurred method) which can be
directly associated to a keyword that would be displayed (for
visibility, these are AOS/LOS, for eclipse these are "eclipse
entry/eclipse exit" ...). We will provide you with the association
when you'll need them.
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.
Perhaps I did not use the back button. This does work now, I probably
made a mistake. My bad.
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 ?
If it is a recommended best practice, lets use it. I'm not yet used to
mobile device user interfaces (I'm an old school guy).
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.
I don't really like having a user interface do any computation or in
fact temper with user input at all. I have seen this before and it is
a nightmare to get reproducible results and to perform tests and
validation. Of course, for simple multiplicative changes like m to
kilometer conversion, it looks appealing. However, I know some people
go up to have the graphical user interface perform complete space
flight dynamics computation like orbit conversions ... In fact, I have
already seen it actually done in an operational product.
best regards,
Luc
Alexis
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.