Android Question How to convert java in b4a

[Pantelis Loizou]

Hi to everyone

i need to convert the attach class to b4a. what it best solution to do that? I need to develop integration with pos payments. thanks in advanced

#AdditionalJar: vas-v1.2.2-debug.aar
    #AdditionalJar: util-v1.0.1.aar

 

[drgottjr]

the .zip files are your .aar's. change the suffix to .aar and save them in your additional libraries folder.

the .txt files are your java classes. change the suffix to .java and see if you can
build them with SLC (simple library compiler). technically, at that point, you
would have a library (actually, mulitple libraries unless you built them all together).

if you haven't used SLC before, there's a tutorial to get you started.

after a quick look, i think there are missing dependencies. you won't know until
you start to build. fix each error as it interrupts compiling and start over. at some
point you will have a nice .jar or you will have given up. (you'll also need to
include the .aar's in the libs folder of your library to resolve dependencies. the tutorial mentions this).

i haven't mentioned wrapping. that's another, more involved, option.

after you have your library, i assume you'll know how to use it, that is, how
all the steps in a pos transaction fit together.

 

[Pantelis Loizou]

Thanks for your reply. unfortunately i cannot compile them with SLC.

what is the best way to access aar files. (JavaObejct or Inline Java Code)?

is it better to ask the developer to build this as library?

 

[DonManfred]

i cannot compile them with SLC

You can NOT compile any JAR or AAR with SLC. Only JAVA-files.

That said you need to write a wrapper in Java, compile that with SLC and use the compiled library then.

Alternatively you can use JavaObject.

Accessing third party Jar with #Additionaljar and JavaObject - Picasso

The #AdditionalJar module attribute (introduced in B4A v3.80) allows us to reference external jars. With the help of JavaObject it is now possible to integrate third party jars without a wrapper. This solution is good for "simple" libraries. If the API is complicated with many interfaces then...

www.b4x.com

Both variants require some java-knowledge.

 

[MicroDrie]

I think that the file util-v1.0.1.zip is similar to an Android studio project. Both zip files do not contain a jar file that you can use to create a wrapper so that a B4X program can use the payment function(s) via a wrapper.
You may have the source code, but I can't see where you can find the Java source files of the necessary imports:

import com.arke.vas.IVASInterface;
import com.arke.vas.IVASListener;
import com.arke.vas.data.VASPayload;

These files are included as class files in the vas-v1.2.2-debug.zip file, along with a bunch of other classes. In addition to the question of whether all required classes are present, the question is whether those classes correspond to the current release version. Perhaps (if all classes are present) you could try creating a classpath reference to all those files in Eclipse and compiling them into a usable B4X jar file. I think it's too complex for SLC.

What I do wonder is how often and how quickly a new release with bug fixes, improvement(s) and new functionalities should be delivered. Because then you have to go through the same complex development process every time. If you cannot do this yourself, you should use an external person for this and have the solution used properly documented so that in the event of a subsequent adjustment, another person can also understand how the solution works in order to make the necessary adjustments. You have to ask yourself whether you can realize all this for financial payments, which must be indispensable and always executed without errors.

I would advise you to first think carefully and consult with an experienced Java programmer with experience in Eclipse as to what else is needed and how you could possibly achieve this.

 

[Pantelis Loizou]

Thank you guys for your replies. i didn't manage to implement it to my B4A App. due a limited knowledge in java language is there any example similar to my solution?

 

[Pantelis Loizou]

This is the documentation

 

[MicroDrie]

I need to develop integration with pos payments.

It may be possible to integrate your existing B4X program with Android Studio as described in B4A IDE + Android Studio = Synergistic Ecosystem.

 

[drgottjr]

the purpose of my interest was to build a library with slc, which
is what i thought could be done from initial post. as little time
as possible was spent bulletproofing. variables were declared
and assigned simply with a view to silence the compile and to make
things work. they would be handled differently in a production environment.

the classes in the .aars can be extracted and converted to a jar.
with that in hand, i can build a "library" with slc.
in other words, all dependencies and references which appeared
in the posted files were resolved.

i had to turn the various transaction methods into "dummy" routines,
that is, simply emitting logging messages. this is due to the fact
that any app created for this system must be deployed on a
specific ingenico terminal (as described in the documentation).

the terminal is an actual android device. think of the payment system
as a gps or camera on your android device. with intents and listeners
you can access the hardware from your app and receive data back.
with this sytem, your app communicates with the payment system on
the same device. without the terminal there is no way to test anything.

but it does appear possible to "go through the motions", that is:
initialiaze the system, set up listeners (to button clicks), override
methods as required and to receive responses. all of this, while
somewhat tedious, was not terribly difficult. but there is no way to
know what would happen when deploying a b4a app that used the
library or an additional jar to the terminal.

the files posted by op are basically a complete project meant to be built
using android studio. if someone followed the outline in the activity
posted, a b4a app could be built. to access the system, a java
object could be used with the jar i extracted. or the transaction
methods called in the activity could be wrapped in a library as i
did - more or less - with slc. the .jar is already made, so it could be
used by slc to resolve dependencies.

so, i'm included arke.zip (the runnable project), arke.jar (which are
the classes), gvas.jar and gvas.xml (the library and xml)

if the app were deployed on the terminal, it might well initialize the
payment system. from there, i think the rest would not be difficult
since the terminal and the payment software handle the dirty work.
the app is just along for the ride.