Re: [Orekit Developers] [SOCIS 2011] improved specifications

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

On Thu, Aug 4, 2011 at 4:11 PM, Luc Maisonobe <Luc.Maisonobe@c-s.fr> wrote:
> Don't worry about Android 3.0 yet. Many existing tablets (and the one we
> have available now) do run Android 2.2 despite it was designed for
> phones and not tablets. So the main difference is screen size.

As you want. The only thing is that there would be only Android 3.0
tablets on sale in a few months, but as you want :)

>> 5. If they apply, running time optimizations tasks would be nice to do
>> here (as I put this in my original proposition, it would not be nice
>> to forget this :) )
>
> Yes, sorry about that. It is important and you were right to raise this
> flag.

Oh sorry, when I said "not nice" I was speaking of me :)

>>> From a data point of view, the application should be able to use updated
>>> data sets (copying files to SD-card is fine). For first users setup,
>>> having a default initial set of data installed when the application is
>>> installed is mandatory.
>>
>> So you mean that you prefer to embed a dataset in the final .apk and
>> let the user select a custom apk if he wants. Ok :)
>
> I'm not sure it's an apk. As I understand, the application is in an apk
> and it can read files (or zip archives). So as the user installs the
> application, he/she installs an apk and "magically" get an initial data
> set. this initial set may be embedded in the apk, but then it would be
> cumbersome if later one the user wants to customize this data set.
> Another point is that customization should be simple, i.e. user should
> simply drop the files on the sdcard without fancy packaging.

Ok we agree :) Basically the application is in a .apk but you can
embed resources in it. The idea is to embed an initial dataset in here
and AssetManager will give an InputStream to the file we requested (it
may even read it from the .apk on the fly). The user would have access
to a list of dataset he has put in his sdcard in the application's
"Settings" to choose his one if he wants.

> Is it possible to split the application as one apk for the code and a
> separate data set and have both installed automatically ? Another
> possibility would be to have the application without data but a button
> "download initial data set from Orekit web site" that the user would
> need to press. This is less than ideal (I would prefer the user to be
> able to start immediately after application installation), but could be
> useful.

It can be possible to download an initial data set from the Orekit
website but this would make the code a little bit more complex as we
need to check if the dataset is present each time we launch an
activity, and if not found we would need to redirect to the download
activity. But it's possible.

> If I understand correctly, it is a highly modularized system were
> applications are themselves split in different modules launched
> independently and automatically by the OS as request are made. Did I
> understand correctly ?

Yes it's like that. And the AndroidManifest.xml is a sort of public
API which declares to the Android OS which class does what (like
respond to which intent, can act as a background service, can be in
the application menu list, etc...)

> OK. Beware of serialization for Frame, as some frame involve huge
> amounts of data. Earth frames for example come with tremendous series of
> small harmonic effects, plus reference to correction data that are
> precisely what is in the data set mentioned above.
>
> Perhaps the select frame should simply return a proxy object, or even
> simply the "Predefined" enum, so the application get the frame from this
> key thanks to the Frames factory.
>
> For AbsoluteDates, there are no problems, they are simple objects.
>
> Orbits may be difficult too, as orbits contain references to frames ...
> Here again, we may need some custom proxy object.

Ok.

>> So, when these promptFrame, promptDate, ...-like activities will be
>> done, it will be very easy to enable the user to choose a parameter.
>
> As I understand, it will also allow smooth evolution of the application,
> with simple UI first and enhanced UI if needed later.

Yes but the downside is that it also mean that you can't have a
computer-like interface on tablets where you have every setting on the
same window, you'll need to go through a bunch of windows, but that's
the best idea I currently have.

Alexis