Method and device for displaying various dynamic graphs in Android application

Abstract

The invention provides a method and device for displaying various dynamic graphs in an Android application, and the method comprises the steps: taking a ViewGroup container which directly inherits CardView as an image display super container, and setting a dynamic engine adaptation layer interface which supports the adaptation of all dynamic format engines in the ViewGroup container; the method comprises the following steps: receiving an image display super container placed in all page layout XML (Extensible Markup Language) files needing to display a dynamic graph by a developer in an Android application, and generating a dynamic graph engine view instance corresponding to a dynamic graph format through a dynamic engine adaptation layer interface in a page initialization process; obtaining a super container comprising a conventional image view instance and a plurality of dynamic image engine view instances; and when the Android application needs to display the first image, the image display super container uses the corresponding view instance to display the first image according to the image format of the first image, so that the display of the dynamic graph in the Android application is realized. According to the method, the efficiency and convenience of dynamic graph display in development, management and control are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of application development, and particularly relates to a method and device for implementing multiple dynamic graph displays in an Android application. Background Art

[0002] App applications have a strong demand for the display of dynamic graphs, and there are many publicly available dynamic graph solutions: gif format, avif format, lottie format, svga format, pag format, and so on. Each solution has its own advantages and disadvantages, and at the same time, the support for compatibility, animation format, and production methods is also different. In product operation, it is hoped that the same image position can support the display of multiple image resources at the same time, and at the same time, it can adapt to the change of picture size.

[0003] As Figure 2 shown, if this function is implemented according to the existing technology, developers need to add multiple dynamic graph display containers at each coding position that needs to support multiple image resources, and then control the display and hiding of the corresponding images by controlling the visibility of each image container. Such coding implementation has the following problems:

[0004] (1) During the development process, complex layouts and management control codes will be generated. At the same time, for each additional support for an image format, a huge workload will be generated.

[0005] (2) The coding implementation is complex, difficult to manage, has a high maintenance difficulty, and is also difficult to expand, and it is easy to cause bugs.

[0006] (3) The operation interfaces of the container components corresponding to each image format are also different, resulting in complex and difficult control of multiple dynamic graph display containers. Summary of the Invention

[0007] In order to solve the above problems of the existing technology, the present invention provides a method and device for implementing multiple dynamic graph displays in an Android application, which improves the efficiency and convenience of the entire process of dynamic graph display in development, management, and control.

[0008] To achieve the above object, the technical solution adopted by the present invention is:

[0009] In the first aspect, the present invention provides a method for implementing multiple dynamic graph displays in an Android application, including the steps of:

[0010] S1. Use a ViewGroup container that directly inherits CardView as an image display super container, and a dynamic engine adaptation layer interface that supports adaptation of all dynamic format engines is set in the image display super container;

[0011] S2. Receive the developer to place the image display super container in the page layout XML files of all the pages in the Android application that need to display animated images, and during the page initialization process, generate an animated image engine view instance in the corresponding animated image format through the animated engine adaptation layer interface, so as to obtain a super container including a conventional image view instance and multiple animated image engine view instances;

[0012] S3. When the Android application needs to display a first image, the image display super container uses the corresponding view instance according to the image format of the first image to display the first image, so as to realize the display of animated images in the Android application.

[0013] The beneficial effects of the present invention are as follows: An image display super container is established, and through the method of capability registration, the image display super container can support the display of multiple animated image formats. Therefore, there is no need for multiple animated image display containers, which reduces the complexity of animated image display in development and control, thereby improving its efficiency and convenience. At the same time, when it is necessary to add or other animated image formats in the future, through the method of capability registration, only one line of code can quickly realize the extension or deletion of animated image formats, thereby also improving the efficiency and convenience of animated image display in management.

[0014] Optionally, the image display super container also uses Glide.intoMIV to load images.

[0015] Optionally, a unified packaging image resource class is set on the image display super container. The Glide component based on Glide.intoMIV includes glide extension modules for all animated image formats and a unique external glide interface module;

