Memory and Memory Issues Data Storage

1. Memory and Memory Issues Data Storage

2. Types of BB Memory • Internal Flash Memory • aka application storage, onboard memory • internal to the device • contains the operating system and BB JVM (about 10MB to 15MB) • only place where apps can be run • available on all bb devices • stores email messages, organizer data, personal information, etc • where persistent objects/data is stored • older devices around 32MB or more • storm is 128MB, storm 2 is 256MB, torch is 512MB Wendi Jollymore, ACES

3. Types of BB Memory • SRAM • http://www.webopedia.com/TERM/S/SRAM.html • Static RAM • Working memory • E.g. when a persistent object is accessed/edited it is copied to SRAM and worked on there • Controls transient data objects • data objects that have been created during an app session and not saved anywhere • Controls runtime processes • BlackBerry stopped posting amount of SRAM on devices :P Wendi Jollymore, ACES

4. Types of BB Memory • External SD (Secure Digital) cards • microSD card that can be inserted to extend storage on device • optional, removable, contains a FAT file system • supported on o/s 4.2 or later, except 8700 series • amount of SD card storage varies • the device can support up to a certain amount (see specs for each device) • users might only have a certain sized card • E.g. Storm, Storm2, Torch all support up to 32GB card, but some carriers include 8GB card with device Wendi Jollymore, ACES

5. Types of BB Memory • Built-in media storage (device memory) • embedded multimedia card (eMMC) • not removable • also known as internal memory or onboard device memory • not on all devices, and size varies on those that have it • E.g. Storm has 1GB, Storm 2 has 2GB, Torch has 4GB Wendi Jollymore, ACES

6. Persistence & Object Handles • Persistent storage – storage that persists when app is not running and device shut off • Data that isn’t deleted when app stops or device resets/shuts down • The opposite is non-persistent storage • Data that is still there as long as the device is running • But is lost when the device shuts off/resets Wendi Jollymore, ACES

7. Persistence & Object Handles • Two kinds of object handles: • Object Handles (Transitive Object Handles) • Every object you use requires a “handle” in memory • Think of it sort of like a reference to that object • Persistent Object Handles • For objects that are persisted across device resets • i.e. stored persistently on the device Wendi Jollymore, ACES

8. Persistence & Object Handles • Example: A vector of 10 strings will consume 11 persistent object handles • 1 handle for the vector • 10 handles for each string in the vector • There is a fixed number of persistent object handles available in the system • Determined by the amount of flash memory. • A 32MB device is limited to about 65,000 persistent object handles and 132,000 object handles. • You could run out of persistent object handles well before you run out of memory Wendi Jollymore, ACES

9. Low Memory Manager • If SRAM runs low, JVM swaps with flash memory • If flash memory is full, problems! • Garbage collector tries to free up memory no longer in use • When SRAM and flash memory get full • Garbage Collector runs more often and it will take longer Wendi Jollymore, ACES

10. Low Memory Manager • Handles memory resources on the BB when available • When resources fall below a certain thresh-hold • Frees used memory to provide more available memory • All apps work with the low memory manager to free as much memory as possible when device is low on memory • When low memory manager will work: • Amount of flash memory falls below a certain threshhold (usually 400KB to 800KB) • # of persistent object handles available falls below 1000 • # of object handles available falls below 1000 Wendi Jollymore, ACES

11. Low Memory Manager • Will remove low priority stuff like cached data • Then will go to medium priority stuff • old emails and out of date calendar entries • If critical, will remove more recent emails, phone logs, etc Wendi Jollymore, ACES

12. Conserve Memory Resources • Flash memory • Refers to the raw persistent storage space that is available on each handheld. • Remember that this is fixed • Amount depends on device • This is where persistent data and object handles are stored Wendi Jollymore, ACES

13. Conserve Memory Resources • Reduce the number of objects! • Fewer objects means fewer persistent object handles and object handles • Recall Vector example with 10 String objects • 11 handles • If you had 3000 records, that’s 33,000 handles • On some older devices with only 16MB memory, this is too much • A device with 16MB flash memory can only hold 27,000 persistent object handles Wendi Jollymore, ACES

14. Conserve Memory Resources • Data Structure Selection • Make sure data structure contains minimum possible number of objects • especially with vector or hashtable - great objects but resource heavy - avoid using if possible • Use primitive types instead of objects - primitives require no object handle • Note that an array is an object so an array of primitives requires one object handle • Strings are equivalent to byte arrays so a string will take one object handle Wendi Jollymore, ACES

