Re: [Openrocket-devel] Android is done!

[<kr...@su...>]

> OpenRocket development mailing list
	<ope...@li...> wrote: 
>
> Hi Kevin,
> 
> Sorry for not getting back to you sooner...
> 
> I loaded the latest version on my phone and it looks great.  I'd like
> to update just a few minor details:
> 
> - The version number should be visible somewhere.  I'm wondering
> whether it would make sense to have it in small text on the main
> screen, but at least in the About screen.

I think putting it on the main screen makes sense.  There is plenty of real estate and putting it in the Strings.xml file makes it pretty easy to change.


> - You could change the copyright statement to "Copyright 2007-1012
> Sampo Niskanen and others.  Android version by Kevin Ruland."

Sure.

> - The license should be stated somewhere.  At least in the short form
> of "Licensed under GPLv3 or later" in the About screen.  Later on it
> would be good to have a "License" button/link in the about screen
> which would provide the entire license from LICENSE.TXT (or just link
> to http://openrocket.sourceforge.net/license.html).
> 

I'll put a link to the home page and license in the about box.  I don't know if I can put hypertext in a text field, I hope so, since that would be easiest.

> Is the small icon + text at the top according to the new Android
> design guidelines or something?  I guess they weren't there earlier.
> 

That has been there for a little while now - maybe a month or so.  Android newest ui guidelines recommends using the ActionBar paradigm.  They had a sample implementation which provides this on pre-gingerbread devices so I adapted that to fit.  Had to make some changes to make it work correctly but since it's Apache all is good.

> Should we now start versioning both core and the Android version based
> on year+month (i.e. 12.03)?  And should there be some indication that
> it's specifically the Android version (12.03a, 12.03And or similar)?
> I've also used the "1.1.10pre" version number in SVN so as to know
> when bug reports are from a development version, I guess this could be
> "12.03-dev" or something.
> 

The year.month system is pretty nice.  Now is as good a time as any to implement it.  Do you want to support point releases?  For example, if in April we patch the android code should it be 12.03.1?  or 12.04?

I suspect that the android code might change a little more rapidly than the core code at least in the short term because of additional bugs.

Lets just call it "OpenRocket for Android 12.03"  I don't think anybody will be terribly confused by that.  Maybe point releases could be "OpenRocket for Android 12.03 p1" or so.

> 
> I could update the web page to contain a download section for Android
> so we can get this baby out.  We're having our hybrid rocket launch
> next Monday, so I'm a bit busy, but I'll see if I have time before it.
>  At least next week I'll have more time.

I'm in no particular rush.  Enjoy the flights and take some video to share.

> 
> My brother had a really cool idea that I'm now experimenting with
> (trying to get something working by Monday).  We've previously
> measured wind speed by releasing a balloon and tracking it with an
> angle meter, filling in data regularly to a spreadsheet that computed
> wind speed at various altitudes.  This could be completely automated
> by the phone, so you just type in the ascent rate of the balloon and
> track it along the edge of the phone, and the software then provides a
> plot of wind speed vs. altitude.  Similarly we could implement an
> triangulation-based altimeter.  I think these would be really great
> features on the mobile version.  (Not for the first release of
> course...)

Somebody on TRF suggested using a similar mechanism to estimate rocket apogee.  My biggest concern is sensor accuracy.  So you would need to measure the baseline (using GPS presumably), then use the gyro, accelerometer & compass to measure the phone position.  Not all phones have a gyro and relying on compass & accel alone gives pretty poorer results.  Accuracy of GPS is something like 30feet.  Then to have reliable measure of altitude you need to have a baseline ~1/2 altitude (my guess here).  Finally, to account for 3 dimensions you really need two measurements at the same time.

Do some searching for "android sensor fusion"....

I think the logical next step in the android development is to get a form in place to display the simulation conditions.  Then extend this to support creating new simulations.  The Simulation view would have to be changed slightly - perhaps having a ViewPanel in place to allow you to slide between 3 screens - plot, table of events, and conditions.  The new simulation bit would be a new dialog for conditions & motor selection, background process, etc.

Kevin