We're designing an application that displays several hundred graphical elements on a single screen that need to respond to touch events and that can be animated -- however, they are not full-blown widgets (no focusing and other event handling). Is the View class appropriate for this, or is there a more lightweight class we should use?
(For those familiar with the Qt Framework, we're looking for something like the QGraphicsItem class)
View is just fine. It provides the full functionality and flexibility you may need to obtain graphical elements.
Related
I've got a lot of experience with Java and C#, but I'm new to Android. I mainly use C# because I am enamored of the Control hierarchy. I love the plug-and-play of the ontology. I'm trying to understand the ontology in this new paradigm and I may have been given some false information.
With respect to Apps, that should be the largest component. Within the App, there may be several Activities. An activity can display a number of Fragments. AppWidgets appear to be a special case as they exist as a component of the App, but are shown on their own. And I was told that you can extend Buttons or ProgressBar to create your own components which again appear to be called Widgets.
As I said, I may have this completely wrong. Ideally I would like to create my own widgets which I can put on a Fragment, an AppWidget or an Activity; any of which I might compose into an App. All the online sources I've found only discuss Widget in the sense of an AppWidget? Was I given incorrect information? Can anyone clarify the ontology?
Thanks
"Widget" is a bit of an overloaded term. You will probably have better luck if you search for tutorials on "custom Views" instead. I'll include a brief rundown of various terms and what they mean at the bottom.
A custom View is pretty much anything that extends the View class (or any of its subclasses) and isn't part of the framework. Custom views can be used wherever typical Views are expected, e.g. in layout files or directly constructed in Java. One thing to note: only certain Views can be used in an AppWidget because they are running in another process outside of your app. This means your custom Views cannot be used in AppWidgets. In my experience this tends not to matter too much.
App: An application. Contains components, which are defined in the manifest within the <application> tag.
Activity: One of the four application components. Nearly always has an associated UI, composed of a hierarchy of Views.
Fragment: A framework class that helps modularize your application's code and UI. Fragments can be attached to an Activity and can contribute some UI to the View hierarchy of the Activity. They are entirely optional; you don't have to use Fragments in your app, and you can attach a Fragment without it contributing any UI to the Activity.
View: A UI component, such as text (TextView) or images (ImageView). These are also referred to as "widgets", and you may notice the framework classes are found in the android.widget package. Some views contain other views, so that you can build a UI hierarchy; these will extend ViewGroup and are referred to as "view groups" or "layouts" more or less interchangeably.
AppWidget: Something the user can add to his or her homescreen. This is provided by the app, but is not one of the 4 application components mentioned previously (it is managed by an application component, namely a special subclass of BroadcastReceiver). Most people colloquially refer to these as "widgets" because it's shorter to say and launchers used that terminology as well, thus conditioning users to it.
I'm trying to get into Android development on Android development's terms. To this end, I don't want to push onto it a mental model that is largely based on WinForms development.
My problem is that I find Activities and their fragments too cluttered. There are interface implementations all over the place. There are type hierarchies that get smushed into my Activity files. I find it, to say the least, off putting. When I see examples on the developer.android.com site they seem to advocate this complex, everything in one massive file model.
At the same time, I realize that the demo code is just that, demo code. What's the right approach when working with Android elements?
For example, I would like to have a GridView to display some graphics and allow the user to click on them, or long press on an item to do something. I can do this within an Activity.java file, within a public static class Fragment nested in the Activity.java file. I can then implement the on tap and hold listeners. At this point, I feel that this is a rather muddy design.
Would it be Android-Idiomatic to have instead a class that that extends GridView with my specific implementations of the listeners? In this instance, if the GridView decided to navigate somewhere, it could.
The question really applies to any complex view within Android. ListFragment seems nicer since at least I'm getting a type hierarchy explicitly here. I can have the fragment react to various item events.
I'm at the beginning of my development for my game and I have a basic question.
Is the layout necessary for displaying a view?
I have the method which allows me to make the toolbar disappear and set the view screen wide, but it seems a bit useless to do so.
Besides in the snake sample provided in the sdk, the views are merged without a layout.
So, which one is the best practice.
And if it's the layout-less solution, how to do for a unique view to display?
Thanks.
Well, I am as new as you are too, but as far as I have searched and learned online and with a few examples, all I can say is, NO. Game programming does not need any xml layouts. For developing a game, you need to first create a good basic framework. All the views, sprites, actions, audio, etc... is created at background.
This is a very nice tutorial to start with.
It depends on lots of things, but yes you don't need to create an XML layout. Pay attention to the word XML. You can create a custom class which extends SurfaceView and work in cooperate with Thread to do the update. So in this case you just need to set your Activity's Content View to this subclass of SurfaceView. But by using SurfaceView you have a raw of context which means you should do everything from stratch, e.g you should implement your own button.
Beside this it depends on the engine/framework you use too. But for SurfaceView/Canvas API the lines I mentioned above is valid.
I wrote a calendar app and I'm now rethinking how to display the items. I don't want to use a simple table layout anymore because the different tasks have different durations.
What options are there to create a Layout like this instead of this?
I think drawing is no option respect to performance?
I would also like to use xclicklisteners...
I did something extremely similar to what you want by creating my own view type (extended the View class, and handled my own drawing). Performance is excellent as this is not typically data that is rapidly changing while the view is active (like a video game might).
It's also very simple to support all the usual (or custom) listeners for navigation, selection, touch, etc., etc., etc.
Food for thought.
Does the Android platform lend itself well to a particular style of UI programming like MVC or MVP? Most of my UI experience is with spaghetti code on a very old embedded device or in GWT with MVP so I do not know where to start.
The MVC Pattern is more or less pre build into android.
You have three layers consisting of:
The Model Your data classes, Content providers etc. wrapping all your data.
The Controllers Treat all your activities as controller classes. Don't do anything in them that looks like business logic or data persitance. Just react to events from the model or the user and forward them to the correct layer.
The View Often the Activities are called the view because there it is the java code that is closest to the views. But in my opinion the view layer in Android is mostly defined in xml. You define your buttons, images, state changes etc in xml and then connect it with your application through your Activities.
There are some simple rules to follow to have a basic separation of this layers.
Define as much of your UI in xml only
instantiate Views yourself if there
is no other way to achieve something,
don't change the graphical state of
views from code, for example don't
change the background of a button if
the button is deactivated, or the
color of a font if a button was
clicked, do all this through stateful
drawables, and selectors in xml.
Don't do any data saving or logic in
your activity classes. Call to extra
model classes for this purpose. This
will make your activities clean and
short
If you want to change your data think
about going through a full
controller changes model -> model
informs controller about changes
-> controller changes UI cycle instead of having the controller
change the model and the UI
directly because other observers
of the modes may not be notified.
I do not know if the Android lends itself well to a specific design pattern when it comes to UI development per se, you can certainly use a particular pattern if it helps.
When in doubt you can check out the standard User Interface Guidelines and see what the guidelines are for particular interactions.