I'm making an app that has a listview with a child listview for each parent listview item. The children have a few children items as well. You can add/delete an element from any of these lists. I'm concerned that using MODE_APPEND will be a difficulty because I'm assuming it just appends to the end of the file and I actually want the elements to be grouped together in the file. I'm doing all of this to make sure that the data is available upon the application being destroyed and reopened. I'm also worried that MODE_APPPEND isn't private like MODE_PRIVATE is.
http://developer.android.com/reference/android/content/Context.html#MODE_APPEND
I wouldn't use MODE_APPEND. There shouldn't be no security concerns about that, but it should be easier to handle (group by datatypes, ...) the data by reading and writing the file each time.
Another possibility could be using SQLite as database for storing these values.
Related
I have an adapter, which data consists of my classes AppData (with fields : String, String, Drawable). I implemented drag and drop feature in my recycler view , so I can change views position -> my adapters data changes(actually elements in List are swapped).
But when my activity is killed/ device is rotated data is recreated and positions the order is lost.
I tried this:
implemented Parcelable in AppData and tried to save data in onSaveInstance(). But the size of data is to large to store it in Bundle.
How can I save this order?
Thanks everyone for answers in advance!
I think I have your answer. But before that, try to use this adapter. It implement every thing you need for a recycler view. Make your life easier
https://github.com/CymChad/BaseRecyclerViewAdapterHelper
You don't need to persist all your data, store just the unique part of it. E.g. if your AppData class contains information about apps, it will probably contain the package name, which is sufficient for identifying your objects. It is sufficient to store the package name and the order in the list to be able to rebuild the list in the right order in the future.
Assume we have an Activity with n TextViews that represent one line notes. These notes are stored somewhere (local database, network etc), and each time onResume() being called, the proper number of TextViews are drawn according to that stored data.
Now, lets say the user want to delete a note, what would be the best way the resolve the specific TextView, back to its storage entity?
At the moment, the only way I know is by using View.Tag, and having some manager to translate it to data entity, but it look rather messy.
Are there any other options?
In Android, the Adapter acts a bridge between the view and the data model. You could display the n TextViews in either a ListView or a GridView, and when the user adds or deletes a note, the local or server database is first updated. Upon completion of the web service call and/or the local database update, the new data is added to the underlying Adapter. The View is then refreshed by calling adapter.notifyDataSetChanged(). This would be the way to do it.
Approaches:
If updating the local SQLite database, you could consider using a
CursorAdpater
to hold the data for the View, as it directly maps the entries in
the local database to the View.
If making use of a ContentProvider, it is even possible to combine
a CursorAdapter with a
LoaderManager
and a
CursorLoader:
these plug into the Activity / Fragment life-cycle and monitor
the underlying ContentProvider for changes that are published
automatically to the View on a separate thread.
It is also possible to use a
Filter
in conjunction with the Adapter to define a dynamic mechanism that
sorts the data entries on-the-fly. The filtering is performed by the
Filter on a separate thread, as per a query entered by the user,
possibly in an
AutoCompleteTextView.
References:
See the Retrieving a List of
Contacts
tutorial. The example here retrieves a set of contacts from the
contacts ContentProvider based on a dynamic, alphabetical search by
the user. It makes use of CursorAdapter, CursorLoader and
LoaderManager to monitor and update the data, and it displays the
search results in a ListView.
See also the Android Realtime (Instant) Search with Filter Class example, which shows how a Filter is to be used.
Android AutoCompleteTextView with Custom Adapter filtering.
Android AutocompleteTextView using ArrayAdapter and Filter.
My music app is referencing persistently stored data. All are currently stored as text files:
Favorites - single text file array. App starts, reads the text file, stores in memory. Array is checked when ListView is expanded. If array changes text file is rewritten.
Last Played - single text file array list. Updated every 5 seconds. Retains the history of the played songs to allow the user to return to any album and resume position.
Playlists - currently individual text files, one for each list. List of playlists generated from file names when required. Each playlist text file has array list inside it. Read Write when required.
Most Played - single text file array list. Updated once per song played.
I am wondering whether this data would warrant the need to change to a database, or whether I have taken the right approach. I don't foresee the need for adding additional data so this should be the most I would need.
Advice please!
You can store the text files in SharedPreference and it should work well.
Database if preferable if a lot of data needs to be stored. Using a database is more optimal than parsing a string.
The correct approach is to create a class for each of the things you want to represent, e.g. favourites. Each class has a save() and reload() method. The point is that you can change the underlying storage mechanism in the save() and reload() methods without having to change the rest of your code. Imagine in the future, you want to enable saving to Dropbox. You would simply change these methods and your app would just work (OK, you'd need to add stuff to get Dropbox account details but you get the idea).
You could go further and define Interfaces for loading and saving. That interface can use a single class responsible for nothing except saving and loading. As long as any consumer and provider classes adhere to the interface, you can mix and match, and even implement storage approaches yet to be invented, without recoding your app. You only have one class to work with if, and whenever, you change your storage approach.
class StorageManager(){
enum DataType {Favourites, MostPlayed, PlayList };
...
public save(DataType dataType){
if (dataType == DataType.Favourites){
saveFavouritesToDB();
...
...
}
This approach gives you maximum flexibility, maximum future proofing and better maintainability.
I think it would be better to go with Database.
The database should provide you with some optimizations, performance improvements and basically you don't have to reinvent the wheel (doing read / write operations on the disk, use some buffers before rewriting, and the like).
Plus, I think you will love the way all code will be organized and split into its own layers once you start using this way.
Good afternoon,
I have a simplistic app (just learning) that reads some xml data from a mocked up file. The XML data is well formed into 6 categories and I use the SAX parser to read it. My app basically has two buttons prev & next. So when the app loads I'd like to see the first category of xml data. When the user presses next button...well then I'd like to see the next category of data etc. to the end. My question is how do I go back and forth through the data? Do I load it all into a data object with some form of sorting and iterate back and forth throught the object or do I add an atty field to a parent element and just search the xml for the requested atty and child data? I don't forsee the xml ever getting very large. Just trying to get more experienced input into how to go about synchronizing the data with the gui.
TIA
JB
There are many ways you could go about it. One that is generally a decent path is parse the XML into a data structure that can be used by an Adapter to create the view structures and return them so be shown. That will give you a good level of control over how your data looks and allow you to tie in to many different complex View structures pretty easily.
The data structure that you store it in also has many possibilities. Which ones work best would depend on your particular dataset generally.
Given what I know about your data an ArrayList seems like a straightforward approach. Create yourself a class that will hold all of the data about one category. Create objects of that class in your parser as you are pulling the data out of the XML file, each time you get to a new category add your object to an ArrayList. When your done you should have an List structure that has 1 category object(with all of its data) at each index.
Once you've got that set up make yourself an ArrayAdapter with your List. Override the getView() method to inflate your View objects and populate them with the data from your List.
This Adapter can then feed a parent View (ViewPager, ViewSwitcher, ListView etc...) These parent views will make it easy to iterate over your data structures (i.e. switching from one category to the next and back.)
I'm relatively new to Android and have the following question. I have a local DB on the device from which I want to display the content in an ActivityList. Let's say there is a table "person" on the DB containing general information like "name, surname etc."
Every row in the table should be displayed as an item within the ActivityList.
I know that there exists a sort of Adapter with which I can directly fill the ActivityList with my table data, but is this the way to do it?
Isn't it better to load all the data at startup and then hold them for the entire session and pass the data from one activity to another(or make them static..) if necessary, instead of loading the data every time I change to another Activity?
If I would have a normal Java application I would load the Data at startup and then just work with the loaded objects (at least for reasonable data sets).
Doesn't it make sense for an Android App too?
I will up-rate every answer that makes sense to me.
Thanks!
Slash
I would have a look at the ContentProvider.
You can use it to query your database and then show the content in the ListView using a CursorAdapter.
You need to use an Adapter if you want to work with ListView. So, that is a must. And you can set the Adapter data from your Activity.
As for the "sense" question, it probably makes sense. But as always it depends on a few things:
Will this data be used through out the application? Then it absolutely makes sense to load it once and use it everywhere. How you do that is up to your needs, static access or passing the data, all should work.
And DB access is always expensive. And if you have lots of rows, the loading process from the database can be extremely slow. So, again, load it once and use it everywhere is a good plan.
But be careful about blocking the UI thread when you load this data. You should never access DB from your UI thread. Instead use a worker thread or AsyncTask.