[0016] The step S3 is as follows:

[0017] When the Android application needs to display a first image, the Glide component uses the corresponding glide extension module to load resources according to the image format of the first image, converts the loaded resources into Drawable resources and passes them to the unified packaging image resource class in the image display super container, and the image display super container uses the corresponding view instance according to the image format of the first image to display the first image, so as to realize the display of animated images in the Android application.

[0018] According to the above description, by using the Glide extension method, the powerful advantages of the Glide image loading framework are fully utilized, finally simplifying the development work of multiple image formats on the usage layer, and being able to effectively reduce memory usage and loading efficiency, thereby further improving the efficiency and convenience of the entire process of dynamic display.

[0019] Optionally, the display of the first image using the corresponding view instance in step S3 includes:

[0020] If the first image is a dynamic image, it is rendered and displayed using the corresponding animated image engine view instance.

[0021] Optionally, step S2 further includes:

[0022] Completely transfer the layout attributes of all views in the image display super container through the constructor.

[0023] Optionally, the image display super container in step S3 uses the corresponding animated image engine view for loading and rendering according to the dynamic format of the dynamic image, including:

[0024] The image display super container calls canMatched(path) to determine the animated image engine view to be used according to the dynamic format of the dynamic image.

[0025] Optionally, the animated image formats include gif format, avif format, lottie format, svga format, and pag format.

[0026] Optionally, step S3 further includes:

[0027] If the image display super container does not find a view instance that supports the first image, an image failure instruction is returned.

[0028] In a second aspect, the present invention provides a device for implementing multiple dynamic image displays in an Android application, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the method for implementing multiple dynamic image displays in an Android application in the first aspect.

[0029] Among them, the technical effects corresponding to the device for implementing multiple dynamic image displays in an Android application provided in the second aspect refer to the relevant descriptions of the method for implementing multiple dynamic image displays in an Android application provided in the first aspect. Description of the Drawings

[0030] Figure 1 It is a main flow schematic diagram of the method for implementing multiple dynamic image displays in an Android application according to an embodiment of the present invention;

[0031] Figure 2 It is a flow schematic diagram of implementing multiple dynamic image displays in the prior art;

[0032] Figure 3 Schematic diagram of the structural framework of the MagicImageView super container involved in the first embodiment of the present invention;

[0033] Figure 4 Schematic diagram of the specific process of a method for implementing multiple dynamic graph displays in an Android application in the first embodiment of the present invention;

[0034] Figure 5 Schematic diagram of the cooperative structure of the MagicImageView super container and the Glide component involved in the second embodiment of the present invention;

[0035] Figure 6 Schematic diagram of the specific process of a method for implementing multiple dynamic graph displays in an Android application in the second embodiment of the present invention;

[0036] Figure 7 Schematic diagram of the framework of a device for implementing multiple dynamic graph displays in an Android application in the embodiment of the present invention.

[0037] Explanation of reference numerals:

[0038] 1. A device for implementing multiple dynamic graph displays in an Android application;

[0039] 2. Processor;

[0040] 3. Memory. Detailed implementation manners

[0041] In order to better understand the above technical solutions, the exemplary embodiments of the present invention will be described in more detail with reference to the accompanying drawings. Although the exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and the scope of the present invention can be fully conveyed to those skilled in the art.

[0042] Embodiment 1

[0043] This embodiment is applicable to the Android application development scenario where dynamic graphs need to be displayed. Especially in the case where there are multiple positions in the Android application that need to display dynamic graphs. The existing dynamic graph display has problems with excessive complexity in the entire process of development, management, and control because multiple dynamic graph image display containers are required. This embodiment solves the problems of the above prior art through an image display super container. See the following description for details.

[0044] Please refer to Figure 1 , Figure 3 and Figure 4, A method for implementing multiple dynamic image displays in an Android application, including the steps:

[0045] The present invention provides a method for implementing multiple dynamic image displays in an Android application, including the steps:

