Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Will making 2 database in firebase realtime database help to reduce cost and increase daily download limit of 360MB per day?
The simplest way to reduce the cost is by reducing the downloads. You can do that by caching the data on local storage as much as possible and continuously sync sensitive data.
While reading different articles, one article caught my eye. I'll summarize my findings and also add the link to the article.
Optimizations Possible:
Optimize serialized data saved in the database, this can be achieved easily with GSON, a library to handle JSON data that allows changing the name of serialized entities with annotations. (There are many other libraries that can do the same) GSON #SerializedName
Implementing a memory cache that is kept only during the life of the App. This cache works as follows:
User opens the app and goes somewhere in the app where any kind of favorites is listed, let’s say Bus Stop favorites.
The App requests to the memory cache a list of Bus Stop favorites but as the App has just been launched it returns null.
Then the App requests to Firebase only the node containing Bus Stop Favorites, which are downloaded from the internet and then billed once.
A copy of this favorites is saved in the memory cache.
User plays with favorites, adding, removing or editing them.
Every time a modification is done the resulting favorites list is saved in the memory cache and also sent to Firebase (because uploading data is free).
Now the user can leave the App, and unless it is explicitly removed from the recent App stack by the user or killed by Android, the user can come back to the App and continue playing around with the Bus Stop favorites without incurring in extra billing.
Link to the article mentioned.
Hope this helps!!!.
try to derive data from other data (for example if you have a voting app, instead of storing the number of people that voted, the number of people that upvoted and the number of people that downvoted, you can store only the upvotes and downvotes and do maths to calculate the total amount of people who voted)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
A little background: The main page contains about 25 thumbnail images displayed in a recycle view. I receive a JSON response from an API containing the urls for those images alongside other data.
I save the JSON string in an objectBox database instance and use GSON.fromJSON to create the actual objects when I need to display them. Btw I use the MVVM pattern.
Now there are three scenarios I would like to consider:
1) when changing activities any currently not displayed activity can be deleted at any point by the os without warning and the images with it. Should I cache the images (where? in memory (don't want to waste it) or storage?) or should I just download them again when user returns to the main activity? Seems to me like downloading the images every time user switches the activities would be quite demanding.
2) when user switches off the application entirely and launches it again everything not saved on disk will be wiped off. I would be ok to download the images in this case since it's just one time process and the database will probably need bringing up to date anyway.
3) finally when the phone is not connected to internet the app should display some images even though they might not be current.
So my question is, how should images be cached in scenario like this one and what's the right way to do it?
Can I cache images in objectBox directly or would i be better off with SQLite? Or should i use some other library like Picasso for caching?
Generally yes, images should be cached in at least memory, and depending on your app (how likely is it to be reused,etc) in memory and storage. If you want to support your 3rd point (displaying when offline), you need to do storage caching, and memory caching is optional but probably a good idea.
What library (or if you use a library, I've had good reasons to roll my own on a few times) to use is way off topic for this site, as its mainly opinion. And we'd need lots of specific knowledge of your usecase to advise one over the other.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I'm seeking assistance on a APP I need to create. I don't have no experience with android app development but, I'm studying and practicing.
I'm trying to build an app to record payments from a list of customers and print a receipt when paid. I download a list of customers with pending balance, using json array into android. Now, I'm confused, don't know if I should use arrays or a database to store the list, since I need to update (upload) later to the server. SQLite seems like an option but, I have to download the list every time user is connected to WiFi.
I guess I have to store the payments on an array and flush it once uploaded.
Can you please tell me what would be the best option for the tasks I'm trying to accomplish.
It depends on your use case. Arrays and sqlite can work independently or together.
If you are going to upload the data instantly after downloading within the same session, then you can keep it in the Array and upload it after what ever you need to do with it. Keep in mind that Arrays will be kept in memory and depending on where you are keeping the array object, they might not persist through the life cycle of an activity or the life cycle of your application.
SQLite on the hand writes data to disk, so you will be able to persist it even after user has backed out of your application.
...since I need to update (upload) later to the server
Based on the above, it seems like you should persist your data on disk. SQLite is one of the options for persisting data. Have a look here to see what else is available for persisting data.
You can load up any persisted data into your array and upload it after you have processed it.
Hope this helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am currently creating an app that is a guide for a game which involves the user navigating through categories and a large amount of information being displayed. For instance, if I wanted to review information regarding a specific weapon, I may navigate through Items > Weapons > Ranged > Bow. What would be the best to to set this up so the app would run smoothly? I may have up to 100 of these different items the user can view.
The two current approaches I am considering is either making a local SQL database of all of these items, and then having one activity that pulls from the database based on what the user selects. The other being to just make string resources and then load those resources depending on what item the user selects. Any opinions or insight would be much appreciated.
I am not sure about string resources but if you are doing "read only" operations on the data and not saving any user input I would suggest NOT using SQLite. The problem with SQLite for this use is that you will have to create the tables and populate the database programmatically the first time that the app is run. (someone correct me if there is another way to do this) Basically you will end up writing all of your information as strings or reading it from a file on the device anyway, it will just get inserted into the database and be accessed from there every time after. Another drawback is that every time you want to update the information in the app you will have to add rules in the "onUpgrade" method of the database handler. Accessing the data from SQLite will be faster than reading files but IMHO it is a way bigger pain than it is worth for just read operations (unless you have massive amounts of data.. "massive" in the computer world happens to be pretty darn big).
I would probably store the data in your own files (XML, JSON, or just plain text) and put it in the assets folder. Using a nice folder structure and good file naming in there would allow you to add new information without having to change your program.
Another option is to build a web database, pull the information from there, and save it to the local SQLite database when there is an update to the information that you saved online. This makes it easy for you to make revisions to the content without having to send out an app update but takes quite a bit more work
The Content Provider is the prefered way to store big data on the android platform and fortunately many tools are available to do the hard work for you. With that said I would hardly consider 100 a large amount of data even on a mobile device. Will the data change? In other words is it static or dynamic? I recommend the Content provider but you could use shared preferences, a resource file or even hard code your values.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am developing an android app which handles a lot of text. I'm confused at the data storage and retrieval, Which one should i use for faster data retrieval? Sqlite or file storage (json files, separate file for each category ). First I thought about sqlite because it is more easy to manage data, but it will take sometime to create tables with almost 1000 rows in each table or i have to ship the database with my app and it will increase the download size and then i thought about file storage. Which one should i use, sqlite or json file as the data creation is a one time process an the rest is retrieval? Can anyone suggest a better way, i'm really, really confused.
Assuming that the table creation only happens once when the app is installed, then unless the table creation is very, very slow you can simply do it at app first install and include some appropriate message to the user on the screen.
Ideally, if your app can do other useful things without using the data then you can let the user use other parts of the app while the table creation completes in the background.
I have found from past experience that creating very large simple tables is actually very fast, but you would need to test to see how long your examples take.
Note also that you have the option, through the onUpgrade method of the SQLiteOpenHelper, to only modify the parts of the database that you need to at upgrade times, so you may not have to recreate the full data base when installing new versions of the app. This also includes mechanisms to avoid delaying app startup by deferring the updates until the database is first used, although that may not be what you want in this case.
If you have a lot of text and data, use greenDAO. It will handle your SQLite related stuff. It's a bit confusing at start, but once you tried it you will never use SQLite on Android without it:
http://greendao-orm.com/
Some interesting links:
http://developer.android.com/guide/topics/data/data-storage.html
http://developer.android.com/training/basics/data-storage/index.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 months ago.
Improve this question
I'm making an ecommerce application on Android and, as it is my first serious project, I'm trying to figure out beforehand the best approach to do this.
The application talks to a web service (magento api, meaning soap or xml rpc unfortunately) and gets all the content on the phone (product categories, product details, user credentials etc.). I think it should do lazy loading or something like that.
So, I was thinking to keep the user credentials in a custom Object which will be kept in a SharedPreferences so that every Activity can easily access it. I'll use a couple of ListViews to show the content and AsyncTask to fetch the data needed. Should I keep all the data in memory in objects or should I use some sort of cache or a local database? Also, I'm planning to use a HashMap with SoftReferences to hold the bitmaps I am downloading. But wouldn't this eat a lot of memory?
How can all the activities have access to all these objects (ecommerce basket etc.)? I'm thinking of passing them using Intents but this doesn't seem right to me. Can SharedPreferences be used for a lot of objects and are there any concurrency issues?
Any pointers would be really appreciated. What are some good guidelines? What classes should I look into? Do you know of any resources on the Internet for me to check out?
A very detailed question I will do my best to answer it.
I used the following approach in my application:
I save the user credentials in the shared preferences. The preferences can only hold custom objects if they are serializable and writing and reading from flash memory takes a lot of time. Therefore I load the preferences on startup and store them in memory.
I try to keep all the data in memory that is needed in many places and in a consistent state, all the other memory is passed via serializing to json and passing through an intent or i pass only ids and I re fetch it from the net. (There is definitively a possibility for cashing in a local database but the effort to keep it up to date is to much work at the moment.) To store objects that take to long to reload from internal memory or network and re parse it I use a custom application that holds the reference to some controller objects which manage the caching. The application will stay in memory until your app is closed. This is convenient but can result in needing way to much memory if you are not careful.
The bitmaps that are downloaded by my program are cached on two layers. At the first time I want to access an image I create a image manager object inside my activity scope. That object will try to find the bitmap in an internal map. If it is not there it will try to load it from phone memory if it is not in the phone memory it will download it from the net, store it in the cache folder of my app and put it in the map. In this way the bitmap is accessible as long as the activity runs and is cleaned up at the moment the user changes to another screen. Until now this is sufficient for me.
At the end just begin programming and come back if you encounter other questions or errors and post some more specific questions.
Many useful techniques that you will need to use: ContentProviders, AsyncTasks, Bitmap Caching, ... are used in Romain Guys 'Shelvs' (http://www.curious-creature.org/2009/01/19/shelves-an-open-source-android-application/) app. It's a great start point to get the into a recommend Android flow.