Modified this awesome soft-keyboard for Andoird 2.1 API Level 7

[GoogleCodeExporter]

hello there,
i found this nice app tonight, but sadly it would not work on my rooted nook 
come with android 2.1. so i modified the source code to suit api level 7. 

there are still some problems, but it did work :D

would you mind to publish this version, for more people could enjoy this 
AWESOME APP?

source code and screen capture can be found in the attachment.

NICE WORK ! THANKS YOU GUYS !!!

Original issue reported on code.google.com by elu...@gmail.com on 20 Jul 2011 at 5:48

Attachments:

• hkeyboard.zip

[GoogleCodeExporter]

Issue 15 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 20 Jul 2011 at 6:02

[GoogleCodeExporter]

Thanks for doing this! I haven't had a chance yet to look at the changes, but 
will check it out.

Can you please describe in more detail what the remaining problems are? I don't 
really want to officially declare support for 2.1 if it has major issues, since 
people tend not to read app descriptions and then loudly rant in 1-star reviews 
about the known issues :-(

An alternatively may be to publish a special build separately from the current.

Original comment by Klaus.We...@gmail.com on 20 Jul 2011 at 6:07

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

i made a mistake, tap the "Configure input methods" button in the main activity 
would NOT lead to a crash. on my nook it crashed cos there was no such kind of 
of setting at all. sorry about it.

tested on emulator of android 2.1, it works fine. 

Original comment by elu...@gmail.com on 24 Jul 2011 at 5:39

[GoogleCodeExporter]

Any chance for a compiled version for Android 2.1? Thank you.

Original comment by sport.pr...@gmail.com on 26 Sep 2011 at 8:56

[GoogleCodeExporter]

to: sport.pr...@gmail.com, 

you may try this file ^_@

Original comment by elu...@gmail.com on 26 Sep 2011 at 1:56

Attachments:

• hkeyboard.apk

[GoogleCodeExporter]

Testing it out as we speak. Thank you very, very much.

Original comment by sport.pr...@gmail.com on 27 Sep 2011 at 10:24

[GoogleCodeExporter]

Tested this release extensively and it works perfectly on my el-cheapo 7" 
Rockchip 2818 tablet. Can we expect a 2.1 port of the latest release? At least 
here, if not on the Market? Thanks everyone for all the great work. Best 
keyboard I ever tried!

Original comment by sport.pr...@gmail.com on 8 Oct 2011 at 8:15

[GoogleCodeExporter]

I still plan to look into it, but haven't had a chance yet to see how 
extensively elulis had to change things to get it working. No promises, but if 
it's easy to do I'll try to set up an alternate build.

Original comment by Klaus.We...@gmail.com on 10 Oct 2011 at 8:42

[GoogleCodeExporter]

Thank you very much :)

Original comment by sport.pr...@gmail.com on 17 Oct 2011 at 10:32

[GoogleCodeExporter]

Issue 134 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 26 Dec 2011 at 6:48

[GoogleCodeExporter]

(replying from Issue 134):

> Sorry, I haven't had time to look into this. Issue 57 has a contributed 
patch, but
> for me the main issue is having to set up a separate build for the platform 
and/or
> making sure there aren't any regressions as a result of integrating it   - 
it's
> already  a bit hairy to keep it compatible for Froyo to ICS :-/

Well, I tried to look thru the bugs, but didn't see this. I guess I didn't 
waste much hacking my own patch though - this is for API level 7, not really a 
patch to look at, but source blob, and it doesn't even contain .hg dir inside, 
so can't be turned into a patch easily (go figure which version it is done 
against).

So, by now I have hackerskeyboard tip working on my 1.6 device and exactly 
trying to make it mergeable and maintainable with the main code, not as a 
separate tree. But IMHO it intersects with Issue 2 in that regard - I for 
example exactly had to force-disable voice support and contacts completion 
(*1), so the next natural step is to provide 2nd binary build which doesn't 
have those permissions at all. 

(*1) Contacts completion could be backported, but I find it a strange theme to 
spend time on - none of my hardware keyboards complete contacts, so I don't 
expect virtual ones either ;-).

The patch is 15Kb now and I hope to fork hg repo here and push it there soon. 
Now that we speak, how would you find following trick:

-        mGestureDetector = new GestureDetector(getContext(), listener, null, 
ignoreMultitouch);
+        if (CompatManager.isApiLevel(8)) {
+            mGestureDetector = new Object() {
+                GestureDetector execute() {
+                    return new GestureDetector(getContext(), listener, null, 
ignoreMultitouch);
+                }
+            }.execute();
+        } else {
+            mGestureDetector = new GestureDetector(getContext(), listener, 
null);
+        }

The background is described here for example 
http://blog.javia.org/android-application-backwards-compatibility/ : for Dalvik 
verifier works on the level of methods, so, for a method to run on API level N 
(e.g. 4), it should contain no code beyond that level, and any code requiring 
higher level should be separated into own methods, which would never run on 
level N. Here, I wrap such code in an anon class, which allows it to be at 
least in-place, but requires some in-place shrink-wrap too. This can be a 
normal method too of course, so would make code a bit more "spaghetti" IMHO. 
(But caveat: that blog talks that proguard may be too smart about anon methods, 
so far I made only debug builds). So, if you have specific preference how to 
handle that, please let me know.

Original comment by pmis...@gmail.com on 26 Dec 2011 at 9:47

[GoogleCodeExporter]

pmiscml, many thanks for looking into it! I'm happy to hear that this has 
potential for solving the no-permissions compatibility issue as well, and a 
single additional build for both purposes would be ideal.

For the conditional API methods, I agree with the general approach, but I think 
it's cleaner to use one-time introspection to check for the existence of 
methods directly and save them for later use if present as a possibly-null 
Method object, instead if indirectly inferring presence from the API level, 
since it works reliably even if a 3rd party vendor did unusual things to the 
source tree. See the LatinKeyboardBaseView changes in revision 984825feded0 for 
an example:

http://code.google.com/p/hackerskeyboard/source/detail?spec=svn1f9494d6411f34383
483f03ab4084daaf81cd3d1&r=984825feded0fd609cfa5cdab366da6115fa1372

Feel free to email me preliminary patches or use the code review feature if you 
have your own cloned tree if you want more early feedback.

Original comment by Klaus.We...@gmail.com on 26 Dec 2011 at 6:19

[GoogleCodeExporter]

Original comment by Klaus.We...@gmail.com on 26 Dec 2011 at 6:20

• Changed state: Started

[GoogleCodeExporter]

> I think it's cleaner to use one-time introspection to check for the existence 
of methods directly and save them for later use if present as a possibly-null 
Method object

Unfortunately, that gets very, very verbose. I just tried to code that for 
java.text.Normalizer, which as a class is not avalable for API<9, and it gets 
very boring to forName, then fish for a method and Normalizer.Form constant, 
and I'm not sure if I'd need to query Normalizer.Form type dynamically too. So, 
I give up ;-). I use such "duck typing" when makes sense (== 1 line of code, as 
with checking API level).

Original comment by pmis...@gmail.com on 27 Dec 2011 at 12:31

[GoogleCodeExporter]

Happy New Year! As usual, cleaning up stuff took more time than hacking it ;-). 
I pushed it to 
https://code.google.com/r/pmiscml-hackerskeyboard/source/browse/?name=android-1.
6 , and hope it would as easy to fetch and maybe even merge as with git. But 
just in case, integral patch is attached.

Original comment by pmis...@gmail.com on 3 Jan 2012 at 7:56

Attachments:

• hackerskeyboard-android-1.5.patch

[GoogleCodeExporter]

Hi,
I would like to thank you for your port of hacker's keyboard to android 2.1. I 
am using it on my Nook Simple Touch, seems to be the best keyboard for nook.
You can find a related thread here 
http://forum.xda-developers.com/showthread.php?t=1339199

I have filed new RFE issue 140 for light skin that would be more friendly for 
e-ink display. I am sorry for off-topic in this thread but I would like these 
features in the 2.1 compatible version (only option for Nook STR).

