KR20250096155A - Method and electronic device for uploading image - Google Patents

Abstract

A method for an electronic device to upload an image is disclosed. Specifically, the method for an electronic device to upload an image may include: confirming a request related to uploading a first image stored in a design tool through a plug-in; generating a branch related to the first image in response to the request; generating a first image having a size and name determined based on a set rule; transmitting a request for approval of merging a branch including the generated first image into a master branch to a first user related to the first image; and when a response for approval of the merge is received from the first user, merging the branch into the master branch and uploading the generated first image to a first server.

Description

METHOD AND ELECTRONIC DEVICE FOR UPLOADING IMAGE

Embodiments of the present specification relate to a method and device for uploading an image.

Images provided to users on Internet services may change periodically or when an event such as an application version update occurs. In this regard, the work of changing, modifying, or adding images may be performed manually. Accordingly, a lot of effort and time is required from users to change, modify, or add images.

The present disclosure has been proposed to solve the above-described problems, and the disclosed embodiments seek to provide a method and an electronic device for uploading an image. More specifically, the disclosed embodiments seek to provide a method and an electronic device for merging a branch into a master branch and automatically uploading the generated image to a server when a response for approval of the merge is received from a user.

As a technical means for achieving the above-described task, a method for an electronic device to upload an image according to a first aspect of the present disclosure may include: a step of confirming a request related to uploading a first image stored in a design tool through a plug-in; a step of generating a branch related to the first image in response to the request; a step of generating a first image having a size and name determined based on a set rule; a step of transmitting a request for approval of merging a branch including the generated first image into a master branch to a first user related to the first image; and a step of merging the branch into the master branch and uploading the generated first image to a first server when a response for approval of the merge is received from the first user.

According to one embodiment, the plugin may include a first area for entering address information related to a first user, a second area for entering token information related to authority for accessing the address information, a third area for entering version information of the first image, and a fourth area for entering modification information for the first image.

According to one embodiment, the step of generating a first image may include the step of loading a first image stored in a design tool as a branch is generated; generating a first image having a size and name from the loaded first image; and generating first data for identifying the first image among the images stored in the first server.

According to one embodiment, the first data includes at least one of information about a size, information about a name, and information about a path where the first image is stored on the first server, and the first data may be data in JSON format.

In one embodiment, the step of uploading the generated first image to the first server may include the step of uploading the generated first data to the second server when a response for approval of the merging is received from the first user.

In one embodiment, when a response to the rejection of the merge is received from the first user, the branch is not merged into the master branch, and the rejection of the upload of the first image can be transmitted to the second user who entered the request related to the upload of the first image via the plugin.

According to one embodiment, the set rules may include a first rule for determining the size of the image and the file type of the image based on information about the operating system and resolution information for each device, and a second rule for determining the name of the image based on setting information related to the image.

In one embodiment, the step of transmitting a request for approval of the merge to the first user may include the step of transmitting a request for approval of the merge to address information entered through the first area.

In one embodiment, the step of uploading the first image to the first server may include the step of uploading the first image to an address of the first server corresponding to each of a size and a name.

According to one embodiment, a method of uploading an image may further include: receiving a request for a second image from a second user of a device; identifying second data among data stored in a second server based on the second image and specification information of the device; confirming a second image corresponding to the second data among images stored in the first server based on the second data; and transmitting information about the second image to the device.

An electronic device according to a second aspect of the present disclosure includes: a transceiver; one or more processors; and a storage storing one or more commands executed by the one or more processors, wherein the one or more processors, by executing the one or more commands, can: verify a request related to uploading a first image stored in a design tool through a plug-in; generate a branch related to the first image in response to the request; generate a first image having a size and name determined based on a set rule; transmit a request for approval of merging the branch including the generated first image into a master branch to a first user related to the first image; and when a response for approval of the merge is received from the first user, merge the branch into the master branch and upload the generated first image to a first server.

A recording medium according to the third aspect of the present disclosure may be a non-transitory computer-readable recording medium having recorded thereon a program for causing a computer to execute a method of uploading an image performed by an electronic device.

According to the proposed embodiment, one or more of the following effects can be expected:

In accordance with an embodiment of the present specification, when a request related to uploading an image stored in a design tool is confirmed through a plug-in and a response for approval of the merge is received from a user, the branch can be merged into a master branch and the generated image can be automatically uploaded to a server. Accordingly, the user's effort and time required for tasks including changing, modifying, or adding an image can be minimized.

The effects of the invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by a person skilled in the art from the description of the claims.