[0046] S1. Use a ViewGroup container that directly inherits CardView as the super container for image display. An interface for a dynamic engine adaptation layer that supports adaptation of all dynamic format engines is set in the super container for image display.

[0047] Among them, the dynamic image formats include gif format, avif format, lottie format, svga format, and pag format. It should be noted that this is only an example here. When other dynamic image formats or new dynamic image formats need to be supported in an Android application, the method of this embodiment can also be implemented. In this embodiment, in the Android application to be developed, it is necessary to support three dynamic image formats: lottie format, svga format, and pag format. Therefore, referring to Figure 3 It can be seen that the interface for the dynamic engine adaptation layer in this embodiment needs to adapt and develop the lottie format dynamic image engine adaptation, svga format dynamic image engine adaptation, and pag format dynamic image engine adaptation.

[0048] S2. Receive that the developer places the super container for image display in the page layout XML files of all pages in the Android application that need to display dynamic images, and during the page initialization process, generate an instance of a dynamic image engine view corresponding to the dynamic image format through the interface for the dynamic engine adaptation layer, and obtain a super container including a regular image view instance and multiple dynamic image engine view instances.

[0049] Among them, step S2 further includes:

[0050] Completely transfer the layout attributes of all views in the super container for image display through the constructor.

[0051] That is, in this embodiment, a MagicImageView super container is developed by itself. This container externally undertakes the loading and display of all image formats, and internally provides an adaptation layer for the IMagicDyView interface in the form of ability registration. All specific instances that need to provide image format support for the MagicImageView super container are developed according to the IMagicDyView interface and registered in the MagicImageView super container when needed.

[0052] Specifically, the MagicImageView super container is a ViewGroup container that directly inherits from CardView. CardView is selected to reduce the additional layout nesting problems and performance consumption caused by the need to process rounded corners and other situations when additional layout superposition is required externally.

[0053] Among them, inside the MagicImageView super container, in addition to the regular ImageView image view instance + animated image registration, N animated image engine view instances that need to provide support for animated image display are included. Then, in the constructor of this super container, the layout attributes are completely passed to the imageView + N animated image engine view instances. In this way, externally, all the attributes provided by the animated image engines used can be supported in the xml layout usage of the container. The above-mentioned instances and the corresponding constructor are both set in the wrapper container implementation class and are unified and exposed externally through the interfaces that the wrapper container needs to implement.

[0054] Therefore, for upper-layer usage, only the usage code needs to be written, without having to care about how to load different formats of animated image resources specifically and how to manage the container for displaying animated image resources, thus reducing the workload of upper-layer usage and lowering the difficulty of development and management.

[0055] S3. When an Android application needs to display the first image, the image display super container uses the corresponding view instance to display the first image according to the image format of the first image, realizing the display of animated images in the Android application.

[0056] Among them, the display of the first image using the corresponding view instance in step S3 includes:

[0057] If the first image is an animated image, the corresponding animated image engine view instance is used to render and then display the first image.

[0058] Among them, the loading and rendering of the animated image using the corresponding animated image engine view according to the dynamic format of the animated image in step S3 by the image display super container includes:

[0059] The image display super container calls canMatched(path) to judge the animated image engine view to be used according to the dynamic format of the animated image.

[0060] Therefore, after the MagicImageView super container contains the imageView + N animated image engine view instances, referring to Figure 4It can be seen that when called at the upper layer, the image resources are loaded through the unified load interface. Internally, according to the passed-in image resource path, canMatched(path) is called in the implementation class of the packaging container to determine which animation engine supports the format of the image resources, and then it can be distributed to the animation engine for actual loading and rendering. Among them, since the MagicImageView super container uses the unified load interface, there is no burden of changing the animation format.

[0061] Meanwhile, step S3 further includes:

[0062] If the view instance that supports the first image is not found in the image display super container, an image failure instruction is returned.