Thanks again to all developers of this app.

Original comment by srot.ka...@gmail.com on 4 Jan 2012 at 8:41

[GoogleCodeExporter]

Thank you very much for the patch, and sorry about the late reply. I'm 
currently trying to stabilize and test the current release so that I can get a 
Market release out, then I'll tackle the more invasive changes for the new 
release including your changes.

Original comment by Klaus.We...@gmail.com on 8 Jan 2012 at 3:43

[GoogleCodeExporter]

Just curious about this on Nook Simple touch,  When installed the app does not 
install to system apps and so cannot be chosen as a input option. it is not in 
the list.  Have not been able to find any way to move it to that location.  I 
have the version 1021 posted above.  Thanks

Original comment by cfd...@gmail.com on 8 Jan 2012 at 7:00

[GoogleCodeExporter]

pmiscml, just wanted to let you know I haven't forgotten about your patch. I'm 
planning on a bugfix update for the current Market version soon based on the 
current release candidate, and then I'll import it. I'm planning on some 
changes, mainly moving some of the conditional version checks to happen one 
time only in wrapper compat classes instead of repeatedly at runtime. Something 
like the reflection-free examples in 
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-
it-too.html . If you have time to take a shot at that I'd appreciate it, but if 
not I'll tackle it in a bit.

cfdamm, I don't own a Nook, and generally I'd consider it out of scope to get 
it running on nonstandard Android devices that don't support normal package 
installation for input methods. Apparently these devices need to be rooted and 
manually reconfigured to get alternate keyboards working.

Original comment by Klaus.We...@gmail.com on 26 Jan 2012 at 3:53

[GoogleCodeExporter]

I am trying to install the keyboard on my Nook Simple Touch - I downloaded 
hkeyboard.apk from the link above, and installed in /system/app . It works 
great, but I can not set a different language. From the main menu I clicked on 
"Hacker's Keyboard", and then when I click on "Configure input method" it 
terminates (and exits to the main menu). When I click on "Get dictionaries", it 
says "There are no matches in Android Market for search: pub: "Klaus Weidner"

This is the best keyboard I have seen (it works great on my Nook Color), I 
really hope I can type in Russian with it on my Nook Simple Touch somehow. 
Please help.

Original comment by mtsiv...@gmail.com on 28 Jan 2012 at 2:05

[GoogleCodeExporter]

Sorry for offtopic, I just want to answer those questions related to Nook STR.

@$cfd...@gmail.com:
To install this (or any other) keyboard on Nook STR you have to move the apk 
file from /data/app to /system/app and then use e.g. Nook Color Tools to choose 
different keyboard. Maybe also "Set current input method" from Hacker's 
keyboard app menu is an alternative.

@mtsiv...@gmail.com
Configure input method is really crashing but I was able to select my language 
other way. Once the Hacker's keyboard is your default keyboard, run any app 
that let's you enter the text. When the Hacker's keyboard pops up, touch the 
"settings" key (right between the Esc and Alt keys) and choose "Settings for 
Hacker's keyboard". Down in the menu there is an item "Input languages" that 
let's you select your favourite languages.
Can't help with dictionaries though, I am not using prediction at all. 

Klaus, thanks a lot for working on this. I am looking forward to new version 
with theming support.

Original comment by srot.ka...@gmail.com on 1 Feb 2012 at 8:25

[GoogleCodeExporter]

@ Klaus: thanks for keeping the patch in mind, and good plan. As for myself, 
past holidays, I'm again dragged into work and other stuff, so not sure if I 
could look into this soon. Plus, it all depends, which approach to use (and I 
believe I cached any checks happening in loops, direct reflection checks happen 
only for once-off code). So, I guess, you, as the author, would have better 
idea how to do it right. My idea was to just prove it can be made to work on 
1.5+, and abstract compat lib at least somewhat, so it could be reused for 
other projects.

Original comment by pmis...@gmail.com on 2 Feb 2012 at 12:41