15. Conserve Memory Resources • Object consolidation • Recall Vector example with 10 String objects and 3000 records • net.rim.device.api.system.ObjectGroup • allows you to group objects so that they take only one handle • string example that takes 11 - can group this into 1) • Problem: grouped objects are read only • so if you edit, you must ungroup, change, re-group again – can affect performance • also ungrouping it obviously requires all the object handles again Wendi Jollymore, ACES

16. Minimize Memory Usage • Use primitive data types instead of objects • E.g. use int instead of Integer • Do not depend entirely on the garbage collector. • Avoid creating many objects quickly. • Set object references to null when you are finished using them. • Reuse objects as much as possible. • Move heavy processing to the server. • Example: filter or sort data before sending it to the BlackBerry smartphone. Wendi Jollymore, ACES

17. Storage Choices • MIDP RMS (record mgmt system) • simple non-relational database format • stores data in arrays of bytes • not much support for sharing data between apps • app data is attached to app, so when app is removed from device, so is data • use this if you're developing for older devices or developing a MIDlet • javax.microedition.rms package Wendi Jollymore, ACES

18. Storage Choices • BlackBerry Persistent Store • similar to RMS • easier to store wider range of objects • can store instances of custom classes • offers optional compression and security • most popular • can be written only to the devices internal flash memory • persists across device resets Wendi Jollymore, ACES

19. Storage Choices • runtime store • similar to persistent store • doesn't persist across device resets • used for apps to share info Wendi Jollymore, ACES

20. Storage Choices • FileConnection API • Allows access to BlackBerry file system • files and folders • Can access application storage, SD card, device memory • File system is where media, pics, downloaded files, attachments from emails, etc are stored • Accessible by all apps on the device • Good for large files, pics, documents • Good for files that need to be accessible (e.g. thru desktop manager) Wendi Jollymore, ACES

21. Storage Choices • SQLite (5.0 and later) • Full database for structured data • Can store and access data on device's internal memory and external sd cards Wendi Jollymore, ACES

22. BB Persistent Store • Stores data to flash memory • Can't access SD card • not good for documents or anything large • Flash memory contains the O/S, email, other data • still should be a lot free – check device specs Wendi Jollymore, ACES

23. BB Persistent Store • net.rim.device.api.system.PersistentStore • Manages a list of keys (long) and objects (PersistentObjects) • List is global across all apps • You don't know which keys are in use by other apps • However, key space is large enough that conflicts never occur • Think of key like the ID or file name Wendi Jollymore, ACES

24. BB Persistent Store • net.rim.device.aip.system.PersistentObject • PersistentStore.getPersistentObject() • returns an instance of PersistentObject • even if key hasn't been used before • therefore, you will always get back a PO, but it might have a null value • so either nothing has been saved with that key or it was deleted Wendi Jollymore, ACES

25. BB Persistent Store • PersistentObject persistentObject = PersistentStore.getPersistentObject(0x2a5c4229e4666089L); • Contents of the Persistent Object are accessed via the getContents() method, which might return null: • Object contents = persistentObject.getContents(); • To set or replace the contents of a PO, use setContents() method: • Hashtable hashtable = new Hashtable(); • persistentObject.setContents(hashtable); Wendi Jollymore, ACES

26. BB Persistent Store • Setting contents doesn't necessarily mean object has persisted • must call commit() method: persistObj.commit(); • Persistent Object maintains a reference to its contents • to change the data in the persistent object, you must modify the instance and call commit() • you don't need to call setContents() again unless you want entirely different object to be associated with that key Wendi Jollymore, ACES

27. BB Persistent Store // This will persist MyKey and New Value // no need to call // persistentObject.setContents() again hashtable.put("MyKey", "New Value"); persistentObject.commit(); Wendi Jollymore, ACES

28. What Can You Persist? • Only objects, not primitives (use wrapper classes) • Any object you persist must implement net.rim.device.api.util.Persistable interface • Some other classes are allowed even though they don't implement Persistable: • wrapper classses, Object, String, Vector, Hashtable • Arrays of primitives and other persistable types Wendi Jollymore, ACES

29. What Can You Persist? • Persistence saves entire object including all objects it references • Objects your object references must also be persistable • e.g You want to persist a Hashtable of Employee objects • Employee class must be persistable (implement Persistable interface) Wendi Jollymore, ACES

30. Exercises • Do the example in Beginning Blackberry (Persistent Store section) • Do the tutorials and lab from the RIM materials • There is also a lab using Runtime store from the RIM materals • All of this is in the notes Wendi Jollymore, ACES