Closed kaievns closed 10 years ago
Hm, this isn't an ideal fix.
In this patch, two (redundant) blocks will get added to config.setup_blocks
- once with config.setup_blocks << bw_config
(which itself will invoke the original &block
) and then once again with the setup_without_bubblewrap
.
I think a better solution is like:
bw_config = proc do |app|
...
block.call(app) if block
end
setup_without_bubblewrap *args, &bw_config
right?
em... i don't think you will call the block twice, you just tap into the original method, call your setup_blocks <<
thing to add your block and then just let the rest of the logic to kick in. i don't know the details of how the setup implemented on the rubymotion side, but it should work like a before filter.
In any case, you always can just put a puts "hello"
in your block and check how many times it was called.
but doesn't really matter, if you can make it better that's great :) I just need bubble wrap to call the original setup so that everything after its initialization could be triggered.
Done!
awesome, thanks! /cc @joerichsen
hey guys, i think i've got a quick fix for the bubble wrap's initialization.
basically the problem is that i've got another rubymotion extension, which also taps into the
setup
function and as bubble-wrap never calls the original setup after it initializes itself, the other extensions don't get configured.