Android port

(Difference between revisions)
Jump to: navigation, search
m (Other art)
('Action bar' icons)
Line 108: Line 108:
 
* [[Android_port/Specification#Main_view]]
 
* [[Android_port/Specification#Main_view]]
 
** Action Bar Logo (48dp)
 
** Action Bar Logo (48dp)
*** 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). Up to 8dp wide, or integrated with the logo.
 
** Open search
 
** Open search
 
** Open controls
 
** Open controls

Revision as of 08:14, 18 March 2012

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.

Contents

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.

Communication

  • IRC channel: #Stellarium on freenode. Webchat client: [1]
  • Development mailing list: [2]
  • Feedback forum
  • Please don't submit bugs related to the port to Launchpad yet. Add them to the Wiki under New Issues, and/or pop on IRC. Anything that seems incomplete probably is.

Remaining tasks

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)

  • Complete first releasable QML-based GUI
    • Design GUI
    • Get GUI basically operational
      • Hook QML up, and a non-functional UI minus configuration dialogs
      • Pinch-zoom
      • Get a the main GUI view actions doing something (playback, accelerometer (not hooked up, but maybe print something))
      • Add button tooltips
      • Add View / Markings / Plugin dynamic button drawers
        • 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
      • 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
    • Cook up additional layouts (small phone, 5" tablet, 7" tablet, 10" tablet)
      • Design
      • Implement
  • Add Android art (icon, replace necessitas' splashscreen, etc.)
  • Consider beginning preliminary ("pre-alpha") testing
  • Localization support
    • Autodetect locales via JNI
    • 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 ETC1 texture compression
      • 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
    • Profile OpenGL
    • Profile with gprof or callgrind
    • Optimization ideas:
      • Consider ways of reducing per-frame accuracy for performance/battery use boost (value caching, lerping and dead reckoning instead of recalculating constantly)
  • Fix most Alpha bugs, any particularly large ones
  • Implement big/easy Alpha feedback
  • "Beta" test
    • Dependent on Necessitas hitting Beta; until it does, spin around 'alpha' versions
  • Implement beta feedback items
  • Fix as many bugs as is feasible
  • Add remaining Android art: all Google Play-required items (banners, large icon, etc.)
  • (Eventually) - First public Google Play / other sources release, followed by bug fixing and more bug fixing

Other tasks

  • add-ons (additional catalogues and such) downloadable via Google Play to reduce bandwidth load from Android users?
  • [3] control the back key
  • location and orientation support
    • scientes suggested on IRC that we might create a multiplatform Location plugin, using QtMobility's Location API. This API appears to support desktop as well as mobile clients.
      • the location API should supported by necessitas, but may require some minor Android-specific hacks. See [4] and [5]

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.

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:

  • 0.75x
  • 1.0x
  • 1.5x
  • 2.0x

The Android GUI design guidelines are at [6] as well as [7]

'Action bar' icons

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 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. 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.

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

  • Android_port/Specification#Main_view
    • Action Bar Logo (48dp)
      • related: left arrow ( see Android_port/Specification#Playback ) for the Action Bar logo when it becomes a back button (is not displayed otherwise). Up to 8dp wide, or integrated with the logo.
    • Open search
    • Open controls
    • Toggle accelerometer (on / off)
    • . . . / maximize sidebar (standard Android-style)

Android / Google Play art

[8]

This time, all sizes in pixels and only one size needed unless otherwise noted

  • Launcher icons (48dp; need all four sizes, so 36px, 48px, 72px, 96px)
  • High Resolution Application Icon (512x512, 32-bit PNG with alpha; Max size of 1024KB)
  • Promotional graphic (optional) (180w x 120h, 24 bit PNG or JPEG (no alpha), Full bleed, no border in art)
  • Feature graphic (optional) (1024w x 500h, 24 bit PNG or JPEG (no alpha) with no transparency; all important elements within 924x400 safe zone in center of image

Other art

  • 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 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)

New issues

Known issues

  • Performance and CPU usage need to be looked at (above)
  • Check for NPOT texture support (driver may be returning true even if it's not)
    • do we care?
  • 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
  • it occasionally crashes very soon after starting; usually shortly after, or even during the loading screen
    • it may happen more frequently immediately after installing the app. The log and logcat output show nothing interesting.
    • 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.

Issues waiting for necessitas

  • 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.
    • there's a fix that's yet to be reviewed
  • resuming the app (switching to another app, then back before Android closes it) results in a blank screen
    • there's a not-yet-reviewed fix for this as well
  • [9]
  • issue 169 - soft keyboard always resizes window

Misc notes

Contributing

Building

See: Building for Android

Contributing

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.

Translators and testers will be needed at some point.

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox