I need some kind of NumberPicker for an App i'm developing, the Problem is: I have the requirement of Api Level 10, and from what the reference says Number Picker was first introduced in 11...
I looked at Date and Time Picker, but both use Numberpickers....
I really am quite new to Android and have no Idea how to create custom widgets, so by looking at the source i don't understand a lot of what is goind on beyond the surface and how those Layouts and Widgets depend on each other.
For now our App uses Spinners, but this is an university project and our professor said he doesn't really like them and would like us to use something similar to a number/date/timepicker...
My Requirements:
First part of my picked "number" is a letter (or more than one, up to a short word) after that two two digit numbers whose range needs to adjust depending on the picked letter.
Any ideas how i could do that better/prettier than by using three spinners and adjusting their arrays (if that is even possible)?
There is a question here on SO describing the same problem for API level 7 (see: How to use NumberPicker in Android app with API 7?). Unfortunately, the situation seems to be the same for api level 10: NumberPicker is not part of the android support library, so you have to look out for backports like this:
https://github.com/SimonVT/android-numberpicker
or write your own implementation.
Related
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html
I have many applications which has great GUI like Any.do, alarm clock from doubletwist etc. I was wondering are ll these applications developed using standard eclipse way using java and xml. I was not able to figure out how can i develop such type of GUI using eclipse xml?
All Android apps with a good UI use java & xml.
The only difference is that good apps need a LOT of work and sometimes a custom implementation of some Android Elements.
xml files catering to the different formfactors is the best way to implement a rich app (in fact I don't think there is any other valid way) :
-They allow you to separate the layouts from the code as much as possible.
-They allow you to treat specific form factors independently.
Additionally, Great apps often re-implements some of the basic UI elements. For exemple the implementation of the actionbar in Flipboard allow them to apply their flipping effect to it, something that you cannot do with the basic ActionBar.
Any.do has just been updated and I have not checked this last version yet, but the last time I tried the app, their implementation was not really good. Buttons were far too cramped in the ActionBar and their custom ActionBar was very slow (more than 1 second to acknowledge a tap).
Additional thoughts : sometimes these beautifully designed apps tend to ignore at least some of the Android conventions. It is a really bad idea : you can create a very beautiful app but if its UI elements are totally different from what users encounters in other Android apps it will just make the overall use of the app confusing. imho the best way to create a great app (both visually & functionally) is to use Holo as a design base that needs to be enriched and do not :
-make something totally opposite to the design conventions of the platform just because you think it is good.
-Use a basic android design block in a totally different way that what it is intended for, it will utterly confuse your users.
-Apply another platform conventions.
-Invent your own rules because "you are strenghtening your brand by having the same design on ios, android and your website". You are just being lazy.
a good starting point is obviously the official design site. android niceties is a good source of inspiration. Holo Everywhere & Android UI UX are very interesting sites in order to get more thoughts on how to improve existing apps.
I'm trying to make a calendar in my app that behaves similar to the default Android calendar app, though simpler. I need it to display an icon (paperclip?) on indicated days. I've been looking at extending CalendarView, but
It only supports >3.0
The main class I'd need to override, WeekView, is private.
I might be able to work around the second point, but I need my application to at least support Froyo. I've looked briefly at others' implementations of CalendarViews, but they're either ugly or... ugly (and I'm not good at making things look good; I mostly rely on widgets that already look pretty).
Thanks!
I want to use a control similar to Swing JSpinner in an Android application. I know that Android has a widget called Spinner, but it's more like a combo box than a JSpinner. I've noticed that DatePicker and TimePicker widgets are using components that are just like JSpinner. The only problem is that I don't really want Date or Time. I just want to get some integer, say from 1 to 50, that user chooses. Is this possible? I've searched Android API reference in and out, but I couldn't find any clue on how to do this. Any help or hint would be much appreciated.
Thanks,
Tomislav
Well, the functionality for the TimePicker is provided by a hidden internal class named NumberPicker, which would probably be exactly what you wanted if only the folks at Google had made it available.
You might want to go to the android source code and lookup the source to android.widget.NumberPicker in the frameworks/base repository. (The repository treats it as if it were a publicly available class, though I see no sign of it in the released dev jars.)
I stole the spinner from Astrid, which stole it from Android's source.
Take a gander here:
http://github.com/ralphleon/TeaTimer/tree/master/src/goo/TeaTimer/widget/
Though my app is GPL, the number picker code is under the permissive Apache license!