I have another question also, one I haven't yet got round to having a bash at coding yet so feel free to complain and tell me to try it first. But I just wanted to know if there is a way of storing data such as references to images
i.e I would have a customer object with a name, age etc and then an image which is contained within the drawable class. So when starting up the Activity (after the first time) I could obtain the name/age primitive types easy enough off of the data store but then when it comes to the image if I store it's id how would I then use that as a reference for the bitmap loader. To obviously avoid retaining two images (the one supplied with the app and if I had to store one to keep the association with the customer object).
Unless the users of your app has a common and amazingly static set of customers you probably don't want to distribute customer images bundled as resources in your app! Store them in the database as blobs.
Related
I saw a similar question but it was a decade old:
My objective is to create an app (Android/Kotlin) where the users can search/reference/lookup an individual item from a reference 'book'. Something along the lines of a dictionary or book of recipes.
The intent is for the app to be able to work offline, when the user may be anywhere.
As there could be thousands of items/records to reference it would seem to be too much for an array.
Is a Room database a good option and, if so, can a pre-loaded database be included in the package that is uploaded to Google Play?
What is best in 2022?
Yes, Room will do exactly what you want, but pre-loading it with data will be tricky (but doable).
You can't technically "pre-load" the database, but what you can do is save all the database objects to a file, using either XML, JSON, or any other format. You will then need to save that file in your project as either an Asset or Raw, and on first app launch, you'll need to read that Asset or Raw resource, parse each record, and save it to the database.
Needless to say, that initial process may take some time, so I'm not sure how good that will be from the user's perspective. But it's definitely pretty straight-forward to implement
Creating the Assets folder
Reading files from Assets
I am developing a launcher for Android and need some advice on designing my persistent storage system.
I wish for people to be able to create different categories for their apps (e.g Media, Utilities, Social). Users must be able to choose the order of their apps and apps can appear in more than one category. Users can update the order of the apps and order should persist on restart. I would also like to keep track of how often apps are launched so that I can have an automatic 'most used' category.
I have had 2 approaches but neither seem ideal:
Save the list of apps to a file (JSON or other), taking note of the package name and position in the list. When required bring this file in and sort by order
Save the list in an SQLlite database, either:
Have a table for each category. Columns would be package_name and list_position
Have a single table, with a column for each category, which stores the position of that app in that category (or null if not present). When a new category is created, a new column is added (not supported in Room).
Option 1 I feel would be tricky to keep dynamic and unsure of efficiency, so I prefer option 2 because its's simple to update and automatically Order By, however it may be overkill to use a DB for this.
Any advice or other possible solutions would be great! Thanks
I'd go for a database approach. I think storing data in a file is perhaps a good choice for small applications where the data don't grow and you flush changes max once before the application is destroyed.
If you want to avoid the boilerplate code of SQLite, then consider Room. Alternatively, you may want to have a look at Realm which is an alternative to SQLite.
If your function is limited then a file based approach works, your approach depends on basis of features you want to have like
-->add i.e (append) specific index or you resorting or shuffling of data is needed.
-->consuming the data i.e If accessing the data in ordered fashion or filtering on multiple features.
Storing data in a file is generally preferred for a small collection of key-values like android Sharedpref itself.
Depending on the functionalities your launcher has the file system gets complex and slower accessing and modification in which case it(file) won't be the best way to store the list of apps (& other info if needed) in a file.
Building a database would help overcome all the complex for future functions like different sorting and other features.
There are many similar questions about this issue but I have clear points about my question to ask you.
I am new at Android development and before only I developed small applications which store small sized data. For example country List, calendar, birthday reminder etc. I stored my small data in single XML file and I parsed it with easy methods. This was enough for me. But for my Mobile Application Development Course I took a project which will store huge static data.
Specifications of my project will like these:
There are about 200 entities.
Each entity has about 20 sub categories which they stored in text format.
Each sub category has about 30-sub categories which they stored again in text format.
Also for each parent entity I will have 2-3 image
If I calculate simply, I have to store 200 X 20 X 30 = 120.000 static data for my application and data does not change. This is only install and use application. Online data interaction is not necessary. (If there are some changes for data I will relase major updates in long periods of time.)
My question is about storing method.
Which way should I choose? SQLite or XML parsing? For your answer can you explain advantages / disadvantages for your choice?
Interesting project, although not necessarily realistic.
To manage a large amount of "static" data, you'll want a database. XML parsing forces you to store the data in memory, which means that you have to read it into memory on a regular basis. Remember that you can't count the in-memory data being around when the user goes to your app; Android may have destroyed your app previously.
On the other hand, you can use an SQLite database on disk directly from your app. It's persistent, even if your app goes away. You'll have to load the database once, when you install the app.
Consider wrapping your SQLite database in a content provider. This will, among other things, allow you to do asynchronous queries using a CursorLoader.
fellow programmers! I'm new... hope you can help!
So. I'm currently developing an application that allows users to choose four different images from a set of images that I have saved in my res/drawable/ folder, and then save those choices as an entry in a database.However, I then need to be able to redisplay those four images when the user asks for them, and I'm not sure what the best way of storing the images is since my current setup isn't going to work for me in the future.
Right now, I have it working so that I actually insert the R.java int identifiers into the database for each of the images, so the database has four columns: img1(int), img2(int), img3 (int), img4 (int). Then when I write a query, I just use those values in place of R.drawable.someImage.
It works fine. Except... when I add new images to my res/drawable folder, all of the drawable ids get changed! Then the ids I have in the database are wrong, and some pull up the wrong images, and some throw NullPointerExceptions!
This is a problem, because I want to be able to update the app with new images after the users download it. How should I be storing these images so that they can be dynamically chosen, but then be reliably be referenced again?
This is a problem, because I want to be able to update the app with new images after the users download it.
I don't quite understand this - if you are going to distribute new images 'after' the users download your app then the new images are never going to have resource ids (as found in R.java) as these are auto-generated as part of the build process.
Do you really mean this or do you intend to update the app with new images and have the users download it again?
If you are going to update the app with new images periodically and have the users download the updated app, you can find the resource id at runtime using...
int resId = getResources.getIdentifier("img1", "drawable", "com.mycompany.mypackagename");
At this point, of course, you'll need to know the names of all the drawables although this could be achieved with a string array in your res/values/strings.xml.
If, however, you want to add new images without the need for the user updating the app, I'd think about maintaining an image directory (on the SD card for example). This way, you would simply just need to store the path to the image files in the DB.
Resources can be accessed as raw data: use AssetManager.open(..) Then you can use BitmapFactory.decodeStream(..) to create a Bitmap from the data stream.
So you can just save filenames of images and instantiate Bitmaps via above commands.
I'm just looking for some insight into what would be the best way for me to store images as part of my app.
I have an activity that represents a 'Job' which has a couple of edittext's and underneath was planning on using the Gallery component to show images relevant to this job.
The job data is stored in a database (on the sdcard) so was also thinking of creating a table to store 'JobImages' and having each image stored as a byte array.
But I'm not sure if it would be better to store the images directly on sdcard under a folder structure specific to my application and the job. E.g. using the job ID number as a folder name.
Depending on which method I use will greatly determine the code that goes into an 'adapter' that allows me to bind to the gallery component so before I begin I was wondering if anyone has had the same design problem and what option they chose.
Thanks,
Dave
Regardless of what storage method you choose, don't let that stop you from writing the code that will use it. Write a class that abstracts this from your app and just gives you images, how/where it retrieves images from, doesn't matter, this will also help you in the future if you decide to change your storage method, you will only have to change this class, not the whole app.
Back to the original question, it depends how you'll be using the images, if you already have a db and need to associate the images with other records or add additional properties (i.e. a database of animals in a shelter with their pictures and other attributes), makes sense to store in a db. If all you care about are pictures that don't have any need to be organized (i.e. the built in Gallery), then store in a folder.
Here's a link on how to store in DB: http://www.helloandroid.com/tutorials/store-imagesfiles-database