FIG. 1 is a drawing for explaining a system in which a method for uploading an image by an electronic device according to one embodiment of the present invention can be implemented.
Figure 2 is a flow chart illustrating how an electronic device uploads an image.
Figure 3 is a diagram to explain the process of uploading an image in more detail.
Figure 4 is a drawing explaining the operation of designing an image through a design tool and requesting an image upload through a plug-in.
Figure 5 is a drawing for explaining an interface for entering information for uploading an image to a server via a plug-in.
Figure 6 is a diagram illustrating a branch created in response to a request related to uploading an image.
Figure 7 is a diagram illustrating source code related to operations performed on a cloud-based platform.
Figure 8 is a diagram to explain how images and data generated through a cloud-based platform are managed separately in a distributed version control system.
Figure 9 is a diagram for explaining an image generated through a cloud-based platform.
Figure 10 is a diagram illustrating data generated through a cloud-based platform.
Figure 11 is a diagram illustrating a screen related to a request to a first user to approve the merge of a branch into the master branch.
FIG. 12 is a block diagram schematically illustrating an electronic device for uploading an image according to one embodiment.

The terms used in the embodiments are selected from the most widely used general terms possible while considering the functions of the present disclosure, but this may vary depending on the intention of a technician working in the field, precedents, the emergence of new technologies, etc. In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the meanings thereof will be described in detail in the corresponding description section. Therefore, the terms used in the present disclosure should be defined based on the meanings of the terms and the overall contents of the present disclosure, rather than simply the names of the terms.

When a part of the specification is said to “include” a component, this does not mean that other components are excluded, unless otherwise specifically stated, but rather that other components may be included. In addition, terms such as “part,” “module,” etc., described in the specification mean a unit that processes at least one function or operation, which may be implemented by hardware or software, or a combination of hardware and software.

The expression “at least one of a, b, and c” as used throughout the specification can encompass “a alone,” “b alone,” “c alone,” “a and b,” “a and c,” “b and c,” or “all of a, b, and c.”

The "terminal" mentioned below may be implemented as a computer or portable terminal capable of connecting to a server or other terminal via a network. Here, the computer includes, for example, a notebook, desktop, laptop, etc. equipped with a WEB Browser, and the portable terminal may include, for example, a wireless communication device that ensures portability and mobility, such as a communication-based terminal such as IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), LTE (Long Term Evolution), and all kinds of handheld-based wireless communication devices such as a smartphone, tablet PC, etc.

Below, with reference to the attached drawings, embodiments of the present disclosure are described in detail so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein.

In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present invention belongs and are not directly related to the present invention will be omitted. This is to convey the gist of the present invention more clearly without obscuring it by omitting unnecessary explanations.

For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically illustrated. In addition, the size of each component does not entirely reflect the actual size. The same or corresponding components in each drawing are given the same reference numbers.

The advantages and features of the present invention, and the methods for achieving them, will become clear with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and the present embodiments are provided only to make the disclosure of the present invention complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be loaded onto a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement the function in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured article including an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may be installed on a computer or other programmable data processing apparatus, a series of operational steps may be performed on the computer or other programmable data processing apparatus to produce a computer-executable process, so that the instructions executing the computer or other programmable data processing apparatus may also provide steps for executing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a particular logical function(s). It should also be noted that in some alternative implementation examples, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may in fact be performed substantially concurrently, or the blocks may sometimes be performed in reverse order, depending on the functionality they perform.

Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

FIG. 1 is a drawing for explaining a system in which a method for uploading an image by an electronic device according to one embodiment of the present invention can be implemented.

Referring to FIG. 1, a system (10) according to various embodiments may be a system for uploading an image. The system (10) may include an electronic device (100), a first user (120), a second user (110), a first server (130), and a second server (140). The system (10) illustrated in FIG. 1 only illustrates components related to the present embodiment. Therefore, a person having ordinary skill in the art related to the present embodiment may understand that other general components may be further included in addition to the components illustrated in FIG. 1.

Each of the electronic device (100), the first server (130), and the second server (140) may include a transceiver, storage, and a processor. In addition, each of the electronic device (100), the first server (130), and the second server (140) means a unit that processes at least one function or operation, and this may be implemented by hardware or software, or a combination of hardware and software. Meanwhile, throughout the embodiments, each of the electronic device (100), the first server (130), and the second server (140) is referred to as a separate device or server, but this may be a logically divided structure, and at least some of them may be implemented by a separate function in one device or server.

According to one embodiment, the electronic device (100), the first server (130), and the second server (140) may include a plurality of computer systems or computer software implemented as network servers. For example, at least some of the electronic device (100), the first server (130), and the second server (140) may refer to a computer system and computer software that are connected to a lower device that can communicate with another network server through a computer network such as an intranet or the Internet, receive a task execution request, perform the task accordingly, and provide the execution result. In addition, at least some of the electronic device (100), the first server (130), and the second server (140) may be understood as a broad concept that includes a series of application programs that can operate on a network server, and various databases built on internal or connected other nodes. For example, at least some of the electronic device (100), the first server (130), and the second server (140) may be implemented using a network server program provided in various ways according to an operating system such as DOS, Windows, Linux, UNIX, or MacOS.

