Question: Right now, this is named sl4acompat. Should be renamed to sl4a or sl4asomething and reserve sl4acompat to the pyjnius version of a same-API future module?

sl4acompat is a good name. Don't put the sl4a related files by default in src, but copy it in the dist if the recipe is used. Then even you have the .java files only if you want it.

@tito: thanks for the comments! I knew that its far from perfect, but needed a working PoC to grab "stop now" or "keep going" feedback. I will take this as a "keep going, we will merge when cleaned a bit more".

Can you please take a look at #189 and #192, as the Python part of the contributed recipe will need this ones to work?

Just to reinforce, I believe that every things should be done with pyjnius. In fact, I believe that Plyer should be implemented for android using some module API-compatible with the SL4A API, as this API have tons of usage examples. Than the intermediate compatible layer could be ported to pyjnius in parallel with Plyer development.

Does it makes sense?

We already taken inspiration on SL4A and ... (i don't remember the name, but it has been renamed few years ago, HTML5/js framework), but never put time to plyer (except Ben who did amazing jobs on the notifications).

I would not accept plyer to use the RPC system, but implementing plyer interface with sl4a inspiration, yes. For the new object that need an API, take time to learn about others platform, and see if the API proposed by SL4A would fit, or if it needs to be adapted. Then do an API, and implement it :)

It's not hard really, just time is needed to do proper things / stable API

I understand. Nobody likes the RPC system, as it sucks. My problem on this is that I need to do some PoC to get resources to reimplement The Right Way. I mean time and people willing to help "clean" the mess. But some people only step up after seeing a PoC :/

Anyway, I totally understand on not allowing Plyer to be built over some RPC system, even temporarily.

Hum... I think that maybe I was not that clear on my (lack of) vision: I see a good model on having:

For the PoC world: Plyer -> SL4A API -> RPC -> SL4A Service -> Java (you having the right to dislike and not merge it)
For the porting "contest": Plyer -> SL4A API -> raise NotImplementedError()
For the ideal world: Plyer -> SL4A API -> pyjnius -> java

This way I can keep compatibility with existing codes/examples on the future, and ideally would have two teams/taskforces: one working on Plyer, and assuming that the underlining API works, and another working on the port to pyjnius.

The main reason is that I see real value on the pyjnius-based compatibility layer, but its just my opinion :)

After a night's sleep, i think that despite my personal opinion, it would be bad to your contribution. The "behind the hood" is our issue, not the user issue. If you are motivated, then maybe i can motivate people to write too, and we might be able to do the ideal at the same time.

For example: i can add you directly on the plyer project. We create a branch, and start to create only the API that sl4a have and we don't have. Only after, i'm 200% that some API are so simple that pyjnius usage will be straightforward. For the one that are not obvious, use the sl4a RPC approach.

Then, in the plyer documentation, indicate that if you want to have all the features, enable sl4acompat recipe in python-for-android. After a while, when it will not be needed anymore, just remove the requirement.

Does that looks good to you ?

Feel free to join irc.freenode.net on #kivy channel

Looks good. Well... I will work on the kivy-remote-shell service before getting back to this one. Then will architect and start the middle layer. I really believe in having something between Plyer and pyjnius/sl4acompat. What is usually the best time for you to talk on the IRC?

Can we move this to plyer instead?

@trivedigaurav I am not against, but it needs changes on the AndroidManifest.xml

I dont know a way for the recipes to do this kind of additions before the build right now.

@alanjds Would you like to discuss this on IRC?

@trivedigaurav Sure. Tonight after the workday I will log to IRC, ok? If you got there, lets talk. See ya :)

Sure. What timezone would it be though?

On Mon, Jun 2, 2014 at 8:52 AM, Alan Justino da Silva <
notifications@github.com> wrote:

@trivedigaurav https://github.com/trivedigaurav Sure. Tonight after the
workday I will log to IRC, ok? See ya.

—
Reply to this email directly or view it on GitHub
#191 (comment)
.

I am on GMT-3. Will probable get online about 21-22:00 GMT-3, and be there for about two or four hours.

I'll close this PR. Many work has been done later on plyer, we even got this year another GSOC on it. Use plyer instead!

And a big kudo to @alanjds for this work, even if it didn't got merged, this motivated us to go in a better direction faster ^^