Check the compatibility of InputAccessLib with different API levels.

[rishabhjain08]

Check if InputAccessLib is compatible with API level 15 and API level 10.

[rishabhjain08]

@jorgesilva as of API level 11 some new functions have been added to the interface android.view.Window.Callback. This interface has been implemented in the class ca.idi.tecla.lib.InputAccess. Will we have to create 2 seperate libraries, one for API level <=10 and another one for the rest.

[ijdoc]

I have seen the Android SDK implement backward compatibility with older API calls so that devs don't have to create too many versions of the same product. I believe some of this is resolved by removing the override directives from the unsupported calls. Would you mind just making sure this is definitely not possible before we fork the project?

If we do end up forking the project, we will have to get rid of master and make the build for the most recent API the new target of the project.

The way to go about this now is to make this latest change into a different branch (e.g., API_Level_11-15) and another branch for API_Level_5-10, both pulling from devel for now. Would you mind sorting this out @rishabhjain08 ?

[rishabhjain08]

I found a way to make InputAccessLib compatible with both API level 10 and API level 15 using reflection but I had to add an extra package(android.view) to the library folder of the repository. Is that fine??

On Thu, Jun 14, 2012 at 7:22 PM, Jorge Silva < reply@reply.github.com

wrote:

I have seen the Android SDK implement backward compatibility with older API calls so that devs don't have to create too many versions of the same product. I believe some of this is resolved by removing the override directives from the unsupported calls. Would you mind just making sure this is definitely not possible before we fork the project?

If we do end up forking the project, we will have to get rid of master and make the build for the most recent API the new target of the project.

The way to go about this now is to make this latest change into a different branch (e.g., API_Level_11-15) and another branch for API_Level_5-10, both pulling from devel for now. Would you mind sorting this out @rishabhjain08 ?

---

Reply to this email directly or view it on GitHub: https://github.com/idrc/InputAccessLib/issues/12#issuecomment-6328515

[ijdoc]

There was one other instance in which I used reflection and it had unstable results. Is this approach an "oficial" solution to this kind of problem? If not, I think we will have to go for the forked versions of the library.

[rishabhjain08]

I read about the method from this link : http://android-developers.blogspot.in/2009/04/backward-compatibility-for-android.html. Does it count as official? Also I have tried it on emulator and everything is working fine.

On Thu, Jun 14, 2012 at 9:57 PM, Jorge Silva < reply@reply.github.com

wrote:

There was one other instance in which I used reflection and it had unstable results. Is this approach an "oficial" solution to this kind of problem? If not, I think we will have to go for the forked versions of the library.

---

Reply to this email directly or view it on GitHub: https://github.com/idrc/InputAccessLib/issues/12#issuecomment-6333519

[rishabhjain08]

@jorgesilva I have created two different branches in idrc/InputAccessLib as per your suggestion, one for APIs 5-10 and another one for APIs 11-15. I have made changes to the branch APIs 11-15 so that it can be used by devs who are developing for API levels >10. What should now be done? Should I commit code using reflection into devel? The link http://android-developers.blogspot.in/2009/04/backward-compatibility-for-android.html states that if you have used reflection you should test it on all your target devices. I have tested on physical device running Android 2.3 and on emulators running GINGERBREAD and ICE_CREAM_SANDWICH but I don't have access to other physical Android devices. What should I do?

[ijdoc]

@rishabhjain08 I did a bit more research on this and found out there is yet another way to do this, which seems better. It is called lazy loading. You can read about it here: http://android-developers.blogspot.ca/2010/07/how-to-have-your-cupcake-and-eat-it-too.html

Let me know if you think this is likely to be more stable than using reflection. You can "save" your reflection code into a separate branch while you work on lazy loading, which, unless you disagree, seems like a better way to solve the problem.

[rishabhjain08]

I read the blog you referred and some other related Q/A on stack-overflow and tried to code it but I don't think that is helpful in our case. What we need is to call methods on object of android.view.Window.Callback because we are using getCallback() method in the code which returns object of type android.view.Window.Callback(at least when the app runs for the first time, because thereafter we can set our custom Callback) while the method shown at http://android-developers.blogspot.ca/2010/07/how-to-have-your-cupcake-and-eat-it-too.html is helpful if we are creating our own objects but we are not. We have an object of type android.view.Window.Callback and we want to call its methods. Personally, I think reflection has no stability issues. It only needs testing on different devices. I have tested on physical device running Android 2.3 and on emulators running GINGERBREAD and ICE_CREAM_SANDWICH but I don't have access to other physical Android devices.

[ijdoc]

Ok, it seems reflection is the best alternative then, is this the implementation currently in the devel branch? I just tested a level 8 3rd-party app build on GINGERBREAD and it works fine.

[rishabhjain08]

No, the implementation is in the reflection branch. It only needs slight modifications like changing the name of the makeAccessible method(which I am doing right now) rest everything is all right and its ready to be tested.

[rishabhjain08]

I have updated the branch reflection. Its ready to be tested.

[rishabhjain08]

Merged devel with reflection

[ijdoc]

Changed some instances of layout parameters from match_parent to fill_parent to ensure backwards compatibility. The remaining reviews will be done as part of pre-release testing (issue #26)

[rishabhjain08]

Took care of ActionProvider class was introduced with API level 14. Also handled methods introduced to MenuItem interface in later API levels such that the library is also compatible with older versions of android.