The electronic device (100), the first server (130), and the second server (140) can communicate with each other through a network (not shown). The network includes a Local Area Network (LAN), a Wide Area Network (WAN), a Value Added Network (VAN), a mobile radio communication network, a satellite communication network, and a combination thereof, and is a comprehensive data communication network that allows each network component shown in FIG. 1 to communicate smoothly with each other, and may include wired Internet, wireless Internet, and a mobile radio communication network. The wireless communication may include, but is not limited to, wireless LAN (Wi-Fi), Bluetooth, Bluetooth low energy, Zigbee, WFD (Wi-Fi Direct), UWB (ultra wideband), infrared communication (IrDA, infrared Data Association), NFC (Near Field Communication), etc., for example.

According to one embodiment, the electronic device (100) may, through a plug-in, verify a request related to uploading a first image stored in a design tool, create a branch related to the first image in response to the request, create a first image having a size and name determined based on set rules, transmit a request for approval of merging a branch including the created first image into a master branch to a first user (120) related to the first image, and when a response for approval of the merge is received from the first user (120), merge the branch into the master branch and upload the created first image to a first server.

The design tool may be a tool for designing UI/UX with functions that are activated in applications under various operating systems. For example, the design tool may be Figma, but is not limited thereto. The plugin may be software that operates as an extension module for providing additional functions through the design tool. Specifically, the additional function provided through the design tool may be to automatically upload an image designed and saved by a user through the design tool to a server. The second user (110) may be a user who inputs a request related to uploading an image saved in the design tool through the plugin.

The image designed through the design tool can be managed through a distributed version control system. Specifically, the distributed version control system can include a branch and a master branch, and the distributed version control system can be Github, but is not limited thereto. A branch is a dedicated workspace for each user and can be used to store, modify, and manage various types of data such as source code and images. In relation to this, various types of data related to images can be stored in the branch. That is, a first image having a size and name determined based on a set rule can be managed in a branch corresponding to a second user (110). In addition, the master branch can be a shared workspace where files such as source codes developed collaboratively by multiple users are managed. That is, various files such as source codes developed by multiple users can be managed in an integrated manner through the master branch. In relation to this, the operation of merging data stored in each user's individual branch into the master branch needs to be performed after confirming whether the data stored in each individual branch is appropriate. In this regard, the first user (120) is a user who has the authority to approve the merge of a branch into the master branch, and the second user (110) can input information to identify the user who has the authority to approve the merge of a branch into the master branch when entering a request related to uploading an image through the plugin.

The first server (130) is a server to which the generated image is uploaded, and may be a CDN (Content Distribution/Delivery Network). More specifically, a resource of an image file type (e.g., png) may be uploaded to the first server (130). The second server (140) is a server to which data for identifying the image is uploaded, and may be a CMS (Content Management System). The data for identifying the image may be data in the form of JSON (JavaScript Object Notation) in order to efficiently transmit and receive images rather than relatively high-capacity images, but is not limited thereto.

The image provided to the user on the Internet service needs to be dynamically determined based on information about the operating system of the user's device, resolution information based on the specifications of the user's device, and information about the communication speed currently supported by the user's device. That is, even if the image has the same design, multiple versions of the image may be stored in the first server (130) depending on the operating system and resolution. In addition, in order to distinguish between multiple versions of the image even if the design is the same, data for identifying the image may be stored in the second server (140) while being determined differently.

Figure 2 is a flow chart illustrating how an electronic device uploads an image.

Referring to FIG. 2, it can be clearly understood that some of the operations of uploading an image by the electronic device (100) may be changed or substituted, or some of the order between the operations may be changed, within a range clearly understandable to a person having ordinary skill in the art to which the present invention pertains.

In step S210, the electronic device (100) can confirm a request related to uploading a first image stored in a design tool through a plug-in.

A second user (110) can input a request related to uploading an image stored in a design tool through a plug-in. In response to the input request, the electronic device (100) can confirm a request related to uploading a first image stored in the design tool through the plug-in. The operation of designing an image through a design tool and confirming a request related to uploading a first image stored in the design tool through the plug-in will be examined in detail with reference to FIGS. 4 and 5.

In step S220, the electronic device (100) may generate a branch related to the first image in response to the request.

According to one embodiment, the electronic device (100) may create a branch related to the first image upon confirming the request. The created branch may be a dedicated branch of the second user (110), and data related to an image designed by the second user (110) through a design tool may be stored in the branch. That is, data related to an image designed by the second user (110) through a design tool may be managed through the dedicated branch of the second user (110). The operation of creating a branch related to the first image will be described in detail with reference to FIG. 6.

