WO2016107465A1 - 一种卡片式桌面的实现方法、装置和系统 - Google Patents

一种卡片式桌面的实现方法、装置和系统 Download PDF

Info

Publication number
WO2016107465A1
WO2016107465A1 PCT/CN2015/098258 CN2015098258W WO2016107465A1 WO 2016107465 A1 WO2016107465 A1 WO 2016107465A1 CN 2015098258 W CN2015098258 W CN 2015098258W WO 2016107465 A1 WO2016107465 A1 WO 2016107465A1
Authority
WO
WIPO (PCT)
Prior art keywords
desktop
module
view
resource
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2015/098258
Other languages
English (en)
French (fr)
Inventor
罗自荣
钟学书
杨扬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2016107465A1 publication Critical patent/WO2016107465A1/zh
Priority to US15/639,677 priority Critical patent/US20170302747A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/986—Document structures and storage, e.g. HTML extensions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the present invention relates to the field of computer application technologies, and in particular, to a method, device and system for implementing a card type desktop.
  • the first way the user first installs an application installation package in the mobile terminal, and then the merchant sends the service to the specific application, and the application notifies the operating system to prompt relevant information in the task bar or the like. The user clicks on the relevant information to enter the specific application to view the details.
  • the first method has the problem that the corresponding application installation package needs to be pre-installed in advance, and the user needs to jump to the specific application when viewing the details.
  • the problem with the second method is that the pushed data structure is relatively simple, the experience is relatively simple, not friendly enough, and basically one-off.
  • a card-based desktop technology in which a desktop process displays data in the form of a service card on a desktop.
  • the desktop is no longer just the entrance to the application, but the user can see the information they need to see directly on the desktop.
  • the desktop process uses a certain desktop area for the display area of the card view, and defines a display template of the display area.
  • the underlying service connects to the server, obtains the data to be displayed, and then the desktop process takes the data. Fill into the display template to form a view that appears on the desktop.
  • the present invention provides a method, device and system for implementing a card-type desktop, so that the desktop can get rid of the limitation of the template when displaying data, thereby reducing consumption.
  • the present invention provides a method for implementing a card-type desktop, the method comprising:
  • the service management module sends the resource address of the card-type desktop service from the server to the desktop module;
  • the desktop module creates a usable view area on the desktop, where the view area is used to display a service card corresponding to the resource address, and a view corresponding to the service card is created in the view area, and the view information and the resource are The address is sent to the rendering module;
  • the rendering module acquires the resource file corresponding to the resource address from the server, and renders the resource file to the view according to the view information.
  • the method further includes:
  • the desktop module stores related information of the service card into a database, and related information of the service card includes the resource address and the view information.
  • the method further includes:
  • the desktop module After the desktop module and the rendering module are started, the desktop module reads information about a service card in a database, creates a view on the desktop according to the view information, and displays the resource address and the view information. Sent to the rendering module;
  • the rendering module After the resource module obtains the resource file corresponding to the resource address, the rendering module renders the acquired resource file to the created view according to the view information.
  • the method further includes:
  • the service management module After receiving the content update message that includes the resource address, the service management module sends the content update message to the desktop module;
  • the rendering module re-acquires the resource file corresponding to the resource address from the server, and the obtained The resource file is re-rendered to the corresponding view.
  • the method further includes:
  • the desktop module obtains the event that the user deletes the service card, the view corresponding to the service card is deleted, and the view area occupied by the view is restored to be usable.
  • the method further includes:
  • the rendering module obtains an operation event of the user on the service card, responds to the operation event, or reports the operation event to the desktop module and responds to the operation event by the desktop module;
  • the operation event is reported to the rendering module, and the rendering module responds to the operation event, or the operation is performed.
  • An event is reported to the desktop module and is responsive to the operational event by the desktop module.
  • the rendering module responding to the operation event includes:
  • the rendering module acquires a resource file corresponding to the resource address requested by the operation event from the server, and renders the obtained resource file to a view corresponding to the service card;
  • the rendering module reports the operation event to the desktop module, the desktop module creates a new window on the desktop, and sends the information of the window to the rendering module; the rendering module acquires the operation from the server The resource file corresponding to the resource address requested by the event, and the obtained resource file is rendered to the newly created window according to the information of the window.
  • the responding to the operation event by the desktop module includes:
  • the desktop module sends the resource address requested by the operation event and the view information corresponding to the service card to the rendering module, where the rendering module acquires the resource file corresponding to the resource address requested by the operation event from the server And rendering the obtained resource file to the corresponding view according to the view information; or
  • the desktop module creates a window on the desktop, and sends the resource address requested by the operation event and the newly created window information to the rendering module, where the rendering module acquires the resource corresponding to the resource address requested by the operation event from the server. After the file, the obtained resource file is rendered to the newly created window according to the window information.
  • the newly created window covers all or part of the view on the desktop, or the window is in a fixed area of the desktop, and the fixed area does not conflict with the view on the desktop.
  • the JS code further reports the size and/or location information of the window to the desktop module when reporting the operation event to the desktop module;
  • the desktop module executes the creating a window on the desktop according to the size and/or location information of the window.
  • information exchange between the desktop module and the rendering module is performed by means of inter-process communication.
  • the rendering module invokes a web engine to perform the rendering operation.
  • the invention also provides an implementation device of a card desktop, the device comprising: a service management module, a desktop module and a rendering module;
  • the service management module is configured to send a resource address of a card-type desktop service from the server to the desktop module;
  • the desktop module is configured to: after receiving the resource address, create a usable view area on the desktop, where the view area is used to display a service card corresponding to the resource address, and the service card is created in the view area. Corresponding view, sending the view information and the resource address to the rendering module;
  • the rendering module is configured to: after receiving the resource address and the view information sent by the desktop module, acquire a resource file corresponding to the resource address from the server, and render the resource file to the view according to the view information. .
  • the desktop module is further configured to store related information of the service card into a database, and related information of the service card includes the resource address and the view information.
  • the desktop module is further configured to: after the desktop module and the rendering module are started, read related information of a service card in a database, according to the view information.
  • a view is created on the desktop, and the resource address and the view information are sent to the rendering module.
  • the service management module is further configured to: after receiving the content update message that includes the resource address, send the content update message to the desktop module;
  • the desktop module is further configured to send the content update message to the rendering module
  • the rendering module is further configured to re-generate the resource file corresponding to the resource address from the server, and re-render the obtained resource file to the corresponding view.
  • the desktop module is further configured to delete a view corresponding to the service card when the user deletes the service card, and the view area occupied by the view is restored to be usable.
  • the rendering module is further configured to: when acquiring an operation event of the user on the service card, respond to the operation event, or report the operation event to the desktop module,
  • the desktop module is responsive to the operational event;
  • the rendering module is further configured to acquire an operation event reported by the JS code on the service card, and respond to the operation event; or
  • the desktop module is further configured to acquire an operation event reported by the JS code on the service card, and respond to the operation event.
  • the rendering module specifically executes when responding to the operation event:
  • the operating event is reported to the desktop module, and after receiving the information about the window sent by the desktop module after creating a new window on the desktop, the resource file corresponding to the resource address requested by the operation event is obtained from the server.
  • the obtained resource file is rendered to the newly created window according to the information of the window.
  • the desktop module specifically executes: sending the resource address requested by the operation event and view information corresponding to the service card to the rendering module when responding to the operation event; or
  • the desktop module is configured to: when creating a window on the desktop, send the resource address requested by the operation event and the newly created window information to the rendering module; the rendering module is further used to After the resource file corresponding to the resource address requested by the operation event is obtained from the server, the obtained resource file is rendered to the newly created window according to the window information.
  • the newly created window of the desktop module covers all or part of the view on the desktop, or the desktop module creates a new window in the fixed area of the desktop, and the fixed area and the desktop are The views do not conflict.
  • the desktop module is further configured to receive a size and/or location information of a window that is further reported when the JS code reports the operation event, according to the size and/or location information of the window. Perform the operation of creating a window on the desktop.
  • information exchange between the desktop module and the rendering module is performed by means of inter-process communication.
  • the rendering module invokes a web engine to perform the rendering operation.
  • the present invention also provides a system for implementing a card-type desktop, the system comprising: a management server and a mobile terminal;
  • the management server is configured to obtain a resource address of the card service, and send the resource address of the card service to the mobile terminal;
  • the mobile terminal includes the above device.
  • the provider server is further configured to send a content update message including the resource address to the management server;
  • the management server is further configured to send the content update message to the mobile terminal.
  • the invention also provides a method for implementing a card type desktop, the method comprising:
  • Creating a usable view area on the desktop where the view area is used to display a service card corresponding to the resource address, and a view corresponding to the service card is created in the view area;
  • the resource file is rendered to the view.
  • the method further includes:
  • the resource file corresponding to the resource address is obtained from the server, and the obtained resource file is re-rendered to the corresponding view.
  • the method further includes:
  • the view corresponding to the service card is deleted, and the view area occupied by the view is restored to be usable.
  • the method further includes:
  • the obtained resource file is rendered to the corresponding view according to the view information, or a new window is created on the desktop, and the obtained resource file is rendered to the newly created file. window.
  • the present invention uses the rendering module to render the resource file, and can no longer rely on any template to implement loading and displaying of any form of resource content, thereby reducing the consumption caused by the storage template.
  • FIG. 1 is a structural diagram of a system architecture based on an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a layout of a card-type desktop according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a main method according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of creating a new card service according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of establishing a card service when a mobile terminal is restarted according to an embodiment of the present invention
  • FIG. 6 is a flowchart of updating content of a service card according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of a first type of event in response to a user interaction with a service card according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of a second interaction event between a user and a service card according to an embodiment of the present invention.
  • FIG. 9 is a flowchart of a third interaction event between a user and a service card according to an embodiment of the present invention.
  • FIG. 10 is a diagram showing an example of a desktop card according to an embodiment of the present invention.
  • FIG. 11 is a diagram showing an example of the desktop card update shown in FIG. 10;
  • FIG. 12 is a diagram showing an example of a desktop formed by the desktop card shown in FIG. 11 in response to a user operation event;
  • FIG. 13 is a diagram showing another example of a desktop formed by the desktop card shown in FIG. 11 in response to a user operation event.
  • the system architecture on which the embodiments of the present invention are based mainly includes a provider server 10, a management server 20, and a mobile terminal 30.
  • the provider server 10 can also be independent of the system, that is, the system architecture includes the management server 20 and the mobile terminal 30.
  • the mobile terminal 30 may include an implementation device of a card desktop.
  • the implementation device of the card desktop may further include a service management module 31, a desktop module 32, and a rendering module 33.
  • the resource here may be text, video, picture, etc.
  • the resource address that needs to be sent may be sent to the management server 20 through the provider server 10, where the resource address may adopt a URL. (Uniform Resource Locator), which is described by URL in subsequent embodiments.
  • the management server 20 can open the interface only to the provider server 10 having the partnership.
  • the management server 20 transmits the URL to the service management module 31 in the mobile terminal 30.
  • the card service can be registered and subscribed to the management server 20 in advance, and the management server 20 transmits the URL of the corresponding card service to the mobile terminal that registers and subscribes to the card service. For example, if a user subscribes to a provider's reading service, if the provider sends a URL, the management server 20 sends the URL to the service management module 31 in the user's mobile terminal 30.
  • the service management module 31 in the mobile terminal 30 transmits the URL to the desktop module 32.
  • the desktop module 32 obtains the URL, it creates a usable view area on the desktop, and the view area is used to display the service card corresponding to the URL.
  • the view area that can be used here can be an unoccupied view area on the desktop, or an attempted area on the desktop that is not occupied within a preset range.
  • the desktop module 32 then creates a View corresponding to the service card in the view area, and provides the view information and the URL to the rendering module 33.
  • the information of the View may adopt the handle of the View, that is, the desktop module 32 passes the handle of the created View to the rendering module 33.
  • the service management module 31 and the desktop module 32 can be implemented in the form of a process in the mobile terminal 30, that is, respectively, as a service management process and a desktop process.
  • the view area can be created on the desktop according to the preset layout of the card type desktop.
  • the desktop module 32 can create the view area of the service card according to the layout manner shown in FIG. 2. If there is an unoccupied view area, the service card's resource file is rendered into the view on the view area, and there can be up to 4 service cards on the desktop.
  • the example shown in FIG. 2 is only an example of a layout, and the embodiment of the present invention does not limit the layout of the card-type desktop.
  • the rendering module 33 obtains the corresponding resource file according to the URL provided by the desktop module 32, that is, the resource file corresponding to the URL is obtained by the provider server 10, and the resource file is usually an HTML (HyperText Mark-up Language) file. But it can also be a multimedia file such as a video file or a picture. Of course, the multimedia file can also be embedded in an HTML file.
  • HTML HyperText Mark-up Language
  • the rendering module 33 After the rendering module 33 obtains the resource file, the resource file is rendered into the corresponding View according to the information of the View provided by the desktop module 32, so that the resource file can be displayed in the view area, and is represented as a resident on the desktop.
  • Desktop service card In addition, the desktop module 32 can store related information of the service card into the database for the mobile terminal 30 to automatically read at startup. Take the relevant content and display the corresponding service card.
  • the information related to the service card may be the URL information and the information of the corresponding View, and the information of the View may include a handle of the View, location information of the View, and the like.
  • the rendering module 33 can be implemented in the manner of a web engine, that is, an operation that invokes a web engine to perform rendering.
  • the rendering module 33 may enable a rendering process to render all the service cards, or may enable the rendering process to be rendered separately for each service card (in this case, the service card and the rendering process are one-to-one). Relationship).
  • the main process includes: parsing the HTML file, converting the HTML document into a DOM tree, and then performing style parsing, adding colors, sizes and other attributes on the DOM tree to form a rendering tree (render) Tree). Then use buffer (buffer) to draw each node of the rendering tree, and fill the contents drawn in the buffer to the View corresponding to the service card.
  • the desktop module 32 and the rendering module 33 adopt a cross-process processing method for the buffer, that is, the desktop module 32 is responsible for the management of the buffer, and the rendering module 33 is responsible for rendering the resource file by using the buffer.
  • each service card corresponds to a buffer, and the shared rendering process respectively renders the View corresponding to the service card by using the buffer corresponding to each service card.
  • This method is preferably applied to the case where the page complexity is relatively low, and the memory is saved.
  • each service card corresponds to a rendering process
  • all service cards share a buffer.
  • the rendering module uses the shared buffer and the corresponding rendering process to render the resource file. This case is preferably applied to a case where the page complexity is high, and the processing capability is strong.
  • the desktop module 32 reads the URL information and the View information in the database, and then creates a View on the desktop according to the View information, and provides the information of the URL information View to The rendering module 33, after obtaining the resource file corresponding to the URL by the rendering module 33 (that is, requesting and obtaining the resource file corresponding to the URL from the provider server 10), rendering the resource file to the corresponding View.
  • Updates can be periodic or accidental.
  • the provider server 10 sends a content update message including the URL to the management server 20, and the management server 20 transmits the message to the service module 31 of the mobile terminal 30.
  • the service management module 31 sends the message to the desktop module 32, and the desktop module 32 transmits the message.
  • the rendering module 33 re-acquires the resource file corresponding to the URL, and re-renders the resource file to the corresponding View.
  • the service card is resident on the desktop unless the user manually deletes it. That is, when the desktop module 32 obtains the event that the user deletes the service card, the view corresponding to the service card is deleted, and the view area occupied by the view is restored to be usable, that is, it is not occupied.
  • the service card is resident on the desktop, and the user can interact with the service card through the UI interface: when the user operates on the service card, the rendering module 33 or the JS code on the service card can be captured on the service card.
  • the operation is directly responsive to the operation and/or reported to the desktop module 32, which is responsive to the operation by the desktop module 32.
  • the user interacts with the service card through the UI interface to request a new resource file.
  • the user requests a resource file corresponding to the link by clicking a link in the resource file on the service card, and then, for example, a view corresponding to the service card. Due to the limited display area, only a part of the entire page is displayed. Other content requires the user to request the remaining resource files that are not displayed by sliding, clicking the button of "display remaining page content", or sliding the slider.
  • the service card's JS code or rendering module 33 captures the event, and the rendering module 33 or desktop module 32 is notified if the JS code captures the event.
  • the rendering module 33 obtains the event triggered by the user, if the event is within the response authority of the rendering module 33, the rendering module 33 directly acquires the resource file corresponding to the resource address requested by the event from the provider server 10, and The obtained resource file is rendered into the corresponding View.
  • the rendering module 33 obtains the event triggered by the user, if the event is outside the response authority of the rendering module 33, the event can be reported to the desktop module 32.
  • the desktop module 32 provides the resource address requested by the event and the information of the corresponding View to the rendering module 33.
  • the rendering module 33 acquires the resource file from the provider server 10
  • the new resource file is rendered to the corresponding View.
  • the desktop module 32 can also create a new window, and then provide the address information and the corresponding window information requested by the event to the rendering module 33, and the rendering module 33 obtains the resource corresponding to the address requested by the event from the server. After the file, the obtained resource file is rendered to the newly created window.
  • the desktop module 32 may send the address requested by the event and the information of the View to the rendering module 33, and the rendering module 33 obtains the address corresponding to the event requested from the server. After the resource file, the obtained resource file is rendered into the corresponding View. Alternatively, the desktop module 32 creates a new window, and sends the requested address and the newly created window information to the rendering module 33. After the rendering module 33 obtains the resource file corresponding to the address requested by the event from the server, the obtained resource file is obtained. Render to the newly created window.
  • the desktop module 32 When the desktop module 32 is newly created, it can adopt various methods, for example, creating a large window, and the position of the window may cover all or part of the View on the card desktop. As another example, the window can be in a fixed area of the desktop that does not conflict with the View on the card desktop.
  • the process of creating a new card service as shown in FIG. 3 is specifically implemented, which specifically includes the following steps:
  • a resource address of a card-type desktop service from the server is received.
  • a usable view area is created on the desktop, and the view area is used to display a service card corresponding to the resource address, and a view corresponding to the service card is created in the view area.
  • the resource file corresponding to the resource address is obtained from the server, and the resource file is rendered to the corresponding view according to the view information.
  • the resource file corresponding to the resource address is obtained from the server, and the obtained resource file is re-rendered to the corresponding view.
  • the view corresponding to the service card is deleted, and the view area occupied by the view is restored to be usable.
  • the resource file obtained by the view information is rendered to the pair.
  • the view should be, or create a new window on the desktop to render the obtained resource file to the newly created window.
  • the process may be as shown in FIG. 4.
  • the service management module and the desktop module are implemented in a process manner.
  • the rendering module is implemented by a web engine, and specifically includes the following steps:
  • step 401 the service management process sends the URL from the management server to the desktop process.
  • the desktop process creates a view area on the desktop that is not occupied, and the view area is used to display a service card corresponding to the URL, and the view corresponding to the service card is created on the view area.
  • step 403 the desktop process provides the URL and the handle of the View to the web engine.
  • step 404 the web engine obtains the HTML file corresponding to the URL, renders the HTML file to the corresponding View according to the handle of the View provided by the desktop process, and stores the URL information, the handle of the View, and the location information in the database.
  • the web engine can return status information during the rendering process to the desktop process.
  • the way of inter-process communication may include, but is not limited to, the manner of broadcasting, the way of file mapping, the way of sharing memory, the way of sharing a dynamic link library, and the like. That is to say, the service management process sends the URL to the desktop process through inter-process communication, and the desktop process provides the URL and the view handle to the web engine through inter-process communication, and the web engine returns the rendering state through inter-process communication. information.
  • the embodiment of the present invention adopts a rendering manner, and no longer depends on any template, and can implement loading and displaying of any form of resource content, and does not need to store multiple templates, thereby reducing consumption.
  • the acquisition and rendering of resource files is no longer performed by the desktop process, but by another process web engine, the rendering of the service card does not affect the desktop process, nor does it burden the desktop process, thereby reducing consumption and improving Stability.
  • the mobile terminal can directly view the resource file pushed by the provider server on the desktop without installing a specific application, thereby saving the operation cost of the user and enhancing the user experience.
  • the mobile terminal If the mobile terminal is restarted, it can be started according to the process shown in FIG. 5, which specifically includes the following steps:
  • step 501 after the desktop process and the rendering process are started, the desktop process reads the URL information and the View information in the database, and creates a View on the desktop according to the View information.
  • the desktop process creates a view area, and creates a View on the view area.
  • step 502 the desktop process provides the URL and View information to the web engine.
  • step 503 the web engine obtains the HTML file corresponding to the URL, that is, requests and acquires the resource file corresponding to the URL from the provider server.
  • step 504 the web engine renders the retrieved HTML file to the corresponding View.
  • the rendered status information can be returned to the desktop process.
  • the display of the card desktop can be automatically performed, and the user can directly see the customized service card from the desktop.
  • the mobile terminal can perform the update process as shown in FIG. 6, as shown in FIG. 6, the process specifically includes the following steps:
  • step 601 when the service management process receives the content update message including the URL, the message is sent to the desktop process.
  • step 602 the desktop process sends the message to the web engine.
  • step 603 the web engine reacquires the HTML file according to the URL included in the message, and re-renders the HTML file to the corresponding View.
  • the rendered status information can be returned to the desktop process.
  • the mobile terminal can perform the process as shown in FIG. 7, in which the user clicks on the link on the service card and the web engine has the response authority as an example. Specifically, the following steps are included:
  • step 701 the JS code of the service card captures the event that the user clicked on the link on the service card, notifying the web engine of the event.
  • the event processing module in the web engine can also directly capture the event that the user clicks on the link on the service card.
  • step 702 the web engine obtains an HTML file corresponding to the link from the provider server, and renders the HTML file to a view corresponding to the service card.
  • the mobile terminal can also perform the process as shown in FIG. 8, in this embodiment, for example, the user swipes the service card and the web engine does not have the response right. Specifically, the following steps are included:
  • step 801 the JS code of the service card captures an event of the user sliding the service card, notifying the web engine of the event.
  • the event of the user sliding the service card can also be directly captured by the event processing module in the web engine.
  • step 802 the web engine escalates the event to the desktop process.
  • the event can be reported directly to the desktop process by the JS code of the service card.
  • step 803 the desktop process creates a new window, and sends the address information of the new resource file and the information of the window to the rendering process.
  • step 804 the rendering process obtains an HTML file according to the address information of the new resource file, and renders the HTML file to the newly created window. And can return rendering status information to the desktop process.
  • the mobile terminal can also perform the process as shown in FIG. 9, in which the user slides the service card and the web engine does not have the response right, for example. Specifically, the following steps are included:
  • step 901 the JS code of the service card captures an event of the user sliding the service card, notifying the web engine of the event.
  • the event of the user sliding the service card can also be directly captured by the event processing module in the web engine.
  • step 902 the web engine reports the event to the desktop process.
  • the event can be reported directly to the desktop process by the JS code of the service card.
  • step 903 the desktop process sends the address information of the new resource file and the information of the corresponding View to the rendering process.
  • step 904 the rendering process obtains an HTML file according to the address information of the new resource file, and renders the HTML file to the corresponding View. And can return rendering status information to the desktop process.
  • This embodiment is different from the embodiment shown in FIG. 8 in that after the user clicks on the link, the resource file corresponding to the link is also displayed in the original View, and the embodiment shown in FIG. 8 is displayed through a new window. .
  • the desktop process can create a new window according to the preset window size and location information.
  • the JS code can report the window size and/or location information to the desktop process when the event is reported, and the desktop process follows the received process. Window size and/or location information to create a new window.
  • the JS code can determine the size and/or position of the window suitable for displaying the HTML file according to at least one of the size of the HTML file corresponding to the link, the size and resolution of the screen of the mobile terminal, and the like.
  • the embodiments of the present invention are not limited.
  • the user can interact with the service card through the UI interface provided by the service card on the card-type desktop to obtain more service content, thereby further improving the user experience.
  • the service card provides multiple implementations that are displayed in the original View or displayed in a newly created window.
  • the implementation is flexible and rich.
  • the process shown in FIG. 4 can be implemented on the desktop.
  • the desktop card shown in FIG. 10 the desktop card includes four service cards, wherein the four service cards are "news webpage 1", “reading webpage 1", and "video webpage 1" provided by the provider. "and social networking page 1".
  • Each service card can update the content of the service card according to the flow shown in FIG. 6, assuming that the news service card in FIG. 10 updates the content of the service card every two hours, after the update. After the service card is formed, a card type desktop as shown in FIG. 11 is formed, and the content of the news service card becomes "news type web page 2".
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.
  • the above-described integrated unit implemented in the form of a software functional unit can be stored in a computer readable storage medium.
  • the above software functional unit is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform the methods of the various embodiments of the present invention. Part of the steps.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种卡片式桌面的实现方法、装置和系统，服务管理模块（31）将来自服务器端的卡片服务的资源地址发送给桌面模块（32）；所述桌面模块（32）在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图，将视图信息和所述资源地址发送给渲染模块（33）；所述渲染模块（33）从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。本片式桌面的实现方法、装置和系统能够摆脱模板的限制，降低系统消耗，提高桌面的稳定性。