[0063] As Figure 4 shown, in this embodiment, if there are still image resources that the user wants to load but are not supported in the image display super container, the image failure instruction is called back to LoadCallback and it is up to the outside to decide how to handle it.

[0064] Embodiment 2

[0065] Please refer to Figure 1 、 Figure 3 、 Figure 5 and Figure 6 For a method of implementing multiple dynamic image displays in an Android application, based on the above Embodiment 1, the image display super container also uses Glide.intoMIV to load images. Thus, by expanding the functions of the powerful Glide image loading library, the ability to load image resources for the MagicImageView super container view is added, ultimately simplifying the development work of multiple image formats on the usage layer.

[0066] Referring to Figure 5 and Figure 6 It can be seen that a unified image resource packaging class is set on the image display super container. The Glide component based on Glide.intoMIV includes glide extension modules for all animation formats and the only external glide interface module, namely the glide-miv module. Among them, the glide extension modules include the glide-miv-lottie module and the glide-lottie module corresponding to the lottie format, the glide-miv-svga module and the glide-svga module corresponding to the svga format, and the glide-miv-pag module and the glide-pag module corresponding to the pag format. Thus, step S3 is:

[0067] When an Android application needs to display the first image, the Glide component uses the corresponding Glide extension module to load resources according to the image format of the first image, and converts the loaded resources into Drawable resources and passes them to the unified wrapper image resource class in the image display super container. Then, the image display super container uses the corresponding view instance according to the image format of the first image to display the first image, realizing the display of animated images in the Android application.

[0068] That is, in this embodiment, code is written one by one for specific animated image engines, adding encodings such as transcoder, resource, decoder, and LibraryGlideModule to implement the ability extension of the Glide component to the animated image engines, and obtaining the corresponding Glide extension modules. After the Glide component provides the extension ability to each animated image engine, it is necessary to provide the conversion of the MivWrapDrawable wrapper. Similarly, it is also necessary to implement the conversion ability encoding for each Glide extension module, and then use them in combination on the glide-miv module.

[0069] Among them, the glide-miv module is the unified external entry in the Glide extension. The resources loaded by the Glide component will be converted into Drawable resources wrapped by MivWrapDrawable and passed to the MagicImageView super container. Then, the canMatched(Drawable) method in the registered animated image engine instance will be called internally for judgment, and then the actual scheduling display of the animated image engine will be performed.

[0070] Refer to Figure 5 It can be seen that MivWrapDrawable is the unified wrapper image resource class provided for the Glide component extension in the MagicImageView super container. The conversion relationship between the resources loaded by the Glide component and the Drawable resources is set in the glide-miv module.

[0071] Among them, for the Glide extension module, in order to facilitate the use of the upper layer, each extension module extends the interface capabilities of Glide and provides a convenient interface call scheme. At the same time, as Figure 6 shown, in order for MagicImageView to facilitate the use of the Glide component, it provides an extended interface of loadByGlide to meet the call needs of the upper layer, so as to load image resources through the loadByGlide interface.

[0072] In summary, this embodiment has the following advantages:

[0073] 1. By means of capability registration, the image display super container can support the display of multiple animated image formats. Thus, there is no need for multiple animated image display containers, reducing the complexity of animated image display in development and control, thereby improving its efficiency and convenience. At the same time, when additional animated image formats need to be added or other formats are involved in the future, through the method of capability registration, only one line of code is required to quickly implement the extension or deletion of animated image formats, thus also enhancing the management efficiency and convenience of animated image display.

[0074] 2. Using the Glide extension method, making full use of the powerful advantages of the Glide image loading framework, ultimately simplifying the development work of multiple image formats on the usage layer, and being able to effectively reduce memory usage and loading efficiency, thereby further improving the efficiency and convenience of the entire process of dynamic display.

[0075] Embodiment Three

[0076] Please refer to Figure 7 , a device 1 for implementing multiple dynamic image displays in an Android application, including a memory 3, a processor 2, and a computer program stored on the memory 3 and executable on the processor 2. When the processor 2 executes the computer program, the steps in the above-mentioned Embodiment One or Two are implemented.

