I need to implement UI where user will be able to easily browse large set of text articles. I consider using TextSwitcher and onTouchEvent method implemented in order to have UI similar to browsing pictures in gallery. Do you have any ideas?(besides ListView) Would be grateful for any hints.
update: I want to show these articles randomly, so I do not want to let user browse among them.
I think this is not really a UI design problem but more of an application design problem.
On mobile devices, even counting tablets, you have very very small screen real estate.
The statement : "How can I browse large set of xx on a mobile with a 3 inches screen" is antinomical and the answer is : "You shouldn't" :)
Give your user a very powerful search engine, organize your content in a tree of categories so that at the end of a branch or after a search there is no more than 10 to 20 results.
You can even go the evil root of : "Sorry your request generated more than 50 results, try to be more specific."
It will give you the following :
-Great usability
Your content is now(was) organized and easy to reuse in other
projects
Low bandwith usage (given this is web service based app)
Lower battery comsumption
No need to spend three days making your own custom UI component
:D
Related
So I'm on my first android project and I'm implementing a native app. One of the components is to book a seat on a seating map.
General specifications:
Handle venues that have different seating layouts and amount of seats, over 200
The seats can have different sizes and shapes, i.e. large round VIP seats and standard square seats. Imagine small round stadium with a lot of custom seating and different orientation, with a stage in the middle. (I have an image but can't post because I don't have enough reputation)
What I have tried so far:
Created custom seat class with size, seat number, orientation and seat type
Used a StaggeredGridLayout and a view-adapter to load each of these objects dynamically from a DB onto this layout.
My concerns: No matter how much I was worked on it, it never came out the way I wanted. Basically, I think this is better for grid maps with one sized objects like bus seats placed in the distance between each other and doesn't have a huge irrelevant object in the middle like a stage.
I was thinking about changing directions completely after doing some research: Using webview? Each venue would be a web page, that would be linked from the venue object from the DB. Then in that web page, I could make this sort of venue a lot easier because I could just place out this layout manually and style with different div elements or make an interactive javascript map, attach a button and make a call using Jquery/Javascript to my native android app.
What are your opinions, is this a feasible solution?
To be honest, an interactive seat map development was the most challenging task I have ever had in my development life. But some how I have done it for an asymmetric seat plan.
This type of work can be achieved in following two ways.
1. Using GPU rendering - Much easier process as almost every device has GPU by default. It detects the interaction point and check it's RGB value to detect the right path has been interacted and return this through client interface (with some drawbacks). e.g: Webview interacting Js interface in android and others.
2. Using CPU based drawing - Draw each and every path on the canvas and repeatedly it need to check the touched/interacted point is inside the paths or not. It will use more the CPU if paths are more complex to render/draw on the canvas for every single interaction. (hug CPU usage and some other constraints)
I am tired of searching some library in android which is very useful like Macaw in iOS development. This library handles the interactive path inside a svg file and help to interact with the client side.
Anyways for me, neither of the two options are not feasible though. I will go with importing/downloading .svg file to your android application and make it interaction using JavascriptInterface in your app. Unfortunately, this is less worse solution that I have found out so far.
UPDATE:
Here is my approach to make it workable. See my medium blog post. Hope it will help you.
I have been working on an android project that has a feed similar to Instagram/Facebook and I am trying to figure out the best strategy for consuming the data from my database.
Specifically I am wondering if I should query all the data at once (assume 50 records +) or if should I perform queries as the user scrolls -- grabbing so many records at a time. If the ladder, about how many posts/records should I get per query assuming the content/size is similar to that of a Facebook post.
I've spent a descent amount of time researching this issue and haven't come across anything so any suggestions would be much appreciated. I do apologize if this issue has already been addressed and if you could you just post the location of the answer that'll work too.
Thanks in advance!!
Fetching all the data can be too much at times and your app will have very slow response time, that why it's better to load some data at a time and just add it as you get it. In my opinion it's best to load 2 screens of data at a time, so try and see how many posts you can have in a screen and get x2 (if on one time you can see 5 posts, load 10 at a time) or load for example 10 at the first time and 5 each next time. This truly is your preference as I think.
If this is the method you want to use keep in mind that there are different screen sizes for android (from android wear to different sized mobile phones, tablets and smart tv-s) so try making different methods for each group if devices. You can maybe have an abstract class (or interface) with the method and have every other class for different size extend or implement (regarding of using class or interface) to make the code more well written, easier to change and reusable.
But all in all it's in your hands and you can make it by your liking. Hope this helps, and gives you some matter to wrap your head around.
I'd like some advice regarding Android UI (in)efficiency. I'm trying to determine the best way to build a particular layout for my app, however I think my initial idea potentially runs the risk of brutalising performance. Basically I have three very similar and related app components, and to configure them, I need user input. The three components share different parameters within a global set. I want to determine a nice, fluid fashion in which to display this input form on the device.
What I'd like to do is simply allow users to use one form in place of three. All three components are related/similar and they share some of the configuration parameters the user is required to enter.
My initial idea is as follows:
Build an extensive layout of UI elements necessary for initial display for any of the three instances via XML. Unfortunately, given the number of parameters organised in rows, this will amount to approximately 50 view objects in total in this case.
Create activity so that the user enters the screen, and understands
they are required to initially choose one of three values from a
Spinner widget at the top of the screen.
By using bitwise comparison operators, simply show/hide the various
controls related to the chosen Spinner value. (Triggered via
Spinner's onItemSelectedListener() )
Create some minor/lightweight animations and so on so they
understand pieces of the puzzle are being added or removed to
reflect their choice.
Alternatively, a second theory involves using three different activities, and saving state between the three, passing parameters between them... Perhaps I should abandon my initial idea and use something along those lines? A third alternative?
The primary motivation for doing this instead of just breaking it into three separate forms is it should allow for users to experience a consistent UI with minimal frustration if they choose to re-think their initial selection. Using the above, if a user fills out half of the form and decides they'd like to use an alternative option from the Spinner, their information is obviously retained, because they'd be using the same view objects.
I would like to ask you all for a little advice on how I can achieve this without risking too much of a performance decline on typical, mid-range Android devices (by that I mean handsets most users own, from Froyo up, and in particular those from Gingerbread up). I'm concerned because I only have access to one test device and it's a HTC One X handset, and that's obviously an extraordinarily poor choice for getting a handle on how capably most mortal devices can render more complex layouts.
I'd also appreciate any guidance regarding tips for optimising performance... I understand from scouring the community and Android's developer resources that rendering some layout objects is more exhaustive than rendering others, and I should opt for LinearLayout where possible (as opposed to RelativeLayout for example). Is there any definitive resource for comparing the performance of UI options? I'd very much like to spare you the time and effort, and go and acquire the knowledge myself.
Thanks in advance for the time and effort. Cheers.
Edit: I guess I should mention that if necessary, almost none of these views need to be drawn to the screen when the activity is initially loaded (the first time anyway)... If desired, I can initially load only a few views, and the Spinner widget. It'd be like loading 'No option selected' instead of Option 1, by default. The impact on the user may actually be minor if the device is sluggish because their device won't actually have to draw more than a mere handful of view objects when the activity is loaded. At any one point, the device is probably only required to render and subsequently display about 30 view objects at any one time. I guess the critical issue is, "Will the user experience a hang or a delay if their phone is struggling to load a lot of XML, even if it's not displaying it all when the activity is loaded?"
+1 for great effort on the question. My personal suggestion is that you stick with your second theory. Keep your data separate from the views -- store the entered values somewhere such as SharedPreferences or a database -- and have three different layouts (one for each form). On creating your Activity, check each common field for a previously stored value and populate that field if one exists. Trying to do something like the first list, while maybe clever, would hardly be ideal.
I think it would make more sense to just develop layouts for the different device screens. You can do this, and put different layouts in different folders. Here is a great article that talks about some of this. I wouldn't give people the "option" to choose. They may not always know the answer, so it is best to let the phone decide which layout to use.
Here is the article:
http://developer.android.com/guide/practices/screens_support.html
I have android application that is written "regular" way. layouts, java, APK.
Now, depending on some factors I want data to be presented differently to different users with different preferences, etc. Doing it using XML layouts will be very problematic in couple of reasons:
Upgrade issue - we have bunch of users and they not good at upgrading.
Hard to maintain and code.
So, I'm toying with idea of "templates" where we can serve templates from server and just use device to generate those.
Web app won't work because our data available offline in case there is no connection.
There is buttons and stuff that user can press to call regular Activities and do things.
I envision something like:
HTML 5 template with {tags} that I will populate from data. I will receive tempaltes and data separately from server. I will merge that data and display on UI.
Now my question is how do I:
Display HTML5 inside Activity
Intercept button push in HTML in my Java code?
Is this bad idea to write something like this?
It sounds reasonable to me. You can use a WebView for displaying the content. Your app can manage a cache of downloaded templates and other content and display it in the web view either from the web site or from the cache if offline.
I think your objections to layouts are offbase. You really might be better off with layouts. Here's why:
Your app can be set to auto-update by users if you do not change permissions. But pushing updates to your app will remain an issue unless your app is entirely web-based. (not a bad approach by the way) But so long as you have a native app, you will need to push updates from time to time.
And as far as being hard to maintain and code, layouts are specifically designed to make this type of customization manageable. You can break pieces of the layout common to different settings into separate files, and add them with includes.
You can use fragments to adapt to a variety of form factors.
You can serve up different layout based on screen size, language, orientation, or any of a wide variety of variables.
Check out some of the series on layout tricks, and get more familiar with being a layout power user. I think in the long run it will save you a lot of effort, assuming you don't switch to making your app a web app instead.
http://android-developers.blogspot.com/2009/02/android-layout-tricks-2-reusing-layouts.html
http://developer.android.com/resources/articles/layout-tricks-merge.html
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
Google: Android Layout Tricks.
Great stuff.
Another benefit: Compiler checking. No broken functionality because a variable or field has the wrong name. Not the case with HTML.
Another benefit: works offline too with no messing around.
And last - you will have a non-trivial amount of work attempting to get this hybrid HTML stuff working the way you want, and then have a very unusual and custom code base that nobody here on Stack Overflow will be able to help you with. Stick with Layouts and there are lots of experts who can help you tackle the stickiest layout puzzles.
I'm working on an app that involves displaying comments from a website. These comments are threaded on the original site, so I'd like to replicate that experience within the app. I know that Android has an ExpandableListView, but it only does two levels and I was hoping for more.
Each top-level content would be aligned to the left. Replies would be indented by x units, replies to the reply would be indented x*2 units, etc.
Additionally, I'd like the ability for the user (or even the application code) to minimize/maximize threads. This would be particularly useful if the first comment has 8724 replies - you could just minimize the original comment instead of scrolling endlessly until you reach the second top-level comment.
What is the best way to present this multi-level list to the user? Are there any native/third-party classes/libraries I can use, or would I be better of coding this list in HTML and displaying that to the user instead?
I don't really think you should use a tree for displaying thread. Device screens are too small for this kind of widget. I would prefer multiple activities for displaying different levels of the thread. But I'm not a UI designer so my opinion may be far from the ideal solution.
EDIT: Here's an open-source tree-view widget: http://code.google.com/p/tree-view-list-android/.