I want to share an interface between two applets as client and server with different package AID. I saw the link: [0x6f00 error casting Javacard Shareable Interface
In the above link is said: both client and server have to be in same package.
I have a question now. is it possible client uses server functions if they have different package AID?
Thank you very much.
Client and server don't have to be in the same package! They just both need to depend on the same package, which contains the shared interface.
In the linked question, there was a problem with interfaces: OP declared two interfaces with the same name in two separate packages. That is why casting failed and 6F00 status was thrown.
How to use Shareable interface:
1.Declare your shared interface public in your server-side package:
package com.test.mypackage.a;
public interface SharedObject extends Shareable {
public void foo();
}
2.Use the interface in your client code:
package com.test.mypackage.b;
import com.test.mypackage.a.SharedObject;
...
SharedObject obj = (SharedObject) JCSystem.getAppletShareableInterfaceObject(svrAid, (byte)0);
Use your server applet as a library when building your client applet.
Load your server applet cap file first.
Then load your client applet cap file.
Shareable interface cannot be used for applets in same package.Since it works for applets with different contexts.
Shareable interface is used when one applet(Client Applet) need to access methods from another applet(Server applet) provided both the applets are located in different packages.Applets in different packages are separated by a firewall to prevent access to applet data across package.
Please check this simple implementation for shareable interface it will clear your doubts about its use case.
https://stackoverflow.com/a/57200926/4752262
Related
Is that possible for a javacard applet to download and install another applet?
Is that possible for an applet to send APDUs (information) to another applet?
If so, can anyone lead me to proper documentations to begin?
Is that possible for a javacard applet to download and install another applet?
No, that's not possible, there is simply no API for it. In all the examples from Global Platform - which is probably more relevant than the Java Card specifications - the applet data is loaded through APDU commands. There is an Applet.install method in the Java Card API of course, but it gets called by the system and cannot be used from another applet - not even a security domain, as far as I know.
Is that possible for an applet to send APDUs (information) to another applet?
Yes, you can have one class implement the Shareable interface and share it through the getShareableInterfaceObject method. All Java Card tutorials will include this.
The APDU buffer cannot be shared, but it doesn't need to, you can simply access it through the APDU methods. From the API:
The Java Card runtime environment designates the APDU object as a temporary Java Card runtime environment Entry Point Object (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 6.2.1 for details). A temporary Java Card runtime environment Entry Point Object can be accessed from any applet context. References to these temporary objects cannot be stored in class variables or instance variables or array components.
Please do read tutorials or buy the old but still valid Java Card technology for Smart Cards. It's old, but the core principles are still completely valid, and most other basic things can be learned by studying the API.
I share a Data Transfer Object between an C# Azure Mobile Services server and client. I use the same class in both applications.
The TableController class used by Azure mobile services requires the DTO to inherit from 'EntityData', which in turn implements interface 'ITableData'.
ITable Data lives is part of reference:
Microsoft.WindowsAzure.Mobile.Service.Tables
I have not figured out how to include that reference without installing the entire server-side mobile services package in nuget:
WindowsAzureMobileServices.Backend
That includes OWIN, and many other references the client does not need. This is what I am doing currently. This works for a desktop application I am currently working on, but I think it will not work for universal apps and windows phone apps.
I also looked at microsoft's samples for mobile services, and there they use separate classes as DTOS for server and client.
Is it really the case that we have to write the same code twice?
No, but you could better make use of Shared Projects, and partial classes.
Your Shared Project will have common properties for the entities.
Other projects will reference this Shared one, and can add some other properties to shared entities, still using partial classes.
I have precise experience with AMS, so I know what you are meaning.
In my experience, is anyway not realistic to think to have exactly the same entity classes for client and server.
For instance, in so called Portable Class Libraries you can have a very small subset of framework, and references available.
Other than properties, you normally put attributes on POCO class files. On the client you may have some attributes that aren't available/meaningful for the server (e.g. SQLite attributes), or viceversa. You may can get stuck in this situation also with the shared projects approach I suggest, but it could be managed there with what so called preprocessor directives.
Ok, I am uisng GWTP, it got Client, Server & Shared package.
I have a Util class in client.
my.client.Util.java{
public static String method1();
//more methods here
}
In server i have
my.server.GetDataActionHandler{
///Should I do like this
String s=my.client.Util.method1();
}
Is it safe to do that or I should put Util into shared package, like this
my.shared.Util.java{
public static String method1();
//more methods here
}
What is the different if we put a Util in shared package? is it safer or any other good reasons?
client is as safe as shared, these are just names and conventions.
By placing your class in client though, you lose the indication that you're using it also on the server side, where client-specific code won't run.
By placing it in shared, you're signaling to yourself that you should make sure the code your put in the class can effectively be used in both the client and the server.
Read here about GWT MVP atchitecture
Read more here about GWT Architectural Perspectives
Accessing client side code from server side will become your code tightly coupled. Shared package is used for this purpose but still its not for any UI specific code. Shared packages is used to define some DTO (Data Transfer Object) and Utility classes.
There is no meaning of accessing any GWT UI specific utility classes at server side.
Try to decouple your code in such way if in future you want to use your server side classes for Swing application or any other web application other than GWT then you can easily incorporate it. Think about it.
I have some problems with creating static libraries.
Let say I have the static library A which I created and I included that to static library B with the relevant header files. I need to create a static library C which will be my final library and it it should include static library B which implicitly include the static library A. So I need to hide both implementation details of library A and B in the library C but it should not visible to the end user. Only an interface will be provided.
1) So let say my static library A uses some dependencies which are some libraries in the SDK. So do I need to import in my final project although I included the library C?
At the moment I am having some build issues when I tried above.
2) Can we bundle 3rd party static libraries inside our static libraries and distribute only our library?
3) Let say we are downloading some 3rd party code. Using that we are creating static libraries. Can we distribute a static library using 3rd party code. If so do we need to expose the code?
4) How does the static library acceptance in App store. Is it like the normal process? (I mean projects bundles with static libraries)
Thank you,
Regards,
Dilshan
Wow. Four questions. If only I could get 4x the rep. :)
Yes, you need to include the frameworks in the App's project. Linking a framework in a static library only creates references to symbols that don't exist. These need to be resolved during app link by linking in the frameworks to the final app.
I take it you're thinking about selling an SDK of static lib files and header files. Yes, it is technically possible to link it all into one giant library (see ar(5) for details) and ship the library and select header files, but see answer #3.
Depends on the license for the third-party library. Consult legal counsel if you have questions.
Most apps have a static library linked in to the app. For example, the vast majority of free apps include AdMob or similar advertising packages, which are distributed as a static library. A static library doesn't, per se, violate any Apple submission policy, but the library can violate a policy, such as including undocumented APIs. If the static library violates a submission policy, an app that uses it will be rejected, even if the app doesn't use that feature.
Incidentally, you can't completely "hide" the interfaces of library A and B (from your example.) If you could, Apple would and it would not be possible to use undocumented APIs. All you can really do is leave them out of the headers and documentation.
I accidentally used HashSet and HashMap defined under the package com.google.gwt.dev.util.collect in the client side code. Found out the package does not have a module xml file and hence these collection classes are not meant to be used on the client side.
What is the purpose of having these classes in the GWT SDK, if these aren't supposed to be used within the client package? There definitely has to be some benefit from these classes to merit inclusion in the SDK.
What am I missing?
Those collection implementations were written by Google engineers to improve the performance (specifically memory usage) of the GWT internals, such as the Java-to-JavaScript compiler. They are implementation details not intended to be part of the public API and should not be used by GWT developers.