[0077] Since the system / device described in the above embodiments of the present invention is the system / device adopted for implementing the method in the above embodiments of the present invention, based on the method described in the above embodiments of the present invention, those skilled in the art can understand the specific structure and variations of the system / device, and thus will not be elaborated here. Any system / device adopted by the method in the above embodiments of the present invention falls within the scope of protection of the present invention.

[0078] Those skilled in the art should understand that the embodiments of the present invention can be provided as methods, devices, or computer program products. Therefore, the present invention can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0079] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (apparatuses), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions.

[0080] It should be noted that in the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a claim listing several means, several of these means can be embodied by the same hardware element. The use of the terms first, second, third, etc. is for convenience only and does not denote any order. These terms can be construed as part of the name of the element.

[0081] In addition, it should be noted that in the description of this specification, the description of terms such as "one embodiment", "some embodiments", "embodiment", "example", "specific example" or "some examples", etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without conflict, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0082] Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications after learning the basic creative concept. Therefore, the claims should be construed to include the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0083] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention should also include these modifications and variations.

Claims

1. A method for realizing multiple dynamic image display in an Android application, characterized in that: Includes steps: S1. Using a ViewGroup container that directly inherits CardView as an image display super container, wherein a dynamic engine adaptation layer interface that supports adaptation of all dynamic format engines is provided in the image display super container; S2, receiving the image display super container placed in all page layout XML files that need to display dynamic images in the Android application by the developer, and generating a dynamic image engine view instance in the corresponding dynamic image format through the dynamic engine adaptation layer interface during the page initialization process, and obtaining a super container including a regular image view instance and multiple dynamic image engine view instances; S3. When the Android application needs to display the first image, the image display super container uses the corresponding view instance to display the first image according to the image format of the first image, thereby realizing the display of the dynamic image in the Android application.

2. A method for realizing multiple dynamic graph display in Android application according to claim 1, characterized in that: The image display super container also uses Glide.intoMIV to load images.

3. A method for realizing multiple dynamic graph display in Android application according to claim 2, characterized in that: The image display super container is provided with a unified packaging image resource class, and the Glide component based on Glide.intoMIV includes glide extension modules of all animated image formats and the only external glide interface module; The step S3 is: When an Android application needs to display a first image, the Glide component uses the corresponding glide extension module to load resources according to the image format of the first image, converts the loaded resources into Drawable resources and passes them to the unified packaged image resource class in the image display super container, and the image display super container uses the corresponding view instance to display the first image according to the image format of the first image, thereby realizing the display of dynamic images in Android applications.

4. A method for realizing multiple dynamic image display in an Android application according to any one of claims 1 to 3, characterized in that: The display of the first image using the corresponding view instance in step S3 includes: If the first image is a dynamic image, the first image is rendered and displayed using a corresponding dynamic image engine view instance.

5. A method for realizing multiple dynamic image display in an Android application according to any one of claims 1 to 3, characterized in that: The step S2 further comprises: The layout attributes of all views in the image display super container are fully passed through the constructor.

6. A method for realizing multiple dynamic graph display in Android application according to claims 1 to 3, characterized in that: In step S3, the image display super container uses the corresponding dynamic image engine view to load and render according to the dynamic format of the dynamic image, including: The image display super container calls canMatched(path) to determine the dynamic image engine view to be used according to the dynamic format of the dynamic image.

7. A method for realizing multiple dynamic image display in Android application according to claims 1 to 3, characterized in that: The animated image formats include gif format, avif format, lottie format, svga format and pag format.

8. The method for realizing multiple dynamic image display in Android application according to claim 5, characterized in that: The step S3 further comprises: If the image display super container does not find a view instance that supports the first image, an image failure instruction is returned.

9. A device for realizing multiple dynamic image display in an Android application, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, a method for displaying multiple dynamic images in an Android application as described in any one of claims 1 to 8 is implemented.

Images