remove - cordova run browser

¿Debería declararse un complemento de phonegap en el archivo config.xml?

Question

Soy un novato en el desarrollo del teléfono, así que tengo un par de preguntas:

1) Estoy usando el complemento del acelerómetro. Leí en el manual que necesito declarar el complemento en el archivo config.xml para usarlo. Sin embargo, noté que incluso si eliminé la declaración de config.xml

<feature name="Accelerometer">
    <param name="android-package" value="org.apache.cordova.AccelListener" />
</feature>

el acelerómetro todavía funciona.

Así que me gustaría preguntarle si en la versión de phonegap 3.0.0, el uso de config.xml es obsoleto. Si ese es el caso, ¿dónde está la vinculación?

2) Uso la plataforma de Android para construir la aplicación. En la estructura del proyecto, hay tres archivos config.xml con contenido diferente:

• a) En los activos / www / phonegap-app-hello-world-3.0.0 / www / config.xml
• b) En los activos / www / phonegap-app-hello-world-3.0.0 / config.xml
• c) En el archivo res / xml / config.xml

¿Cuál es el uso de cada uno de ellos? ¿Dónde supongo que debo declarar mi complemento? Lo hice en el archivo res / xml / config / xml

Gracias

Answer 1

Config.xml es utilizado principalmente por la compilación del teléfono.

Si está utilizando phonegap 3, debe administrar sus complementos utilizando la CLI:

$ phonegap local plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-network-information.git

El único config.xml que debe editar es /www/config.xml, los otros se generan automáticamente a partir de ese cuando crea su proyecto usando:

$ phonegap build ios

Answer 2

Desde Cordova 5.0, sí .

<?xml version=''1.0'' encoding=''utf-8''?>
    ...
    <plugin name="cordova-plugin-console" spec="^1.0.0" />
    ...
</ xml>

Complementos de ahorro masivo en un proyecto existente:

$ cordova plugin save

En una instalación nueva (o después de una limpieza), puede agregar todos los complementos con:

$ cordova prepare

Agregar / actualizar / eliminar también se puede hacer a través de cli:

$ cordova plugin add <plugin[@<version>] | directory | git_url> --save
$ cordova plugin update <plugin[@<version>] | directory | git_url> --save
$ cordova plugin remove <plugin> --save

No hay una actualización masiva por el momento. Puede eliminar el directorio de plugins luego ejecutar un $cordova prepare .

Fuentes:

• http://cordova.apache.org/docs/en/5.1.1/platform_plugin_versioning_ref_index.md.html
• https://cordova.apache.org/news/2015/04/21/tools-release.html

Answer 3

Desde cordova 3.5 , podemos persistir los complementos en el archivo config.xml

<feature name="Network Information">
    <param name="id" value="org.apache.cordova.network-information" />
    <param name="version" value="0.2.10" />
</feature>

El siguiente comando recuperará los complementos definidos en config.xml

cordova restore plugins --experimental

El siguiente comando escribirá los complementos instalados actualmente en config.xml (3.5):

cordova save plugins --experimental

En 5.x y posterior:

cordova plugin save

Fuente: http://cordova.apache.org/news/2014/07/10/tools-release.html

Answer 4

Es posible que desee comprobar esto para el complemento accelermator : Phonegap Acceleramator plugin .

También puedes buscar allí cualquier complemento que necesites

Answer 5

Estoy bastante seguro de que la razón por la que aún puede usar el complemento es porque editó el config.xml incorrecto o no ejecutó las herramientas de línea de comandos de cordova para propagar los cambios al archivo config.xml correcto que realmente usa el aplicación

Hay varios archivos config.xml en diferentes lugares en un proyecto de Cordova 3.x. Trataré de darle una descripción general de las diferentes ubicaciones de los archivos y cómo debe interactuar con ellos. Tenga en cuenta que esto es lo que sucede cuando utiliza la CLI ( interfaz de línea de comando ): he generado esta estructura de directorio escribiendo:

cordova create {MyApp}
cordova platform add android ios
cordova plugin add org.apache.cordova.network-information

O antes de Cordova 3.1, reemplace la última línea con:

cordova plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-network-information.git

