Say we have to code a custom View for a toggle button.
A toggle button typically has these two characteristics:
- Is clickcable (i.e. will somehow report click events)
- Has a state (on/off)
Where should we put the piece of code that makes the toggle button switch state whenever clicked?
Does it belong to the custom View itself?
Should the View be totally 'dumb' instead and just report clicks letting the business logic set its on/off state instead (e.g. via a setState() API on the View).
What are the pros and cons of both approaches?
Let's assume in our codebase we want to strive to let the business logic handle the application state as much as possible and let the Views just handle their "rendering": How the answers to the questions above will change in this respect?
Where should we put the piece of code that makes the toggle button
switch state whenever clicked?
A Widget runs on the home screen of the device, so the business logic needs to be called with a PendingIntent
here you can find a valid explanation, and also this blog gives some working examples, even more complex
Clickable widgets in android
Related
In my Android app I have a custom layout that is being used as a button - it consists of some TextViews and an ImageView, additionally it has some gradient background.
I'm aligning my app now to conform to the Accessibility rules. In order to do so, I would need to convert this layout into a button, so that TalkBack can correctly indicate the action, that this whole layout is clickable and serves like a button.
I know that on iOS there is a possibility to set the UIAccessibilityTraits to treat such view as a button - this kind of solution would save me a huge amount of work in terms of migration.
Is there any similar solution on Android for that? What approach should I follow in order to make this layout recognized correctly by TalkBack?
No, there's no concept of accessibility traits on Android - but you can still get a good accessibility experience without needing to specifically convert your layout into a Button.
Generally, it's most important that TalkBack (or whatever accessibility service is being used - remember, it's not just TalkBack) is able to detect that the widget is clickable and to be able to read a coherent description of what it does. The additional information that it's a button, specifically, isn't super useful, especially because there are so many different kinds of UI elements that it's often a very ambiguous question whether something even is a button.
You can test this by selecting it in TalkBack and confirming that it reads the content description properly, says something along the lines of "Double tap to activate," and performs the correct action when you double tap.
If it's not correct, make sure the content description, clickable flag, and click action are set correctly on the widget's AccessibilityNodeInfo.
Use case:
Enable the Google TalkBack accessibility service and navigate to an
app (e.g. Google Messenger)
In this app, assuming that you'll be presented with a list of items
to select, arbitrarily navigate to one of them using Talkback gestures (swipe right or just click once on one of them)
Rotate the screen
Expected behaviour:
The previously highlighted item should still be highlighted; the user
should be able to continue it's navigation
The Google Messenger app is a perfect example of this correct
behaviour
Messenger After rotation
My Sunshine app behaviour:
The previously highlighted item is not highlighted after Screen
Rotation
The user has to navigate again to the previously selected item
Depending on the screen, finding and having an item selected again can be a pain... not what we want to induce to our user
Sunshine After rotation
How should we implement this?
I'm thinking, as a solution, at Accessibility Events and intercepting them... but this doesn't seem to be right, doesn't seem to be "best practice" (e.g. creating a Custom View and implement the methods handling these Events)
! Note that the green highlighted list item doesn't seem to be focused (getCurrentFocused() returns null)
! Note that the list items become focused if we use D-Pad navigation, instead of TalkBack navigation (but this is another discussion...)
L.E:
I've spend a whole day on this, trying to "get the focus" of the
highlighted item, but the item is NOT focused. This is why I assume
that this feature must be tackled in some other way and I would like
to know your (!) experienced opinion before I spend another 2 days
re-creating all the used Android components (as I assume it could be done - this doesn't sound very "best practice", doesn't it ?)
This is NOT a homework, there's nothing wrong with my current code
(so, there's no code to post, unless one would like my whole project)
and, given that this is my first post, I could not attach more than 2
pictures (this is why the "before" screens are missing)
Just give me a good hint, based on experience, and I will implement it and post the finished, working code here.
It should work out of the box if you implement stable IDs in your RecyclerView.Adapter (and potentially disable the ItemAnimator on the RecyclerView (rv.setItemAnimator(null)) which you can do conditionally if TalkBack is enabled).
Here's a blog post I wrote about the item animator bug.
I ran into the same problem while working on the same project.
Hint: listView.setItemChecked(int position, boolean value);
Good luck :)
Our Android app currently has a large number of dialog and alert boxes. I'd like to switch these to toasts, but there's a problem - some of them require the user to choose whether to view more info or just dismiss the popup. It doesn't look like there's a way to do this with toasts.
Is there any existing Android library that supports tappable toasts (i.e., you tap it and it triggers a function call to a listener in the app, sort of like a notification)? If not, is there a recommended alternative for this "tap-here-to-do-something-otherwise-I'll-just-vanish-in-a-few-seconds" UI pattern, or should I just roll my own fragment class for it?
I have to do something similar to my app so I wrote, DropViewNotification, a boiler plate to make it happen by animating the so-called notification into the screen. It doesn't do automatic dismiss as this should only act as a tool.
It accept any kind of view to make it versatile as I need to put at least two or three obvious view into it (TextView, ProgressBar, ImageView). You can switch it's content on the fly if you want to. Animation can also be customized for both showing and dismissing of the notification and the main content.
In real-life you might want to consider adding controller class to handle the display of the content and auto dismissal, etc. Hope it's of some use to you.
Wondering which gesture to use to be able to allow the user to touch the object with their finger, slide and release the object and allow the object to continue to move across the screen once they release the object. This would all be in Air for Android as well. I don't want to move the stage itself, just an object on the screen. Thanks for any help!
I am not quite sure if this is what you are looking for, but you should consider reading here. It starts like this:
With the Android drag/drop framework, you can allow your users to move
data from one View to another View in the current layout using a
graphical drag and drop gesture. The framework includes a drag event
class, drag listeners, and helper methods and classes.
Although the framework is primarily designed for data movement, you
can use it for other UI actions. For example, you could create an app
that mixes colors when the user drags a color icon over another icon.
The rest of this topic, however, describes the framework in terms of
data movement.
Your question leads me to believe that you need something like this to happen. Hope this helps and sorry if you are asking something different. Cheers
I was in the midsts of tinkering in android with the goal of trying to make this small exploration game. I actually got pretty far so far: a nice sprite system, a title screen with a main menu that is all in game code (no UI buttons or anything) that launch various activities. An activity that loads this cool map view, that when clicked on will load up another view of a more detailed "zoomed in" action part of a map. It all works pretty well but now I am left wondering how well I am going about this.
(What happens to a view when you instantiate and then move the set the context to a new view? I am guessing as long as the activity is alive all the instantiations of various views that an activity uses are still good? And in an activities onPause is when id have to save the data thats changed in these views to persist the state in the event the user quits the game etc.. ?)
I have three menu options at the start of the game. The main one is:
New Game
The new game, I launch my main map
activity that can launch three views:
First two are a loading screen for
the second, a map screen.
Third view is a more detailed action
orientated part that uses this sprite
engine I developed.
It all works pretty good as in the map view you click on a cell it tells the Calling Activity through a listener to start the detailed action view, and passes in the ID of the cell (so it knows what objects to load in the detailed view based on the cell clicked in second view). (This took me awhile to figure out but someone helped here on another question to get this.) Reference that helped me on this part here. I also used the various information here on ViewSwitcher.
I got even a yes no dialog box in the second view that asks if they really wanna goto that cell when they click on it, a yes tells the calling activity to set the new view. What helped me to get this working was this reference here. I also had to fiddle with the calls to getContext and that, I am still not 100% sure what getResources and getContext do for me.
So is it bad practice to call and load a dialog from a view? If it is, then I don't understand how if I have an event in the view that needs to pop up a dialog how I do that? Call back to the activity and let the activity handle it the dialog response and then call a method on the view for the response?
So far all this works great, I did have a bit to learn about threads too. I spawn a different thread for my MenuView (handles the detection of button clicks and responses), my CellMap view which handles the cool big map that users can click on to see the indepth view which is my SystemView view.
So basically the activity call list is like this:
Home.Activity -> ScrollMap.activity which listens to CellMap wher ethe Yes/No dialog apperas (in the view of CellMap) and if the answer is yes to the question, then the onTouchEvent starts up the SystemView view using
private CellMap.MapClickedListener onTouchEvent=
new CellMap.MapClickedListener() {
#Override
public void onMapClick(int id) {
setContentView(new SolarSystem(theContext,id));
}
};
To help anyone else, that listener had to be defined in my CellMap class. Then in the ScrollMap activity when I am about to start the CellMap I just call a method to CellMap sets the map click listener. So far this is the only way I have been able to get data from a dialog (in this case a it was clicked so set the new view) back to the calling activity. Is this proper practice?
Now my biggest question is, I have a playerObject class I want to initialize on new game event (I know how to detect that push) and that then is available to any view in any activity for the life time of the cycle. So far the game activity has just two (3 if you count the loading progress bar) views. I want to get the players name, is that another activity or view? I cannot find a decent tutorial of just how to make a simple input dialogg box that would return a string.
How do i go about passing this stuff around? After I get the players name from wherever that edit box is to be loaded, I want to set the players name in the class and pass that class instance off to another view or activity so they may get at that data. Everything I have searched on this seemed like overkill or not the right way. Whats the best way to pass this "playerClass" around so that I can access it from other views (to say display the players name in every view).
I also have my Home Activity that waits for an onClick on 3 buttons, it then launches their activity that shows the view. I realize a continue game and new game are the same activity and will just change in data loaded off the drive to restore a save game. When the new game button is clicked I would love to get the players name they want to use and of course set the member of the playerClass to this name so it persists.
Where do I call (an edit dialog is it?) the edit dialog from? (more over how do I build one that can take an okay button and input from keyboard etc). Id also like to make it pretty, maybe I could have a simple view that has one edit box in it and a nice image background (though I haven't figured out how to place the edit boxes to fit nicely matching a background i draw for it. I guess id like an edit dialog I can skin to look how i want it to and fit the look of the game).
I am actually kinda happy what I got so far its looking not to bad, just not sure about some specifics like getting user input for a name of the player. Storing that information and passing it then to other activities and views.
Is it better to have one GameMain activity, and a ton of views:
Map view
Character sheet view
inventory view etc etc?
Or Should there be diff activities in there somewhere as well?
You've written a lot here, so I'm go gonna go ahead and answer the questions I think you're asking.
First, how can one share information between activities and views? If you're just sharing it between views in a single activity, store it in the instance of the Activity subclass.
Sharing between activities requires a little bit more. Instead of using an instance of the default Application class, you can create a subclass of Application and use that instead. Put your data in fields of that subclass. To tell your app to use your subclass, modify the app manifest like so:
<application
....
android:name=".YourAppClassNameHere">
....
</application>
As for getting user input, the simple answer is use the built-in EditText view. since you seem to want to give your game a more "custom" style, though, you may need to go about creating your own editable textbox. That and buttons should allow for most sorts of basic user input.
Now, good practice vis-a-vis activities and views. I'm not aware of a standard for this, but when designing I generally try to think of activities as more conceptually separate elements, whereas views are conceptually interwoven. the line between the two is dependent, in part, on the scope of the app; an app with a narrow focus can afford to break more actions down into different activities than can one with a much broader focus.
Your "GameMain" example is a bit on the fence, but I think you've made the right choice: the activity is "playing the game," as opposed to a menu or high-scores table, and the views present different aspects of the game being played.