In step S230, the electronic device (100) can generate a first image of a size and name determined based on the set rule.

According to one embodiment, the electronic device (100) may generate a first image having a size and a name determined based on a set rule in response to the generation of a branch. Here, the set rule may include a first rule for determining a size and a file type of an image based on information about an operating system and resolution information for each device, and a second rule for determining a name of the image based on setting information related to the image. That is, the size of the image may be determined based on the first rule, and the name of the image may be determined based on the second rule. The first images having various sizes and names may be managed through the generated branches. An operation of generating a first image having a size and a name determined based on the set rule will be described in detail with reference to FIGS. 7 and 8.

In step S240, the electronic device (100) may transmit a request for approval of merging a branch including the generated first image into the master branch to the first user (120) associated with the first image.

The second user (110) can manually input a user who has the authority to approve the merge of the branch into the master branch through the plug-in. If there is no input for a user with the authority to approve, the electronic device (100) can send a request to the user who manages the design work of the second user (110) as to whether to approve the merge of the branch into the master branch.

The user's review of whether to approve the merge of a branch into the master branch may be referred to as a pull request review task. Specifically, the first user (120) who has received a request for whether to approve the merge of a branch into the master branch may check review items including whether there are any errors in the number of images stored in the branch, whether the versions of the images are appropriate, and whether the names of the images are incorrectly set, and may decide to approve or reject the merge. Regarding the request for whether to approve the merge of a branch into the master branch, a screen provided to the first user (120) will be examined in detail in FIG. 11.

In step S250, when a response for approval of merging is received from the first user (120), the electronic device (100) can merge the branch into the master branch and upload the generated first image to the first server (130).

When there are no errors in various data stored in the branch corresponding to the second user (110), the second user (110) can approve the merging of the branch into the master branch. Accordingly, the electronic device (100) can merge the branch into the master branch and upload the generated first image to the first server (130). In addition, the electronic device (100) can upload first data for identifying the first image to the second server (140).

When there is an error in some of the various data stored in the branch corresponding to the second user (110), the second user (110) may reject the merge of the branch into the master branch. Accordingly, the branch may not be merged into the master branch. In addition, the fact that the upload of the first image has been rejected may be transmitted to the second user (110). Accordingly, the second user (110) may modify the image through the design tool and then re-enter the request related to the upload of the image.

That is, a user who has completed the design of an image through a design tool can simply request an image upload through a plug-in of the design tool, and the subsequent operations from image creation to image upload can be performed automatically. Data according to the performed operations can be divided into the first server (130) or the second server (140) according to the type of data and efficiently stored and managed. Accordingly, the user's effort and time required for tasks including changing, modifying, or adding an image can be minimized.

Figure 3 is a diagram to explain the process of uploading an image in more detail.

In one embodiment, the electronic device (100) may include, but is not limited to, a distributed version management system (303) and a cloud-based platform (304). For example, the electronic device (100) may further include a design tool (301) and a plug-in (302).

Through the design tool (301), the user can design an image having a function that is activated in an application under various operating systems. The image designed through the design tool (301) may include a simple image such as an icon to a complex image. In order to release the image designed through the design tool (301), the user can input a request related to uploading the image through the plug-in (302). In response to the request related to uploading the image being confirmed, the electronic device (100) can create or pull a branch. As the branch is created, the distributed version control system (303) can trigger a task including an operation of creating data and an image to be stored in the branch to the cloud-based platform (304).

The cloud-based platform (304) may be a platform that oversees the setup, security, and maintenance of data, and provides immediate access to the distribution and updates of the data. For example, the cloud-based platform (304) may be, but is not limited to, Circle CI. The cloud-based platform (304), which is triggered to perform a task from the distributed version control system (303), may fetch an image designed in the design tool (301). The cloud-based platform (304) may automatically generate an image of a size and name determined based on a set rule from the image designed in the design tool (301). In addition, the cloud-based platform (304) may generate data for identifying an automatically generated image among the images stored in the first server (130). The cloud-based platform (304) may store or merge the generated image and data in a branch. Accordingly, the branch may store various versions of an image corresponding to an image in the design tool (301) for which a request has been confirmed, and data for identifying each of the various versions of the image.

The distributed version control system (303) may transmit a request for approval of merging a branch into the master branch to the first user (120). The first user (120) who has received the request for approval of merging a branch into the master branch may check review items including whether there are any errors in the number of images stored in the branch, whether the versions of the images are appropriate, and whether the names of the images are set incorrectly. Accordingly, the first user (120) may transmit a response including approval or rejection of merging the branch into the master branch to the distributed version control system (303). If the merging of the branch into the master branch is rejected, the branch may not be merged into the master branch, and the process for image distribution may be terminated. Conversely, if the merging of the branch into the master branch is approved, the branch may be merged into the master branch.

