I am attempting to use vstirbu's Instagram plugin (https://github.com/vstirbu/InstagramPlugin) for Cordova with my app. My app is using the Appgyver Steroids platform. after adding the plugin to my build the app builds fine and I am able to install it on the phone fine. there is only one page where the Instagram functionality is needed and when that page is opened I get the "undefined is not an object (evaluating 'window.plugins.Instagram.share')" error. are there other Instagram plugins available that I might try out or are there steps to initialize the plug in that I might be missing.
I am assuming you built a debug scanner version with the plugin. I had this issue with a BLE plugin. I was trying to reference the plugin as window.plugins.nameOfPluginObject and it didn't exist. It didn't exist that way, but it did exist as nameOfPluginObject. I could make calls to it that way. nameOfPluginObject.someMethod();.
See if you can debug the app in Safari / Chrome and use the console to type typeof window.plugins.Instagram and then typeof Instagram. I am guessing typeof Instagram returns object and the other returns undefined.
Is Cordova loaded in that page? Are you making the calls after deviceready (although if it's the console, I suppose you're alright). The plugin JavaScripts are loaded when cordova.js loads. Also, you can extract the IPA file (just rename it to .zip) and see if the plugin files are correctly in the package (although if it builds correctly, it should be fine).
Related
Developer A created a Chrome extension in a Mac environment. Built, tested, published and working for all end consumers.
Developer B cloned the repo used to create the extension, built it in a Windows environment and the Chrome extension fails when posting data to an external API. The same is true when building the extension in a WSL2/Ubuntu environment.
Basic Troubleshooting
Verified developers are using identitical npm and node versions
Verified the zipped extension, built in a Mac environment, works when tested locally in a Windows environment
Odd Behavior of Extension Built in Windows
A popup created by the extension contains an error not present in the 'good' version.
popup.js:2 Uncaught SyntaxError: Invalid or unexpected token
And the offending line:
let payload = {}; // Object to hold data payload
Extension retrieves configuration data from a secure external API
Extension does not post data to a secure external API and does not report any API connectivity errors
Have any of you encountered this? If so, penny for your thoughts.
Update: VSC claimed the file was in UTF8 and, to be thorough, I re-saved the file as straight UTF8. The issue persists. (Thank you for the suggestion, wOxxOm)
We brought another developer into the mix and found the problem.
Turns out npm build isn't sufficient. Our process required npm run start in order to create a working deployable extension.
I will expand my answer if I invest the time into determining why this is.
Thanks again.
All, I am trying to using third party NodeJS SDK in Titanium Studio. However, I consistently encounter dependency issues, such as util.js, utils.js, ms.js, events.js etc. I tried to add the missing module manually, but it looks like it will become un-tractable as there are so many dependencies.
My questions are :
1. Is that possible to use NodeJS based SDK in Titanium Studio .
2. If so, what is the right approach to include the dependencies.
Thanks a lot!
Titanium can't get Coffee scripts to work natively (assuming you want to deploy the TitaniumWrapper.coffee). A possible solution you may want to try is hooking a plugin http://billdawson.com/titanium_coffee_script/ in order to pre-compile Coffee scripts.
You can also try to embed everything using a Tiwebview that wraps HTML to load mojio-js.js but you would still need to observe events mojio client (like replacing keys, login an user and create a few model instances).
Hope you find the info useful and can serve for further research.
I was developing a Spotify apps and all of the sudden Spotify restarted and updated.
Yey, great.. I got version 0.8.3.222.g317ab79d... however typing spotify:app:the_app_name doesnt work anymore. I get metadataFailed, sorry I could not find this app.
Anyone knows where I can find a downgrade?
Spotify 0.8.3 changed the app lookup slightly. The URI for getting at apps in development is now spotify:app:application-identifier-in-manifest.
This changes the behaviour in old versions, which used the application's directory name to load applications. It's also worth noting that your application must have a valid identifier and version in its manifest.json file. Remember to restart the client when changing your manifest so it notices the changes!
The keys you need to set are BundleIdentifier (which will be used to find the app) and BundleVersion. Documentation on the keys can be found here.
When you check spotify.com you can see there is a be right back message this indicated either server or application failures just hold for a few minutes/hours and return to developing after message is gone.
I just created my first Xpage application, and I now wanted to port it to a simple mobile application, using the mobile controls in the Xpages Extension Library. Notes/Domino 8.5.3 Upgrade Pack 1 are installed on both client/Designer and server.
The Xpage application works fine in both client and browser.
I created a new Xpage, called "mobileMainPage", and simply add a Single Page Application control to it, save the file and attempt to open it through a browser (Safari first, then IE 9 just to test). In both cases I get the following error message:
Unexpected runtime error
The runtime has encountered an unexpected error.
Exception
Cannot find the library com.ibm.xsp.extlib.library, required by the application /Contacts.nsf.
I am opening the database on the server (entering the URL of the .xsp file in the browser). I am not using the preview browser feature of Domino Designer, but is calling the page like a user would.
How do I fix this? I even tried to install Upgrade Pack 1 once more. Still getting the same error message.
It really sounds like the library is not installed on the server.
type tell http osgi ss com.ibm.xsp.extlib on the server console and verify that the plugin is installed, that command should return a list of the extlib plugins and fragments and if they have been correctly resolved or not.
in your Domino console type:
tell http xsp diag com.ibm.xsp.extlib
also try:
tell http xsp diag com.ibm.xsp.extlib.mobile
This will tell you whether or not the plugin is resolved. If the plugin is not found it means the plugin is not installed the to correct location (domino/data/domino/workspace/applications/eclipse/plugins).. If a plugin that extlib depends on is not resolved it will show in the console.
Chapter 3 of the XPages Portable Command Guide goes into this in great detail :-)
Let me know the results of the above command
Make sure to tell your app that it should use the extension library. Open the Application Properties and go to the Advanced tab. Here, verify that the 'com.ibm.xsp.extlib.library' is checked.
I just encountered a similar issue when firing up a new server in a virtual machine (was testing out an issue with different server version). I included notes.ini setting OSGI_HTTP_DYNAMIC_BUNDLES and pointed it to a updatesite database I hastily replicated over from another server.
I am not certain for sure, but once I added my new server to the updatesite and restarted http, it took.
Possibly this is related to Using a plugin generated with Firebreath in a Firefox Extension?; however, my question is possibly more specific, so here goes...
I'm working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. The resulting plugin on this platform is an "npXXX.so" file, which I got symlinked in ~/.mozilla/plugins. Then, I have coded an extension that uses this plugin - and apart from the symlink, nothing else seems required - all seems to work just smashing :)
So, knowing that "firefox supports installing your plugin via XPI. This is not recommended by the FireBreath team", now I'd still like to package the extension AND the plugin into an XPI file. So, I'm reading a bit on Structure of an installable bundle - MDN, and I can see these two possibilities:
/components/* XPCOM components (*.js, *.dll), and interface files from *.xpt (>=1.7)
...
/plugins/* NPAPI Plugins (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3
Now, it says: "The older XPCOM- and LiveConnect-based APIs for plugins should not be used.", so I guess the "/components" directory should not be used (even if it is given as an example in the above page). And I can not find this stated explicitly anywhere, but I'm guessing FireBreath builds NPAPI plugins - so presumably "/plugins" is the way to go. (There is also mention of "/platform", but it clearly says it's been deprecated for Firefox > 3.6).
Ok, so far so good... So I try to copy the plugin file to plugins/linux inside the extension directory:
cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/
... and then insert the following in chrome.manifest:
binary-component plugins/linux/npXXX.so ABI=Linux_x86-gcc4
... then I zip the whole extension directory (the plugin included) as an .xpi, try to install it on a different computer. There, the .xpi succesfully installs, the .so file is indeed unpacked under the profile's extensions/XXX/plugins/linux/ directory - and every cross-platform (javascript) code of the extension works fine; except that the plugin cannot be found.
Now, of course, the user could themselves symlink the extension .so to ~/.mozilla/plugins/; however, I would like to spare the user of that :)
How would I go about this kind of packaging thing - is there a recommended way to do it?
Many thanks in advance for any answers,
Cheers!
Edit: found Shipping a plugin as a Toolkit bundle - MDN which claims only install.rdf , and a plugins/obj.so is needed; then I found Running Quake Live in Firefox 4, 5 and 6 on Linux [fixes inside], referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.. If I install that, I get both a Quake extension and a Quake plugin (and that even with Error Console complaining "Could not read chrome manifest file '/path/to/extensions/quakeliveplugin#idsoftware.com/chrome.manifest'.") .... but if I try the same with my FireBreath plugin (e.g. just an install.rdf and plugin in /plugins), only extension gets shown - no plugin (and no reasonable error messages).. Could this be a problem with FireBreath?
Well, I'll post this as an answer - I have just confirmed that FireBreath plugin does in fact work being packaged in the simple "toolkit bundle" way as an .xpi extension.
Basically, I just cleared up my development PC's Firefox profile, and tried to install the .xpi carrying the plugin there - and on the dev PC, the plugin shows in about:plugins and runs just fine (even if it's just unpacked in profile/extensions/EXT/plugins/obj.so, and not in ~/.mozilla/plugins)... In fact, I packaged both the extension and the plugin in separate .xpi's, which were then merged in a single one as recommended in Multiple Item Package - MDN - and that works fine too (upon loading the merged xpi, one gets prompted about installing two extensions - one for the plugin carrying one, and the other for the "plain" extension)...
So the problem was on the other test computer only - and the problem seems to be that I'm using Gnome libraries in the plugin, and while my dev PC is Ubuntu 11.04 - I think this test PC was Ubuntu 10.04 ... So, quite likely, the problem is incompatible Gnome libraries in the plugin build; unfortunately, I don't get many errors back from firefox, even if I do:
NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile
(... as recommended in Logging Multi-Process Plugins - MDN - however, the /tmp/plugins.log remains empty). The only thing Firefox on the problem machine spits is something like this to stdout:
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'
... and I cannot tell if this has something to do with the plugin or not... But I guess at least the packaging part got confirmed as working now :) Cheers!
EDIT: After a while, the Firefox on the test PC did spit out the following (although I would have expected this message to pop up instantly):
LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]
... which finally confirms it was a build problem I have had.