Description

一种卡片式桌面的实现方法、装置和系统 【技术领域】
本发明涉及计算机应用技术领域，特别涉及一种卡片式桌面的实现方法、装置和系统。
【背景技术】
随着移动终端的大量普及和发展，移动终端已经不仅仅是用户进行通讯的工具，也逐渐成为获取信息的重要手段，大量商家也利用移动终端向用户发送自己的服务。目前通用的方式主要是以下两种：
第一种方式：用户首先在移动终端中安装应用安装包，然后商家将服务发送到具体的应用中，应用再通知操作系统在任务栏等中提示相关信息。用户点击相关信息进入具体的应用来查看详情。
第二种方式：商家通过短消息等发送一些简单的文本或者链接信息。
第一种方式存在的问题是需要提前预装对应的应用安装包，而且用户查看详情时需要跳转进入具体的应用。第二种方式存在的问题是推送的数据结构比较简单，体验比较简陋，不够友好，而且基本是一次性的。
针对上述问题，目前提出了一种卡片式桌面技术，桌面进程在桌面上以服务卡片的形式显示数据。使得桌面不再仅仅承当应用的入口，而是用户直接在桌面就能看到自己需要看到的信息。目前的卡片式桌面技术中，桌面进程把某个桌面区域用于卡片视图的显示区域，并定义好这个显示区域的显示模板，底层服务连接服务器端，获取需要显示的数据，然后桌面进程将数据填充到显示模板中，形成一个视图显示在桌面上。
然而这种方式存在的比较严重的问题是：需要为不同结构的卡片服务定制不同的模板，如果移动终端没有对应的模板是无法正常显示的，这就意味着有多少结构的卡片服务，就需要移动终端预置差不多同样数量的模板，消耗较大。
【发明内容】
有鉴于此，本发明提供了一种卡片式桌面的实现方法、装置和系统，以便于桌面在显示数据时，摆脱模板的限制，从而降低消耗。
具体技术方案如下：
本发明提供了一种卡片式桌面的实现方法，该方法包括：
服务管理模块将来自服务器端的卡片式桌面服务的资源地址发送给桌面模块；
所述桌面模块在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图，将视图信息和所述资源地址发送给渲染模块；
所述渲染模块从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。
根据本发明一优选实施方式，该方法还包括：
所述桌面模块将所述服务卡片的相关信息存入数据库，所述服务卡片的相关信息包括所述资源地址以及所述视图信息。
根据本发明一优选实施方式，该方法还包括：
当所述桌面模块和所述渲染模块启动后，所述桌面模块读取数据库中的服务卡片的相关信息，依据所述视图信息在桌面上创建视图，并将所述资源地址和所述视图信息发送给所述渲染模块；
所述渲染模块从服务器端获取所述资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到创建的视图。
根据本发明一优选实施方式，该方法还包括：
所述服务管理模块接收到包含所述资源地址的内容更新消息后，将所述内容更新消息发送给所述桌面模块；
所述桌面模块将所述内容更新消息发送给所述渲染模块；
所述渲染模块重新从服务器端获取所述资源地址对应的资源文件，将获取的 资源文件重新渲染到对应的视图。
根据本发明一优选实施方式，该方法还包括：
所述桌面模块获取到用户删除所述服务卡片的事件时，删除所述服务卡片对应的视图，该视图所占用的视图区域恢复成可使用。
根据本发明一优选实施方式，该方法还包括：
所述渲染模块获取到用户在所述服务卡片上的操作事件时，响应所述操作事件，或者将所述操作事件上报给所述桌面模块并由所述桌面模块响应所述操作事件；或者，
所述服务卡片上的JS代码获取到用户在所述服务卡片上的操作事件时，将所述操作事件上报给所述渲染模块，由所述渲染模块响应所述操作事件，或者将所述操作事件上报给所述桌面模块并由所述桌面模块响应所述操作事件。
根据本发明一优选实施方式，所述渲染模块响应所述操作事件包括：
所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件，将获取的资源文件渲染到所述服务卡片对应的视图；或者，
所述渲染模块将所述操作事件上报给所述桌面模块，所述桌面模块在桌面上新建一个窗口，将该窗口的信息发送给所述渲染模块；所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件，依据所述窗口的信息将获取的资源文件渲染到新建的窗口。
根据本发明一优选实施方式，所述桌面模块响应所述操作事件包括：
所述桌面模块将所述操作事件所请求资源地址和所述服务卡片对应的视图信息发送给所述渲染模块，所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到对应视图；或者，
所述桌面模块在桌面新建一个窗口，将所述操作事件所请求资源地址和新建的窗口信息发送给所述渲染模块，所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述窗口信息将获取的资源文件渲染到新建的窗口。
根据本发明一优选实施方式，所述新建的窗口覆盖所述桌面上的全部或部分视图，或者，所述窗口在所述桌面的固定区域，该固定区域与所述桌面上的视图不冲突。
根据本发明一优选实施方式，所述JS代码在上报所述操作事件给所述桌面模块时，进一步上报窗口的大小和/或位置信息给所述桌面模块；
所述桌面模块依据所述窗口的大小和/或位置信息执行所述在桌面上创建一个窗口。
根据本发明一优选实施方式，所述桌面模块和所述渲染模块之间采用进程间通讯的方式进行信息交互。
根据本发明一优选实施方式，所述渲染模块调用web引擎执行所述渲染的操作。
本发明还提供了一种卡片式桌面的实现装置，该装置包括：服务管理模块、桌面模块和渲染模块；
所述服务管理模块，用于将来自服务器端的卡片式桌面服务的资源地址发送给所述桌面模块；
所述桌面模块，用于接收到所述资源地址后，在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图，将视图信息和所述资源地址发送给所述渲染模块；
所述渲染模块，用于接收到所述桌面模块发送的资源地址和视图信息后，从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。
根据本发明一优选实施方式，所述桌面模块，还用于将所述服务卡片的相关信息存入数据库，所述服务卡片的相关信息包括所述资源地址以及所述视图信息。
根据本发明一优选实施方式，所述桌面模块，还用于在所述桌面模块和所述渲染模块启动后，读取数据库中的服务卡片的相关信息，依据所述视图信息 在桌面上创建视图，并将所述资源地址和所述视图信息发送给所述渲染模块。
根据本发明一优选实施方式，所述服务管理模块，还用于接收到包含所述资源地址的内容更新消息后，将所述内容更新消息发送给所述桌面模块；
所述桌面模块，还用于将所述内容更新消息发送给所述渲染模块；
所述渲染模块，还用于重新从服务器端获取所述资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
根据本发明一优选实施方式，所述桌面模块，还用于获取到用户删除所述服务卡片的事件时，删除所述服务卡片对应的视图，该视图所占用的视图区域恢复成可使用。
根据本发明一优选实施方式，所述渲染模块，还用于获取到用户在所述服务卡片上的操作事件时，响应所述操作事件，或者将所述操作事件上报给所述桌面模块，由所述桌面模块响应所述操作事件；或者，
所述渲染模块，还用于获取所述服务卡片上的JS代码上报的操作事件，并响应所述操作事件；或者，
所述桌面模块，还用于获取所述服务卡片上的JS代码上报的操作事件，并响应所述操作事件。
根据本发明一优选实施方式，所述渲染模块在响应所述操作事件时，具体执行：
从服务器端获取所述操作事件所请求资源地址对应的资源文件，将获取的资源文件渲染到所述服务卡片对应的视图；或者，
将所述操作事件上报给所述桌面模块，接收到所述桌面模块在桌面上新建一个窗口后发送的该窗口的信息后，从服务器端获取所述操作事件所请求资源地址对应的资源文件，依据所述窗口的信息将获取的资源文件渲染到新建的窗口。
根据本发明一优选实施方式，所述桌面模块在响应所述操作事件时，具体执行：将所述操作事件所请求资源地址和所述服务卡片对应的视图信息发送给所述渲染模块；或者，
所述桌面模块在响应所述操作事件时，具体执行：在桌面新建一个窗口，将所述操作事件所请求资源地址和新建的窗口信息发送给所述渲染模块；所述渲染模块，还用于从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述窗口信息将获取的资源文件渲染到新建的窗口。
根据本发明一优选实施方式，所述桌面模块新建的窗口覆盖所述桌面上的全部或部分视图，或者，所述桌面模块在所述桌面的固定区域新建窗口，该固定区域与所述桌面上的视图不冲突。
根据本发明一优选实施方式，所述桌面模块，还用于接收所述JS代码上报所述操作事件时进一步上报的窗口的大小和/或位置信息，依据所述窗口的大小和/或位置信息执行所述在桌面上创建一个窗口的操作。
根据本发明一优选实施方式，所述桌面模块和所述渲染模块之间采用进程间通讯的方式进行信息交互。
根据本发明一优选实施方式，所述渲染模块调用web引擎执行所述渲染的操作。
本发明还提供了一种实现卡片式桌面的系统，该系统包括：管理服务器和移动终端；
所述管理服务器，用于获取卡片服务的资源地址，并向所述移动终端发送所述卡片服务的资源地址；
所述移动终端包括上述装置。
根据本发明一优选实施方式，所述提供商服务器，还用于向所述管理服务器发送包含所述资源地址的内容更新消息；
所述管理服务器，还用于向所述移动终端发送所述内容更新消息。
本发明还提供了一种卡片式桌面的实现方法，该方法包括：
接收来自服务器端的卡片式桌面服务的资源地址；
在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图；
从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该 资源文件渲染到所述视图。
根据本发明一优选实施方式，该方法还包括：
接收到包含所述资源地址的内容更新消息后，重新从服务器端获取所述资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
根据本发明一优选实施方式，该方法还包括：
获取到用户删除所述服务卡片的事件时，删除所述服务卡片对应的视图，该视图所占用的视图区域恢复成可使用。
根据本发明一优选实施方式，该方法还包括：
获取用户在所述服务卡片上的操作事件；
从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到对应的视图，或者在桌面新建一个窗口，将获取的资源文件渲染到新建的窗口。
由以上技术方案可以看出，本发明采用渲染模块对资源文件进行渲染的方式，不再依赖任何模板就可以实现任意形式资源内容的加载显示，降低了存储模板所带来的消耗。
【附图说明】
图1为本发明实施例所基于的系统架构结构图；
图2为本发明实施例提供的一个卡片式桌面的布局实例图；
图3为本发明实施例提供的主要方法流程图；
图4为本发明实施例提供的创建新的卡片服务的流程图；
图5为本发明实施例提供的移动终端重新启动时建立卡片服务的流程图；
图6为本发明实施例提供的更新服务卡片的内容的流程图；
图7为本发明实施例提供的第一种响应用户与服务卡片交互事件的流程图；
图8为本发明实施例提供的第二种响应用户与服务卡片交互事件的流程 图；
图9为本发明实施例提供的第三种响应用户与服务卡片交互事件的流程图；
图10为本发明实施例提供的桌面式卡片的实例图；
图11为图10所示桌面式卡片更新后的实例图；
图12为图11所示的桌面式卡片在响应用户操作事件后形成的一种桌面实例图；
图13为图11所示的桌面式卡片在响应用户操作事件后形成的另一种桌面实例图。
【具体实施方式】
为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。
为了方便对本发明实施例的理解，首先对本发明实施例所基于的系统架构进行描述。如图1中所示，本发明实施例所基于的系统架构主要包括提供商服务器10、管理服务器20以及移动终端30。其中，提供商服务器10也可以独立于该系统，即该系统架构包括管理服务器20以及移动终端30。
可选地，该移动终端30中可以包括卡片式桌面的实现装置。
可选地，该卡片式桌面的实现装置可以进一步包括服务管理模块31、桌面模块32和渲染模块33。
如果某提供商需要进行针对移动终端的资源推送，这里的资源可以是文本、视频、图片等，可以通过提供商服务器10将需要发送的资源地址发送给管理服务器20，其中的资源地址可以采用URL(Uniform Resource Locator，统一资源定位符)，后续实施例中均采用URL进行描述。这里管理服务器20可以仅向具有合作关系的提供商服务器10开放接口。
管理服务器20将该URL发送给移动终端30中的服务管理模块31。在本发明实施例中，移动终端30的用户如果希望获得卡片式桌面的卡片服务， 可以预先向管理服务器20注册并订阅卡片服务，管理服务器20向注册并订阅卡片服务的移动终端发送对应卡片服务的URL。例如，某用户订阅了某提供商的读书服务，则如果该提供商发送URL时，管理服务器20将该URL发送给该用户的移动终端30中的服务管理模块31。
移动终端30中服务管理模块31将该URL发送给桌面模块32。该桌面模块32获取到该URL后，在桌面上创建一个可使用的视图区域，该视图区域用以显示该URL对应的服务卡片。这里可使用的视图区域可以是桌面上未被占用的视图区域，也可以是桌面上在预设范围内未被占用的试图区域。然后桌面模块32在该视图区域创建该服务卡片对应的View(视图)，将该View的信息以及URL提供给渲染模块33。其中View的信息可以采用View的句柄，即桌面模块32将创建的View的句柄传递给渲染模块33。
上述服务管理模块31和桌面模块32在移动终端30中可以以进程的形式实现，即分别体现为服务管理进程和桌面进程。
在桌面上可以按照预设的卡片式桌面的布局方式来创建视图区域，举一个例子，如图2中所示，桌面模块32可以按照图2中所示的布局方式来创建服务卡片的视图区域，如果存在未被占用的视图区域，则将服务卡片的资源文件渲染到该视图区域上的视图中，桌面上最多可以存在4个服务卡片。当然图2中所示仅仅为一种布局的实例，本发明实施例并不对卡片式桌面的布局进行限制。
渲染模块33根据桌面模块32提供的URL获取对应的资源文件，即到提供商服务器10获取该URL对应的资源文件，该资源文件通常为HTML(HyperText Mark-up Language，超文本标记语言)文件，但也可以是视频文件、图片等多媒体文件，当然多媒体文件也可以嵌入HTML文件中实现。
渲染模块33得到资源文件后，根据桌面模块32提供的View的信息将该资源文件渲染到对应的View中，这样该资源文件就能够在上述视图区域中显示，在桌面上就体现为一个常驻桌面的服务卡片。另外，桌面模块32可以将服务卡片的相关信息存入数据库，供移动终端30在启动时能够自动读 取该相关内容并显示对应的服务卡片。其中服务卡片的相关信息可以是URL信息和对应的View的信息，该View的信息可以包括View的句柄、View的位置信息等。该渲染模块33可以采用web引擎的方式实现，即调用web引擎执行渲染的操作。
在本发明实施例中，上述渲染模块33可以启用一个渲染进程对所有的服务卡片进行渲染，也可以针对各服务卡片分别启用渲染进程进行渲染(这种情况下服务卡片和渲染进程是一对一的关系)。
渲染进程在对HTML文件进行渲染时，主要流程包括：解析HTML文件，将HTML文档转换为一棵DOM树，然后进行样式解析，在DOM树上进行颜色、尺寸等属性的添加形成渲染树(render tree)。然后利用buffer(缓冲器)对渲染树的每个节点进行绘制，将buffer中绘制的内容填充至服务卡片对应的View。在本发明实施例中，桌面模块32与渲染进模块33对buffer采用跨进程的处理方式，即桌面模块32负责buffer的管理，在渲染模块33负责利用buffer进行资源文件的渲染。
当所有服务卡片共用一个渲染进程时，每个服务卡片对应一个buffer，该共用的渲染进程分别利用每个服务卡片对应的buffer对服务卡片对应的View进行渲染。这种方式优选应用于页面复杂度比较低的情况，比较节省内存。
当各服务卡片分别对应渲染进程时，所有服务卡片共享一个buffer，渲染模块获取到资源文件后，利用该共享的buffer以及对应的渲染进程对资源文件进行渲染。这种情况优选应用于页面复杂度高的情况，处理能力较强。
一旦服务卡片创建完成，如果移动终端30重新启动，则桌面模块32读取数据库中的URL信息和View的信息，则依据View的信息在桌面上创建View，并将该URL信息View的信息提供给渲染模块33，由渲染模块33获取该URL对应的资源文件(即向提供商服务器10请求并获取该URL对应的资源文件)后，将该资源文件渲染到对应的View。
另外，还可能存在这样的情况，即提供商需要更新服务卡片的内容，该 更新可以是周期性的，也可以是偶然性的。那么提供商服务器10会将包含URL的内容更新消息发送给管理服务器20，管理服务器20再发送给移动终端30的服务管理模块31，服务管理模块31再发送给桌面模块32，桌面模块32再发送给渲染模块33，渲染模块33重新获取该URL对应的资源文件，并将该资源文件重新渲染到对应的View。
上面已经提及，服务卡片常驻于桌面，除非用户手动删除。即桌面模块32获取到用户删除服务卡片的事件时，删除该服务卡片对应的View，此时该View所占用的视图区域恢复成可使用，即未被占用。
另外，服务卡片常驻于桌面，用户可以通过UI接口与服务卡片进行交互：当用户在服务卡片上进行操作时，则渲染模块33或该服务卡片上的JS代码可以捕捉到在该服务卡片上的操作，从而直接响应该操作和/或上报给桌面模块32，由桌面模块32响应该操作。
大多数情况下，用户通过UI接口与服务卡片的交互为新的资源文件的请求，例如用户通过点击服务卡片上资源文件中的链接以请求该链接对应的资源文件，再例如服务卡片对应的View由于显示区域有限，通常仅显示一个整体页面的部分内容，其他内容需要用户通过滑动、点击“显示剩余页面内容”的按钮、或者滑动滑块的方式来请求被未显示的剩余资源文件。无论哪种方式，一旦用户触发了请求新的资源文件的事件，服务卡片的JS代码或者渲染模块33捕捉到该事件，如果JS代码捕捉到该事件会通知渲染模块33或者桌面模块32。
渲染模块33获取到用户触发的事件时，如果该事件在该渲染模块33的响应权限之内，则直接由渲染模块33从提供商服务器10获取该事件所请求资源地址对应的资源文件，并将获取的资源文件渲染到对应的View中。
渲染模块33获取到用户触发的事件时，如果该事件在该渲染模块33的响应权限之外，则可以将该事件上报给桌面模块32。桌面模块32将该事件所请求资源地址和对应View的信息提供给渲染模块33，由渲染模块33从提供商服务器10获取资源文件后，将新的资源文件渲染到对应的View。另外， 在这种情况下，桌面模块32也可以新建一个窗口，然后将该事件所请求地址信息和对应的窗口信息提供给渲染模块33，由渲染模块33从服务器端获取该事件所请求地址对应的资源文件后，将获取的资源文件渲染到新建的窗口。
如果JS代码将捕捉到的事件会通知给桌面模块32，则桌面模块32可以将该事件所请求地址和View的信息发送给渲染模块33，由渲染模块33从服务器端获取该事件所请求地址对应的资源文件后，将获取的资源文件渲染到对应的View中。或者，桌面模块32新建一个窗口，将该事件所请求地址和新建的窗口信息发送给渲染模块33，由渲染模块33从服务器端获取该事件所请求地址对应的资源文件后，将获取的资源文件渲染到新建的窗口。
桌面模块32在新建窗口时，可以采用多种方式，例如新建一个大的窗口，该窗口的位置可能覆盖掉卡片式桌面上的全部或者部分View。再例如，该窗口可以在桌面的一个固定区域，该固定区域与卡片式桌面上的View不会冲突。
对于移动终端而言，具体执行了如图3所示的创建新的卡片服务流程，具体包括以下步骤：
在301中，接收来自服务器端的卡片式桌面服务的资源地址。
在302中，在桌面上创建一个可使用的视图区域，该视图区域用以显示上述资源地址对应的服务卡片，在该视图区域创建该服务卡片对应的视图。
在303中，从服务器端获取该资源地址对应的资源文件，并依据上述视图信息将该资源文件渲染到对应的视图。
在此基础上，如果接收到包含上述资源地址的内容更新消息后，重新从服务器端获取该资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
获取到用户删除该服务卡片的事件时，删除该服务卡片对应的视图，将该视图所占用的视图区域恢复成可使用。
获取到用户在服务卡片上的操作事件时，从服务器端获取该操作事件所请求资源地址对应的资源文件后，依据视图信息将获取的资源文件渲染到对 应的视图，或者在桌面新建一个窗口，将获取的资源文件渲染到新建的窗口。
当采用图1所示的系统架构实现上述创建新的卡片服务流程时，其过程可以如图4中所示，在图4所示的实施例中，服务管理模块和桌面模块以进程的方式实现，渲染模块以web引擎的方式实现，具体包括以下步骤：
在步骤401中，服务管理进程将来自管理服务器的URL发送给桌面进程。
在步骤402中，桌面进程在桌面上创建一个尚未被占用的视图区域，该视图区域用以显示该URL对应的服务卡片，在该视图区域上创建该服务卡片对应的View。
在步骤403中，桌面进程将该URL和View的句柄提供给web引擎。
在步骤404中，web引擎获取该URL对应的HTML文件，根据桌面进程提供的View的句柄将该HTML文件渲染到对应的View，并将URL信息、View的句柄和位置信息存储于数据库中。
另外，web引擎可以将渲染过程中的状态信息返回给桌面进程。
上述过程中，服务管理进程、桌面进程和web引擎之间采用进程间通讯的方式进行信息交互。进程间通讯的方式可以包括但不限于：广播的方式、文件映射方式、共享内存方式、共享动态链接库的方式等等。也就是说，服务管理进程通过进程间通讯的方式将URL发送给桌面进程，桌面进程通过进程间通讯的方式将URL和View的句柄提供给web引擎，web引擎通过进程间通讯的方式返回渲染状态信息。
从上述过程中可见，本发明实施例采用渲染的方式，不再依赖任何模板，可以实现任何形式资源内容的加载显示，也不用再存储多种模板，降低了消耗。另外，资源文件的获取和渲染不再由桌面进程执行，而由另一个进程web引擎执行，服务卡片的渲染不会影响桌面进程，也不会给桌面进程带来负担，从而降低了消耗，提高了稳定性。
另外，移动终端不用安装具体的应用，就能够直接在桌面上看到提供商服务器推送的资源文件，节省了用户的操作成本，增强了用户体验。
如果移动终端重新启动，则可以按照如图5中所示的流程进行启动，具体包括以下步骤：
在步骤501中，桌面进程和渲染进程启动后，桌面进程读取数据库中的URL信息和View的信息，依据View的信息在桌面上创建View。
由于View的信息中包含View的句柄和View的位置信息，依据View的位置信息以及预设的卡片式桌面的布局方式，桌面进程创建视图区域，在该视图区域上创建View。
在步骤502中，桌面进程将URL和View的信息提供给web引擎。
在步骤503中，web引擎获取URL对应的HTML文件，即向提供商服务器请求并获取该URL对应的资源文件。
在步骤504中，web引擎将获取的HTML文件渲染到对应的View。并可以将渲染的状态信息返回给桌面进程。
通过该过程，当移动终端启动时，就可以自动进行卡片式桌面的显示，用户就能够从桌面上直接看到订制的服务卡片。
对于提供商需要更新服务卡片的内容时，移动终端可以执行如图6所示的更新流程，如图6中所示，该流程具体包括以下步骤：
在步骤601中，服务管理进程接收到包含URL的内容更新消息时，将该消息发送给桌面进程。
在步骤602中，桌面进程将该消息发送给web引擎。
在步骤603中，web引擎依据消息中包含的URL重新获取HTML文件，将该HTML文件重新渲染到对应的View。并可以将渲染的状态信息返回给桌面进程。
可见，资源文件需要更新时，不需要过多的长连接和轮询的功耗，只需要按照图6中所述的流程发送内容更新消息即可。
当用户通过服务卡片提供的UI接口与服务卡片进行交互时，移动终端可以执行如图7中所示的流程，在该实施例中以用户点击服务卡片上的链接且web引擎具备响应权限为例，具体包括以下步骤：
在步骤701中，服务卡片的JS代码捕捉到用户点击服务卡片上的链接的事件，将该事件通知给web引擎。
在本步骤中，也可以由web引擎中的事件处理模块直接捕捉用户点击服务卡片上的链接的事件。
在步骤702中，web引擎从提供商服务器获取该链接对应的HTML文件，将该HTML文件渲染到该服务卡片对应的View。
当用户通过服务卡片提供的UI接口与服务卡片进行交互时，移动终端还可以执行如图8中所示的流程，在该实施例中以用户滑动服务卡片且web引擎不具备响应权限为例，具体包括以下步骤：
在步骤801中，服务卡片的JS代码捕捉到用户滑动服务卡片的事件，将该事件通知给web引擎。
在本步骤中，也可以由web引擎中的事件处理模块直接捕捉用户滑动服务卡片的事件。
在步骤802中，web引擎将该事件上报给桌面进程。
另外，也可以直接由服务卡片的JS代码将事件上报给桌面进程。
在步骤803中，桌面进程新建一个窗口，将新的资源文件的地址信息和窗口的信息发送给渲染进程。
在步骤804中，渲染进程依据新的资源文件的地址信息获取HTML文件，将该HTML文件渲染到新建的窗口。并可以向桌面进程返回渲染状态信息。
当用户通过服务卡片提供的UI接口与服务卡片进行交互时，移动终端还可以执行如图9中所示的流程，在该实施例中以用户滑动服务卡片且web引擎不具备响应权限为例，具体包括以下步骤：
在步骤901中，服务卡片的JS代码捕捉到用户滑动服务卡片的事件，将该事件通知给web引擎。
在本步骤中，也可以由web引擎中的事件处理模块直接捕捉用户滑动服务卡片的事件。
在步骤902中，web引擎将该事件上报给桌面进程。
另外，也可以直接由服务卡片的JS代码将事件上报给桌面进程。
在步骤903中，桌面进程将新的资源文件的地址信息和对应View的信息发送给渲染进程。
在步骤904中，渲染进程依据新的资源文件的地址信息获取HTML文件，将该HTML文件渲染到对应View。并可以向桌面进程返回渲染状态信息。
该实施例与图8中所示实施例不同的是，用户点击链接后，该链接对应的资源文件还在原来的View进行显示，而图8所示的实施例是通过一个新的窗口进行显示。
在上述图8所示的流程中，桌面进程可以按照预先设置的窗口大小和位置信息，来新建窗口。
另外，在上述图8所示流程中，如果JS代码直接将事件上报给桌面进程，则JS代码在上报事件时，可以将窗口大小和/或位置信息上报给桌面进程，桌面进程按照接收到的窗口大小和/或位置信息新建窗口。这种方式下，JS代码可以根据链接对应的HTML文件的大小、移动终端屏幕的大小和分辨率等信息中的至少一种确定出适合显示该HTML文件的窗口大小和/或位置，具体如何确定本发明实施例不加以限制。
由图7至图9所示的流程可以看出，用户在卡片式桌面上，可以通过服务卡片提供的UI接口与服务卡片进行交互，获取更多的服务内容，更进一步提高了用户体验。另外，还提供了在原来的View中显示，或者在新建的窗口中显示的多种实现方式，实现方式灵活且丰富。
举一个效果的实例，如果某用户订制了新闻类的服务卡片、读书类的服务卡片、视频类的服务卡片以及社交类的服务卡片，则通过图4所示流程，可以在桌面上实现如图10所示的桌面式卡片，该桌面式卡片包含四个服务卡片，这四个服务卡片中分别是提供商提供的“新闻类网页1”、“读书类网页1”、“视频类网页1”和“社交类网页1”。
每一个服务卡片都能够按照图6中所示的流程更新服务卡片的内容，假设图10中的新闻类服务卡片每隔两个小时就会更新服务卡片的内容，更新后 服务卡片后形成如图11中所示的卡片式桌面，新闻类服务卡片的内容变为“新闻类网页2”。
假设用户在图11中所示的卡片式桌面上点击了“新闻类网页2”中的某个具体新闻的链接，则可以按照图8所示的流程执行，将该链接对应的“新闻类网页3”显示在新建的窗口中，如图12中所示。也可以按照图7或图9中所示的流程执行，将该链接对应的“新闻类网页3”显示在原来的View中，如图13中所示。
在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (30)

  1. 一种卡片式桌面的实现方法，其特征在于，该方法包括：
    服务管理模块将来自服务器端的卡片式桌面服务的资源地址发送给桌面模块；
    所述桌面模块在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图，将视图信息和所述资源地址发送给渲染模块；
    所述渲染模块从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。
  2. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    所述桌面模块将所述服务卡片的相关信息存入数据库，所述服务卡片的相关信息包括所述资源地址以及所述视图信息。
  3. 根据权利要求2所述的方法，其特征在于，该方法还包括：
    当所述桌面模块和所述渲染模块启动后，所述桌面模块读取数据库中的服务卡片的相关信息，依据所述视图信息在桌面上创建视图，并将所述资源地址和所述视图信息发送给所述渲染模块；
    所述渲染模块从服务器端获取所述资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到创建的视图。
  4. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    所述服务管理模块接收到包含所述资源地址的内容更新消息后，将所述内容更新消息发送给所述桌面模块；
    所述桌面模块将所述内容更新消息发送给所述渲染模块；
    所述渲染模块重新从服务器端获取所述资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
  5. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    所述桌面模块获取到用户删除所述服务卡片的事件时，删除所述服务卡片对 应的视图，该视图所占用的视图区域恢复成可使用。
  6. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    所述渲染模块获取到用户在所述服务卡片上的操作事件时，响应所述操作事件，或者将所述操作事件上报给所述桌面模块并由所述桌面模块响应所述操作事件；或者，
    所述服务卡片上的JS代码获取到用户在所述服务卡片上的操作事件时，将所述操作事件上报给所述渲染模块，由所述渲染模块响应所述操作事件，或者将所述操作事件上报给所述桌面模块并由所述桌面模块响应所述操作事件。
  7. 根据权利要求6所述的方法，其特征在于，所述渲染模块响应所述操作事件包括：
    所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件，将获取的资源文件渲染到所述服务卡片对应的视图；或者，
    所述渲染模块将所述操作事件上报给所述桌面模块，所述桌面模块在桌面上新建一个窗口，将该窗口的信息发送给所述渲染模块；所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件，依据所述窗口的信息将获取的资源文件渲染到新建的窗口。
  8. 根据权利要求6所述的方法，其特征在于，所述桌面模块响应所述操作事件包括：
    所述桌面模块将所述操作事件所请求资源地址和所述服务卡片对应的视图信息发送给所述渲染模块，所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到对应视图；或者，
    所述桌面模块在桌面新建一个窗口，将所述操作事件所请求资源地址和新建的窗口信息发送给所述渲染模块，所述渲染模块从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述窗口信息将获取的资源文件渲染到新建的窗口。
  9. 根据权利要求7或8所述的方法，其特征在于，所述新建的窗口覆盖所 述桌面上的全部或部分视图，或者，所述窗口在所述桌面的固定区域，该固定区域与所述桌面上的视图不冲突。
  10. 根据权利要求8所述的方法，其特征在于，所述JS代码在上报所述操作事件给所述桌面模块时，进一步上报窗口的大小和/或位置信息给所述桌面模块；
    所述桌面模块依据所述窗口的大小和/或位置信息执行所述在桌面上创建一个窗口。
  11. 根据权利要求1、3、4、6、7或8所述的方法，其特征在于，所述桌面模块和所述渲染模块之间采用进程间通讯的方式进行信息交互。
  12. 根据权利要求1、3、4、6、7或8所述的方法，其特征在于，所述渲染模块调用web引擎执行所述渲染的操作。
  13. 一种卡片式桌面的实现装置，其特征在于，该装置包括：服务管理模块、桌面模块和渲染模块；
    所述服务管理模块，用于将来自服务器端的卡片式桌面服务的资源地址发送给所述桌面模块；
    所述桌面模块，用于接收到所述资源地址后，在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图，将视图信息和所述资源地址发送给所述渲染模块；
    所述渲染模块，用于接收到所述桌面模块发送的资源地址和视图信息后，从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。
  14. 根据权利要求13所述的装置，其特征在于，所述桌面模块，还用于将所述服务卡片的相关信息存入数据库，所述服务卡片的相关信息包括所述资源地址以及所述视图信息。
  15. 根据权利要求14所述的装置，其特征在于，所述桌面模块，还用于在所述桌面模块和所述渲染模块启动后，读取数据库中的服务卡片的相关信息， 依据所述视图信息在桌面上创建视图，并将所述资源地址和所述视图信息发送给所述渲染模块。
  16. 根据权利要求13所述的装置，其特征在于，所述服务管理模块，还用于接收到包含所述资源地址的内容更新消息后，将所述内容更新消息发送给所述桌面模块；
    所述桌面模块，还用于将所述内容更新消息发送给所述渲染模块；
    所述渲染模块，还用于重新从服务器端获取所述资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
  17. 根据权利要求13所述的装置，其特征在于，所述桌面模块，还用于获取到用户删除所述服务卡片的事件时，删除所述服务卡片对应的视图，该视图所占用的视图区域恢复成可使用。
  18. 根据权利要求13所述的装置，其特征在于，所述渲染模块，还用于获取到用户在所述服务卡片上的操作事件时，响应所述操作事件，或者将所述操作事件上报给所述桌面模块，由所述桌面模块响应所述操作事件；或者，
    所述渲染模块，还用于获取所述服务卡片上的JS代码上报的操作事件，并响应所述操作事件；或者，
    所述桌面模块，还用于获取所述服务卡片上的JS代码上报的操作事件，并响应所述操作事件。
  19. 根据权利要求18所述的装置，其特征在于，所述渲染模块在响应所述操作事件时，具体执行：
    从服务器端获取所述操作事件所请求资源地址对应的资源文件，将获取的资源文件渲染到所述服务卡片对应的视图；或者，
    将所述操作事件上报给所述桌面模块，接收到所述桌面模块在桌面上新建一个窗口后发送的该窗口的信息后，从服务器端获取所述操作事件所请求资源地址对应的资源文件，依据所述窗口的信息将获取的资源文件渲染到新建的窗口。
  20. 根据权利要求18所述的装置，其特征在于，所述桌面模块在响应所述 操作事件时，具体执行：将所述操作事件所请求资源地址和所述服务卡片对应的视图信息发送给所述渲染模块；或者，
    所述桌面模块在响应所述操作事件时，具体执行：在桌面新建一个窗口，将所述操作事件所请求资源地址和新建的窗口信息发送给所述渲染模块；所述渲染模块，还用于从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述窗口信息将获取的资源文件渲染到新建的窗口。
  21. 根据权利要求19或20所述的装置，其特征在于，所述桌面模块新建的窗口覆盖所述桌面上的全部或部分视图，或者，所述桌面模块在所述桌面的固定区域新建窗口，该固定区域与所述桌面上的视图不冲突。
  22. 根据权利要求20所述的装置，其特征在于，所述桌面模块，还用于接收所述JS代码上报所述操作事件时进一步上报的窗口的大小和/或位置信息，依据所述窗口的大小和/或位置信息执行所述在桌面上创建一个窗口的操作。
  23. 根据权利要求13、15、16、18、19或20所述的装置，其特征在于，所述桌面模块和所述渲染模块之间采用进程间通讯的方式进行信息交互。
  24. 根据权利要求13、15、16、18、19或20所述的装置，其特征在于，所述渲染模块调用web引擎执行所述渲染的操作。
  25. 一种实现卡片式桌面的系统，其特征在于，该系统包括：管理服务器和移动终端；
    所述管理服务器，用于获取卡片服务的资源地址，并向所述移动终端发送所述卡片服务的资源地址；
    所述移动终端包括如权利要求13至20中任一权项或者权利要求22所述的装置。
  26. 根据权利要求25所述的系统，其特征在于，当所述移动终端包括如权利要求16所述的装置时，所述提供商服务器，还用于向所述管理服务器发送包含所述资源地址的内容更新消息；
    所述管理服务器，还用于向所述移动终端发送所述内容更新消息。
  27. 一种卡片式桌面的实现方法，其特征在于，该方法包括：
    接收来自服务器端的卡片式桌面服务的资源地址；
    在桌面上创建一个可使用的视图区域，该视图区域用以显示所述资源地址对应的服务卡片，在该视图区域创建所述服务卡片对应的视图；
    从服务器端获取所述资源地址对应的资源文件，并依据所述视图信息将该资源文件渲染到所述视图。
  28. 根据权利要求27所述的方法，其特征在于，该方法还包括：
    接收到包含所述资源地址的内容更新消息后，重新从服务器端获取所述资源地址对应的资源文件，将获取的资源文件重新渲染到对应的视图。
  29. 根据权利要求27所述的方法，其特征在于，该方法还包括：
    获取到用户删除所述服务卡片的事件时，删除所述服务卡片对应的视图，该视图所占用的视图区域恢复成可使用。
  30. 根据权利要求27所述的方法，其特征在于，该方法还包括：
    获取用户在所述服务卡片上的操作事件；
    从服务器端获取所述操作事件所请求资源地址对应的资源文件后，依据所述视图信息将获取的资源文件渲染到对应的视图，或者在桌面新建一个窗口，将获取的资源文件渲染到新建的窗口。
