Corona using older Android UI element? (a Google Play Feature issue)

Solar2D Android
#1

Hi guys - 

   We are working on a feature opportunity with Google Play. When they did their round of testing, an issue came up that I think we’ll need the Corona Labs guys to weigh in: 

  • The app is using visual elements from older platforms in some areas (for example Android 2.3 Gingerbread or Android 4.x Holo visual elements on Android 5.0+ devices). Ensure that on Android 5.0+, all activities inherit Theme.AppCompat, Theme.Material or one of their descendants, and that all UI elements use styles from the Material/AppCompat palette (e.g. Widget.Material…, Widget.AppCompat… or ?android:attr/…) Please see attachment.
    For more info:
    http://developer.android.com/design/material/index.html

    And here is the screenshot that they sent us.

https://dl.dropboxusercontent.com/u/14319758/toddlerpuzzle_08_13_15_old.jpg

   Basically, in the screenshot, we have an activity indicator overlaid on top of the screen while the user is doing an IAP restore. 

native.setActivityIndicator( true );

    Based on their feedback, it sounds like Corona is still using an older version of the native UI elements? 

    Can Corona guys confirm if that’s the case? Unfortunately this is a biggie issue since it is preventing us from getting our app featured. 

    

Thanks!

Andrew 

#2

Wow… that’s actually very picky of them.

We are definitely applying the Android 5.0 theme to alerts and the dialog displaying the activity indicator.  But they’re right, we’re not applying the 5.0 theme to the progress spinner animation, well because we couldn’t figure out how to apply it dynamically in Java code at the time since there is no documentation on Google’s end on how to do it.  I’m sure we could figure it out, but it’ll likely require several hours of beating our heads on it.  Meaning if it was simple, then it would have already been done by now.

I recommend that you write up a bug report by clicking the “Report a Bug” link at the top of this page.  This way it gets into our queue to be later.  Thanks

#3

@Andrew,

You’re probably already going to do this, but if you don’t absolutely need that element to be native, I’d go around the issue for now and code up my own spinner and touch blocker to get that app(s) into the store.

-Ed

#4

@Josh. Bug submitted. Case #42320. Any help super helpful. 

http://developer.coronalabs.com/node/843/done?sid=17835

@Ed Yeah, that’s a good idea… Just trying to stay with the stock to keep things lighter and less to maintain…

#5

Andrew, just to be honest with you, I don’t recommend that you wait on us to make this change.  Our queue/todo-list is huge and you may end up waiting longer than you’d like.

You should be able to create your own progress dialog via Corona display objects within a day.  If you want to see an example on how to create an overlay, then have a look at sample project “Interface/DesktopWindow” which shows an overlay that steals all touch events when running it in the Corona Simulator or on a mobile device.  The only deal-breaker here is if you need to show an activity indicator on top of native UI such as TextFields, TextBoxes, WebViews, and VideoViews because native UI is always displayed on top of Corona display objects.

#6

@Josh @Ed

We’ll try to create our own as a work-around. We do have some native elements that the spinner needs to go on top of, but we’ll probably try to turn those off temporarily while the spinner is going - hopefully it’s not too noticeable to the end user. Will let you know if we run into any issues.

Thx!

Andrew 

#7

@Jush @RobMiracle

I want to follow up on this issue. We went ahead and implemented our own spinner using widget.newSpinner, hiding native elements manually when the spinner is spinning.  However, the issue we now run into is the one that others have pointed out, and that is the spinner runs in the same thread as the rest of the code. Consequently, when our code needs to be unzipping/loading assets in preparation for a scene, the spinner would simply freeze. Co-routine simply isn’t practical or even doable in situations where we don’t have a callback to use.

Anyway to prioritize this issue to be addressed on your end? Normally, I don’t think something like this is a major deal, but Google is being very nit-picky on this, and making it a requirement for feature… Which unfortunately does make it important…

Many thanks,

Andrew

#8

One of our engineering spent about 4 hours on this last week, but wasn’t able to figure out how to apply the theme.

You see, the problem here (which I warned up above) is that Google doesn’t provide any documentation or examples on how to set a theme for this UI element “programmatically”.  That’s the issue.  We’ve e-mailed Google on how to do this, but haven’t received a response yet.

