Android Expansion Files Error On First Load.

Solar2D Android
#81

WHY I HAD THOUGHT THIS DIDN’T WORK (previously)

Remember my comment at the beginning of the week that my print statements weren’t outputting with logcat?

I had actually tried two things to test the globalizing of cached_displayNewGroup and both failed in my test/

FIRST THING TRIED

THIS FAILS IN THE SIMULATOR:

  1. Place “widget.lua” in the main project directory next to “main.lua” with the variable set to be global.

  2. Place this code in “main.lua” to test it all in the simulator:

widget = require(“widget”)

if (cached_displayNewGroup) then

    print ("###########  MAIN (widget.lua next to main) - cached_displayNewGroup is NOT nil")

    function display.newGroup()

        return cached_displayNewGroup()

    end

else

    print ("###########  MAIN (widget.lua next to main) - cached_displayNewGroup IS NIL")

end

  1. When I run this, NONE of the print statements in “widget.lua” (see previous post) actually display (as widget is birthed) and cached_displayNewGroup is nil when I test for it.

  2. But, on the other hand, I know that the code in “widget.lua” actually did run (or the Widget code ran somewhere else) – it managed to hose the removeSelf() functionality of any dispely groups I tried to subsequently remove.

  3. After this essentially failed in the simulator, I didn’t think to try it fully on a build for the device (I should have)

=============================================================================

And another bit of simulator “voodoo”. If I change the name of the lua file

to “widget1.lua” and instantiate with this:

widget = require(“widget1”)

Then everything runs just fine with all print statements firing and 

cached_displayNewGroup is NOT nil!

I think I know what you are doing here, I just think it is strange that you

don’t document it anywhere. It will waste someone else’s hours down the road.

=============================================================================

====== CONTINUED BELOW ========================================================================

#82

SECOND THING TRIED

Since I had that strange experience on the simulator, I decided to try everything by using a “widget.lua” file in the “widgetLibrary” folder (the default placement in your examples). When I simply did this and changed my widget=t birth to this:

widget = require(“widgetLibrary.widget”)

The result was that everything tested out well in the simulator and on a device (no expansion file yet, just a single APK). With these results under my belt, I optimistically made a Google Play Build and placed it in the store (with expansion file). Of course I commented out my own birthing of “widget” – I expected that the “Corona Stub” would do that.

I don’t know why I was optimistic. My print statements never fired and, apparently, the Corona Stub didn’t use my instance of “widget.lua” in the directory. So that is where I ended up earlier this week.

BUT THERE’S MORE INTERESTING STUFF (below)

====== CONTINUED BELOW ========================================================================

#83

INTERESTING STUFF 

Did you know . . . .

**  That if you place a “widget.lua” file next to the “main.lua” file and you also place another copy of the “widget.lua” file in a “widgetLibrary” folder, BOTH FILES will be fired by the “Corona Stub” that handles the expansion file checking. The trace statements in each of them will run (file next to “main.lua” runs first). But after they each run, the app stops at a full black screen and nothing else happens (and there are no errors or anything outputted to explain the problem). What is fascinating here is that the “widget.lua” file in a “widgetLibrary” folder DOES NOT RUN when it is there all by itself (without a twin next to “main.lua”).

FINAL IMPORTANT CONCERN

The one thing that concerns me in the approach that I “think” is successful is that I get the following output on first run of the App after it is now downloaded from the Google Play Store. It is this:

> Class.forName: widgetLibrary.widget.luaLoader

WARNING: Could not load ‘LuaLoader’

> Class.forName: widgetLibrary.widget.luaLoader

WARNING: Could not load ‘LuaLoader’

What scares me here is whether this means that “if the APK portion of the app actually needed to go and download the “.obb” expansion file”, that things would break. I just don’t know and would love advice on what is triggering this and whether there is another LUA file I need to place in my project. I would appreciate advice.

Thanks;

Steve

#84

Steve 

It’ll take me a while to read through all that slowly and see if it matches what I see.

Would you be able to make a concise example app? What I did was made an example app

by cut 'n pasting bits from our real app until I found what wasn’t working. If you had an example bit of code I’d be happy to run it here and see if I can get the same results as you.  It would also be easier for the Corona guys if they had something that reproduced the results and they could debug better.

#85

Hi Studycat;

Thanks for the question. And thanks so much for your thoughts on approaches to the problem. I’m presently under the gun to complete a Flash game that I promised would be complete by late this week (yes, my web development roots are on the dark side and we still make money on this Flash stuff). So I’m not certain when I can get to it.

If you are simply interested in what worked for us, it is described in the 4 points of my first post on 8/23.

And if anyone has any questions about “why does this happen?”, it stems from the fact that the core widget code creates a replacement global display.newGroup() function that contains an altered removeSelf(). This removeSelf() is incompatible with the normal functioning of display groups and removing them when cleaning up properly.

And in the specific instance of a “Corona Stub” (that deals with an expansion file), the actual instance of “widget” is destroyed by the stub before the developer’s “main.lua” is run – but the corrupting global display.newGroup() function is left in place by the stub.

In the short, short run, the kludgy steps above eliminate my immediate problem.

In the less short run, Corona could fix this “Corona Stub” problem by reverting display.newGroup() to its intended functioning at the time when the stub has finished its work and is about to set the widget instance to nil.

And by far the best, most elegant solution would be for someone at Corona to write a better memory cleanup chunk of code in “widget.lua”; a chunk of code that does not supplant normal, documented Corona functionality in certain instances – with those instances producing the errors that we developers have experienced.

Does that make sense?

Thanks again for everyone’s help!

Steve