I am creating an application that allows the user to store information about food recipes that they can share on social media. I have an activity that allows the user to upload an image, write ingredients and directions for the recipe. In the past I have worked with shared preferences for saving user information, however, I know that the information stored is unordered. So I want to know what type of storage I should use to achieve this outcome....
My activity that saves user data:
From this I want to load the information into a previous activities list view that will have this type of list element layout:
From this what type of storage approach should I take? if I use shared preferences can I just place the parts I need into the elements of the list manually, for example, extracting the image saved from the user and placing that inside the image section of the listviews? or will the limitations of shared get in the way and maybe use internal storage? what would be the best approach?
Form a structured JSON object out of your data and you can use REALM. It is a new and easy alternative to SQLite.
It is very fast, easy to learn and integrate in your app.
Also, it is scalable means if you decide that you will be taking the same data to your backend then it will be easy for you to handle large amount of data.
Related
I'll provide a link of website so you can understand better what I'm trying to achieve.
If you go on link and then go on > Adventure Holidays > Summer Camps you will get on page where site provide you a random document from collection. So far there is just two documents but you'll get it. So, I want to have different image from each documents that user get.
If user get Kieve Summer Camp show him image of Kieve Camp and so on. But I'm stuck.
Is a better option to create Photo collection and then that collection to connect with every other collection and than compare IDs from photo collection with other documents from other collection? Or is a better way to add field photo on each document and get that image like I'm now getting title, description and etc?
It depends on your needs. The sentence with collection 5 times in it is very confusing. I thing your question is if you should embed or reference the images. In my opinion it would be the beste to store images file based an store just a Link in MongoDB. MongoDB is not a file storage and limited to 16MB per document. I don’t know how big your images are but a file based storage would be the best solution.
So if you stick to your solution I would say to store each image as an own document, maybe with metadata, in a Collection just for images.
I'm trying to implement categories for a mock food delivery app in android.
I want to have categories for a restaurant like burgers, pizza, etc. Within each there might be any number of food items. And these restaurants would include n categories. How do I implement something like this?
For now, the data will be hardcoded into the program for just a proof of concept so please do not include databases as I'm still learning android and am not very familiar with SQLite or FireBase, etc.
This depends on how you want to access the data. You can make Category an Enum and assign it to FoodItem, then have Restaurant have an ArrayList of FoodItems.
OR
You can make Category a class with an ArrayList of FoodItems, and have Restaurant have an ArrayList of Categories.
According to your concept, it looks like you're going to integrate any Web API (REST or anything else like firebase) to fetch data from Web Servers.
I would suggest to do the following:
Create a .json file having your content that you might need to display.
Make some model data classes related to your .json file that needed to be parsed.
Now, read your .json file temporarily from assets folder to get content most out of it (then display it in your app).
In such a way, if you've to do some JSON parsing in nearer future, you'll already have all stuffs needed to parse that JSON (like your Data Transfer Objects DTOs) and code for parsing as well.
So at that time, all you'll have to do is integrate some HTTP client and setup end point because, you're already having JSON parsing at your end or setting up with Firebase (Rest of stuffs are already handled).
I display dates to the user in a layout that are let's say are textual.
When the user presses a button I want to get the information in those fields that represent these "dates" but if I get the text in them is not of value to me.
I would need to store somewhere the original dates that created these "textual" elements and fetch them from there.
Is there a specific construct in android that one can use as a stash area or should I just use a static class with variable to hold them?
In your case, you should use SharedPreferences to store the data by converting it into a String (text) or int/long first.
This will allow you to easily write and retrieve data, and you should use this.
You can also use the file system to save almost any Java object using serializable, on Internal Storage.
Either way, the data will stay there even if your app is closed or the device is turned off.
I'm in the early stages of a note-taking application for android and I'm hoping that somebody can point me to a nice solution for storing the note data.
Ideally, I'm looking to have a solution where:
Each note document is a separate file (for dropbox syncing)
A note can be composed of multiple pages
Note pages can have binary data (such as images)
A single page can be loaded without having to parse the entire document into memory
Thread-safety: Multiple reads/writes can occur at the same time.
XML is out (at least for the entire file), since I don't have a good way to extract a single page at a time. I considered using zip files, but (especially when compressed) I think they'd be stuck loading the entire file as well.
It seems like there should be a Java library out there that does this, but my google-fu is failing me. The only other alternative I can think of is to make a separate sqlite database for every note.
Does anybody know of a good solution to this problem? Thanks!
Seems like a relational database would work here. You just need to play around with the schema a little.
Maybe make a Pages table with each page including, say, a field for the document it belongs to and a field for its order in the document. Pages could also have a field for binary data, which might be contained in another table. If the document itself has additional data, maybe you have a table for documents too.
I haven't used SQLite transactions on an Android device, but it seems like that would be a good way to address thread safety.
I would recommend using SQLite to store the documents. Ultimately, it'll be easier than trying to deal with file I/O every time you access the note. Then, when somebody wants to upload to dropbox, you generate the file on the fly and upload it. It would make sense to have a Notes table and a pages table, at least. That way you can load each page individually and a note is just a collection of pages anyway. Additionally, you can store images as BLOBS in the database for a particular page. Basically, if you only want one type of content per page, then you would have, in the pages table, something like an id column and a content column. Alternatively, if you wanted to support something that is more complex such as multiple types of content then you would need to make your pages a collection of something else, like "entities."
IMO, a relational database is going to be the easiest way to accomplish your requirement of reading from particular pages without having to load the entire file.
I have a dialog box that the user inserts various data through gui controls,
and this information is saved as an xml file (implemented in java).
The information stored in the xml file is configuration information
for the application.
I can manually modify the xml configuration file, but I also want to provide this capability through a UI as well.
So when the dialog is opened (for creation of configuration) a corresponding well-defined object is populated by the various values input by the user.
Once the user presses 'save' the information in the object is stored as xml.
Now I was thinking to provide the option for edit the file via UI. So the same dialog is displayed to the user, but this time with the configuration information already filled-in by the loaded file. The corresponding object is populated as well.
I am not sure what is the best way to modify the file at this point.
Should I use 2 objects, 1 that stores all the file's info and 1 that stores the modified values from the dialog, and start comparing the objects for changes so that I modify the file? Or should I delete the file and create a new one?
Which is the best approach, and how would I proceed in each?
Thank you
Consider the data flow. The user will work with the GUI and make changes. The moment they make a modification, the data on the GUI is out of step with the XML. If the user opts to save the data then a simple marshalling operation (trivial if using JAXB) will ensure that the XML is updated. You don't need to compare every field, there's no point - of course you have validated the contents prior to committing them to file. If the user opts to cancel then no marshalling takes place.
There is no need to make a backup and no need to compare what is already in the XML.
However, if the user needs to be able to undo a save (such as revert to previous configuration) then you'll need a backup structure (or maintain a stack of GUI models in memory). I would not recommend that approach, though, as you're just chucking in needless complexity. Users are typically happy with a Save or Cancel button and no Revert.
Keep it simple. Just overwrite the entire file using the updated object. Then you won't need any special code for each case. All you will need is one method to marshall the object into the file and one method to un-marshall it.