PCT/CN2015/098258 2014-12-31 2015-12-22 一种卡片式桌面的实现方法、装置和系统 Ceased WO2016107465A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/639,677 US20170302747A1 (en) 2014-12-31 2017-06-30 Card-type desktop implementation method, apparatus, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410848894.XA CN105808277A (zh) 2014-12-31 2014-12-31 一种卡片式桌面的实现方法、装置和系统
CN201410848894.X 2014-12-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/639,677 Continuation US20170302747A1 (en) 2014-12-31 2017-06-30 Card-type desktop implementation method, apparatus, and system

Publications (1)

Publication Number Publication Date
WO2016107465A1 true WO2016107465A1 (zh) 2016-07-07

Family

ID=56284243

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/098258 Ceased WO2016107465A1 (zh) 2014-12-31 2015-12-22 一种卡片式桌面的实现方法、装置和系统

Country Status (3)

Country Link
US (1) US20170302747A1 (zh)
CN (1) CN105808277A (zh)
WO (1) WO2016107465A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112000416A (zh) * 2020-08-28 2020-11-27 贝壳技术有限公司 卡片视图生成方法、装置及计算机可读存储介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018112928A1 (zh) * 2016-12-23 2018-06-28 北京金山安全软件有限公司 一种信息展示方法、装置及终端设备
CN110874198B (zh) * 2018-08-31 2023-08-22 成都鼎桥通信技术有限公司 一种门户信息展示方法和装置
CN109684008B (zh) * 2018-12-19 2022-03-29 Oppo广东移动通信有限公司 卡片渲染方法、装置、终端及计算机可读存储介质
US11200294B2 (en) * 2019-03-20 2021-12-14 Hisense Visual Technology Co., Ltd. Page updating method and display device
CN110300178B (zh) * 2019-07-02 2021-07-20 迈普通信技术股份有限公司 通信设备、业务卡、主控卡、文件访问方法及装置
CN112559098B (zh) 2019-09-26 2022-04-26 华为技术有限公司 一种卡片渲染方法及电子设备
CN113741781B (zh) * 2021-06-15 2022-06-28 荣耀终端有限公司 通知显示方法和电子设备
CN114374726B (zh) * 2022-01-07 2024-10-11 阿里巴巴（中国）有限公司 一种云桌面处理方法及系统
CN114138146B (zh) * 2022-01-29 2022-07-26 荣耀终端有限公司 一种卡片推荐方法及电子设备
CN120029978A (zh) * 2022-10-14 2025-05-23 荣耀终端股份有限公司 文件管理方法、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477557A (zh) * 2009-01-13 2009-07-08 苏州智讯科技有限公司 一种理解用户互联网浏览行为的媒体展现平台
US20120236109A1 (en) * 2011-03-17 2012-09-20 Hon Hai Precision Industry Co., Ltd. Method for sharing resource of a videoconference using a video conferencing system
CN104077426A (zh) * 2014-06-30 2014-10-01 北京金山安全软件有限公司 数据记录方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9892196B2 (en) * 2006-04-21 2018-02-13 Excalibur Ip, Llc Method and system for entering search queries
US8365082B2 (en) * 2008-10-23 2013-01-29 Savnor Technologies Llc Universal content referencing, packaging, distribution system, and a tool for customizing web content
US9600447B2 (en) * 2008-12-01 2017-03-21 Adobe Systems Incorporated Methods and systems for page layout using a virtual art director
CN102841901B (zh) * 2011-06-23 2015-09-09 腾讯科技（深圳）有限公司 一种网页显示的方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477557A (zh) * 2009-01-13 2009-07-08 苏州智讯科技有限公司 一种理解用户互联网浏览行为的媒体展现平台
US20120236109A1 (en) * 2011-03-17 2012-09-20 Hon Hai Precision Industry Co., Ltd. Method for sharing resource of a videoconference using a video conferencing system
CN104077426A (zh) * 2014-06-30 2014-10-01 北京金山安全软件有限公司 数据记录方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112000416A (zh) * 2020-08-28 2020-11-27 贝壳技术有限公司 卡片视图生成方法、装置及计算机可读存储介质
CN112000416B (zh) * 2020-08-28 2024-01-05 贝壳技术有限公司 卡片视图生成方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
US20170302747A1 (en) 2017-10-19
CN105808277A (zh) 2016-07-27

