FIELDThe specification relates generally to mobile electronic devices, and specifically to a method and apparatus for managing memory in a mobile electronic device.
BACKGROUNDWhile the capabilities of mobile electronic devices such as cellular telephones and smart telephones continue to increase in terms of computational power, storage space and the like, the usage of such devices is also becoming more widespread. Greater numbers of more varied users can result in demands for improved functionality being placed on mobile electronic devices. This demand can outpace the improving technical attributes of such devices. As a result, there remains a need for frugal use of mobile electronic devices' resources.
BRIEF DESCRIPTIONS OF THE DRAWINGSEmbodiments are described with reference to the following figures, in which:
FIG. 1 depicts a schematic representation of a mobile electronic device, according to a non-limiting embodiment;
FIG. 2 depicts a shared cache maintained by the mobile electronic device ofFIG. 1, according to a non-limiting embodiment;
FIG. 3 depicts a method for managing memory in a mobile electronic device, according to a non-limiting embodiment;
FIG. 4 depicts the shared cache ofFIG. 2 following performance of the method ofFIG. 3, according to a non-limiting embodiment;
FIG. 5 depicts a method for managing memory in a mobile electronic device, according to a second non-limiting embodiment; and
FIG. 6 depicts a method for managing memory in a mobile electronic device, according to a third non-limiting embodiment.
DETAILED DESCRIPTION OF THE EMBODIMENTSAn aspect of the specification can provide a method for managing memory in a mobile electronic device, the method comprising: receiving a request to install an application; receiving at least one indication of data intended to be maintained in a shared cache; determining, based on the at least one indication, whether data corresponding to the intended data exists in the shared cache; upon a negative determination, writing the intended data to the shared cache; and repeating the receiving at least one indication, the determining and the writing for at least one additional application. A computer readable storage medium for storing computer readable instructions for execution by a processor, the computer readable instructions implementing the method can also be provided.
Another aspect of the specification can provide a mobile electronic device comprising: a memory for maintaining a shared cache; a processor interconnected with the memory, the processor configure to receive a request to install an application; the processor further configured to receive at least one indication of data intended to be maintained in the shared cache; the processor further configured to determine, based on the at least one indication, whether data corresponding to the intended data exists in the shared cache maintained within the memory; the processor further configured to write, upon a negative determination, the intended data to the shared cache; and to repeat the receiving at least one indication, the determination and the writing for at least one additional application.
FIG. 1 depicts a mobileelectronic device100. Mobileelectronic device100 can be based on the computing environment and functionality of a hand-held wireless communication device. It will be understood, however, that mobileelectronic device100 is not limited to a hand-held wireless communication device. Other electronic devices can be used, such as cellular telephones, smart telephones, media players and laptop computers. Mobileelectronic device100 can include aprocessor102 interconnected with aninterface104 by way of a communication bus (not shown).Interface104 provides wireless or wired communication capabilities, or both wireless and wired communication capabilities, to mobileelectronic device100, by way of alink106 connecting mobileelectronic device100 to anetwork108. In the case of wireless communication,link106 can be a wireless link based on core mobile network infrastructure (e.g. Global System for Mobile communications (“GSM”); Code Division Multiple Access (“CDMA”); CDMA 2000; 3G; 4G).Link106 can also be based on wireless local area network (“WLAN”) infrastructures such as the Institute for Electrical and Electronic Engineers (“IEEE”) 802.11 Standard (and its variants), Bluetooth or the like, or hybrids thereof.
Mobileelectronic device100 can also include one or more output devices such as aspeaker110, amotor112 and a light emitting diode (“LED”)114.Speaker110,motor112 andLED114 are interconnected withprocessor102 over a communication bus (not shown), and can be operable to generate notification signals. For example,speaker110 can generate an audible notification signal, such as a ring-tone;motor112 can generate a tactile notification signal by causing mobileelectronic device100 to vibrate; andLED114 can generate a visual notification signal, for example by flashing on and off.
Mobileelectronic device100 can include a further output device in the form of adisplay module116 interconnected withprocessor102 via a communication bus (not shown).Display module116 comprisescircuitry118 for generating arepresentation120, for example of data maintained on mobileelectronic device100. It will now be apparent to those skilled in the art thatdisplay module116 can include a flat panel display (e.g. liquid crystal display (“LCD”), plasma, and the like), a cathode ray tube (“CRT”), and the like.
Mobileelectronic device100 can also include aninput device121 interconnected withprocessor102 via a communication bus (not shown).Input device121 can comprise any suitable input device for accepting input data. For example,input device121 can include button(s), a keypad, a track ball, a scroll wheel and any combination thereof.Input device121 can also comprise other suitable devices that will occur to those skilled in the art. As a further example,input device121 can include a touch screen integrated withdisplay module116.
Mobileelectronic device100 can also include amemory122 interconnected withprocessor102 via a communication bus (not shown).Memory122 can be read only memory (“ROM”), Electrically Eraseable Programmable Read Only Memory (“EEPROM”), flash memory, or Random Access Memory (“RAM”). It will be appreciated thatmemory122 can also be any combination or hybrid of the above-mentioned types of memory.Memory122 can maintain plurality of applications, indicated generically at124.Applications124 can comprise computer readable instructions for execution byprocessor102 to implement any of a wide variety of functionalities on mobileelectronic device100. It will be understood that whileapplications124 are shown as being maintained inmemory122,applications124 can be stored on any computer readable medium. Examples of such a computer readable medium includememory122, a removable diskette, CD-ROM, ROM, fixed disk, USB drive and the like. The computer readable medium can also be located remotely to mobileelectronic device100 and the instructions can be transmitted toprocessor102 vianetwork108,link106 andinterface104.
Applications124 can thus be processed, or executed, byprocessor102 which makes appropriate use ofmemory122 as necessary during such execution. It will be understood thatmemory122 can maintain any number ofapplications124. For example,memory122 can maintain one or more email applications, one or more contacts applications, one or more social networking applications, web browsers and the like. In general,processor102 can be configured, via execution ofapplications124, to cause mobileelectronic device100 to carry out a variety of actions that will occur to those skilled in the art (e.g. sending email, uploading and downloading web content and the like).
Memory122 can also maintain a sharedcache126. Sharedcache126 can comprise a reserved address space. Sharedcache126 can also comprise a reserved amount of storage space (i.e. not confined to any particular address space). The reserved amount can change as data is added to sharedcache126. Sharedcache126 can contain data defining settings and content for use byprocessor102 during execution ofapplications124. Turning toFIG. 2, an exemplary sharedcache126 is shown. Sharedcache126 can containdata200 and202.Data200 anddata202 can be name-value pairs as shown inFIG. 2. It will now be apparent to those skilled in the art that while sharedcache126 is depicted in a tabular format inFIG. 2, this format is for illustrative purposes and is not strictly necessary. It will also be apparent that sharedcache126 need not include the data “Name-Value” as shown in the header row ofFIG. 2. This header row is provided purely for illustrative purposes.
Each name-value pair includes a name and an associated value. For example,data200 comprises aname200n, “Pull Time Interval” and avalue200v, “5 minutes.”Data200 thus defines a setting named “pull time interval” maintained in sharedcache126. Such a setting can be read frommemory122 byprocessor102 via execution of anapplication124. For example,processor102 can be configured via execution of an email application to regularly request new emails from a server (not shown) vialink106 andnetwork108.Processor102 can be configured, via execution of the email application, to readdata200 and thereby cause mobileelectronic device100 to request new emails from the server once every five minutes.
As a further example,data202 defines another setting, comprising aname202nand avalue202v, named “Sync Contacts.”Processor102 can be configured, via execution of a social networking application for example, to synchronize locally-stored contacts (not shown) maintained inmemory122 with contacts maintained in a server (not shown) associated with the social networking application.Processor102 can further be configured, via execution of the social networking application, to readdata202 and thereby cause mobile electronic device to synchronize locally-stored contacts with contacts stored on the server, or to not synchronize contacts (in other words,value202vin the present example can take values of “Yes” or “No”).
It will now be apparent to those skilled in the art thatprocessor102 can be configured to access the contents of sharedcache126 during execution of a variety of applications. For example, the social networking application mentioned above can further configureprocessor102 to regularly request new messages or other data maintained in the social networking server. In such an exemplary situation,processor102 can be configured to readdata200 during execution of the social networking application as well asdata202. That is, data200 (as well as any other data contained in shared cache126) can affect the actions ofprocessor102 and by extensionmobile device100 during execution of any of a plurality ofdifferent applications124.
When anew application124 is installed onmobile device100—that is, newly stored inmemory122 for present or later execution byprocessor102—memory122 and particularly sharedcache126 can be managed to provide the data required by thenew application124, as will be discussed in greater detail below with reference toFIG. 3.
FIG. 3 depicts a flowchart of amethod300 for managing memory in a mobile electronic device.Method300 will be described in conjunction with its performance on mobileelectronic device100, though it will be understood that neither mobileelectronic device100 normethod300 need be exactly as shown. For example, the blocks ofmethod300 need not appear in exactly the order shown inFIG. 3.
Beginning atblock305, mobileelectronic device100 receives a request to install anapplication124 atprocessor102. For example, the request can be received frominput device121 or from a remote computing device (not shown) vianetwork108, link106 andinterface104.
Proceeding to block310, mobileelectronic device100 receives at least one indication of data intended to be maintained in sharedcache126 for use by thenew application124. Such an indication can be received atprocessor102 during installation of theapplication124. In general, the at least one indication can be a representation of data required by theapplication124 that can be used in the remainder ofmethod300 to manage sharedcache126. In some embodiments, the intended data (that is, data to be maintained in sharedcache126 for use byprocessor102 during execution of thenew application124, following its installation) can comprise at least one name-value pair as described above in connection withFIG. 2. Further, the at least one indication for a given name-value pair can be the name from that name-value pair. Thus, during the installation ofapplication124processor102 can receive at least one name from at least one name-value pair intended to be maintained in sharedcache126.
Method300 then proceeds to block325, whereprocessor102 can be configured to determine whether any indications remain to be processed. It will now be apparent that a plurality of indications can be received during the installation ofapplication124. That is,application124 can require that a plurality of items of data—for example, name-value pairs—be maintained in sharedcache126 for use during the execution ofapplication124.
If the determination atblock325 is affirmative,method300 proceeds to block330, where the next un-processed indication is read byprocessor102.Method300 then proceeds to block335, whereprocessor102 can be configured to determine, based on the indication fromblock330, whether data exists in sharedcache126 corresponding to the intended data required byapplication124. In some embodiments,processor102 can thus be configured to assess whether sharedcache126 contains a name-value pair with a name corresponding (that is, equal to) to the intended name read atblock330.
In the present exemplary performance ofmethod300, it will be assumed that the first indication read atblock330 is the intended name “Sync Contacts.” The determination atblock335 is therefore affirmative, as sharedcache126 does contain a name-value pair with a corresponding name.Method300 therefore returns to block325.
Following another affirmative determination at block325 (meaning that another indication remains to be processed during the installation of application124)method300 proceeds again toblocks330 and335. It will be assumed that the next indication read atblock330 is the intended name “Push Notification.” For this indication, the determination atblock335 will be negative, as “Push Notification” does not appear in sharedcache126, as shown inFIG. 2.Method300 then proceeds to block340.
Atblock340,processor102 can be configured to write the intended data to the sharedcache126. The results of a performance ofblock340 can be seen inFIG. 4, whereadditional data206 comprising aname206n“Push Notification” and avalue206v“Email” has been added to sharedcache126.Data206 can thus define a setting which determines the desired method of notification for push notifications resulting from the execution ofapplication124.
Following the performance ofblock340,method300 returns to block325. Referring again toFIG. 4, the results of another affirmative determination atblock325, followed by another negative determination atblock335, are shown.Further data206 has been added to sharedcache126, comprising aname206n“ABC_Logo” and avalue206v. Value206vcan be an image file. For example,value206vcan be the logo of an entity associated withapplication124. The logo can be displayed in arepresentation120 generated bydisplay module116 during execution ofapplication124. It will now be apparent that various types of data can be stored as values in sharedcache126. For example, textual and numeral values can be stored, as well as images, videos, sound files and the like.
In the present exemplary performance ofmethod300, the next determination atblock325 is negative. In other words, following the processing of three indications as described above, no further indications remain to be processed during the installation ofapplication124.Method300 then proceeds to block345.
At block345 a further request can be received to install afurther application124. Following performance ofblock345,method300 returns to block310 and the receipt of indications and determination of whether or not corresponding data exists in sharedcache126 can be repeated. It will be understood that performance ofblock345 need not take place immediately after performance ofblock325. Rather, performance ofblocks325 and345 can be separated by a wide variety of time periods—two minutes or three years or any time period in between, for instance. The performance ofblock345 illustrates thatprocessor102 can be configured to manage sharedcache126 of mobileelectronic device100 during installation of any of a variety ofdifferent applications124. In some embodiments, the next performance ofmethod300 resulting from a further installation request can therefore result in no data being added to shared cache126 (if all the indications received in connection with the further application are representative of data already contained within shared cache126).
Referring now toFIG. 5, a method500 for managing memory according to another embodiment is shown. It will be noted that several blocks of method500 are similar to blocks ofmethod300. Those blocks are numbered similarly to the corresponding blocks ofmethod300, with the exception of leading “5” being used rather than a leading “3.” Thus, blocks505,510,525,530,535,540 and545 are as described above in connection with their corresponding blocks ofmethod300. Method500 also includesblocks515 and520. Performance ofblock515 can take place after performance ofblock510. Atblock515,processor102 can be configured to determine whether sharedcache126 exists. If the determination is negative,processor102 can be configured to create sharedcache126, for example by reserving a predetermined amount of storage space inmemory122. Method500 then proceeds to block525. If the determination atblock515 is positive, method500 simply proceeds to block525.
Referring now toFIG. 6, amethod600 for managing memory according to a further embodiment is shown. As with method500 above, blocks similar to those ofmethods300 and are identified with similar numbers (with a leading “6” rather than a “3”). Thus blocks605,610,625,630,635,640 and645 are as described above in connection with their corresponding blocks inmethod300. Atblock610, however, the indications received can include both the name and the value of a name-value pair intended to be stored in sharedcache126.
Following an affirmative determination atblock635, rather than return to block625method600 proceeds to block650. Atblock650,processor102 can be configured to compare the intended value included in the indication with the existing value associated with the corresponding name within sharedcache126. For example, the indication can include the intended name “Sync Contacts” and the intended value “No.” Referring briefly toFIG. 4, the determination atblock635 is affirmative as sharedcache126 does contain acorresponding name202n“Sync Contacts.” However, the determination atblock650 is negative, as the associatedvalue202v(“Yes”) does not match the intended value of “No.”Method600 therefore proceeds to block655, whereprocessor102 can be configured to overwrite the existingvalue202vwith the intended value. It will now be apparent that in some embodiments, the overwriting atblock655 can occur after a confirmation or request to overwrite (not shown) is received, for example in the form of input data received atprocessor102 frominput device121.
When the determination atblock650 is affirmative,method600 simply returns to block625.
It will now be apparent that as data maintained in sharedcache126 can be accessed byprocessor102 via execution of any of a variety ofapplications124, changes made to sharedcache126 during execution of an application can affect the execution of a different application. For example,data204 of sharedcache126 can be edited during execution of an application by way of input data received atprocessor102 frominput device121. The editing can be, for example, a change ofvalue204vfrom “Email” to “Ring.” Subsequent execution of another application which configuresprocessor102 to readvalue204vcan then be affected in that notifications generated byprocessor102 occur as ring-tones rather than emails.
Certain advantages will now occur to those skilled in the art. For example, rather than each one ofmultiple applications124 maintained onmobile device100 creating a separate cache with data for use byprocessor102 during execution of that application, data within sharedcache126 can be re-used byprocessor102 during execution of different applications. This allows for reduced usage ofmemory122 of mobileelectronic device100. Other advantages may also occur to those skilled in the art.
As a further variation, in someembodiments processor102 can be configured to examine the contents of shared cache126 (that is, the settings and content stored therein).Processor102 can further be configured to retrieve and install new (i.e. currently not present on mobile electronic device100) applications based on the results of the examination.Processor102 can also be configured to controldisplay module116 to generate arepresentation120 recommending certain new applications to a user of mobileelectronic device100.
Persons skilled in the art will appreciate that there are yet more alternative implementations and modifications possible for implementing the embodiments, and that the above implementations and examples are only illustrations of one or more embodiments. For example, elements of the various methods described herein can be combined. That is,method300 can include a cache creation step, method500 can include an overwrite step and so on. The scope, therefore, is only to be limited by the claims appended hereto.