The distributed version control system (303) can trigger the cloud-based platform (304) to distribute images and data stored in a branch to multiple servers. Accordingly, the cloud-based platform (304) can upload the images to the first server (130) and upload low-capacity data for identifying the images to the second server (140). Specifically, the cloud-based platform (304) can upload the corresponding images to the address of the first server (130) corresponding to each image of different size and name.

Figure 4 is a drawing explaining the operation of designing an image through a design tool and requesting an image upload through a plug-in.

A user can design various images on an Internet service through the user interface (400) of the design tool. For example, a user can design an image (401) with an icon related to rocket delivery and a string of characters, rocket delivery, written on it through the user interface (400) of the design tool. Here, the image (401) may be the smallest-sized image among three images related to rocket delivery. In order to distribute the image, on the user interface (400) of the design tool, the user can click a plugin called Coupang IconBot (402) that provides a function of uploading an image to a server among the extension modules that provide additional functions. An interface related to the plugin when the plugin called Coupang IconBot (402) is clicked will be described below.

Figure 5 is a drawing for explaining an interface for entering information for uploading an image to a server via a plug-in.

A tab (500) for settings of the interface of a plugin called Coupang IconBot (402) may include an area (501) for entering address information related to a first user and an area (502) for entering token information related to authority for accessing the address information.

The electronic device (100) may transmit a request for approval of merging a branch into a master branch to an address corresponding to a user entered in an area (501). Address information corresponding to a user who manages design work of a second user (110) may be displayed by default in the area (501). Token information related to authority for accessing an address corresponding to a user entered in an area (502) may be input. Token information related to authority for accessing an address corresponding to a user who manages design work of a second user (110) may be displayed by default in the area (502).

The publish tab (500) of the interface of the plugin called Coupang IconBot (402) may include an area (512) for entering version information of an image and an area (513) for entering modification information for a first image. In addition, the publish tab (510) may include an area (511) for displaying a current version of a distributed version management system, an area (514) for entering a request related to uploading an image and determining whether to provide a message to the first user at the same time, and an area (515) for receiving an input for requesting uploading an image.

The current version of the distributed version control system displayed in the area (511) may be to prevent conflicts due to different version information when performing an operation of merging an image designed in a design tool, an image and data generated through a cloud-based platform (304), an operation of merging the generated image and data into a branch, and an operation of merging a branch into a master branch. In addition, the version information input through the area (512) may be a version of an image designed by a design tool, and a message or commit input through the area (513) may be content about the difference between a previous version of an image input through the area (512) and a current version of an image. That is, the message input through the area (513) may include modified content, and designers and developers may effectively identify modified or added content based on the message input through the area (513). For example, the version information input through the area (512) may be 1.5.6, and the message input through the area (513) may be a change in the color of a logo.

After information is entered through the tab for setting (500) and the tab for publishing (510), the user can input a request to upload an image to the electronic device (100) through the area (515). In response to receiving the request, the electronic device (100) can create a branch related to the first image.

Figure 6 is a diagram illustrating a branch created in response to a request related to uploading an image.

The interface (600) may be an interface for a branch in a distributed version control system corresponding to a second user who inputs a request related to uploading an image. The version displayed in the area (601) of the interface (600) may correspond to version information of an image designed in a design tool, which may correspond to version information of 1.5.6 input through the area (512). In addition, the message displayed in the area (602) of the interface (600) may correspond to information on the difference between the current version and the previous version of the image, which may be a change in the color of the logo, which may be a message input through the area (513).

The area (603) of the interface (600) may display information about the performance of an operation on the cloud-based platform (304). Specifically, the distributed version control system (303) may trigger a task, including an operation to create data and an image to be stored in a branch, to the cloud-based platform (304) as a branch is created, and information about the performance of the operation on the cloud-based platform (304) according to this may be displayed in the area (603) of the interface (600). In relation to this, when a sub-area (604) within the area (603) is clicked, information about the operation currently being performed on the cloud-based platform (304) may be displayed.

Figure 7 is a diagram illustrating source code related to operations performed on a cloud-based platform.

Referring to the source code (700) of FIG. 7, the operation of the cloud-based platform (304) can be largely divided into i) an operation of bringing in an image designed through a design tool and generating various versions of the image and data for identifying the image, and ii) an operation of uploading the image to a first server (130). The operation of bringing in an image designed through a design tool and generating various versions of the image and data for identifying the image may correspond to a first area (701) of the source code (700). The operation of uploading the image to the first server (130) may correspond to a second area (702) of the source code (700).

