¿Cómo funciona la actualización de software?

He estado leyendo la Introducción a la Progtwigción Java de Liang durante un par de semanas, y esa pregunta surgió cuando el autor dijo: "No es necesario que los desarrolladores creen, y que los usuarios instalen, las principales versiones de software nuevas".

¿Cómo funciona la actualización de software? Por ejemplo, parches para juegos, nueva versión de productos y ese tipo de cosas. En el libro, hay un ejemplo de que, siempre que mantenga una interfaz de una class igual, no necesita hacer ningún cambio en ninguna de las classs que dependen de la que ha cambiado. Está bien, pero aún es un poco abstracto (por ejemplo, ¿cómo creo un parche de actualización solo con esa class?).

También estoy interesado en libros sobre el tema.

Gracias.

Echa un vistazo al libro

Diseño práctico de API: confesiones de un arquitecto de framework Java (Jaroslav Tulach, Apress, 2008)

Creo que cubre la mayoría de los aspectos sobre los que preguntas.

Para el tema sobre el envío de nuevas versiones de software o actualizaciones, eche un vistazo a la tecnología Java Web Start, por ejemplo.

El envío de una actualización a una aplicación web podría considerarse implícito ante los usuarios, ya que los cambios realizados en un server centralizado 1 son proporcionados por el propio browser web.

1 o un set de serveres

Creo que el concepto que intentas entender es el uso de una interfaz como tipo. En un progtwig Java, se puede declarar que una variable tiene el tipo de alguna interfaz definida. Las classs que implementan esa interfaz se pueden instanciar para variables del tipo de interfaz. Sin embargo, solo se pueden usar methods declarados en la interfaz. En time de compilation, la interfaz se usa para verificar types. Sin embargo, en time de ejecución, el bytecode que realmente hace el trabajo proviene del implementador de la interfaz. Un ejemplo:

