Save to Cocos2dx UserDefault from the Cocos2dxActivity.java file? - cocos2d-x

My problem is rather simple, I can save to the "cocos2d::UserDefault" from iOS by doing this, because the .mm file can execute cpp easily:
cocos2d::UserDefault::getInstance()->setStringForKey("notification_payload", payload_string);
however on java i can't do this, so i was wondering if there is a simple cocos2dx method that can be used on java.
I know i might be able to execute cpp code from java by following this guide:
http://stnguyen.com/cocos2d-x/call-cpp-functions-from-java.html
But if possible i would like to avoid this.

After several hours of searching i found the answer.
Cocos2dx has a helper class to interact from java, the methods available from that class are listed here (this is for version 2.x but it worked in 3.x):
http://nigam.biz/cocos2dx/classorg_1_1cocos2dx_1_1lib_1_1_cocos2dx_helper.html
and an example of how they are implemented can be seen here (randomly found this on the internet, i don't think its an official documentation):
https://github.com/OiteBoys/Kunonekok/blob/master/kunonekonok/proj.android/src/org/cocos2dx/lib/Cocos2dxHelper.java
So the code i used is:
Cocos2dxHelper.setStringForKey("notification_payload","value");

Related

How could I go about loading functions from NTDLL without linking against it or any other DLLs?

I've been experimenting with loading functions from the Windows system DLLs using only the loader functions exported by NTDLL. This works as expected. For the sake of curiosity and getting an even better understanding of the process structure in NT-based systems, I've started trying to load functions from NTDLL by doing the following steps:
Load the PEB of the process from gs:[60h]
Iterate over the modules loaded into the process according to the loader to find NTDLL's base address
Parse the PE headers of NTDLL
Try to parse the export table to find LdrLoadDll, LdrGetDllHandle, and LdrGetProcedureAddress
This fails at step 4. After stepping through it in a debugger (both VS2019 and WinDbg Preview), it seems as though the offsets I've tried yield an invalid structure that leads to an access violation when my code compares the current function name to one of the ones I'm searching for. My code is being compiled and run on a 64-bit copy of Windows 10 Pro build 21364. Note that I'm using my own header that contains definitions for the structures used for this (these definitions are from winnt.h and here) because the Windows headers don't really play nice with the rest of my code. The function trying to do this is here. For the record, this is part of an attempt to implement my own libc (again, for the sake of curiosity). The code that calls the functions is here. Any help with this is tremendously appreciated.
Nevermind, turns out I had outdated verbose definitions of the structures I was using. I found better (more up-to-date) definitions at https://vergiliusproject.com.

How can I marshal JSON to/from a POJO for BlackBerry Java?

I'm writing a RIM BlackBerry client app. BlackBerry uses a simplified version of Java (no generics, no annotations, limited collections support, etc.; roughly a Java 1.3 dialect). My client will be speaking JSON to a server. We have a bunch of JAXB-generated POJOs, but they're heavily annotated, and they use various classes that aren't available on this platform (ArrayList, BigDecimal, XMLGregorianCalendar). We also have the XSD used by the JAXB-XJC compiler to generate those source files.
Being the lazy programmer that I am, I'd really rather not manually translate the existing source files to Java 1.3-compatible JSON-marshalling classes. I already tried JAXB 1.0.6 xjc. Unfortunately, it doesn't understand the XSD file well enough to emit proper classes.
Do you know of a tool that will take JAXB 2.0 XSD files and emit Java 1.3 classes? And do you know of a JSON marshalling library that works with old Java?
I think I am doomed because JSON arrived around 2006, and Java 5 was released in late 2004, meaning that people probably wouldn't be writing JSON-parsing code for old versions of Java.
However, it seems that there must be good JSON libraries for J2ME, which is why I'm holding out hope.
For the first part good luck but I really don't think you're going to find a better solution than to modify the code yourself. However, there is a good J2ME JSON library you can find a link to the mirror here.
I ended up using apt (annotation processing tool) to run over the 1.5 sources and emit new 1.3-friendly source. Actually turned out to be a pretty nice solution!
I still haven't figured out an elegant way to do the actual JSON marshalling, but the apt tool can probably help write the rote code that interfaces with a JSON library like the one Jonathan pointed out.

Understanding run time code interpretation and execution

I'm creating a game in XNA and was thinking of creating my own scripting language (extremely simple mind you). I know there's better ways to go about this (and that I'm reinventing the wheel), but I want the learning experience more than to be productive and fast.
When confronted with code at run time, from what I understand, the usual approach is to parse into a machine code or byte code or something else that is actually executable and then execute that, right? But, for instance, when Chrome first came out they said their JavaScript engine was fast because it compiles the JavaScript into machine code. This implies other engines weren't compiling into machine code.
I'd prefer not compiling to a lower language, so are there any known modern techniques for parsing and executing code without compiling to low level? Perhaps something like parsing the code into some sort of tree, branching through the tree, and comparing each symbol and calling some function that handles that symbol? (Wild guessing and stabbing in the dark)
I personally wouldn't roll your own parser ( turning the input into tokens ) or lexer ( checking the input tokens for your language grammar ). Take a look at ANTLR for parsing/lexing - it's a great framework and has full source code if you want to dig into the guts of it.
For executing code that you've parsed, I'd look at running a simple virtual machine or even better look at llvm which is an open-source(ish) attempt to standardise the virtual machine byte code format and provide nice features like JITing ( turning your script compiled byte code into assembly ).
I wouldn't discourage you from the more advanced options that you machine such as native machine code execution but bear in mind that this is a very specialist area and gets real complex, real fast!
Earlz pointed out that my reply might seem to imply 'don't bother doing this yourself. Re-reading my post it does sound a bit that way. The reason I mentioned ANTLR and LLVM is they both have heaps of source code and tutorials so I feel this is a good reference source. Take it as a base and play
You can try this framework for building languages (it works well with XNA):
http://www.meta-alternative.net/mbase.html
There are some tutorials:
http://www.meta-alternative.net/calc.pdf
http://www.meta-alternative.net/pfront.pdf
Python is great as a scripting language. I would recommend you make a C# binding for its C API and use that. Embedding Python is easy. Your application can define functions, types/classes and variables inside modules which the Python interpreter can access. The application can also call functions in Python scripts and get a result back. These two features combined gives you a two-way communication scheme.
Basically, you get the Python syntax and semantics for free. What you would need to implement is the API your application exposes to Python. An example could be access to game logic functions and render functions. Python scripts would then define functions which calls these, and the host application would invoke the Python functions (with parameters) to get work done.
EDIT: Seems like IronPython can save you even more work. It's a C# implementation of CPython, and has its own embedding API: http://www.ironpython.net/

Multithreaded Html to Pdf conversion via Single-Threaded Qt

I am using Qt webkit Jambi API's to convert HTML to PDF.
My target is to create a jar for above conversion so that it could be used in a multithreading environment, but since QWebPage and QWebframe (QT webkit) are GUI classes, therefore the jar classes cannot be initialized from child threads.
So i am stuck as i don't know how to work around this problem.
Also i am a novice in QT , can anyone provide good reference about QT application's lifecycle, event loops and related stuff.
thanks in advance.
Ashish
Well, actually, I just use Firefox to do "Print to File" and select PDF as the filetype. But that's for manual work - although I suppose you could script Firefox.
I think in a Linux environment - and I'm assuming Linux/Unix because you mentioned Qt - that you could probably string together a couple of nx command-line apps. Possibly enscript has something that would help. If not, I'm pretty sure I've seen other solutions, just can't recall them off the top of my head. If you can transform the HTML to Postscript, getting a PDF out of it is trivial.
If HTML4 and (parts of) CSS1 suffice for your needs, then you can use QTextDocument together with QPrinter in a separate thread.
"Programming with Qt, Second Edition", O'Reilly, is excellent but only covers Qt3. A lot of the basic still apply to Qt 4.5.
"C++ GUI Programming with Qt 4 (2nd Edition)", ISBN 0132354160, is not bad.
The Qt docs contain examples and tutorials too.
It's not clear to me why you can't initialize a jar with GUI classes from within child threads. Is this an artificial limitation set on Jambi by the trolls?
I took note of this example on Rendering a webpage with Qt and Webkit to a QPixmap, which theoretically doesn't need to show anything on the screen. QWebPage and QWebFrame both inherit QObject. Using the sample code from the above link, it should be possible to get a webpage's rendered contents without a GUI.
My primary task was to get html to pdf conversion for printing the pdf.
I tried to get QT jambi (QT webkit C++ api also) to work in multithreaded environment but could not.
My final solution was as follows:
I used ‘wkhtmltopdf’ native binary from here,
wrote a java wrapper capturing the standard input and output streams.
Initialized the ‘wkhtmltopdf’ binary for each java thread that required the html to pdf conversion.
Also i never worked on erjiang's advice because by then I had moved out of the task and never got time to work on his advice.

Handling properties in Scala

I'd like to know what is the most efficient way of handling properties in Scala. I'm tired of having gazillion property files, xml files and other type of configuration files in Java and wonder if there's "best practice" to handle those someway more efficient in Scala?
Why would you have a gazillion property files?
I'm still using the Apache commons Digester, which works perfectly well in Scala. It's basically a very easy way of making a user-defined XML document map to method calls on a user-defined configurator class. I find it extremely useful when I want to parse some configuration data (as opposed to application properties).
For application properties, you might either use a dependency injection framework (like Spring) or just plain old property files. I'd also be interested to see if Scala offers anything on top of this, though.
EDIT: Typesafe config gives you a simple and powerful solution for configuration - https://github.com/typesafehub/config
ORIGINAL (possibly not very useful):
Quoting from "Programming in Scala":
"In Scala, you can configure via Scala code itself."
Scala's runtime linking allows for classes to be swapped at runtime and the general philosophy of these languages tends to favour convention over configuration. If you don't want to deal with gazillion property files, just don't have them.
Check out Configgy which looks like a neat little library. It includes nesting and change-notification. It also include a logging library.
Unfortunately, it didn't compile for me on the Mac instances I tried. Let us know if you have better luck and what you think...
Update: solved Mac compilation problems. See this post.