vlang / vab

V Android Bootstrapper

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Specify more details in README

elimisteve opened this issue · comments

Exciting project!

Questions it'd be great to answer some place, either here or in the README:

  1. Can we do network calls from V in an Android app generated with vab? Last I heard there are extra hoops one must jump through to use the network on Android from a language other than Java or Kotlin, though that was 3 years ago.

  2. Are there any apps in the Play Store right now that were written in V? If so, consider linking to them!

  3. What limitations should we expect right now?

  4. Has anyone built the UI and glue code in Kotlin, and built the rest of the app in V?

Thanks!

  1. Any best practices/recommendations for writing the UI in pure V, or is that not practical yet?
  1. Any best practices/recommendations for writing the UI in pure V, or is that not practical yet?

Try it with
https://github.com/vlang/ui

Exciting project!

Thanks!

Questions it'd be great to answer some place, either here or in the README:

I don't think listing what vab can't do will help more users right now. So for now I'll answer here.
I'm aware that people will expect interop with other big V projects like V UI (and my own JNI support module). The plan is to get 100% interop with all V projects. If it's written in V it should be able to run on Android.
The road can be a little long at some points though due to Android's messy nature.

1. Can we do network calls from V in an Android app generated with vab? Last I heard there are extra hoops one must jump through to use the network on Android from a language other than Java or Kotlin, though that was 3 years ago.

I'm not sure - I haven't tried yet (networking is generally not my thing - so it's low on my current TODO).
I'm pretty sure though that we can get it working no problem.
But there's currently some overlap of essential components in V that need to work better together.

To use some features, like, networking on Android - you need the user's permission first (in some cases, in other cases you can access the feature no problem - "it all depends"). To get the permission from the user you need to implement a UI flow to obtain the permission you need - this flow makes things more difficult for us currently, not impossible, but just consumes precious developer time.

As mentioned, network access is on my TODO so it's a question of when I get time right now.

2. Are there any apps in the Play Store right now that were written in V? If so, consider linking to them!

I only know of one - but it's currently hidden on my personal account. I tried to transfer the rights to Alex but things stalled for some reason - people have on several occasions (Discord mostly) asked to get an official V developer account on Google Play to show these things off. I have no idea how far off we are from having anything setup @medvednikov ? There's plenty of things now to show off IMO.

3. What limitations should we expect right now?

A lot :)
The next "big" thing we should get running is probably garbage collection. Again we have a little way to go.
Currently we're undecided on how to build and distribute the garbage lib on Android.

4. Has anyone built the UI and glue code in Kotlin, and built the rest of the app in V?

Not that I know of. I just know it's possible since it's just a code -> JVM bytecode compiler - it's on my TODO.
Please keep in mind that every time we open up for a new tech-stack we also open the waterfall of user issues that needs to be handled, currently Java is more than enough to fight with.
Currently we don't have much dev resources focusing on Android, maybe that will change at some point, maybe not.

5. Any best practices/recommendations for writing the UI in pure V, or is that not practical yet?

V UI works fine on Android, but it needs a million key-press-love-strokes to get the examples on par with the desktop versions 😄
We're also discussing how to get JNI support to V UI - since we'll (to my only knowledge) need it for some essential parts like soft input handling (better known as "The on-screen keyboard"). The reason is that Android let developers code their own keyboards (thus we have GIF, Smiley, Swipe, Full, 60% etc. -type keyboards) - this freedom means that the soft input, in many cases doesn't emit classic character codes like you'd expect from a PC keyboard - thus the Android maintainers only supply partial support for it via the available C headers - the rest needs help from Java/Kotlin.

Thanks!

No problem!