I'm somewhat new to Android and am in the process of designing an application with a couple fairly complex views. One of the views is intended to involve a complex view displaying information associated with model objects and segregated into several different views; the navigation of which is meant to be achieved using sliding effects (i.e. sliding one's finger across the screen to traverse from one screen to the next, etc). The view itself will be used to host multiple sets of views for varying types of model objects, but with a general structure that is reused between them all. As a rough example, the view might come up to display information about a person (the model object), displaying several details views: a view for general information, a view displaying a list of hobbies, and a view displaying a list of other individuals associated with their social network. The same general view, when given a model object representing a particular car would give several different views: A general view with details, A view containing photo images for that vehicle, a view representing locations which it could be purchased from, and a view providing a list of related cars. (NOTE: This is not the real data involved, but is representative of the general intent for the view). The subviews will NOT cover the entire screen real-estate and other features within the view should be both visible and able to be interacted with by the user.
The idea here is that there is a general view structure that is reusable and which will manage a set of subviews dynamically generated based upon the type of model object handed to the view.
I'm trying to determine the appropriate way to leverage the Android framework in order to best achieve this without violating the integrity of the framework. Basically, I'm trying to determine how to componentize this larger view into reusable units (i.e. general view, model-specific sub-view controllers, and individual detail views). To be more specific, I'm trying to determine if this view is best designed as a composite of several custom View classes or a composite of several Activity classes. I've seen several examples of custom composite views, but they typically are used to compose simple views without complex controllers and without attention to the general Activity lifecycle (i.e. storing and retrieving data related to the model objects, as appropriate). On the other hand, the only real example I've seen regarding a view comprised of a composite of Activities is the TabActivity itself, and that isn't customizable in the fashion that would be necessary for this.
Does anyone have any suggestions as to the appropriate way to structure my view to achieve the application framework I'm looking for? Views? Activities? Something else?
Any guidance would be appreciated. Thanks in advance.
I'm trying to determine the
appropriate way to leverage the
Android framework in order to best
achieve this without violating the
integrity of the framework.
Phones have very limited RAM and very limited CPUs. Your average Android device has the power of a decade-old PC, or worse. Please do not over-engineer your application.
To be more specific, I'm trying to
determine if this view is best
designed as a composite of several
custom View classes or a composite of
several Activity classes.
I'd argue "none of the above". If you are aiming to make "custom View classes" for distribution to the Android developer community at large, that's one thing. For your circumstance, though, just build your Views -- don't subclass them. I am definitely of the "composition over inheritance" mindset when it comes to Android's View system.
IMHO, Activity is your controller (or perhaps presenter, a la MVP, is the better architectural analogy), layout XML and their constituent Views are the view layer, and your database is your model.
I'm not sure that I followed all that you were saying there, a diagram showing the flow might help, but..
You generally can only have one Activity visible at a time. That activity is responsible for rendering the entire view. The only exception to that that I have seen is a pop-up, alert style window. In my experience those tend to be a bit slow though. Typically you have a new activity every time you change pages. It sounds like in your case it might be every time the general view changes.
You can, however, easily have a few layouts that are reused in various activities. Layouts are composable, so you can, for example, have one layout for your detail layout that gets included in the main layout.
Related
I am actually developing an Android application on which I should display dynamic forms based on metadata contained inside JSON documents. Basically the way it works (without the details) is that a JSON document represent the structure of a form:
{
"fields": [
{
"name": "fieldA",
"type": "STRING",
"minCharacters": 10,
"maxCharacters": 100
},
{
"name": "fieldB",
"type": "INTEGER",
"min": 10,
"max": 100
},
{
"name": "fieldC",
"type": "BOOLEAN_CHECKBOX",
"defaultValue": true
}
...
],
"name": "Form A"
}
What I'm doing actually when the application receive one of those JSON documents is that it loop through each fields and parse it to the appropriate view (EditText, Checkbox, custom view, etc.), adding a tag to the view (to be able to retrieve it easily) and add the view to a LinearLayout. Here is a pseudo-code of how it is working actually:
//Add form title
linearLayout.addView(new TextView(form.name));
//Add form fields
for(Field field: form.fields) {
View view;
switch(field.type){
case STRING: view = new EditText();
...
}
view.setTag(field.id);
linearLayout.addView(view);
}
The issue with this is that with large forms (like >20 fields), it need to inflate lot of views and the UI thread suffer a lot. Another point to take into account is that a single screen may have multiple forms (one after another vertically sorted).
To avoid overloading the UI thread I thought of 2 possible solutions:
Using a RecyclerView.
Using Litho by Facebook.
But multiple questions comes to me when considering these 2 solutions:
Is it a good use case to use Litho? Or using a RecyclerView is enough?
What about the state of my views? If I use a Recycling pattern, would I be able to keep the state of each of my fields (even those off-screen) and so being able to save the form without losing data?
If I use a Recycling pattern to display one form, how would I handle multiple forms? Can we have nested RecyclerView? Forms need to be displayed one after another like inside a vertical RV but if forms themselves are RV, how should I handle this?
This is more a "good practice" question and giving the right way or one of the right way of achieving my goal than a need of a specific answer with code example, etc.
Thank's in advance for your time.
When architecting for the mobile application I would like to address the following questions:
Is it a good use case to use Litho? Or using a RecyclerView is enough?
Are the views are being recycled properly:
What does it mean to us is consider, creating 40-50 view per screen and as user moves out of the view, system should not mark all views for GC rather it should be inside some kind archived list and as we require it again we should be able to fetch from it.
Why do we need to that: GC is the costliest operation which would cause app rendering to be jitter, we try to minimize the GC to called at this point by not clearing the views
For this I would like to go with litho, justification is here as your requirement seems to have more of variable count of viewtypesreference
Conclusion: Litho +1, RecyclerView +0
What about the state of my views? If I use a Recycling pattern, would I be able to keep the state of each of my fields (even those off-screen) and so being able to save the form without losing data?
Saving EditText content in RecyclerView This is one the component but same logic should be appliced to checkbox or radiobutton as well. or as in state-maintenance for litho is here
Conclusion: Litho +1, RecyclerView +1 both has specific API's to achieve state maintenance
If I use a Recycling pattern to display one form, how would I handle multiple forms? Can we have nested RecyclerView? Forms need to be displayed one after another like inside a vertical RV but if forms themselves are RV, how should I handle this?
This has to be addressed with user experience plus technical capability: As per user behaviour IMHO,I discourage the nested vertical scroll however others were able to achieve it you can easily find on how to in SO. Optimal solution would be to have horizontal scroll within either Andriod's or litho's recycler view as here
NOTE: If you need to know implementation details, please raise it as separate question, I would be happy to help there
UPDATE #1:
The issue with this is that with large forms (like >20 fields), it need to inflate lot of views and the UI thread suffer a lot.
UI creation/layout has to be performed at the backend only adding to the view has to be done on UI thread. And litho does it in-built. However same can be achieved native recycler view as well but you have to move off the UI thread and post periodically to UI.
Ok, you have two separate problems here. One is overwork the UI thread, and the other is to keep the state of your anonymous views. About the first part:
1.-Litho could help you with this. But you have to move all your logic towards litho components instead of android widgets. Since I don't know your codebase, I don't know how hard this can be. A recyclerview would help with view recycling, but that only matters if you are well, using a list.
2.-It could, as long as you have a way to keep a representation of the widget's state that you can pass to the adapter and then back to the view (I'm assuming you generate all the windows by code and then have zero reference to them) and so. It sounds messy, and it is messy, so I won't try it.
3.-You can, but is messy. Best approach in this case would be having horizontal recyclerviews inside a vertical recyclerview. Nesting recyclerviews inside another recyclerview with the same direction creates funny problems, like "Why this cell is not scrolling". I would avoid using the recyclerview as a parent if the view does not need it.
Now, to the solutions:
A) UI Overloading: According to your pseudocode, you aren't inflating stuff. You are creating java objects which happens to be subclasses of View. That's good, because creating objects in a background thread is far easier than inflating (Parsing XML and use it as arguments to generate identical copies of a given resource by invoking constructors) stuff in a background thread. While a LinearLayout context constructor requires an UI thread to be executed, other things, like textviews, don't. So you can create the latter ones inside an asynctask and after you are done generating your whole hierarchy, execute the methods that need the UI thread and add the generated layout to the window. For the view classes that don't support being created as java objects asynchronously, you can have an XML file with just that component, like the linearLayout, and create then asynchronously with the support package asyncLayoutInflater. this solution can be implemented in any codebase and would allow you to make your UI generation completely asynchronous.
B)Keeping track of the view state: Again, I'm assuming your view hierarchy is anonymous. If so, what you need is to generate an interface you can use as a contract to invoke both state saving and state loading from a lifecycle aware component, like the activity. After creating such interface, subclass the widgets and create a subscription/event bus system in each widget that saves/loads the state from the widget every time is triggered. That way, each of of the components on the screen would be able to remember their state while remaining anonymous.
Just use the RecyclerView and create views on runtime (you are not inflating, you are instantiating)
Dynamically creating and adding views should not slow the UI thread considerably on mid-range devices. If it does, do investigate for bottlenecks elsewhere
You can perform a simple benchmark by adding/removing/setting text with lots of views dynamically inside a RecyclerView or even a LinearLayout hosted by a ScrollView, and you'll see it goes smooth
Use jetpack composer provided by android
https://developer.android.com/jetpack/compose
Suppose I have RecyclerView with hundreds of items. There are a few different view types. When I click on an item it has to change its UI. As I see it there are two options:
change the item to a different view type and notify the adapter that it changed so that it can inflate a new view to display the new state.
have both views in a single xml file. only one is visible at any time. Toggle between them using the setVisibility function when the state changes.
there are a lot of articles online about heterogeneous RecyclerViews using lots of view types, but i have yet seen one about the best practices when item views dynamically change and the RecyclerView becomes more heterogeneous over time.
which method is best to change an existing view in a recycler view? what are the tradeoffs?
The tradeoffs are pretty obvious.
Both UIs in a single View: depending on your views, this might:
Make the Views heavy to inflate and layout
Slow down the binding process, since you have to bind both UIs
Eventually, lag down the scrolling process.
On the other hand, you have a fast, precise control over what Views should change appearance at a certain time. Having both UIs in the same place allows for finer animations and transitions between one state and another.
Different View types: I think your case is not why view types were created in the first place - they are meant for having different childs at the same time, in different positions of the list. This:
Might slow down the transition. You have to be extremely careful on how you tell the adapter to reload the objects. As you can read anywhere, you might want to avoid notifyDataSetChanged(), which reloads any object, and rather use notifyItemChanged() or such. This requires some work and attention.
Does not allow (not easily, at least) for visual transition between one state and another.
The answer is that, IMO, only you can know. You should ask yourself:
Are these Views complex? Do they have a deep hierarchy? Would having both of them reduce performance (e.g. in the binding part)?
Would it be easy to understand which views are changed, and call notifyItemChanged(int position) in the second case? Reloading the whole dataset has a huge impact on performance, if you have lots of items.
Do you need some visual transition between one state and another? Maybe you want both UIs to fit into a single container (like different informations in a CardView)? If this is mandatory, then option 1 is better.
Do you have more than 2 UIs? If so, I would go with view types, so as not to host too many views in a single child layout.
and similar questions.
I have an android app that I'm developing using Xamarin. The app contacts the server and, via web service (SOAP), receives a list of objects. Currently, in my axml file I have just linear layout (ll) within scrollview tags and nothing else. In the code, I loop through the collection and new up the elements that I want and attach it to a layout. Once I'm done with each record, I attach (i.e.AddView) to the master layout (ll). Everything works.
I have a couple of concerns and I appreciate some feedback on it.
1) Each object in the list contains an URL to an image online. Currently, for each object, my process downloads the picture individually. Would ListView give me any advantage of reusing (caching , etc.) an already downloaded picture even though other attributes of the objects are different? Will there be any gain in terms of network utilization if I switch to ListView?
2) Is drawing elements by hand (like I'm doing) an acceptable best-practice?
Thanks all.
Definitely use a ListView. There is a great article here by Lucas Rocha that outlines exactly why ListViews are beneficial and how to make them perform even better. To give you a few examples, ListViews minimize the number of view inflations you do, and they only create the list items currently visible on the screen or about to become visible on the screen.
This is a huge improvement from your approach, since your current method would load every element in the list before presenting the activity to the user. Therefore, drawing elements by hand like you're currently doing is definitely not best-practice.
Also, for displaying images from URLs in your Xamarin app, I highly recommend that you use the Xamarin component UrlImageViewHelper. Despite being incredibly easy to implement in your app, it will improve performance drastically since it takes care of image caching and async image loading.
I've been looking at creating a stylistically different list view, like many other people, and I started by looking to extend AbsListView. Per the Android doc, AbsListView is:
Base class that can be used to implement virtualized lists of items. A list does not have a spatial definition here. For instance, subclases of this class can display the content of the list in a grid, in a carousel, as stack, etc.
After some effort and review of the ListView implementation, it looks like it may not be possible to extend AbsListView the way ListView does because of the coupling of the two classes and the inability to access certain package members. I stumbled on this form Romain Guy:
AbsListView and AbsSpinner are designed to be extended within the
framework. They could also be extended in 3rd party apps but we did
not expose all the necessary protected fields and methods on purpose.
We want to be very careful in how we expose such APIs so as to not get
stuff for future extensions and internal changes. Our current
recommendation is you simply copy/paste the code you need inside your
app.
I started trying to do this but copying AbsListView becomes a rabbit hole of copying in a bunch of other stuff and it really just seems like a losing proposition. I wanted to see if anyone has had success extending AbsListView who could share a methodology.
[1] http://developer.android.com/reference/android/widget/AbsListView.html
[2] https://groups.google.com/forum/?fromgroups#!topic/android-developers/UhbR1tpVvF0
The post is circa 2010, but his assessment still holds true today. Certain necessary methods & fields are protected, in order to prevent future incompatibilities that could result from changing the internals of AbsListView.
The best solution is still to copy the code for AbsListView into your project, along with necessary dependencies (the rabbit hole you mentioned).
In the meantime, if you want to describe what kind of View you're trying to build, we might be able to point you in a direction that's slightly easier than creating your own AbsListView?
I've had the same experience trying to subclass ListView and AbsListView to develop a 2D scrollable spreadsheet. I ended up with my own subclass of ViewGroup which handles layout and a subclass of TwoDScrollView to handle the scrolling. The hardest parts are getting flings to work correctly (ie. create and place new views before they scroll into view) and synchronizing view positions between scrollable components. With enough time though, it is possible to create a robust component that pulls data from a Cursor and scrolls it around quite smoothly and quickly.
I need some valuable advice from you guys...
I have a UI where I have to drag objects from one view to another.
I have a rough sketch of this UI below
I think I have to create a custom view for this. I have to drag a square and a ball from bag 1 and bag2 [both bags are scrollable, can contain 10 to 60 items each] and drop it to the closet one by one. and later I have to find the number of items in the closet. The items in the closet must be arranged in a well maintained fashion [may be ...like 6 in a row].
Where should I start?
How many custom views should I use?
Is there a simple and effective UI solution for this?
Happy coding..!
I would suggest a design with three different GridView objects laid out inside a ViewGroup that supports dragging objects from one GridView to another. The objects would be custom ImageView subclasses so you'd have a place in code to support a drag-and-drop protocol of some sort and because you'd likely want to associate some data that is specific to your application with the objects being dragged.
As for the drag-and-drop protocol, you could consider an adaptation of the Android Launcher drag-and-drop framework or the current drag-drop classes described on the Android developers' website. I don't have much to say about the current drag-drop classes. I have not tried them yet, but understanding them is on my to-do list. However, I have done an adaptation of the Launcher code, and I have written it up on my blog and posted demo apps and source code there. See Drag-Drop for an Android GridView.
With the framework that originated in the Android Launcher, you have a good set of classes and interfaces to work with. Some of the objects include: DragLayer, DragSource, DropTarget, DragController, DragView. The DragLayer is a custom ViewGroup within which all drag-drop operations occur. It delegates handling of all the touch events to a DragController, which is the object that does the actual moving of objects around on the screen. As it does so, it interacts with DropTarget objects to give the user visual feedback that something is being dragged and that a place to drop something is available. A DropTarget is an object where something can be dropped. A DragSource is the interface for objects that can be dragged within the DragLayer. The Launcher framework is a good one because it gives you a way to think about dragging and dropping and how you want to divide up the responsibilities defined by the framework.
The reason I suggest GridViews for your problem is it sounds like you are thinking that way already. The closet has "maybe 6 in a row" so that could be a GridView with one or more rows depending on how screen space you have. A GridView would also work for the container that holds the squares and circles. If that is a good fit, you could study the code in my drag-drop tutorial and see if that makes it easy for you to move objects from one GridView to another.
In my demo program, I ended up with a custom subclass of ImageView that I called an ImageCell. These are views that are on the grid. An ImageCell allows objects to be dragged from them and onto them. For awhile as I worked on the tutorial, I had a custom GridView class too but ended up with the standard GridView. It sounds like you'd want a custom GridView because it sounds like being in the closet is different than being in the other sections. Having it gives you a convenient place for the methods you have not thought of yet.
I hope some of these suggestions prove useful.
Depends on the Android version you are targeting. For 11 and above you can use the built in drag and drop functionality, otherwise you are pretty much on your own. I would normally advice you to implement some sort of a long press action that might even allow you to select multiple items and move them in batches, which would be a really simple thing to implement.
If you really need DnD you should check out this example, it should give you some idea on how to make your own implementation.
I think that bag1, bag2 and closet can be three instance of the same configurable custom view (let's name it CustomBagView).
CustomBagViews should be responsible for displaying items (using a gridview of imageview for example).
I think those will not need to handle drag & drop directly but they should support
removing and adding elements
provide a setOnItemTouched(Interface_class) callback setter.
Then you will need to code a Container custom view (let's name it BagContainerView) that will contain the three bags and handle the dragging & dropping from the bags.
You will provide a handleDrag callback to each bag using CustomBagView.setOnItemTouched, then track the finger motion in it.
When the dragging finishes, you must find where it ends, locate the right 'customBagView' and ask it to add the item to its list.