<div class="toc">'''Note''': There is a '''paid''' [https://play.google.com/store/apps/details?id=com.noctuasoftware.stellarium ''Stellarium Mobile''] port for Android by [http://www.noctua-software.com/ Noctua Software]. Noctua Software was established by Fabien Chereau, who is the original author of Stellarium, and his brother. ''Stellarium Mobile'' is Fabien's fork/port of Stellarium which was originally created for Nokia smartphones. Said app is not related to the port discussed on this page; this port is being developed with the intention of being merged into Stellarium-proper and becoming an official Stellarium.org-supported port, or at the very least staying up-to-date with any changes made to the official version of Stellarium and deviating from it minimally.</div>

You can build it at any time, though (see: '''[[Building for Android]]'''). If you want to help out in any way with development, it would be appreciated.

You can build it at any time, though (see: '''[[Building for Android]]'''). If you want to help out in any way with development, it would be appreciated.

+

+

This page is development-centric right now; most of this will have to be spun off into another page at some point.

== Specification / design ==

== Specification / design ==

−

See: '''[[Android port/Specification]]''' for a detailed breakdown of the current design, with use cases. Technical implementation details are broken-up into tasks below.

+

See: '''[[Android port/Specification]]''' for a detailed breakdown of the current design. Technical implementation details are broken-up into tasks below.

== Communication ==

== Communication ==

Line 20:

Line 24:

=== Rough timeline ===

=== Rough timeline ===

(This is a rough timeline / list of ''remaining'' feature tasks; some completed items may be in here, most not. Bugs and general issues are below, and slot into the timeline ''somewhere'')

(This is a rough timeline / list of ''remaining'' feature tasks; some completed items may be in here, most not. Bugs and general issues are below, and slot into the timeline ''somewhere'')

+

+

(I took a break. I'm active again, but Stellarium advanced quite a bit in the mean time, and some things broke when I merged these changes into my branch. I've readded ES 2 support and have to readd input/actions and look at a potential crash, but I'm just about back to the list again)

**** See specification. These drawers will contain buttons added by code; buttons won't be hardcoded in the QML. This will allow for easier interaction with plugins.

** Fix the static plugins

** Fix the static plugins

*** Some don't support ES 2. Based on IRC discussions, these plugins should be, whenever possible, doing their drawing through StelPainter and ''not'' accessing OpenGL directly

*** Some don't support ES 2. Based on IRC discussions, these plugins should be, whenever possible, doing their drawing through StelPainter and ''not'' accessing OpenGL directly

*** plugins know too much about the GUI; they access the concrete StelGui directly to create buttons, rather than the abstract StelGuiBase

*** plugins know too much about the GUI; they access the concrete StelGui directly to create buttons, rather than the abstract StelGuiBase

−

** Add pretty, Android-styled button icons

+

** <strike>Add pretty, Android-styled button icons

*** Decide on DPI buckets

*** Decide on DPI buckets

−

*** Add a custom image provider for icons. This image provider will choose the correct icon based on the DPI bucket we're in. This process will be transparent to QML; all it needs to do is use use this image provider (e.g. <code>Image{ source: "scaled://image.png" }</code>), and it'll get the image from the correct bucket

+

*** Add a custom image provider for icons. This image provider will choose the correct icon based on the DPI bucket we're in. This process will be transparent to QML; all it needs to do is use use this image provider (e.g. <code>Image{ source: "scaled://image.png" }</code>), and it'll get the image from the correct bucket</strike>

** Add search

** Add search

*** ...

*** ...

Line 56:

Line 63:

* Localization support

* Localization support

** Autodetect locales via JNI

** Autodetect locales via JNI

+

*** This works; however, we need to manually fall back when we don't have the language+country, as this isn't handled by libintl-lite. For instance: if the locale requests "fr_CA" (which doesn't exist), we should fall back to "fr" (sans country code). Currently it just fails and falls back to "C" (English/US, the default)

** Ensure that everything in QML is translatable, and in the gettext files

** Ensure that everything in QML is translatable, and in the gettext files

* Accelerometer support

* Accelerometer support

Line 61:

Line 69:

* Alpha testing

* Alpha testing

* Optimize

* Optimize

−

** Implement ETC1 texture compression

+

** Implement texture compression (PVR, DXT, ETC1)

−

*** ETC1 may have issues with large chroma shifts, which could render it useless for us. If so, may have to use device-specific texture compression formats. => more work. We may want to move that way ''eventually'' anyways

+

*** PVR and DXT are device-specific (PowerVR and Tegra, respectively)

+

*** ETC1 may have issues with large chroma shifts, which may make it of limited use. IIRC, it also lacks an alpha channel; a shader to handle alphas stored in a second texture would be necessary

** ''scientes'' suggested on IRC that we might create a multiplatform Location plugin, using QtMobility's [http://doc.qt.nokia.com/qtmobility/location-overview.html Location API]. This API appears to support desktop as well as mobile clients.

** ''scientes'' suggested on IRC that we might create a multiplatform Location plugin, using QtMobility's [http://doc.qt.nokia.com/qtmobility/location-overview.html Location API]. This API appears to support desktop as well as mobile clients.

Line 85:

Line 95:

=== Art ===

=== Art ===

The following art is needed. Each section of art is accompanied with a link to the specification page describing what that piece of art is used for.

The following art is needed. Each section of art is accompanied with a link to the specification page describing what that piece of art is used for.

+

+

==== Raster artwork ====

Note that 1dp = 1px at 160dpi. Google recommends using a 3:4:6:8 scaling ratio for assets for screens of different densities; this means we'll end up having 4 sets of most every piece of art; to convert from dp to pixels for each of the groups:

Note that 1dp = 1px at 160dpi. Google recommends using a 3:4:6:8 scaling ratio for assets for screens of different densities; this means we'll end up having 4 sets of most every piece of art; to convert from dp to pixels for each of the groups:

Line 93:

Line 105:

The Android GUI design guidelines are at [http://developer.android.com/guide/practices/ui_guidelines/index.html] as well as [http://developer.android.com/design/index.html]

The Android GUI design guidelines are at [http://developer.android.com/guide/practices/ui_guidelines/index.html] as well as [http://developer.android.com/design/index.html]

+

+

Android artwork can be found in the AOSP repositories. The [http://developer.android.com/design/index.html Android design] site also has vector art, but it's under a somewhat vague license (unrestricted use ''to develop your apps''). Much of the same art is available rasterized in AOSP's repository (under the Apache license 2.0) though.

+

+

==== Vector artwork ====

+

+

Vector artwork (in SVG format) can also be used. In that case, one can include them for as many of the above groups as desired. Simple icons may just be one image; more complex ones might have a simpler fallback for lower-DPI screens so that they don't end up as a blur.

+

+

==== Art grouping ====

+

+

Currently, the art resides in <code>data/mobileGui</code> in the following directories:

+

* images-ldpi (low DPI; 0.75x scaling factor)

+

* images-mdpi (medium DPI; 1.0x scaling factor)

+

* images-hdpi (high DPI; 1.5x scaling factor)

+

* images-xhdpi (extra-high DPI; 2.0x scaling factor)

+

* images (used as a fallback if no images were found in the above directories; most vector art is here)

The current thought is to imitate Android's Action Bar to provide a layout that's consistent with other Android apps. Standard size for an Action Bar icon in Android 4.0, according to the Android Design guidelines, is 24dp x 24dp.

+

The current thought is to imitate Android's Action Bar to provide a layout that's consistent with other Android apps. Standard size for an Action Bar icon in Android 4.0, according to the Android Design guidelines, is 32dp x 32dp.

The Action Bar itself is 48dp high.

The Action Bar itself is 48dp high.

−

The Action Bar logo (see [[Android_Port/Specification]]; the icon on the far-left of the bar) should be larger than the other icons. It can be the same size as the launcher icon. In fact, it can be the same image as the launcher icon, or it can be a variant with larger margins, whatever works best.

+

The Action Bar logo (see [[Android_port/Specification]]; the icon on the far-left of the bar) should be larger than the other icons. It can be the same size as the launcher icon. In fact, it can be the same image as the launcher icon, or it can be a variant with larger margins, whatever works best.

−

There's more details in the guidelines, but Google says they should be flat (not shaded, outlined, or shadowed), pictographic, and #ffffff at 80% opacity. If we diverge from that, we should keep things consistent.

+

There's more details in the guidelines, but Google says they should be flat (not shaded, outlined, or shadowed), pictographic, and #ffffff at 80% opacity ('''*** I think it's a good idea if we just do the opacity programatically. Make the image 100%, have Stellarium do 80% or 30% depending on if it's enabled or disabled. Halves the number of images we need to bother with...'''). If we diverge from that, we should keep things consistent.

−

If we're doing activated/deactivated icons like Stellarium does, the deactivated ones should probably still be fairly bright (near or at #ffffff / 80%). Mobile devices vary in screen quality, and are frequently used with low brightness settings and in adverse lighting conditions.

+

If we're doing activated/deactivated icons like Stellarium does, the deactivated ones should probably still be fairly bright (near or at #ffffff). Mobile devices vary in screen quality, and are frequently used with low brightness settings and in adverse lighting conditions.

*** related: left arrow ( < ) for the Action Bar logo when it becomes a back button (is not displayed otherwise). Up to 8dp wide, or integrated with the logo.

+

*** related: left arrow ( see [[Android_port/Specification#Playback]] ) for the Action Bar logo when it becomes a back button (is not displayed otherwise). There's an Android asset for this.

** Open search

** Open search

** Open controls

** Open controls

−

** Toggle accelerometer (on / off)

+

** Toggle accelerometer

** . . . / maximize sidebar (standard Android-style)

** . . . / maximize sidebar (standard Android-style)

* [[Android_port/Specification#Object_selected]]

* [[Android_port/Specification#Object_selected]]

+

* (these should probably be shadowed or outlined as they don't have a background behind them)

** Deselect object

** Deselect object

** Center on object

** Center on object

Line 121:

Line 150:

* [[Android_port/Specification#Playback]]

* [[Android_port/Specification#Playback]]

−

** Rewind (on / off)

+

** Rewind

−

** 1x speed (on / off)

+

** 1x speed

−

** Current time (on / off)

+

** Current time

−

** Fast forward (on / off)

+

** Fast forward

* [[Android_port/Specification#Search]]

* [[Android_port/Specification#Search]]

** Search

** Search

−

* [[Android_port/Specification#Pull-down bar]]

+

* [[Android_port/Specification#Menu]]

** Close/minimize sidebar

** Close/minimize sidebar

** Night vision mode

** Night vision mode

Line 135:

Line 164:

** Location

** Location

** Settings

** Settings

−

** Information box

+

** Sky dialog

+

*** (for enabling/disabling stars, planets, etc.)

** View dialog

** View dialog

−

** Markings dialog

+

*** (likewise for markings; grids, constellations, etc.)

** Plugins dialog

** Plugins dialog

+

*** (Plugins add their buttons to this one; could contain anything)

==== Android / Google Play art ====

==== Android / Google Play art ====

Line 151:

Line 182:

==== Other art ====

==== Other art ====

* Qt splashscreen (any size)

* Qt splashscreen (any size)

−

** the same size as the normal splash is probably fine; 512x512. Or anything smaller. Or larger, even. Will be placed in the center of the screen and scaled ''down'' until it fits in view

+

** the same size as the normal splash is probably fine; 512x512. Or anything smaller. Or larger, even. Will be placed in the center of the screen and scaled ''down'' uniformly until it fits in view

** this is shown ''before'' the normal Stellarium splashscreen, but this one doesn't have a version # or anything else on it that isn't baked-in (so yes, we get two splash screens, so this should probably not be a repeat of the other one)

** this is shown ''before'' the normal Stellarium splashscreen, but this one doesn't have a version # or anything else on it that isn't baked-in (so yes, we get two splash screens, so this should probably not be a repeat of the other one)

== New issues ==

== New issues ==

+

<!-- As above, the Stellarium Mobile port on Google Play is unrelated. Please don't add issues for that here. -->

== Known issues ==

== Known issues ==

−

* Performance and CPU usage need to be looked at (above)

+

* Tegra devices no longer work. The only ''currently-known'' Tegra issue is that there are non-unrollable loops in a couple of the shaders, which aren't supported

−

* Check for NPOT texture support (driver may be returning true even if it's not)

+

* since updating, the splash screen only shows up for a moment (less than one second)

−

** do we care?

+

** this appears to be a common issue when building Stellarium on Windows (see mailing list)

−

* App should be suspended or outright killed when it's switched away from, as it continues to go full tilt and drain battery

+

−

* need to (re)disable "Zoom to Fullscreen" option on tablets

+

* Performance and CPU usage need to be looked at

−

* it occasionally crashes very soon after starting; usually shortly after, or even during the loading screen

+

* Check for NPOT texture support (some drivers ''may'' be returning true even if it's not)

−

** it ''may'' happen more frequently immediately after installing the app. The log and logcat output show nothing interesting.

+

** Not certain of this any longer. It may have been a necessitas issue rather than a driver one; on the same device, it's no longer an issue.

−

** this is associated with startup somehow; after the ~30 second mark, I've not seen it crash. I've had it running overnight unintentionally without instability.

+

* App should be suspended when it's switched away from, rather than waiting for Android to kill it

=== Issues waiting for necessitas ===

=== Issues waiting for necessitas ===

−

* [https://sourceforge.net/p/necessitas/tickets/120/ necessitas bug #120] prevents us from using the package's Assets directory, as we would ideally do. For now, manually copy the files that get placed in stellarium/android/java/assets to /sdcard/stellarium on the device.

+

* <strike>[https://sourceforge.net/p/necessitas/tickets/120/ necessitas bug #120] prevents us from using the package's Assets directory, as we would ideally do. For now, manually copy the files that get placed in stellarium/android/java/assets to /sdcard/stellarium on the device.</strike>

−

** there's a fix that's yet to be reviewed

+

** necessitas now has a new, official mechanism for accessing APK assets. see [http://community.kde.org/Necessitas/Assets]

−

* <strike>resuming the app (switching to another app, then back before Android closes it) results in a blank screen

Latest revision as of 05:35, 2 January 2013

Note: There is a paidStellarium Mobile port for Android by Noctua Software. Noctua Software was established by Fabien Chereau, who is the original author of Stellarium, and his brother. Stellarium Mobile is Fabien's fork/port of Stellarium which was originally created for Nokia smartphones. Said app is not related to the port discussed on this page; this port is being developed with the intention of being merged into Stellarium-proper and becoming an official Stellarium.org-supported port, or at the very least staying up-to-date with any changes made to the official version of Stellarium and deviating from it minimally.

Experimental port of Stellarium to Android using not-yet-complete Android port of Qt, necessitas.

This is an experimental branch built on an incomplete library and is not yet ready for public consumption.

An official public release won't happen until some time after necessitas reaches Beta, and this port is sufficiently mature, whichever comes later; testing releases will probably start well before then.

You can build it at any time, though (see: Building for Android). If you want to help out in any way with development, it would be appreciated.

This page is development-centric right now; most of this will have to be spun off into another page at some point.

(This is a rough timeline / list of remaining feature tasks; some completed items may be in here, most not. Bugs and general issues are below, and slot into the timeline somewhere)

(I took a break. I'm active again, but Stellarium advanced quite a bit in the mean time, and some things broke when I merged these changes into my branch. I've readded ES 2 support and have to readd input/actions and look at a potential crash, but I'm just about back to the list again)

Some don't support ES 2. Based on IRC discussions, these plugins should be, whenever possible, doing their drawing through StelPainter and not accessing OpenGL directly

plugins know too much about the GUI; they access the concrete StelGui directly to create buttons, rather than the abstract StelGuiBase

Add pretty, Android-styled button icons

Decide on DPI buckets

Add a custom image provider for icons. This image provider will choose the correct icon based on the DPI bucket we're in. This process will be transparent to QML; all it needs to do is use use this image provider (e.g. Image{ source: "scaled://image.png" }), and it'll get the image from the correct bucket

Add search

...

Add settings screen

Create item types, a view, and a basic model

Hook items up to backend

Refine items, view and model

Have multiple list views working, along with categories

Complete the models (with most necessary settings)

Add locations screen

A specialized settings screen with a little image of the Earth and such

Design

Implement

Hook up to GPS/location/(orientation?) plugin

Plugin doesn't exist yet. QtMobility's location support looks like it supports desktop OSs, so this plugin would be useful for more than just mobile

This works; however, we need to manually fall back when we don't have the language+country, as this isn't handled by libintl-lite. For instance: if the locale requests "fr_CA" (which doesn't exist), we should fall back to "fr" (sans country code). Currently it just fails and falls back to "C" (English/US, the default)

Ensure that everything in QML is translatable, and in the gettext files

Accelerometer support

Fix large bugs and feature requests from pre-Alpha

Alpha testing

Optimize

Implement texture compression (PVR, DXT, ETC1)

PVR and DXT are device-specific (PowerVR and Tegra, respectively)

ETC1 may have issues with large chroma shifts, which may make it of limited use. IIRC, it also lacks an alpha channel; a shader to handle alphas stored in a second texture would be necessary

Note that 1dp = 1px at 160dpi. Google recommends using a 3:4:6:8 scaling ratio for assets for screens of different densities; this means we'll end up having 4 sets of most every piece of art; to convert from dp to pixels for each of the groups:

Android artwork can be found in the AOSP repositories. The Android design site also has vector art, but it's under a somewhat vague license (unrestricted use to develop your apps). Much of the same art is available rasterized in AOSP's repository (under the Apache license 2.0) though.

Vector artwork (in SVG format) can also be used. In that case, one can include them for as many of the above groups as desired. Simple icons may just be one image; more complex ones might have a simpler fallback for lower-DPI screens so that they don't end up as a blur.

The current thought is to imitate Android's Action Bar to provide a layout that's consistent with other Android apps. Standard size for an Action Bar icon in Android 4.0, according to the Android Design guidelines, is 32dp x 32dp.

The Action Bar itself is 48dp high.

The Action Bar logo (see Android_port/Specification; the icon on the far-left of the bar) should be larger than the other icons. It can be the same size as the launcher icon. In fact, it can be the same image as the launcher icon, or it can be a variant with larger margins, whatever works best.

There's more details in the guidelines, but Google says they should be flat (not shaded, outlined, or shadowed), pictographic, and #ffffff at 80% opacity (*** I think it's a good idea if we just do the opacity programatically. Make the image 100%, have Stellarium do 80% or 30% depending on if it's enabled or disabled. Halves the number of images we need to bother with...). If we diverge from that, we should keep things consistent.

If we're doing activated/deactivated icons like Stellarium does, the deactivated ones should probably still be fairly bright (near or at #ffffff). Mobile devices vary in screen quality, and are frequently used with low brightness settings and in adverse lighting conditions.

Icons. 32dp unless otherwise noted, and all four sizes are needed (see above):

the same size as the normal splash is probably fine; 512x512. Or anything smaller. Or larger, even. Will be placed in the center of the screen and scaled down uniformly until it fits in view

this is shown before the normal Stellarium splashscreen, but this one doesn't have a version # or anything else on it that isn't baked-in (so yes, we get two splash screens, so this should probably not be a repeat of the other one)

necessitas bug #120 prevents us from using the package's Assets directory, as we would ideally do. For now, manually copy the files that get placed in stellarium/android/java/assets to /sdcard/stellarium on the device.

necessitas now has a new, official mechanism for accessing APK assets. see [9]

Right now, the main thing I need is development help. Please feel free to lend a hand; create a branch off the current one (see Building for Android) and go to town. Read above for means of communication.