Re: [Orekit Developers] [SOCIS 2011] Status of the Android application

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

On Mon, Aug 8, 2011 at 5:15 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
> Is there a limit on the size of the file we can safely handle ? Should we reduce some
> files by reducing their time range and let the user download only useful small parts
> (lets say 1 year for each data type) ?

I don't think there is such a limit. The only thing we could encounter
is the time required to read and parse the data.

> What does the failed binder transaction error mean ?

Before the last commit I was passing AbsoluteDate/TimeScale instances
through the Android IPC system between the different windows (because
you can embed a serializable object in the so-called "Intent"), the
only problem is that a message seems to have a maximal size we seem to
hit when we serialize the TimeScale returned by
TimeScalesFactory.getGMST() and that how I think the binder
transaction error meant.

So I used the method you adviced me when we spoke about passing Orekit
objects by the IPC system, I now use light proxy objects with a load()
method which would return the Orekit object and this works perfectly.
They are called DateProxy and TimeScaleProxy.

>> Also, when I said "By creating a /sdcard/orekit/ folder and storing
>> the orekit-data.zip inside, it works." it also implies changing the
>> System.setProperty("orekit.data.path", "/sdcard/"); line of the
>> Android application sourcecode to /sdcard/orekit/ :)
>
> If we force users to use one folder only, using the orekit.data.path system
> property programmaticaly is awkward. This is a default configuration that
> was intended for external use (i.e. when some script launches the
> application and set the property beforehand). For mandatory programmatic
> setting, the cleanest way to configure Orekit is to use something like:
>
> DataProvider provider = new DirectoryCrawler(new File(/sdcard/orekit));
> DataProvidersManager.getInstance().addProvider(provider);
>
> In fact, this could later be expanded by having some user preferences with a
> few data folders, and even some URLS for online data (using NetworkCrawler
> for these data instead of DirectoryCrawler). The number of DataProvider
> instances the DataProvidersManager handles is not limited.

Oh I see.

Originally I used System.setProperty as a temporary hack just to make
it work, but you're right :) Thanks

Alexis