Similar Documents

Publication Publication Date Title
WO2016107465A1 (zh) 一种卡片式桌面的实现方法、装置和系统
CN108052334B (zh) 页面跳转方法、装置、计算机设备和存储介质
US8156418B2 (en) Image acquisition from dynamic content for delivery to network-enabled static display devices
US20170300459A1 (en) Card-type desktop implementation method and apparatus
US9071651B2 (en) Dynamic content delivery to network-enabled static display device
US9122377B2 (en) Method and system for interworking plurality of applications
CN104426925B (zh) 网页资源获取方法及装置
CN103064738B (zh) Linux下本地应用程序窗体嵌入浏览器的方法及系统
WO2023093673A1 (zh) 一种信息处理方法、装置、系统及存储介质
CN107301182B (zh) 一种展示内嵌图片的网页的方法和装置
WO2011038564A1 (zh) 网络应用中移动终端屏幕显示的自适应方法及系统
CN112035205A (zh) 数据处理方法、装置、设备和存储介质
WO2015154666A1 (zh) 桌面展示网页片段的方法及截取网页片段至桌面展示系统
CN110580318B (zh) 信息的展示方法、装置以及存储介质
JP2025510078A (ja) ドキュメントブロック共有方法、システム、記憶媒体、及びプログラム
CN108319619B (zh) 数据处理方法及装置
CN109240664A (zh) 一种采集用户行为信息的方法及终端
CN103838553B (zh) 显示控制方法和电子设备
CN106844763B (zh) 一种对互联网媒体文件进行修改式展现的方法及其装置
CN105224611A (zh) 基于浏览器的操作处理方法、装置以及浏览器
CN113448649B (zh) 一种基于Redis的首页数据加载的服务器及方法
CN105868195A (zh) 图片上传方法及装置
CN113220296B (zh) 安卓系统交互方法及装置
CN117390326A (zh) 页面管理方法、装置、设备以及存储介质
WO2010045848A1 (zh) 一种数据显示的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15875143

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15875143

Country of ref document: EP

Kind code of ref document: A1