sorry for the confusing title. I will try to explain my problem.
My app displays some content day-wise in a ListView. The user is able to switch days back and forth (e.g. by swiping his finger to the left/right). Now I want to implement some nice transition effect (like the new Android market has).
The problem is, that the content is generated dynamically and it can take a while to load. Also you can move (theoretically) infinite days to to past or to the future.
How can I implement a nice looking transition that is responsive and also tells the user, that some work is done in the background.
Just to clarify, I'm not asking how a ListView or an AsyncTask works, but rather for design concepts for my idea.
Thanks in advance.
If I understand correctly what you mean, I think you should try and preload in background the previous and following page, and keep them in memory ready to come in with the swipe.
Every time you change day you would recycle one page of data to load a new one (in one direction or another).
Obviously the user can still swipe too fast and you won't have time to preload things, but in that case I don't think you can do anything better than transitioning in the page with a nice spinner in it (not a blocking dialog).
Related
short version: navigating into a RecyclerView with TalkBack gestures forces you to swipe through every item before you can move on, is that normal? Is there a standard way to navigate out and onto the next element?
I'm trying to get accessibility features working smoothly in an app I'm working on, but I've run into a problem with part of the UI. I'm using RecyclerViews sized so you can only see one item at a time, snapping to the centre, so you can swipe to change the current value from a range. It's basically the NumberPicker approach but directly in the UI, instead of a separate dialog.
The issue is by doing swipe gestures (Default linear navigation) through the UI, as soon as it lands on the RecyclerView, it starts on the current item and then navigates through every single item in the list. It won't exit the RecyclerView until it's hit the last item and has nowhere else to go.
My question is, is this normal? I'm new to TalkBack and I can't find much info on what's expected in every situation. I know my situation is a little unusual (since navigating the RecyclerView implicitly means changing the current item) but just being trapped inside the list until you go through every item seems a really strange way to navigate in general.
I know there are solutions like adding navigation headings etc (which is how the Play Store seems to handle this with their "infinite" horizontally scrolling app selections) but I just wanted to check I wasn't missing something. TalkBack announces "in list" and "out of list" when you tap on/outside of the RecyclerView, so it seems like there should be a way to explicitly navigate in and out with a gesture too...? Would users be used to switching to Controls or Headings navigations to do this?
Thanks! I really want to make this work for everyone but it's hard to know if I've done something wrong, or if I'm just bumping into limitations with the standard components
I am developing an application which should display a number of tiles on the first page. Tiles are generated dynamically from json, each should allocate itself according to size specified in json and should take as much screen as required. Each tile represents short summary of information. The requirement is that when tile is pressed user is redirected to another page which provides more detailed info (like a form) which takes the whole page. User then should be able to go back to previous page and choose another tile if needed or go back to the first one. I don't know in advance how many tiles there will be and what are their components, so everything is dynamic. There is also a possibility that small tiles(with different info) can be required to be drawn on detailed view.
At the moment I am on the stage where all small tiles are displayed on the first page and I need to find the best way to display detailed view and allow user to navigate easily and quickly. Each tile extends RelativeLayout because of absolute positioning of components inside. I am considering switching tiles from Layout to Fragments because they seem to be providing flexibility required and many articles and tutorials I search refer to them. In this case when user presses the tile fragment, all existing tiles would be replaced with required detail fragment. Pressing back button would replace detail fragment with previous smaller ones on the screen (would it be display all of them or only one?).
Another option I am considering is to leave layouts and on tile press redirect user to a separate Activity with detail view. In this case navigating back seems to be destroying activity and it will need to be redrawn again if user wants to come back to it (redraw is not desirable).
My question is what is better for performance. Each tile as well as detail view might have some images in it and full page will take time to load. But figuring out how to handle this with Fragments programmatically might take a while and the last thing I want to find is that Fragments are not suitable. Maybe you have other ideas for scenario described? Any good tutorials/articles where Fragments are created and managed programmatically completely(no XML).
I am relatively new to Android and completely lost now.
Edit:
Thanks everyone for your advice. I can't choose the best answer at this point. I have to do some more research and learning now. Will do that later.
Fragment should be the best way to go. because filling details in a fragment dynamically is easy. will help check some codes i have written that could solve this
Fragments are a new style in Android for creating GUIs, they should not be compared with simple Activity + xml layout's in performance terms. Fragments were created to make it easier to build complicated GUIs, on both phones and tablets. You can create low performance GUI using both methods.
From your description I suppose its best to create two fragments, and wire them in Master Detail pattern. Master will be your json list with short summaries, and detail will be your additional data fragment. You can still put both fragments in separate activities, and show detail fragment from master one (master actitity will get hidden) - this makes sense on small screen devices. But you can show both fragments on one screen on tablets. See 'Master Detail Flow Template', http://developer.android.com/tools/projects/templates.html.
So fragments gives you a lot of flexibility to modify your UI, without huge code rewrites.
Some new widgets like ViewPager will work only with fragments, so if you want to use it you better invest time in learning them.
From what you have described above you do not need Fragments to do this. On your main page you can use a GridView to display your tiles. You could create two other Activities. One called TileActivity which will open each time a tile is pressed. Then you could create a PopulateActivity which would populate the TileActivity with the relevant information depending on which Tile was pressed. In terms of performance instead of closing the TileActivity to go back to the main page you could use Intent Flags so that the TileActivity isn't closed it is just added to the stack and then restarted instead of recreated each time its called.
i m just wondering about some android ui aspects where i need some advices! Might be, that my idea so far is not the best...
Basically I m working on an app, which plays streams in a player (main screen). The user can select streams in a second screen (tabbar screen), where he can switch between three different lists, each one is in one of the tabs and each tabbarclick starts a new activity (i m not using an ActionBar or sth, I just created an own UI element which consist of three icons, current one selected and the other two starting a new Activity):
ListViewActivity1: dynamically created ViewFlipper with nested ListViews (f.e. country->state->city..) from a database
ListViewActivity2: simple ListView with favorits from ListViewActivity1
ListViewActivity3: simple ListView with UserGenerated content
So far it s working great but I m starting to struggle...
Everytime the user enters the tabbar screen again, I want him to be exactly at the last ListView where he was. So basically I m looking for a way to store the different screens if the user leaves them. I came across onSaveInstanceState(Bundle savedInstanceState), but this doesn't really fit my needs. The ListViewActivity 1 is a really complex list with up to six levels sometimes, which I really don't want to transport in a savedInstanceState! Is there another way?
Actually if I go back in the BackStack, this really saves the different states like I want it to. So it is possible, I just don't find anything like this..
So, question 1: Is there a way to save a view like the BackStack does?
question 2: Is this whole idea of ui-implementation a good solution to set up an app?
thanks for any input!
I have done live user testing for a list in my app, and have come to an interesting puzzle.
A list, specifically a single-column table in iOS, may often have a swipe right gesture for more actions, like the twitter app and mail app, and a million other apps. But when important functionality is embedded in the UI beyond that action, and a user cannot figure it out, the only thing that comes to mind to alleviate that is something like the accessory button, ie. a right-pointing triangle or chevron button.
There is probably another way but it's not coming to me. Maybe making the rows taller than normal?
This was meant as a comment but was rejected as too-long.
So after thinking more about this, the ideal solution is a visual clue, rather than painfully obvious text saying "swipe a row for more options". Perhaps when a list (UITableView, etc) is shown and rows (UITableViewCell, etc) are created and added, then as they appear an animation begins of the main visible content sliding into place in the OPPOSITE direction of the desired swipe animation, with a minimal visual indicator afterward, reminding the user that the content is moveable!
Sound good? Optionally, immediately before the animation begins, any underlying content may be shown for a split second (if its supposed to appear underneath). Sweet!
I'm working on an app in which I would like to implement swipe-to-dismiss functionality in the ListView - similar to what we see in Android 4.0's notification bar, recent apps list or browser tabs. I want to run the app on the devices running Android 2.2+. See the following image. I also want to change the transparency of the item being swiped-away - just like in ICS.
I checked the source of the ICS web browser on http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.0.1_r1/com/android/browser/TabScrollView.java?av=f but couldn't figure out which class is particularly responsible for implementing this functionality.
Can anyone point me in the right direction here? Can we do this using Android Compatibility Library? Please let me know. Many thanks.
I've thought about implementing such a feature as well, but I haven't done it yet. So the only thing I can provide are some ideas on how I would approach that problem. If I've eventually written some code I will post it here.
The main class needed is a custom Adapter which extends a ListAdapter (ArrayAdapter, SimpleCursorAdapter etc.).
The adapter applies a View.OnTouchListener to all of its Views.
Whenever that listener detects a horizontal scroll dx, it calls concernedView.offsetLeftAndRight(dx) (which will make the view draggable). Of course the adapter has to save the current horizontal offset for the view. If the user was dragging a view and removes his/her finger from the screen, the touchListener will detect this as well and start a slide back animation. Using the current offset we can also calculate an alpha value, so the view will fade out when it approaches the screen borders.
If one list entry is eventually dismissed by the user, it becomes a bit tricky, and I'm still not sure how I would implement the following action: The list content has to be updated (or the adapter has to ignore the dismissed entries) and the views that were below the one that was dismissed must hover upwards in order to fill the gap. I think it might work to let the ListView load the new content, but that would fill the gap instantly. In order to avoid that, I would then start an animation that lets all the concerned views hover from their old position (where we still had the gap) back to their current position (where the gap is filled).
These are just some of my thoughts on the issue that might help some people getting started on working on the problem. Like I said, I'm probably going to implement that sometime in the future and of course I will post the code here.
I would appreciate any feedback in the comments, but I don't want to thorougly explain every single aspect of my idea, that would take me too much time ;)
I know this is quite an old question, but for anyone still searching for this, you can have a look at Roman Nurik's library here: https://github.com/romannurik/Android-SwipeToDismiss
This shows how to create the required behavior for list-view as well as for normal views.