Changing const socket to window.socket solved the issue. Thanks a lot!
Regarding the javascript logging, it is partially working on the device now 
(so part of the problem seems to have been linked to the const socket 
instead of window.socket because changing that changed the javascript 
logging from zero to some). However, it seems that if the frequency of 
logging events is too high, only the last logging event is passed to the 
CN1 logger.  For example, in my onload browsercomponent event, I have two 
javascript log calls: internalBrowser.execute("logger.log(\"SocketIO bridge 
init\")"); and internalBrowser.execute("logger.log(\"SocketIO bridge 
started\")"); . But only the latest is thrown by CN1 in my adb logcat. 
Now, if I add the new js command: logger.log(\"emit "+eventName+"\"); 
before my js socket.emit() function , this is this emit hello log only that 
is thrown by CN1 in the adb logcat (because in my MyApplication class I 
have a socket.emit("hello"...) call that comes just after the socket 
initialisation (that will call the browsercomponent onload event)), the 
"SocketIO 
bridge started" log is not shown anymore. If I click on my emit event 
button, the "emit click" log is displayed though, meaning that the js 
logger is still functionnal (it is only if the frequency of log events is 
too high that there is an issue with only the latest log event beeing kept)


On Monday, April 9, 2018 at 1:31:15 PM UTC+2, Steve Hannah wrote:
>
> Just looking at your code.  Not sure why logging isn't working for you, 
> but this code which instantiates your socket, may be problematic:
>
> internalBrowser.execute("const socket = io('"+server_url+"')");
>
> There is no guarantee that the Javascript expression executed in 
> BrowserComponent.execute() is run in the global context.  It may be run 
> inside the context of an anonymous function, so your "socket" variable 
> won't be accessible from anywhere else. 
>
> I would change it to
>
> internalBrowser.execute("window.socket = io('"+server_url+"')");
>
> Steve
>
>
> On Fri, Apr 6, 2018 at 9:29 PM, Shai Almog <shai....@gmail.com 
> <javascript:>> wrote:
>
>> Steve is better at these things so I'll leave it to him. I do agree that 
>> debugging JS <-> Java is a pain in the neck. We made several attempts at 
>> simplifying it but mostly focusing around debugging on the simulator.
>>
>> Is it possible that this is failing due to same origin? 
>> I doubt that's the case if you opened the connection already but maybe 
>> injected code impacts this?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "CodenameOne Discussions" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to codenameone-discussions+unsubscr...@googlegroups.com 
>> <javascript:>.
>> Visit this group at 
>> https://groups.google.com/group/codenameone-discussions.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/codenameone-discussions/b06c16a5-342f-4ee8-8751-1a97a66c56ff%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/codenameone-discussions/b06c16a5-342f-4ee8-8751-1a97a66c56ff%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Steve Hannah
> Software Developer
> Codename One
> http://www.codenameone.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to codenameone-discussions+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/codenameone-discussions/6398df82-1bd8-4d1d-aedf-ea3f76642202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to