I cannot find a replacement plugin for a videoplayer plugin I've been using for the past year.
Question:
To play local storage and/or online videos, what has been your way of implementing? (And have you tried using the PhoneGap version cli-6.5.0?) iFrame using the tag does not work for me. I have to assume it's because it's an app.
The dawsonloudon player isn't on NPM, so I'm a little stuck as to finding a suitable replacement. And example code would be appreciated, as it feels like it is lacking
What I did to resolve this:
Since PhoneGap moved its plugin repository to NPM, the DawsonLouden plugin hasn't made it over to NPM. So the build process essentially stopped because it couldn't find it.
What I did was bring the Dawson Louden plugin into the application, instead of making reference to the plugin via the config.xml. This allows the plugin to be used internally versus grabbing it externally from the plugin repository.
Not being too familiar with plugins, I found an article which stepped me through how to download the Dawson Louden plugin code (via GitHub) and then use that plugin within my solution:
https://github.com/krisrandall/streaming-media-plugin-demo
Just make reference to the VideoPlayer GitHub project instead of the streaming media plugin project:
https://github.com/dawsonloudon/VideoPlayer
(also don't worry about the last 5 steps of the example...there is no demo project to download from GitHub). You will have the plugin source code at this point anyways.
You should copy the source code for the plugin into the "plugins" folder within your PhoneGap project.
Then I instead of saying this in the config.xml:
<gap:plugin name="com.dawsonloudon.videoplayer" version="1.0.0" />
Make reference to the local plugin in the config.xml using the feature tag:
<feature name="VideoPlayer" >
<param name="android-package" value="com.dawsonloudon.videoplayer"/>
</feature>
That was all it took. One other note I discovered is that the VideoPlayer plugin didn't work on my Galaxy S5 but did on S6.
Related
I am developing a flutter app. I want to let the user select some sounds.
When selected, I want the app to play its mp3 file in the assets folder. I tried with AudioPlayer plugin but I haven't achieved to play local files...
I have been searching for awhile and I haven't found any good answer to my questions, furthermore, the posts were created 2 or 1 year ago, so maybe we need an updated answer.
I have found this post: How to play local mp3 file with audioplayer plugin in Flutter
but my project doesn't find this package import 'package:path_provider/path_provider.dart'; [THIS PART IS SOLVED]
And when flutter will have a built-in audio manager? Are they/you working on it?
Thanks in advance!
EDIT: Also, I would like to play different mp3 at the same time, with different volume. Is it possible?
That import directive you see tells Dart that a particular source file uses classes from a different source file. The package: prefix tells Dart that the imported file is part of an external dependency. So you need to tell your project that you have a dependency. This is done in the pubspec.yaml file.
Dart's pub dependency manager takes care of finding the right version of the dependency for you, and downloading it. Add the path_provider package to your pubspec.yaml file. Each package's installing tab shows how to do this.
You can find a whole library of useful flutter (and Dart) packages here.
path_provider is a special type of package called a plugin which contains some Dart code together with iOS and Android specific code. This is necessary because playing audio or creating local files is platform specific.
We have a project that uses Groovy extensively and we use Maven to build our artifacts. (IntelliJ as our IDE)
We wanted to incorporate some automated code-style checking, and thought we might use codecarc-maven-plugin. However, since that was from Codehaus, which gone now, is the plugin actively supported somewhere else?
Any other good options to run a Groovy style checker automatically during a Maven build?
That's a good catch. I'll add a pull request to update the website link. You can find the new plugin information on GitHub: https://github.com/gleclaire/codenarc-maven-plugin
I've been trying to use the Atto plugin template (https://github.com/justinhunt/moodle-atto_newtemplate) to try and create my own Atto plugin. I've made the changes outlined in the README, and got shifter to run via npm. It appears to generate the build folder that matches the other plugins.
I'm able to see the plugin in configuration, and it's showing up in the Atto Toolbar Settings, but, when I pop open a text editor, I don't get an icon, and the console logs moodle-editor_atto-editor: Plugin 'testplugin' could not be found - skipping initialisation
I've found a few references in the docs that shifter is no longer used, and grunt is the new way to go, but I can't find any actual docs on this, and no gruntfile seems to exist anywhere.
Has anyone come across this before? What am I missing?
You will need to run shifter on your YUI code for it to work - the usual way of doing that, for Moodle 2.9 and above is to use grunt - see https://docs.moodle.org/dev/Grunt for more details.
Not sure if this was ever resolved. The template is really helpful and it also comes with lib, db, and version PHP scripts. The string that you use as the plugin name has to be consistent throughout these scripts, as well as in your JS file. By default, it is set to atto_NEWTEMPLATE. Did you perhaps change this string to atto_testplugin in one place but not in all the others?
Environment:
VS2015 with cordova tools.
Win8.1.
Practise project is WinJS ToDo sample app from web.
Maybe this is just SUE (Stupid User Error) but when I'm adding barcodereader plugin (config editor ui -> using git address) all goes fine and new plugin comes to plugin folder in project tree.
Problem is that I can't seem to find way to use that new plugin at all. I can add <script src=""> tag for plugin's .js-file and it compiles, but when I try actually do something with plugin from code, it isn't recognized at all.
My new love with VS is suffering now...
The problem is that you need a definition for the plugin in order to consume it in a TypeScript project. The usual place to find definitions (commonly defined in d.ts files) is on www.definitelytyped.org. However in this case, the plugin author probably has not defined a TypeScript definition so you won't find it there.
That means you'll need to write one yourself. Think of a d.ts file like a header file in c++. It defines the interfaces and contracts in the library you're consuming. It's really not too hard to write these once you've learned how to do it. Here's one link that might be useful:
https://typescript.codeplex.com/wikipage?title=Writing%20Definition%20%28.d.ts%29%20Files
Hope that helps.
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.