Although not shown in FIG. 7, the source code (700) may further include an area corresponding to setup information for identifying an image that the second user has requested to upload to the server among the images stored in the design tool. Specifically, the cloud-based platform (304) may identify an image that the second user has requested to upload to the server among the images stored in the design tool based on the token information in the source code (700) and the address information of the image.

In addition, although not shown in FIG. 7, the source code (700) may include an area corresponding to information about a rule for determining a size and name related to an image. The information about the rule may be preset for each image designed through a design tool and stored on a distributed version management system (303). If the information about the rule is not preset for each image designed through a design tool, the information about the rule may be set to correspond to information about a default rule.

Figure 8 is a diagram to explain how images and data generated through a cloud-based platform are managed separately in a distributed version control system.

Figure 9 is a diagram for explaining an image generated through a cloud-based platform.

Figure 10 is a diagram illustrating data generated through a cloud-based platform.

The cloud-based platform (304) can automatically generate an image of a size and name determined based on rules set from an image designed through a design tool, and data for identifying the image. Each of the generated images and data can be managed and stored separately within a branch of a distributed version control system (303).

In the folder of the first area (801) of the interface (800), an image with a size and name determined based on a rule set from an image designed through a design tool can be stored.

The folder named native in the first area (801) may correspond to a local storage in the distributed version control system (303), and images may be created and stored in the folder for each operating system that supports the Internet service. Referring to FIG. 9, since the Internet service can be supported by operating systems called iOS and AOS, an iosNative file in a PDF file format and an AOSNative file in an SVG file format may be stored in the folder named native in the first area (801), respectively. Since the folder named native in the first area (801) corresponds to a local storage for each operating system in the distributed version control system (303), images stored in the folder named native in the first area (801) may not be uploaded to the first server (130).

The folder named Upload in the first area (801) may be a storage within the distributed version management system (303) where images to be uploaded to the first server (130) via the cloud-based platform (304) are stored. Images stored in the folder named Upload may be uploaded to the first server (130) later. Referring to FIG. 9, images designed via the design tool may be generated as images of eight different sizes depending on the resolution. For example, images in the iOS operating system may be generated as iphone@3x, iphone@2x, and iphone depending on the resolution information. Specifically, iphone@3x may be an image with a higher resolution than iphone@2x, and iphone@2x may be an image with a higher resolution than iphone. In other words, an image displayed on a recently released, high-spec device among devices of the iOS operating system may correspond to iphone@3x, and an image displayed on a long-released, low-spec device among devices of the iOS operating system may correspond to iphone. As another example, images in the AOS operating system can be xxxhdpi, xxhdpi, xhdpi, hdpi, mdpi depending on the resolution information. Here, dpi (dots per inch) indicates the total number of dots per inch (inch) wide and per inch high, so the order of xxxhdpi, xxhdpi, xhdpi, hdpi, mdpi can be in order from high resolution to low resolution. In other words, images displayed on high-spec devices that were recently released among devices with the AOS operating system can correspond to xxxhdpi, and images displayed on low-spec devices that were released a long time ago among devices with the AOS operating system can correspond to mdpi.

The data.json of the second area (802) is data in JSON format and may be data for identifying each of the various versions of the images stored in the folder named Native and the folder named Upload in the first area (801). The file called data.json may correspond to the source code entered in the area (1010). The data.json may include information about the size of the image, information about the name of the image, and information about the path where the image is stored in the first server (130).

Specifically, the source code input into the area (1010) may be displayed in the area (1020) in a structured manner corresponding to the input through the area (1015). The source code input into the area (1010) may include information corresponding to each of iosNative, AOSNative, iphone@3x, iphone@2x, iphone, xxxhdpi, xxhdpi, xhdpi, hdpi, and mdpi of FIG. 9. Resolutions 0 to 7 of the area (1020) may correspond to mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi, iphone, iphone@2x, and iphone@3x of FIG. 9 in that order. The source code corresponding to the sub-area (1011) and the sub-area (1021) may correspond to information on the image (901) of the hdpi resolution of FIG. 9. Information about an image with hdpi resolution may include i) the address information being coupnang/rds/logo/hdpi/logo_rocket_small1697447490667.png, ii) the code information being HDPI, iii) the image size information being that the image width information is 60.00067138671875, and iv) the image height information being that the image size information is 14.

In addition, the sub-area (1022) may be a general name for various versions of images stored in the Native folder and the Upload folder, which may be 'LOGO_ROCKET_SMALL'. The name of the image may be determined based on the setting information related to the image. For example, the name of the image may be configured in a form in which three pieces of information are combined based on '_', and information on the image type of the image may be described in the first part, information on the image shape may be described in the second part, and information on the size of the image may be described in the third part. For example, the image (401) of FIG. 4 may be the smallest-sized icon image among three icon images related to rocket delivery, and the image type of the image (401) may be LOGO, the image shape of the image (401) may be Rocket, and the size of the image (401) may be SMALL. That is, the name corresponding to the image (401) of FIG. 5 may be determined as 'LOGO_ROCKET_SMALL'.