Si utiliza solo los scripts de shell de nivel de plataforma para compilar la aplicación (la "antigua" forma en que lo hicimos en Cordova 2.X), generalmente puede usar el mismo flujo de trabajo, pero necesitará usar Plugman para administrar complementos . (Estamos en el proceso de documentar estos dos "flujos de trabajo" diferentes).

Primero, cuando creas una aplicación con cordova create MyApp , creará una estructura de proyecto vacía como esta:

/myApp/
        /www/           # This is where your "cross-platform'' files go.
                        # The build tools copy these files over to the correct
                        # asset folder for each platform, like /assets/www/ for
                        # android or just /www/ for iOs. This is where you should
                        # be doing most/all of your work and is what should
                        # probably be version controlled.
        /platforms/
            /android/   # These will only appear after `cordova platform add`
            /ios/       # You should generally not touch these file as they are
                        # recreated quite often, although changes will persist.
        /plugins/
            /android/   # These will only appear after `cordova plugin add`. They
                        # pretty much just contain the native and web plugin code
                        # for all platforms that a plugin supports.
            /ios/
        /merges/        # This is where you can place platform-specific code that
                        # you write that will get merged in with your cross
                        # platform source, see the "customize each platform"
                        # section of: http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html

Debe realizar todos los cambios en los archivos en /www/ , que es el código fuente "multiplataforma". Lo que está en esta carpeta generalmente se copiará y se propagará a la carpeta www nivel de plataforma cuando use las herramientas de línea de comando (ya sea its /assets/www para Android o simplemente /www/ para iOS). De esta manera, solo necesita una única carpeta de origen para su aplicación: esta es la carpeta que debe tener bajo control de versión. Cualquier cambio en la configuración de la aplicación que desee se debe realizar en el archivo config.xml ubicado en esta ubicación; más tarde, cuando utilice las herramientas, este archivo config.xml se copiará (y algunas veces se modificará con información de configuración específica de la plataforma) en el lugar apropiado para cada aplicación, como /platforms/android/res/xml/config.xml (para Android ) o /platforms/ios/AppName/config.xml (para iOS).

Supongamos que desea agregar el complemento de aceleración al escribir el cordova plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-network-information.git . Si tuviera que ejecutar un diff después de este comando, verá que se han cambiado o agregado los siguientes archivos:

plugins / org.apache.cordova.network-information / - Esta nueva carpeta contiene toda la metainformación y el código del complemento, incluidos el código web y nativo, para cada plataforma compatible.

plugins / android.json y plugins / ios.json - Ambos archivos han sido editados ahora para contener una referencia al complemento de información de red. Aquí es donde verá el bit config-munge de JSON. A medida que agrega más complementos, este archivo crecerá continuamente para hacer referencia a todos ellos. Este archivo le dice a las herramientas de línea de comandos qué código necesita reemplazar y en qué archivos. Por ejemplo, después de agregar el complemento cordova-plugin-network-information, verá esto en /plugins/android.json :

{
        "prepare_queue": {
            "installed": [],
            "uninstalled": []
        },
        "config_munge": {
            "res/xml/config.xml": {
                "/*": {
                    "<feature name=/"NetworkStatus/"><param name=/"android-package/" value=/"org.apache.cordova.networkinformation.NetworkManager/" /></feature>": 1
                }
            },
            "AndroidManifest.xml": {
                "/*": {
                    "<uses-permission android:name=/"android.permission.ACCESS_NETWORK_STATE/" />": 1
                }
            }
        },
        "installed_plugins": {
            "org.apache.cordova.network-information": {
                "PACKAGE_NAME": "io.cordova.hellocordova"
            }
        },
        "dependent_plugins": {}
    }

Esto le dice a los scripts que escriban el nombre de la función en res/xml/config.xml (nuevamente, para iOS, esto será diferente, ya que el archivo de configuración del nivel de la aplicación está en una ubicación diferente en iOS), y también le dice que escriba android.permission.ACCESS_NETWORK_STATE permiso en AndroidManifest.xml (no encontrarás nada como esto en iOS ya que no se necesitan permisos). (Por cierto, lo que se escribe en cada uno de estos archivos json se define en el complemento plugin.xml archivo.)

