Background: I've want my users to select their birth year from a list of birth years.
I'm currently using a spinner with an item resource in XML that creates a long-scrolling drop-down list. I've read posts on using DatePicker but it would require some major modifications that make is somewhat unstable from platform to platform. So my question is:
How best to represent a selectable list of years in a form?
I do not think there is much of best practice available here. What you choose will depend on the feel of your application and how well the method integrates with it.
That said, a simple EditText is likely best - nothing clever required. Consider also setting android:digits="1234567890" on it. Doing so will also display the comfortable numeric keyboard.
I can't say I'm familiar with the andriod user interface but why does it have to be mutually exclusive to either selecting or typing in a year? Cannot you have a textbox with a drop down button next to it to select a year?
For me personally, I'd consider a date picker to be a little extreme unless you are wanting their full DOB in which case you need to be really careful how you do it due to the large variations on date representations throughout the world; in that situation then a date picker would possibly be the most suitable option.
Edit: Just something to note, if you do choose a drop down list, make sure by default you select a suitable year rather than the most recent. You know your users best but it is unlikely that you'll get a 10 year old using your app, and showing 10 items (which would automatically be skipped for 99.99% of the users) on a drop down listbox can be quite a bit of screen real estate on a small device.
Related
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 an idea to let users translate my application to their own languages.
I imagine this in this way:
If application is not translated to user's system language, English version of UI is displayed and user is asked for help in translation (it's obvious)
Next, user is asked for translate some phrases from English to his mother tongue. And asked to check some others translations. (it's a bit of work, but nothing sophisticated)
Hard part of my idea is:
User presses "update translation" and text resources for this application are update to latest editions.
Of course it's possible to make frequent updates, but this approach has some disadvantages:
1. I have to make all of those updates frequently, and not all of users will be happy with it.
2 Even if updates will be done weekly, time from make effort to get results will be too long form most of users, and probably, response will be not as good as it can be.
Have you any idea how to load translations "on-line"?
Android currently doesn't support this. To accomplish what you want, you'd need to insert your own resource handling code to return strings everywhere they are used in your UI. This means you couldn't let the framework load strings itself (for example no use of android:text="#string/something" in your layouts), and calling your own function to retrieve a string that wraps Resources.getString()/getText().
And you'll also need to deal with the fact that resource IDs are not stable and can change with every build of your app.
So you are looking at something quite non-trivial.
I have done some internationalizations using:
launchpad with android2po
getLocalization
I will first check if they have some kind of api. If there is no API, I would check the gettext's java implementation and handle translations with it.
You could cache any of the current user's translations in a file on the SD/storage, and show it to that specific user. Then, when it gets its weekly update, remove the cached file and start again?
I'm looking to make a new type app that when the user open it for the first time it will open up a pop-up menu that contains multiple check boxes that the user can select from and will then save their selections for later use. After the user selects their choices I would like to have a monthly based calender on this same screen that the user can select a date from and based on their selection this will then take them to a separate screen showing the news for that day.
I am fairly new to android app development and this will be my first go at it. I have read several books and websites but cannot seem to find the help I need to produce the code for the above desired functions. Any and all help with this will be much appreciated.
Read these tutorials and you'll be able to create just what you need
Tutorials
Your question is very vague in fact, so I will only suggest a few points to start reading from, that I believe are important.
I think that you will answer any other questions you may have by reading through the developer documents for Android and studying the supplied examples. But don't hesitate to ask another, more specific question if you run into trouble.
tl;dr
Activities (must read!)
Dialogs (you will need these)
Data Storage (also important for the app you describe)
If you're still lost, just get some sample code from the repository and toy with it.
Good luck!
I have a project which will be a portal to book a conference room. It will be a private app that will be run on a cheap tablet and mounted in the conference room. The app will just update a webserver backend.
I would like to implement a UI that is essentially a grid. The day of the week will be on the x axis and the hours on the y axis. If a particular time has already been books a different color will show. To book the room you press on the cell that corresponds to the day and time you would like and asks to confirm this.
I have played around with a grid view and table layout and can't find anything that fits the bill so suggestions are most welcome.
I have not used openGL yet would this be a good opportunity to learn about it?
There are many ways you could accomplish a layout like that. Personally I am a fan of using RelativeLayouts. They usually tend to require a little bit more to get setup looking how you want. But it is far easier down the line if you decide you want to make any non-trivial changes to the layout. openGL would allow you to do this, but I think you are better off using the layouts and views provided already. At the very most maybe you'll want to create your own subclass of View that fits your needs see Creating Custom Views if you want more info on that.
ok so im making a lovely little app for my phone that will let me convert bases. This would make my APCS homework much better and provide me some practical and useful coding experience.
I see lots of questions concerning the time and date pickers but that is not what i am looking for. For example, on iOS, if you press on something that is almost like a dropdown menu you can scroll through the selections and choose which one you want. Any ideas?
How about a spinner?