According to one embodiment, when receiving a request for a second image from a user of the device, the electronic device (100) may identify a second image to be transmitted to the device among the images stored in the first server (130) using data stored in the second server (140). Specifically, the electronic device (100) may identify second data corresponding to the second image among the data stored in the second server based on the second image corresponding to the received request. In addition, the electronic device (100) may identify address information and code information of a resolution corresponding to the specification information of the device through the identified second data. The electronic device (100) may identify a second image of a resolution corresponding to the identified address information and code information among the images stored in the first server, and may transmit the second image of the identified resolution to the device. That is, the electronic device (100) may effectively identify a suitable image among the images stored in the first server (1030) using data in the form of low-capacity data for transmitting and receiving images. Accordingly, the amount of data required for the image transmitting and receiving process may be minimized.

Figure 11 is a diagram illustrating a screen related to a request to a first user to approve the merge of a branch into the master branch.

According to one embodiment, the electronic device (100) can identify a user who has the authority to approve the merge of a branch into the master branch from the input via the plug-in of FIG. 5. Accordingly, the electronic device (100) can transmit a screen related to a request for approval of the merge of FIG. 11 to an address corresponding to the authorized user.

The user can check review items including whether there is an error in the number of images stored in the branch, whether the version of the image is appropriate, and whether the name of the image is incorrectly set through the screen (1100), and decide whether to approve or reject the merge. Specifically, the user can check whether there are an appropriate number of images (e.g., 2 images in the Native folder and 8 images in the Upload folder) in the Native folder and whether the name of each image is appropriately set through the area (1101). In addition, the user can directly check whether the images were appropriately created through the area (1102).

FIG. 12 is a block diagram schematically illustrating an electronic device for uploading an image according to one embodiment.

The electronic device (100) of FIG. 12 may be an electronic device for uploading an image. The electronic device (100) may include a transceiver (101), a storage (102), and one or more processors (103), according to an embodiment. The electronic device (100) illustrated in FIG. 12 illustrates only components related to the present embodiment. Therefore, it will be understood by those skilled in the art related to the present embodiment that other general-purpose components may be further included in addition to the components illustrated in FIG. 12.

For example, the electronic device (100) may include a transceiver (101) according to an embodiment. The transceiver (101) is a device for performing wired/wireless communication and may communicate with an external electronic device. In addition, the communication technology used by the transceiver (101) may include GSM (global system for mobile communication), CDMA (code division multi access), LTE (long term evolution), 5G, WLAN (wireless LAN), Wi-Fi (wireless-fidelity), Bluetooth, RFID (radio frequency identification), infrared data association (IrDA), ZigBee, and NFC (near field communication). According to an embodiment, the transceiver (101) may transmit a generated first image to a first server (130) and transmit data for identifying the image to a second server (140).

The storage (102) can store information for performing at least one of the methods described above through FIGS. 1 to 12. The storage (102) can store one or more commands executed by one or more processors (103). The storage (102) can be referred to as a memory and can be a volatile memory or a non-volatile memory. The storage (102) can store an image designed through a design tool, and can store an image managed through a local storage within a distributed version control system such as iOSNative and AOSNative of FIG. 9.

One or more processors (103) can control the overall operation of the electronic device (100) and process data and signals. The one or more processors (103) can perform one of the methods described above through FIGS. 1 to 12. The one or more processors (103) can be composed of at least one hardware unit. In addition, the one or more processors (103) can operate by one or more software modules generated by executing one or more commands stored in the storage (102). The one or more processors (103) can control embodiments performed by the electronic device (100) through interactions with the transceiver (101) and the storage (102), and further with components that the electronic device (100) can include.

According to one embodiment, the processor (103) may execute one or more commands to, through a plug-in, check a request related to uploading a first image stored in a design tool, create a branch related to the first image in response to the request, create a first image having a size and name determined based on a set rule, transmit a request for approval of merging the branch including the created first image into a master branch to a first user related to the first image, and when a response for approval of the merge is received from the first user, merge the branch into the master branch and upload the created first image to the first server (130).

Meanwhile, the present specification and drawings have disclosed preferred embodiments of the present invention, and although specific terms have been used, they have been used only in a general sense to easily explain the technical contents of the present invention and to help understand the invention, and are not intended to limit the scope of the present invention. It will be apparent to those skilled in the art that other modified examples based on the technical idea of the present invention can be implemented in addition to the embodiments disclosed herein.

