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.)
Related
Now I am working on Android application which has one main Activity that is displaying some data via GLSurface. This data can be changed in many ways. For this I have several fragments with some lists of variants with extra logic. Problem is that I need somehow transfer data from one place to another.
For example:
I have fragment with list of elements. I used RecyclerView with custom adapter. I am filling list with data from DB. SomeThingDBEntity for example. When I am getting it from Room DB (using Room entities), but it has some extra fields that only required for showing elements in RecyclerView. I need to send user's choice from adapter to fragment, then from fragment to activity, than activity sends it to some class that incapsulates logic of work with GLSurface. SomeThingGLentity for example. Now I am passing only fields, that requered by SomeThingGLentity for showing data (int, String etc.), but in future this list can grow. I can also send directly SomeThingDBEntity and get required fields only in the end when apply changes to SomeThingGLentity. But is it OK to use Room DB entity this way?
Is there any better way of doing this? I can also create third class which will only contain required fields. But where to place and how to call it? Maybe there are some patterns or guidelines of best way of doing it...
It looks like you need a data mapper. Something similar to this - https://github.com/android10/Android-CleanArchitecture/blob/master/data/src/main/java/com/fernandocejas/android10/sample/data/entity/mapper/UserEntityDataMapper.java.
If you use this approach, you will be able to encapsulate the transformation logic from your DBEntity to your BusinessEntity, and if you will change the data format in one of them, only your mapper will need to be edited.
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.
I am developing my first android Application and hoping to get some tips here.
I am getting a JSONObject from an url which then will be parsed in an ArrayList<MyObject>. The list will be used in multiple tabs and be filtered as needed for the tabs. The objects within these list can be modified by the user and the changes should be synchronized with the lists.
So, to speed up loading time I have created a class DataHolder as a singleton which contains 7 arraylist, based from the one JSONObject in different sorting order and filter criterion. The objects in these lists are references from the original list. Populating the lists works fine.
The lists will be used in different fragments and activities.
Now the problem: the second activity contains tabs with fragments. After initializing the fragment... all arraylists in the DataHolder counts 0! I have to save the JSONObject in SharedPreferences and populate it again to get the List. I can't load the url again because it is slowing down the app to much and using SharedPreferences is not an option (I think) because of the need to synchronized the Lists. I have read that using static variables is not the optimal solution, but it seems to be the easiest way :(
What can I do to solve this problem? Should I use Parcelable Objects and always pass the Lists around? Or maybe use SQLite? Or are there other approaches?
The SQLite way is definitively the correct approach, imho.
You should use the internal database to store such lists :
http://developer.android.com/guide/topics/data/data-storage.html#db
use static list for local operation .when user comes out of that screen(activity) save that changes into database.
I'm looking for guidance as to how to modularize my code. I have an activity and a listAdapter and they are getting pretty complex. I'm not sure what code should live where and how much knowledge each of these 2 classes should have of each other. How do you decide whether to put code in an activity or its adapter? And what patterns do you use to keep these classes as lean as possible?
Your description is too generic, so I cannot give you an exact answer (would be useful to explain why they are getting bigger and bigger, what is the extra code good for).
But generically speaking, just think about what each class supposed to do. The "Activity" (as I see it), is a main controller, it "knows everybody", and it connects the other components together (the ListView with the list adapter). The list adapter's purpose is simply to map data to views. If they are getting bigger, extract new (utility) classes.
For example assume a big part of the code in ListAdapter formats timestamps (eg. takes timestamp as long value, and based on current time creates a string like "2 hours ago"). Then it makes sense to create a new utility class called TimeFormat (with a constructor which takes a context, you'll need it later to fetch string resources). Then the ListAdapter will create an instance of this class.
Another example would be data saving. In that case you could create a class called "Model" or "Document" (again with a constructor taking a "Context" instance). It would be responsible (for example) to load the data by parsin XML files, and to save the data by generating XML files. In this case this class would be instantiated by the activity.
Also note that the ListAdapter should really do what it supposed to do: create/setup views based on data. It should never depend on other views (in other views it should work with any ListView in any layout file). So if you have "findViewById" call, which access a view outside of the ListView (or the ListView itself), then that code should be moved to the activity.
Also, when in doubt you can try to find an open source application, which is relatively mature, and does something similarn (and see how that is solving the problem).
Per the adapater documentation in android
An Adapter object acts as a bridge between an AdapterView and the underlying data for that view. The Adapter provides access to the data items. The Adapter is also responsible for making a View for each item in the data set.
So if your code has to do with getting the data to display or creating the views, then it goes in the adapter. Everything else goes in the Activity or else where. If you're spending a lot of code retrieving the information you want to display, consider using some sort of AsyncTaskLoader class. Note that loader classes can be accessed from API Levels less than 3.0 using the android compatibility package.
I'm trying to build a complex form where almost all of the elements are optional. It starts with just a single field and an "add element" button. When you click add, the form shows a Spinner of the types of elements you can add to the form (location, photo, detailed note, timestamp other than "now", etc). When you select an item, it will launch an Activity, and each item has a different associated Activity.
In addition, each choice will have several bits of data, which it would be nice to store "with" the Activity somehow:
An icon and the displayed name in the Spinner
A key for storing the data in the db (as well as passing to a webservice)
A layout for how to display the result on the original form (i.e. a thumbnail for the photo, the lat/lon for the location, etc)
I was considering a set of classes that all extend an abstract FormElement class, and would have static elements for each of the above extra pieces of data. (An additional bump for this solution is how much of a pain Resources are in a static context.)
How can I make this as clean and maintainable as possible? I'd really not enjoy editing five different files to add a new type of element to this form. (Mostly because I can guarantee I'll miss one and spend hours chasing down unbugs.)
A few tips...
Unit tests will prevent "unbugs" :)
When each Activity has obtained the information it needs from the user, call Activity#setResult() with an Intent that contains your per-type data. Intent supports all the Bundle methods, so you can set different types of data as needed.
To support #2, make sure you're using Activity#startActivityForResult(Intent,int) to launch it, and listen for the result in Activity#onActivityResult(int,Intent)
I would probably maintain the list of available "element" types for use with the SpinnerAdapter (e.g., ArrayList<Class<? extends AbstractFormElement>>, and invoke static methods like .getDisplayName(), .getActivityClass(), etc, in the Adapter's getView() method, in order to determine what to display and what Activity to launch.
In this way, your list would actually contain things like { MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}).
As each element is added to the form, add it to an ArrayList<AbstractFormElement>, which will be used to back another Adapter for a ListView. That adapter will dispatch the inflation of a custom view layout, as well as the creation of a ViewHolder, based on what type of object it is -- that will require that each distinct AbstractFormElement will have its own "view type", according to the Adapter. See BaseAdapter#getItemViewType(int) and related getViewTypeCount().
It's worth noting that these will need distinct view types only if one cannot be converted to the other... For example, if you have two "Elements" that only need to display a string of text in the list, those can both share a "text-only" view type. Likewise, two elements that only display a photo, or can easily convert one to the other (e.g., an icon with a caption, vs a photo thumbnail with no caption), can share a single "image-plus-caption" view type.
With the above in mind, you actually would end up having to modify different files to add a new type (well, I guess technically you could have them all in one file, as inner classes, but there's really no good argument for doing that), but if you've done your interface API correctly, and follow good OO practices, and implement good unit tests, you'll considerably reduce the amount of effort required to find bugs -- simply because most of the things involved in adding a new type would actually force a compiler error if you do it incorrectly. Add to that the fact that a proper unit test suite will be able to programmatically add all possible types, and ensure that everything displays properly, and you should have a pretty streamlined process for easy extensibility :)
It sounds like a lot of work, and it might seem tedious and verbose at first... But the end result is actually much more maintainable, especially if your list of element types is going to be fairly extensive.