In the meantime, perhaps it would be best to not animate your custom progress spinner.  Your spinner doesn’t have to look like the one built in Android’s OS, and if it didn’t, then Google will likely have a less of a problem with it.  Just a static image to indicate that the app is waiting for a task to finish will probably suffice.

#9

@Josh We’ll give static loading screen a try and hopefully it passes muster. Please do keep us posted if this gets resolved. thx.

#10

Andrew,

We’ve just modified Corona’s native.setActivityIndicator() to support Android’s material or holo theme, if available.  This change will be made available in daily build #2745.  Thanks for your patience.

#11

You guys rock!!  Thanks!!

#12

Wow… that’s actually very picky of them.

We are definitely applying the Android 5.0 theme to alerts and the dialog displaying the activity indicator.  But they’re right, we’re not applying the 5.0 theme to the progress spinner animation, well because we couldn’t figure out how to apply it dynamically in Java code at the time since there is no documentation on Google’s end on how to do it.  I’m sure we could figure it out, but it’ll likely require several hours of beating our heads on it.  Meaning if it was simple, then it would have already been done by now.

I recommend that you write up a bug report by clicking the “Report a Bug” link at the top of this page.  This way it gets into our queue to be later.  Thanks

#13

@Andrew,

You’re probably already going to do this, but if you don’t absolutely need that element to be native, I’d go around the issue for now and code up my own spinner and touch blocker to get that app(s) into the store.

-Ed

#14

@Josh. Bug submitted. Case #42320. Any help super helpful. 

http://developer.coronalabs.com/node/843/done?sid=17835

@Ed Yeah, that’s a good idea… Just trying to stay with the stock to keep things lighter and less to maintain…

#15

Andrew, just to be honest with you, I don’t recommend that you wait on us to make this change.  Our queue/todo-list is huge and you may end up waiting longer than you’d like.

You should be able to create your own progress dialog via Corona display objects within a day.  If you want to see an example on how to create an overlay, then have a look at sample project “Interface/DesktopWindow” which shows an overlay that steals all touch events when running it in the Corona Simulator or on a mobile device.  The only deal-breaker here is if you need to show an activity indicator on top of native UI such as TextFields, TextBoxes, WebViews, and VideoViews because native UI is always displayed on top of Corona display objects.

#16

@Josh @Ed

We’ll try to create our own as a work-around. We do have some native elements that the spinner needs to go on top of, but we’ll probably try to turn those off temporarily while the spinner is going - hopefully it’s not too noticeable to the end user. Will let you know if we run into any issues.

Thx!

Andrew 

#17

@Jush @RobMiracle

I want to follow up on this issue. We went ahead and implemented our own spinner using widget.newSpinner, hiding native elements manually when the spinner is spinning.  However, the issue we now run into is the one that others have pointed out, and that is the spinner runs in the same thread as the rest of the code. Consequently, when our code needs to be unzipping/loading assets in preparation for a scene, the spinner would simply freeze. Co-routine simply isn’t practical or even doable in situations where we don’t have a callback to use.

Anyway to prioritize this issue to be addressed on your end? Normally, I don’t think something like this is a major deal, but Google is being very nit-picky on this, and making it a requirement for feature… Which unfortunately does make it important…

Many thanks,

Andrew

#18

One of our engineering spent about 4 hours on this last week, but wasn’t able to figure out how to apply the theme.

You see, the problem here (which I warned up above) is that Google doesn’t provide any documentation or examples on how to set a theme for this UI element “programmatically”.  That’s the issue.  We’ve e-mailed Google on how to do this, but haven’t received a response yet.

In the meantime, perhaps it would be best to not animate your custom progress spinner.  Your spinner doesn’t have to look like the one built in Android’s OS, and if it didn’t, then Google will likely have a less of a problem with it.  Just a static image to indicate that the app is waiting for a task to finish will probably suffice.

#19

@Josh We’ll give static loading screen a try and hopefully it passes muster. Please do keep us posted if this gets resolved. thx.

#20

Andrew,

We’ve just modified Corona’s native.setActivityIndicator() to support Android’s material or holo theme, if available.  This change will be made available in daily build #2745.  Thanks for your patience.