The electronic device or terminal according to the above-described embodiments may include a processor, a memory for storing and executing program data, a permanent storage such as a disk drive, a communication port for communicating with an external device, a user interface device such as a touch panel, a key, an icon, etc. The methods implemented as software modules or algorithms may be stored on a computer-readable recording medium as computer-readable codes or program commands executable on the processor. Here, the computer-readable recording medium includes a magnetic storage medium (e.g., a read-only memory (ROM), a random-access memory (RAM), a floppy disk, a hard disk, etc.) and an optical reading medium (e.g., a CD-ROM, a Digital Versatile Disc (DVD)). The computer-readable recording medium may be distributed to computer systems connected to a network, so that the computer-readable code may be stored and executed in a distributed manner. The medium may be readable by a computer, stored in a memory, and executed by a processor.

The present embodiment may be represented by functional block configurations and various processing steps. These functional blocks may be implemented by various numbers of hardware and/or software configurations that perform specific functions. For example, the embodiment may employ integrated circuit configurations such as memory, processing, logic, look-up tables, etc., which may perform various functions under the control of one or more microprocessors or other control devices. Similarly to the fact that the components may be implemented by software programming or software components, the present embodiment may be implemented in a programming or scripting language such as C, C++, Java, assembler, Python, etc., including various algorithms implemented by a combination of data structures, processes, routines, or other programming configurations. The functional aspects may be implemented by algorithms that are executed on one or more processors. In addition, the present embodiment may employ conventional techniques for electronic environment setting, signal processing, and/or data processing. Terms such as “mechanism,” “element,” “means,” and “configuration” can be used broadly and are not limited to mechanical and physical configurations. The terms can also include the meaning of a series of software processes (routines) in connection with a processor, etc.

The above-described embodiments are only examples, and other embodiments may be implemented within the scope of the claims set forth herein.

Claims (12)

In the method of an electronic device uploading an image,
Step 2: Verifying a request related to uploading a first image stored in the design tool via the plugin;
In response to the above request, a step of creating a branch related to the first image;
A step of generating a first image having a size and name determined based on established rules;
A step of transmitting a request for approval of merging the branch including the generated first image into the master branch to the first user associated with the first image; and
When a response for approval of said merge is received from said first user, the step of merging said branch into said master branch and uploading said generated first image to a first server is included.
How to upload an image.
In the first paragraph,
The above plugin,
A first area for entering address information related to the first user, a second area for entering token information related to authority for accessing the address information, a third area for entering version information of the first image, and a fourth area for entering modification information for the first image.
How to upload an image.
In the second paragraph,
The step of generating the first image is:
As the above branch is created, a step of loading the first image stored in the design tool;
A step of generating a first image of the size and the name from the first image loaded above; and
A step of generating first data for identifying the first image among the images stored in the first server,
How to upload an image.
In the third paragraph,
The above first data is,
Contains at least one of information about the size, information about the name, and information about the path where the first image is stored on the first server;
The above first data is,
Data in JSON format,
How to upload an image.
In the third paragraph,
The step of uploading the first image generated above to the first server is:
When a response for approval of the merge is received from the first user, the step of uploading the generated first data to the second server is included.
How to upload an image.
In the first paragraph,
When a response to the rejection of the merge is received from the first user, the branch is not merged into the master branch, and the rejection of the upload of the first image is transmitted to the second user who entered the request related to the upload of the first image through the plugin.
How to upload an image.
In the first paragraph,
The above established rules are:
A first rule that determines the size of the image and the file type of the image based on information about the operating system and resolution information for each device, and
A second rule for determining the name of an image based on configuration information related to the image,
How to upload an image.
In the second paragraph,
The step of sending a request for approval of the above merge to the first user is:
Including a step of transmitting a request for approval of the merger using the address information entered through the first area.
How to upload an image.
In the first paragraph,
The step of uploading the first image to the first server is:
Comprising the step of uploading the first image to the address of the first server corresponding to each of the above size and the above name,
How to upload an image.
In clause 5,
A step of receiving a request for a second image from a second user of the device;
A step of identifying second data among data stored in the second server based on the second image and specification information of the device;
A step of confirming the second image corresponding to the second data among the images stored in the first server based on the second data; and
Further comprising the step of transmitting information about the second image to the device,
How to upload an image.
As an electronic device,
transceiver;
one or more processors; and
comprising storage for storing one or more instructions executed by said one or more processors;
The one or more processors, by executing the one or more instructions,
Through the plugin, check the request related to uploading the first image stored in the design tool,
In response to the above request, create a branch related to the first image,
Generate a first image with a size and name determined based on the established rules,
Sending a request to a first user associated with the first image for approval of merging the branch containing the first image generated above into the master branch, and
When a response for approval of said merge is received from said first user, said branch is merged into said master branch, and said generated first image is uploaded to the first server.
Electronic devices.
A non-transitory computer-readable storage medium having recorded thereon a program for executing the method of any one of claims 1 to 10 on a computer.

Images