Error building Shoutem preview build after modifying extension - shoutem

I've working on modification of the 'shoutem.notification-center' extension using as a guide this tutorial and I'm having some issues.
At first I tried to use the Extend the extension approach, but like I've posted on this issue, didn't quite work.
So I've tried the Directly modify approach, which works fine on my local phone, but once I use the command shoutem push to send my modifications to the server, the instance on Appetize never stops the 'Building your application' message.
The major problem is that there's no error code or feedback.
That was not the first time that happened, I had the same issue modifying other extensions. Any idea why this is happening?

The issue is likely one of two things.
New native dependencies were added that the Builder preview cannot process due to it's predefined binary.
Your directly modified extension works locally, but not on the Builder because locally it's path is still AppName/extensions/shoutem.extName, but on the Builder it's AppName/extensions/yourDevName.extName, so it fails.
The first one can be resolved by either using a non-native solution as a replacement for the native dependency you were using, or to simply use a local emulator for previewing purposes.
The second can be resolved by making sure all extensions that reference the one you directly modified are edited to now reference your new directly modified extension instead of shoutem.extName.
If you could shoot me your app ID in a comment I can let you know which one it is and what the best steps to fix it would be.

Related

How can I build an Agroal connection at runtime with native support

I'm trying to build a dynamic database connection via Agroal inside a native image. It's not possible to use the default config params because I don't know the connection params at compile time. Is that even possible right now?
The connection is built like this at runtime:
AgroalDataSource.from(
AgroalDataSourceConfigurationSupplier()
...)
I'm currently seeing this error:
Class io.agroal.pool.ConnectionHandler[] is instantiated reflectively but was never registered.
Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection
The installed features include: [agroal, cdi, jdbc-h2, jdbc-mysql, jdbc-postgresql, kotlin, narayana-jta, resteasy, resteasy-jackson]
It runs fine on the JVM, but not using Graal. It feels like it should be possible and I'm probably missing something here. I was hoping adding agraol extension would be sufficient but obviously isn't picked up correctly.
The current situation is that we configure Agroal for native images only if you have a datasource defined using Quarkus configuration.
Thus for your use case, for now, you will have to do what we do automatically manually. What we do being registering some classes for reflection and including some resources in the native image.
See https://github.com/quarkusio/quarkus/blob/master/extensions/agroal/deployment/src/main/java/io/quarkus/agroal/deployment/AgroalProcessor.java#L91 and https://quarkus.io/guides/writing-native-applications-tips#using-a-configuration-file.
Obviously, that's not ideal. Could you open an issue on our GitHub so that we can discuss it internally and see if we should/can improve the situation?
In the end, you would still need some reflection registration for your JDBC driver though.

Express-browserify and Watson Visual Recognition - TypeError: fs.existsSync is not a function

I'm trying to get the Watson Visual Recognition to run client side by using express-browserify with reference to the node-sdk for watson-developer-cloud. The VisualRecognitionV3 makes use of the fs package hence I get the fs.existsSync error when I'm trying to call it from the client-side as the browser doesn't know which filesystem to use. My question is how do I go about creating a so called 'abstraction layer' as I am restricted to using the express-browserify package for cross origin calls.
This thread is pretty helpful in shedding some light but I'm not sure where to start regarding the 'abstraction layer' or if there are any other solutions. Also, would something like socket.io work for this? I've linked a clone of the directory here as it seems less clunky than pasting the multiple portions below.
The repository can be cloned and just requires a personal iam_apikey with relevant launch configuration. Appreciate any pointers. Thanks!
I didn't manage to sort this out with express-browserify due to the require(fs) from browser issue but I was able to get it running using the express-ws package

cometd hello world example with dojo

I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html

IAT/EAT hooking "gethostbyname"

I wrote this code to hook API functions by changing the address in the IAT and EAT: http://pastebin.com/7d9N1J2c
This works just fine when I want to hook "recv" or "connect". However for some unknown reason when trying to hook "gethostbyname", my hook function is never called.
I tried to find "gethostbyname" in a debugger by taking the base address of the wsock32.dll module + 0x375e, which is what the ordinal 52 of my wsock32.dll is showing as offset. But that just makes me end up in some random asm code, not at the beginning of a function.
The same method however works fine for trying to find the "recv" entry point.
Does anyone see what I might be doing wrong?
I recommend this tool:
http://www.moduleanalyzer.com/
They do exactly the same and show the url that was connected with that API.
The problem is that there are more than one API to translate an url to an address. The application you are hooking may be using another version of the API that you're not intercepting.
Run some disassembler like IDA and attach to your process after you hook this functions, ida get apply changes on attaching and play process and check what is wrong.
In other way you have many libraries to do hooks with trampolines like Microsoft Detours, NCodeHook etc.

Problems after Qooxdoo migration to 1.3-pre

I checked out the latest SVN trunk of qooxdoo and now i have the following problems:
Some events seems that they are not comming through
Virtual Lists are not filled anymore (the _createWidget() method of the extension from qx.ui.virtual.cell.AbstractWidget is not called)
My original version was QX 1.0.1-pre and the problems appeared also when i tried to migrate to 1.2
Just to get the obvious stuff out of the way, did you follow the steps of the migration guide and make any necessary changes outlined in migration.log?
Aside from that, the virtual widgets are still experimental and no migration path is provided, meaning you'll have to go over your code and check if the parts of the ui.virtual API you're using have changed since 1.0.1.
For the missing events, please provide some more information: What events are you listening for?
The problem with the event seems to be a bug in Qooxdoo