platforms / android / AndroidManifest.xml - Las herramientas CLI se han encargado de agregar a AndoridManifest los permisos definidos en el archivo xml del complemento. Sí, esto sucede cuando cordova plugin add . Estos permisos se copian directamente de lo que se encuentre en el archivo plugins / android.json. Estos permisos también se eliminan cuando ''rm'' un complemento. Sin embargo, la edición de estos archivos se realiza de manera inteligente, ya que puede agregar cosas personalizadas a AndroidManifest.xml y persistirán.

plataformas / android / assets / www / cordova_plugins.js - Este archivo está oculto dentro de los recursos html que conformarán su aplicación final; estos recursos (prácticamente cualquier cosa en / platforms /) no deben ser editados por usted porque serán reemplazados por las herramientas CLI con bastante frecuencia. Cordova utiliza este archivo en tiempo de ejecución para cargar el código del complemento que ha agregado; también se ocupa de asignar los espacios de nombres de JavaScript a los archivos reales (esta es la declaración "clobbers"). Por ejemplo, veo:

{
    "file": "plugins/org.apache.cordova.network-information/www/network.js",
    "id": "org.apache.cordova.network-information.network",
    "clobbers": [
        "navigator.connection",
        "navigator.network.connection"
    ]
}

esto significa que en el código de su aplicación, navigator.connection y navigator.network.connection asignarán al código que se encuentra en plugins/org.apache.cordova.network-information/www/network.js .

plataformas / android / res / xml / config.xml - Este es el archivo config.xml a nivel de plataforma para Android. Este archivo es creado por las herramientas CLI. Mucha de la información que escribe en su nivel superior config.xml (/MyApp/www/config.xml) se copiará aquí, pero no toda (y hay algunas cosas adicionales, no estoy exactamente seguro de dónde el material adicional proviene de.) Este es el archivo que lee Android cuando ejecuta su aplicación y necesita verificar sus datos de configuración. Por ejemplo, el código de Android Cordova usará esto para ver qué plugins están instalados y qué clases nativas asignan a qué espacios de nombres. Creo que la única forma de editar esto es usando la carpeta / merges / que mencioné anteriormente.

plataformas / ios / {AppName} .xcodeprojcj / project.pbxproj - El equivalente de iOS de AndroidManifest.xml

plataformas / ios / {AppName} /config.xml : este es el archivo config.xml a nivel de plataforma para iOS. ¿Ves cómo está en un lugar diferente que en Android? (p. ej., no en /res/xml/config.xml?) La CLI actualiza automáticamente este archivo y no debe tocarlo.

plataformas / ios / www / cordova_plugins.js - El mismo archivo existe en Android (pero en una ubicación diferente) y tiene el mismo propósito: ayudar a Cordova a cargar sus complementos en tiempo de ejecución cuando alguien está usando la aplicación

Creo que eso describe bastante bien todos los archivos y las carpetas que se usan en un proyecto de Córdoba.

Con suerte, ahora puede ver que, en realidad, solo debe editar el archivo /www/config.xml . Este archivo se usará para construir /platforms/android/res/xml/config.xml y /platforms/ios/{AppName}/config.xml , que Cordova utilizará cuando se ejecute la aplicación empaquetada. Partes de este archivo se usarán para editar los archivos AndroidManifest.xml y project.pbxprojc (para Android e iOS, respectivamente).

Esto explica por qué todavía fue capaz de usar el acelerómetro en su aplicación incluso después de eliminar las líneas <feature name="Accelerometer"> - que acababan de volver a copiarse en el nivel config.xml de la plataforma desde la aplicación principal wide config.xml

Supongo que lo único que queda por descubrir es cómo se pueden editar los archivos de configuración específicos de la plataforma; por ejemplo, ¿cómo se puede editar el archivo AndroidManifest.xml? Bueno, resulta que solo puede editar el archivo /platforms/android/AndroidManifest.xml directamente: la CLI es lo suficientemente inteligente como para no borrar sus personalizaciones cuando agrega o elimina automáticamente los permisos de los complementos. Entonces, si por alguna razón necesitas admitir una versión inferior de Android de la que admite Cordova, puedes cambiar el objeto y persistirá aunque tu cordova plugin add|rm {id} llamadas.

Espero que eso aclare las cosas, ¡siéntase libre de hacer más preguntas!