public interface foo { public void bar(); } public class A implements foo { public void bar() { // some code } } public class Example { public static void main(String[] args) { foo aFoo = new A(); aFoo.bar(); } } 

En la class Ejemplo, una variable llamada aFoo se declara de tipo foo, la interfaz. A, que implementa la interfaz foo, contendrá el código para hacer el trabajo de method bar (). En la class Ejemplo, la variable aFoo obtiene una instancia de la class A, de modo que cualquier código que esté en el método bar () de A se ejecutará cuando se invoque aFoo.bar () aunque aFoo se declare de tipo foo.

Por lo tanto, hemos establecido que todo el trabajo se realiza en la class A. Las dos classs y una interfaz anterior se pueden definir en su propio file. Los tres files .class resultantes se pueden empaquetar en un contenedor y enviarse a los clientes como la versión 1.0 del progtwig. Algún time después, se podría descubrir un error en la implementación de bar () en la class A. Una vez que se desarrolla una solución, suponiendo que los cambios están contenidos dentro del método bar (), solo se debe enviar el file .class para A clientes. La class A. actualizada se puede insert en el file .jar del progtwig (después de todo, los files .jar son solo files .zip) sobrescribiendo la versión anterior y sin formatting de A.class. Cuando se reinicia el progtwig, la JVM cargará la nueva implementación de A.bar () y la class Ejemplo obtendrá el nuevo comportamiento.

Como ocurre con casi todo, los progtwigs más complicados pueden ser más complicados. Pero los principios son lo mismo.

Considere un juego que ha sido diseñado para tener varios modules independientes, cada uno interactuando entre sí a través de interfaces solamente. El deployment inicial de dicho juego podría consistir en 15 o 20 files jar individuales.

Aplicar actualizaciones sería una cuestión de conectarse a un server, consultar la última versión de cada file jar, comparar con el file jar que ya tiene y download solo los files modificados.

La versión de este tipo de un pobre sería si estuvieras trabajando en un proyecto que tiene 15 jarras, y harías una corrección crítica de fallas en uno de los flasks. No tendrías que copyr los 15 flasks al sistema de tu cliente; no copyrás el que cambió.

jnlp (del cual Webstart y la nueva implementación de applet son ejemplos) lo hace utilizando un file xml bien definido para definir qué versiones de cada biblioteca se requieren. En este caso, la implementación inicial de la aplicación se puede realizar leyendo el xml (servido por un server web) y descargando dinámicamente los files jar necesarios a una memory caching local durante una operación de arranque. En realidad, no hay una installation inicial en absoluto.

Probablemente sea importante mencionar que este beneficio, aunque ciertamente válido y real, es bastante menor en comparación con la facilidad de mantenimiento y la facilidad de encoding que proviene de la networkingucción de las dependencies entre los modules y el uso de interfaces bien definidas.

La forma más sencilla de actualizar una única class será detener la aplicación, anular la class anterior con la nueva y luego reiniciar. Apagar la aplicación puede no ser apropiado para algunos casos. Para superar esto necesitarás tener un framework / contenedor de algún tipo y desarrollar tus propios cargadores de classs que hagan posible la actualización de una class sin reiniciar. Esto es lo que hacen los serveres de aplicaciones Java.

Para el escritorio / clientes gruesos, hay disponibles algunas soluciones comerciales y gratuitas para actualizaciones de software. Vea este artículo para una comparación. Es bastante antiguo, las nuevas soluciones están destinadas a estar disponibles.

Además de actualizar files JAR individuales (o, en otros entornos de software, files de bibliotecas compartidas o files DLL), existen herramientas de parches binarys que se pueden usar en algunos casos para transmitir un set de cambios en el file base. Un progtwig de parche tomará este file de diferencia y lo fusionará con el file base para producir el nuevo file modificado. Esto solo funciona si el file original no se modifica en el sistema instalado, pero puede funcionar en algunos casos para parchear de forma incremental los componentes de un progtwig en particular.

En realidad, había estudiado marginalmente esto en la universidad, y al investigarlo específicamente, lo encontré bastante interesante. Una cosa para hacer para especificar actualizaciones específicamente es el control de versiones donde para cada versión que publicas especifica qué se ha actualizado. Digamos, por ejemplo, que la diferencia entre la versión 1.0.1 y la 1.0.2 es que mylib.dll se ha actualizado. Ahora diga que la diferencia entre 1.0.2 y 1.0.4 es que myotherlib.dll ha cambiado, y si alguien actualiza su software a la última versión (1.0.4) y actualmente tiene 1.0.1, ambos dll están incluidos en la actualización. .

No estoy seguro de si esto se practica o si se usan methods más inteligentes. Realmente depende del fabricante del software, se usan bastantes methods diferentes, supongo que algunos desarrolladores cifran los files de la aplicación y los agrupan en un formatting personalizado.

Aquí hay un actualizador automático de files por lotes simple para empezar con el concepto … Puede ejecutarlo en segundo plano y usarlo para actualizar los files en lugar de escribirlo en Java, sin embargo, me resulta más fácil escribir en c ++.

 @echo off if not exists "file.jar" goto FM cls echo [1] Update echo [2] Exit set /p "main=1OR2:" if %main% == 1 goto U if %main% == 2 exit :U cls echo Updating... del "file.jar" wget "http://yourserver.com/file.(EXTENSION)" if not exists "file.jar" goto FM cls :FM cls echo You are missing important files! pause >nul exit 

Aconsejo que aprendas a hacer esto en Java, pero si quieres avanzar más, puedes poner un file en el server llamado "version.bat" y luego downloadlo también a la computadora portátil de los usuarios para que pueda leerlo y si es la misma versión que la que tienen, se saltará la descarga y dirá que tienes la versión de testing Advalible !.

NOTA: con el fin de este código, debe ir a google y search wget, download el file adecuado y poner en la misma carpeta que el código anterior, también save el código anterior como (anything.bat)

¿No se está refiriendo al Principio de Responsabilidad Individual? http://en.wikipedia.org/wiki/Single_responsibility_principle

En la práctica, parece que no funciona, a less que tenga algo realmente enorme como Windows, que puede actualizar piezas o un juego que utiliza muchas texturas que no necesitan cambiarse.