My server is written in Java (on GAE). It includes some data classes that I share with an Android client, and would now like to also share with a Dart web client.
By 'share' I mean that I serialize them to JSON and use HTTP or GCM to sync them between client and server.
So, I'm looking for a tool that will generate Dart equivalents for the relevant Java classes, so I don't have to create them manually.
Google Cloud Endpoints does this (converts data classes from GAE languages to client languages) but Dart is not currently amongst the support languages.
I guess GCE could be used to generate js, which could then be used in Dart app, but that is not ideal. So I think this is a possible solution but not an adequate one.
The other problem with this is that the code conversion of is tightly bound to the GCE service - it can't be used independently of GCE and the only way to get GCE to convert your classes is to include them in a GCE interface.
(If they added Dart support to GCE, made the code translator more independent of GCE, and added some features such as an #Ignore attribute, I think it would be very useful!)
The "ad-hoc Java-to-Dart translator" was "written in three days" by Stefan Matthias Aust (last revised on 2014-01-03). The author notes that "there might be errors", and that "I didn't cover annotations and some esotheric[sic] generics syntax."
He provides some useful guidelines for keeping your Java code dart friendly:
"Because Dart doesn't support overloading methods, I strongly recommend to first rename (using your favorite IDE) those methods in Java. I also noticed that Dart doesn't like if types, fields, or methods have the same name. Again, I recommend to rename all such occurrences before translating. He also notes that Dart doesn't support a character type.
You can use this package to generate Dart client code for Google Cloud Endpoints http://pub.dartlang.org/packages/discovery_api_client_generator.
I also successfully used Protocol Buffers for a similar scenario
- http://pub.dartlang.org/search?q=protobuf
- http://pub.dartlang.org/packages/protobuf_builder
See also https://developers.google.com/protocol-buffers/
Related
I am developing an Android application with my friend. I am currently responsible for the backend while she is working on the Android part. The backend is developed in Java using Lambda functions running in AWS Amazon Cloud. The frontend and the backend are totally decoupled (Lambda functions are exposed via REST APIs) except for the POJOs used on both sides. POJOs are serialized by the application into JSON when calling an API and deserialized again into POJOs (very same ones) by the backend when handling API requests.
We want to keep POJOs on both sides exactly the same for obvious reasons but we are wondering what the proper way to do it is. We see the following two options:
1) Simply copy code on both sides. This has the disadvantage of changing common code independently which, sooner or later, will lead to a misallignment.
2) Move POJOs out to a separate library and include it as a dependency on both sides. This seems like a more proper way to solve this issue but how do we ensure that both me and my friend know that a POJO has been changed? Let's say I remove one field from a POJO and create a new version of the shared library. I push changes to our repository and then... tell my friend that I made some changes so she should pull them, build the new version and include it in her project?
Is there a different (better) way to address this issue? Currently the backend is built with Maven but I can switch to Gradle if this would help automate things and make our code consistent (Android Studio forces Gradle builds).
I found similar questions of other people but they were either a bit different or remained unanswered:
Sharing POJOs between Android project and java backend project
Sharing one java library between Android and Java backend (gradle)
Sharing code between Java backend and Android app
There are certainly lots of other ways of doing this and better or not; I will leave that to you to consider.
But before going to sharing the POJOs, I ask you to take a step backwards and take a look at your architecture. You have essentially got:
a Java Backend with REST APIs, supporting JSON payload
an Android Application, capable of making REST calls and deserialising the JSON payloads.
If you note, above, the tech stack does not involve POJO on any level.
You see what I mean? POJO is an implementation detail for you and it is not wise to share it among your components.
How about looking into the future where you add more components to your architecture, say:
iOS application
Kotlin support for Android application
Will your inclination to share POJO code still be intact? Perhaps not.
From what I see, you should design and develop for a REST backend and a REST capable client. Thats all. That should be the bottomline.
So with that, coming back to your requirements of sharing the updates between the backend and the client, you can share the JSON schema between the two, instead of sharing the POJOs. And thereafter, employ an automated system (say, a simple script) to generate POJOs in the backend and the client.
This approach can have certain benefits. For instance:
You will be able to share updates now and in the future, as per your requirements.
This makes your modularity (or decoupling) better too because the backend and the client is not bound by the requirements to use POJOs. For instance, you can use Data class if you decide to use Kotlin in your client.
You can use versioned schema for future, for the times where the client cannot keep up with the backend, or the backend needs to update independently.
and more
Adding to the answer above, I would take advantage of the fact that both languages use Java compilers and apis. Whether the front end uses Java or Kotlin, you can call any of these api libraries directly from your code.
One api in particular, Json-B, provides methods for transforming your Java (or Kotlin) objects into Json for transport, then transforming the Json response back into Java/ Kotlin on the other end.
One caveat: I recently heard that at least parts of the javax.* package were scheduled for deprecation. They should work on Java 14 or lower, but if you are planning on updating in the future, this is something that you will want to consider.
For Java versions 9 or newer, you should also read this first. It will save you some time.
EDIT: Json-B is, in fact, disabled by default in newer Java versions (the package is included but 'hidden'), but the last article linked in the paragraph above talks about acceptable workarounds. IMO it is still the preferred option for working with Json in Java.
I'm trying to send logs to Stackdriver and am a little confounded by the option of two dependencies I could use —
The Google Cloud Client Library recommends google-cloud version 0.35.0-alpha
The logging docs recommend I install google-cloud-logging version 1.14.0
Googling around for the LogEntryOperation I would like to use yields a google-api-services-logging version v2-rev577-1.23.0.
Are the underlying communications mechanisms to Google's API different between these?
Which of these is most feature-full, least likely to be deprecated, and maintained going forward? Why are there so many?
Google Cloud ships two kinds of client libraries:
Auto generated libraries that just export the REST API directly. These are called the "Google API Client Libraries". These have the advantage that they cover every API in every language in complete detail.
For Java, these are in com.google.apis. This is what you found searching for LogEntryOperation.
Hand-crafted libraries that aim to be more "natural". These are called the "Google Cloud APIs". These are easier to use and fit in better with how the language is used. However they are available for fewer API/language combinations, and don't always cover 100% of the API.
For Java, these are in com.google.cloud. This is what our docs recommend. google-cloud is simply a convenience package for all of the available libraries, including the logging-specific google-cloud-logging package.
The logging library is a good example of the difference. As the actual REST API exposes a LogEntryOperation resource, the auto-generated API just creates a LogEntryOperation class that blindly copies this.
By contrast, the manually created API has a more concisely named Operation class. In addition, the manually created API provides a better static constructor, a Builder, and names the first() and last() methods more sensibly.
I found some sample code at the HL7 web site for defining the interfaces for their Common Terminology Services. It came with some parameters for using ILDJ to convert the sample code into Java, for easy importing into my app.
Can anyone show me where to find similar code samples for their Patient Administration domain? And for other HL7 domains, such as Care Provision, Scheduling, Medical Records, etc.?
At the HL7 web site, this link, I read about the javaSIG version of the V3 HL7 RIM Java API. So I googled one of the package names and found this link on the HL7 web site. But as I examine the files for the javaSIG demo zip, I found that the class files were all dated 2005, which seems completely obsolete, even though it claims to support v3 of the RIM.
I then found this link for the java version of the Everest tool set, which claims to support v3 of the RIM, but it is primarily Canadian and only has 700 downloads.
Tools like HAPI seem to only support v2 of the RIM, which is increasingly obsolete.
Can anyone show me how to find the code for the Java api, included packages such as org.hl7.rim, in a modern format that is v3 compliant? In particular, I want to make sure that I get the api for classes like Encounter, Act, Patient, etc. along with the other classes in the domains listed above. I need access to the class definition code because I need to create an underlying MySQL database to match the class definitions, and also map my current, non-standardized classes to the HL7 RIM API.
I would like to avoid having to reinvent the wheel by rolling my own Java versions of their interfaces, if possible.
similar code samples are not published in the same way for things other than CTS.
For java:
V2: Use the HAPI/MIRTH
v3: there's the Everest Project
CDA: There's MDHT
FHIR: there's java code provided.
I think you're asking about v3 ("care provision domain").
See also http://www.healthintersections.com.au/?p=2029.
I'm working on a java problem that (at least is trying) to utilize the twitter API, however, it is my first project using any type of API and I am a little confused. What is the benefit of using a java library for the twitter API such as Twitter4J and how would one go about not using one? I'm a little fuzzy on the topic of APIs in general and I'm not finding anything in my searches that really makes it clear how to use one.Do I need to use a Java library or can I do it without one? what are the pros and cons of using one vs not using one. I am relatively new to this and am having some issues. Any help?
First what an API is:
An application programming interface (API) is a particular set of
rules ('code') and specifications that software programs can follow to
communicate with each other. It serves as an interface between
different software programs and facilitates their interaction, similar
to the way the user interface facilitates interaction between humans
and computers. An API can be created for applications, libraries,
operating systems, etc., as a way of defining their "vocabularies" and
resources request conventions (e.g. function-calling conventions). It
may include specifications for routines, data structures, object
classes, and protocols used to communicate between the consumer
program and the implementer program of the API
The use of the Twitter4J API would allow you to easily call commands that do complex operations, such as get tweets as they are coming in. For projects such as this, using an API is best way to go about it as you are also going to be required to get an access key which allows you permission to use the API.
Examples using Twitter4J: http://twitter4j.org/en/code-examples.html
You need to distinguish between an "API" and a "Library"
You NEED the Twitter API: it's the thing that connects twitter to your code. You can use this to send a "post this to my account" command for instance.
You CAN use a library: it helps your code talk to the api, by doing some of the work for you. You can call a function with only a string as parameter, and this function calls the forementioned send-to-twitter API
You can ofcourse say things like that the library has an API, but this would be confusing the situation a bit.
In the end it is quite nice to use the library because it helps you by writing code in your language.
In a Flex / Java app stack using remoting (via BlazeDS), classes to hold data passed back and forth between client and server need to be maintained in both the client (in ActionScript) and server (in Java).
I want a way to maintain theses classes in Java only, and have the corresponding ActionScript value object classes generated by the build process.
Check out the AS3 generator from the Granite Data Services project:
http://www.graniteds.org
If I recall correctly it's an Eclipse plugin which should be quite easy to use. Just remember that if you exclude a property from the ActionScript class that it will still be serialized by Blaze when it's sent back to the Flex client.
XDoclet2 includes an ActionScript plugin that can generate ActionScript classes from Javadoc comments in Java code.
The downside is that it's based on Javadoc rather than Java annotations, and does not appear to be well-documented or very widely used.
There are a couple of free Java to AS3 converters out there of varying quality:
http://osflash.org/projects/j2as3
http://osflash.org/j2as (this one is AS2, but may be OK for your purposes)
I cannot vouch for their quality but they claim to do what you are looking for.
Personally I take the overhead of maintaining the two code bases manually because once the objects settle there is not much to do and it means I don't have complex rules around the rest of the code which is in the objects.
Plus my Java objects all have getters and setters whereas the AS3 equivalents do not, which means the public/private accessors are different in any case.
HTH
If you're going to be doing a Flex RIA app of any degree of sophistication, then you'll probably be implementing the MVC pattern - ala Cairngorm, Mate, or PureMVC.
Take a look at this Flex code generator as it anticipates your use of MVC in the Flex client and generates code suitably to deliver an even higher degree of leverage:
FCG : a Flex Code Generator